9 posts tagged “erp implementation”

Q. What turns old, underused, disliked ERP software into the best ERP package ever written?

 A. New ERP software.

I’ve implemented ERP into dozens of businesses over hundreds of sites. I’ve also picked up and tried to fix problem implementations which have come to me by way of acquisition. The one thing that I have witnessed over the years is however much the users disliked their old system and criticised it during the selection of the new ERP, they soon would be lauding its use-ability and proficiency once they were in the process of going live with a new system.

You may often hear that the old system did this in such a way or that you can’t find information on the new system like you can on the old one – a series of complaints that undermine confidence in the new system and can quickly send users scurrying to the old ERP to look for data.

Why does this happen? I’d like to suggest a few reasons – some which are easy to address (in theory) and some that is about preparing your team of users for the new world of their new ERP.

Firstly, no matter how much training that you do it is likely to not be enough! But you must try…

Secondly, the training should not only cover the easy day to day stuff but must include some of the most frequent infrequent events…. What? By this I mean the users will soon become familiar with the regular tasks such as entering orders if there is a high volume. The challenge is ensuring that you identify the events that are not everyday occurrences such as sales returns or the process surrounding mis-delivery.  If you can prepare the users and give them confidence in how they will deal with the infrequent events then they will not complain that they have to rely on a key member of the project team or even a consultant to do in the new system what they could easily do their old one.

 An important thing is ensuring that people understand the overall business process that is being catered for in the software. When people understand the impact of errors on other departments and their colleagues’ workload they are more likely to take additional care when they understand ….

Finally do remember that when people are facing change they do get very nervous. The chances are that they have been using their old system for a number of years and they are very likely experts in that system. It gives them some security (whether real or imagined) about their importance to the company and increases their self esteem. By giving them the new ERP they may suddenly feel very vulnerable and worry that if they can’t master the new system they may be at risk of losing their jobs. Some reassuring words when they ask for the umpteenth time how to complete a form or print a report can certainly help sooth frazzled nerves.

One idea is to give each person in the department a particular responsibility to learn a single ‘infrequent’ process and be master of it. This will address two issues at once. First you will have an expert that colleagues can turn to when such an event occurs and two, you will make each person feel that they have key knowledge that makes them important to the success of the implementation.

Then maybe the new ERP may be the best system they’ve ever used...

In some ERP implementations the company will build an internal team taken from different parts of the business to review and build the business processes for the ‘to-be’ model. For my thoughts on getting the right team see my paper ‘Simply the Best (ERP Project Team Members)’.

Often the people drawn into the project team will take specific responsibility for different areas of the business. For example someone will take care of Sales, reviewing and designing the appropriate sales order processes, sales contract set up use, commissions and rebates etc. Another person will be responsible for warehousing whilst someone will understand and design the use for product configuration.

The approach will be for these people to undertake training in the ERP product and they will then design, with the knowledge they have gained, the best business processes to suit the business.

Whilst they will have had to gain an insight as to how the entire business system works and will have an appreciation of how their areas of responsibility interacts with that of their colleagues it is vitally important that they are not allowed to continue without reference to the work their colleagues are undertaking. Why do I say this?

Well, I have seen on a number of projects where I have been brought in to review progress, the following issue: Good modern ERP systems have multiple parameters that allow for many different ways of doing business. These will cover engineer to order, make to order, make to stock and a number of other business topologies – each with their own nuances.  Some business types will and can make good use of more than one of these and this is where the challenge can potentially lie.

In one example I came across there was a mis-match  between business processes designed by different people which meant that the overall process wouldn’t work. This example was because the product design and configuration was based around project type customised items whilst the production planning and warehouse management processes were based purely around an anonymous product philosophy. Unfortunately, this wasn’t discovered until after several months work had been undertaken by the team members.

This is why I recommend the appointment of a BPD Tsar on such projects (BPD = Business Process Design). This doesn’t have to be a formal role but it is someone, either internally or externally, that ensures that the business process works from end to end, and in the event of dispute between the functional area experts, has the final say in how the business process will look. Clearly this person should have a full appreciation of how the business works and should be able to overlay this on the functionality of the business system.

Sometimes this can be the project manager but typically it is not.

However, it is an important responsibility and it can save you months of wasted effort.  

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.

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.

In my early days of being involved in ERP implementation projects I witnessed a phenomenon that I later dubbed ‘Wobbly Wednesday’.

