10 Things to take into consideration before installing an ERP System
Depending on whose statistics you read, only between 20 and 40% of ERP projects are thought of as successful, with the rest either considered as challenged or failed. It is therefore useful to consider some of the risks associated with any ERP implementation. Before doing so, it is important to note that Probitas have never had an implementation fail and that we have achieved this by ensuring that both we and the client understand the risks and have taken the necessary steps to mitigate them.
What will be clear from the list below is that the majority of the ERP risks stem from people not technology.
The risks include:
• Lack of Senior Management Support. Without enthusiastic Senior Management support the project will fail. Everyone should be clear that this is not just an IT project. Senior management have to communicate their vision to the whole organization and ensure it is sufficiently funded and resourced.
• No clear vision. All parties should be absolutely clear on the objectives for the project. What are the benefits that are expected to be achieved and how will the organization be transformed?
• Unrealistic expectations. Whatever a sales rep may say, an ERP project requires planning, resources, realism, commitment and determination.
• Lack of resources. The project will make heavy demands on staff, particularly key users. They will have to be relieved of some of their normal duties and, for larger implementations, at various stages some will work on the project full time. A lack of resources will lead to inaccurate requirements, poor testing, lack of training and a disappointing outcome overall.
• Lack of change management. As has been stressed, this will not just be an IT project. At a minimum, it will change people’s job roles, working practices and daily routines. This should be recognized and effectively managed.
• Selecting the wrong partner. Choosing the right partner is more important than choosing the right product. It is people that will make the project happen. Does the partner have a track record of successful implementations? Do they want to take the time to understand your business? Is everything apparently easy or are they realistic about what the project will involve? Do they challenge assumptions and look for improvements that you may not have thought of? Have you met the individuals who will be working on the project and do you get along with them?
• Choosing the right Product. Although having the right partner is essential, having the right product is obviously pretty important too. For example, is the product scalable to meet your future plans, do other companies in your industry use it, how much bespoke work is required, who owns the IP for any new code, does the supplier have a long term roadmap, are you vulnerable to licence price increases?
• Poor project management. A good internal project manager will more than repay their salary. Once the scale of internal resource requirement has been understood, it is clear that project management is not a role for the IT Manager’s part time assistant.
• Balancing standard functionality and competitive advantage. For any industry there will be characteristics that are unique to that industry. On top of those characteristics there will be behaviours that an organization believes give them an advantage over their competitors.
These characteristics and behaviours can be supported by the ERP system. The key is to be absolutely certain which are the important ones. Only ask for bespoke code where changing to the standard process built in to the product would have a negative effect. Bespoke code adds risk, time and cost and can affect the ability to upgrade in the future. Does a particular behaviour actually give you an advantage or is it just “the way we’ve always done it”?
• Poor design. If you have chosen the right partner then you are already on the right path. There are many ways to achieve the same outcome and it is not always easy for the client to determine the quality of the design. Questions to bear in mind include how easily processes meet the design, are they elegant or do they feel like workarounds, do new bespoke processes break the standard ones, can customisations be easily switched off and are developments referenced back to the design?