5 posts tagged “erp project”

I have a number of friends and relatives who, when they ask what I do for a living, I reply “Computers”.  This is a catch all answer that normally elicits one of two responses. Firstly, “Oh, that’s interesting, how are the kids?” and secondly, “I’m looking to buy a computer for home, what do you recommend?”  To avoid getting involved in helping someone make a decision as to which PC to buy I reply that I only deal in enterprise computing and that the starting price is £100k. That normally finishes the conversation off.

In reality I am in the business of helping manufacturing companies achieve greater value through the application of technology. Mainly through the optimisation and deployment of ERP systems and extended functionality such as shop floor data collection, real time manufacturing machine performance management and the application of automated data collection.

Some people persist and demand to know more about what I actually do and it is always entertaining to watch their eyes glaze over by the time I reach the second sentence. I’m not upset. These friends are from other walks of life such as the caring professions or are personal tax advisors or, dare I admit it, from marketing.

However, I do have a good circle of friends that I have met through my work and they completely understand what I am talking about. I have other friends too who work in the manufacturing industry.  Almost all of them have heard the expression ‘ERP’. They’ve either witnessed it directly (some say suffered), or are aware that the company they work for has an ERP system.

It really is quite a shock then to come across companies in manufacturing industry that are of reasonable size that are completely oblivious to what ERP is all about – and to what extent the business may be affected.

A year or so ago I came across a business that had been acquired by a company based in another country. The head office had sent over a computer with a tier 2 software product on it and told them that this was now the corporate standard and that they must implement it.    

I recently had a further conversation. They decided to implement this system by giving it to the IT manager and telling him to get on with it. No plan, no business case, no budget, no buy-in, no project team, no sponsorship – no hope!

I feel like reporting the senior management to the RSPCITP (The Royal Society for the Prevention of Cruelty to Information Technology People). There clearly is no understanding of what ERP is about, how complicated it can be, that it is not like Microsoft Word – install and use. It truly is bizarre.

 Anyway, I am now going over to explain to the senior people within the business all about ERP – It’s great. I should be able to talk about it for hours and people will actually listen. I hope.

I was viewing my blog statistics the other day and I noticed that a previous blog I had written; ‘Simply the best (ERP Project Team members) which related to a paper I had written by the same title had attracted a disproportionate amount of views.

I suppose there could be a number of reasons for this; a technical fault in the view statistics, or maybe quite a lot of people were bored at around the particular time the blog was published, or perhaps it was actually an interesting subject!

 After I wrote the paper and blog I sat down and wrote another piece that was a little more serious in tone. The main drive of article was about how best to keep your project team members happy once you had persuaded them to join the team. 

 Projects by their nature tend to be transitory things and if you are building a project team from within your business then it is likely there will be a lot of questions and uncertainty from some of those people. In my paper I discuss an approach to making sure you get the best people to join your project.

It’s here – take a look and tell me what you think.

I received a phone call from an old colleague a couple of days ago where he was bemoaning the state of an ERP implementation project he was involved in. He despaired at his influence on it, the current cost overrun, the seeming eternity of it, and many other aspects. It was quite a long conversation.

His main gripe, above all the others, was that the project was seriously off the rails yet no one in senior management was prepared to call a halt to it. The mentality was that having spent so much money thus far, it would be a waste of what had been spent, not to spend more to get the project finished - if you understand my meaning.

I was able to offer some comfort only in as far that I could sympathise with his position. In the past I have witnessed some businesses that are looking at a disastrous ERP implementation that still continue because they will not admit they might be wrong. They are afraid of losing face.
In the past I have halted a couple of large projects and taken the decision to implement something else - this has initially been seen as a ‘brave’ (read impetuous) decision to make by my senior management colleagues but I have been proved right in the end.

On both occasions the projects had similar attributes – inadequate budget (someone had not been realistic otherwise the project wouldn’t have been approved), weak leadership and planning, poor senior management sponsorship, the wrong balance between internal an external expertise and the wrong expectations being set within the business.