This was normally the day, often a week and a half after go-live of the new business system, when the ‘negatives’ and impact of the go-live reached a crescendo and the senior management sat down and seriously considered ‘pulling’ the project and returning to the old legacy system.

And it would normally all start so well. Go-lives are typically scheduled for a Monday so data migration and manual order entry can be completed over the weekend. Monday comes and goes and the users have been so nervous about the system they are surprised it all went so smoothly. Tuesday sees another ‘good’ day and the project team, who stayed late on Monday night getting things right for the Tuesday morning, actually get to go back home. Sometime later in the week the team get together and possibly drink to the success of the project. And then the wheels used to begin to fall off. In those first days all that was dealt with was the basic transactions – more difficult ones would be handled by the project team or consultants. As the week wore on users became more nervous and confused and started to make mistakes. They’d also begin to complain. A delivery would be missed. The wrong product would be made. And the ‘management; would hear and call a crisis meeting. They would honestly consider backing out of the project. This typically happened on the second Wednesday after go live hence me giving it the moniker; Wobbly Wednesday (though I guess I would come up with another alliteration had it been another day of the week).

Fortunately, these days, I don’t witness wobbly Wednesdays anymore. Our detailed planning and preparation for go-live of new ERP systems ensures that everyone has the training and knowledge to be effective from day one. Also, keeping clear communications with the project sponsors, and senior management, means that there are no surprises and no ‘wobbles’.

An important part of our projects here at Neustro, when implementing ERP such as Microsoft Dynamics AX 2009, is a focus on communications. Internal channels to the stakeholders within a business and external communication to customers and suppliers.

For this blog I’d like to talk about internal communications. Regardless of the size of your project it is good to get a communication plan in place and to ensure that it is appropriate, viable and sustainable. In kick-off communications try to ensure that you explain the purpose of the project without using too much jargon. Also make sure that the importance of the ERP project is put across well – yes it can change the way you do business and it can be challenging. But don’t fall into hyperbole and over-blow the projects importance. The business still has to run and serve its customers today: that’s the most important thing.

Try and ensure that the communication plan is sensible in terms of your ability to deliver it – don’t let it consume too much valuable time or resources. Even though it’s marketing, it’s marketing to an internal market, save the money for high quality output for your external audience. The chances are there will be nervousness about the project within the organisation anyway, spending money on perceived ‘showiness’ won’t endear you to your future users.

And finally make sure that it is sustained. As ERP projects continue and everyone is working hard on actually delivering the solution the communication plan can often fall by the wayside. Turning up from the ‘forgotten project’ with a go-live plan only two weeks away will make people more nervous than necessary if they perceive you haven’t been ‘in touch’ with the business for many months.

In ERP implementation projects that are multi-country everyone involved is keen to make the implementation a success – it’s just that different national cultures determine the way that success is achieved. Understanding some basic differences between how different nationalities react to situations can certainly help you overcome barriers to success.

There are four key areas where significant differences in approach can affect your project. Firstly, there is the hierarchical nature of the society. This means that in some societies decision making is a process that can be made quickly because there is little distance between the bosses and the ‘doers’ and decisions made will be supported whereas in some societies there is a strict hierarchy and it is likely you will not have the decision makers in a room.

If you are used to the decision making process in the UK you may find yourself frustrated by the one in Poland – they are very different. The second key trait is how success is viewed within the society. The old saying ‘work to live or live to work’ is important. The French for instance will ensure that the project progresses on a consensual basis wanting to gain agreement from all stakeholders whereas the British will be more inclined to make a decision – right or wrong. Thirdly, how individualistic a nation is can affect the approach to implementation projects. The British tend to be highly individualistic by comparison to, say the Portuguese (excepting Jose Morhinho). So, for instance, relationships will be more important than tasks and this can impact the progress of a project. Finally, avoiding uncertainty and ambiguity is another societal trait that can demonstrate areas of difference to a project approach. The British can live with uncertainty and ambiguity in the hope that things will sort out later whereas Germans are very keen to have all decisions made before progression.

Don’t mistake what I am saying here. There is no ‘better’ approach. Each nation brings many different values to your project but also can impact that project in many ways. If you are involved in multi-national projects and implementations it is wise to gain an understanding of the different cultures involved as it will certainly help you avoid conflict and frustration.