Why did I choose to implement something else? Let me say that it might not always be the right decision. But on these occasions my investigations revealed that the software selected was not the right fit and had been selected for the wrong reasons. These were variously that the person who had driven the original demand for the new system had used it before at a different company and it was therefore his favourite. Another was that the IT team considered that it would help their career prospects by learning and implementing a particular ERP product – they influenced, inappropriately, the final choice. The major factor though, to my mind, was that the final selection had been made because the sales team and process by the vendor had unduly weighted the decision in their favour. A combination of slick sales techniques and opaque pricing and discount schemes had ensured that they got the deal.

And what typically happens at those businesses that decide to carry on regardless? The people who wouldn’t stop for fear of losing faith ended up losing their jobs instead.

At some point in your ERP project you will need to show the key players in your organisation how you and your project team members expect the system to be configured and how it will work within the business. This simulation will give comfort to the future users and managers that the investment has been worthwhile and that it is going to ‘useable’ within the company.

You will use a subset of your current data from your legacy system and demonstrate the most ‘common’ processes – typically ‘Enquiry to Cash’ and ‘Procure to pay’. You will probably take it in turns as team members to present the parts of the process that you own so you can demonstrate to your constituency, sales, production, etc that you have overlaid your experience onto the new business system.

I believe that it is very important that you treat this as a ‘Sales Presentation’ to your colleagues in the business – by this I mean that you should be very well rehearsed and make sure that what you are gong to present is very ‘slick’. You may think that this is unnecessary to an audience that has no choice about the software that is coming their way but I would contend that you will make the acceptance of what is coming a great deal easier if they fully understand your presentation and feel that it is being managed by a very professional team.

In the past I have seen some dreadful presentations. The most common mistakes are these; disjointed process flows where it is clear that people across the disciplines have not really worked together and therefore present an overall process flow that is inconsistent or just plain doesn’t work.

I’ve also seen the different team members have their own ‘logical company’ with their own data. This requires the presenters to switch between companies. This means there is no consistency in the data – it also means that the audience witness a great deal of ‘flicking’ between screens as companies are changed. This is difficult for the audience to follow and appears to give the impression of too much complexity.

Powerpoint slideshows are really useful to explain what is happening in tandem with the live system. But don’t use it as a replacement – I have seen a team present the entire business model in Powerpoint with screen dumps to show each session from the business system. This didn’t allow for the demonstration of any functionality that wasn’t in the script.

So make sure that you have a proper grasp of what you are going to demonstrate, do it in one logical company, rehearse at least a couple of times, and, if required, polish up your presentation skills.

In one extreme case I have witnessed a project halted because this critical event was so badly presented that the management team lost complete confidence in the team and the product.

What’s the worst, or the best, you have witnessed in a business simulation? Let me know.

If you are British you will probably understand the expression ‘The Full Monty’- it normally refers to not holding back or going as far as possible in a particular activity. There is a British film by the same title that ‘displays’ one interpretation of the term.

If you are in the process forming the business case for your ERP project then certainly consider what I call ‘The Full Monty Approach’. I don’t mean that you should lose your job and resort to taking off your clothes in Midlands’ nightclubs (you need see the film I talked about earlier to prove that I am not rambling or mad) but that you should consider all the elements that will get the very best out of your business system investment.

For instance if you are, as part of your implementation, going to consider a high level of control in your warehousing, to include lots and locations, aging, FIFO etc, then not including a barcoding data collection package will potentially be an action that may seriously damage your project. Your users and managers will appreciate the additional traceability that your new ERP system has but certainly will baulk at the overhead involved in attaining it. Adding barcode data collection will definitely make the implementation easier as well as the day-to-day operational activities of managing materials.

Likewise, if a key aim of the ERP implementation is to give you a real insight as to your labour (or if you are reading this in the USA, labor) costs compared to your standard costs then not investing at the same time in shop floor data collection, that allows for real-time capture of operation and downtime, is cheating you out of the value that could be achieved from your investment in ERP.
I strongly advocate that you make these elements, if you need them, part of your budgeted project costs. Not doing so will lead to disappointment from your people because the system won’t meet their expectations. Furthermore, you will have to go to the board again to ask for more money. Sadly, after spending money on ERP many boards resist spending even modest amounts, even when it shows a good ROI, because they lose confidence in the overall strategy. They will also question why such an obvious and perceived essential requirement was not included in the first place.