Our Blog

where we write about the things we love



ERP - A dream to some...

A nightmare to others.  "When I grow up I want to implement ERP", said no one, ever. I certainly didn't, but having worked with ERP since the 1990s, here are some of my observations.

At their heart ERP implementations are complex and represent some of the most challenging and transformational projects an organisation can undertake. Done right they can add huge value, done wrong and they can be very challenging indeed.  

ERP - A dream to some...

Why are they so hard? The simple reason is the interplay between people, processes, data and technology. The way that these factors play out in every implementation is unique to each company. Understanding this interplay is critical before undertaking your ERP implementation. 

Typical challenges include, but are not limited to:  

Executive sponsorship 

The most important aspect of any ERP project is that this is a business project, enabled by IT. It is not an IT project. If it run as an IT project your likelihood of success is dramatically reduced. The Executive must remain engaged through out the process and contribute to swift resolution of conflicting priorities and organisational roadblocks. This means putting the right governance in place from the beginning and communicate this widely with frequent updates. 

Don't under-estimate how hard you are to do business with 

I once asked a wise CIO what his approved budget was for a large (22,000 user, two continent)  transformational project. He said, "well our implementation partner has estimated $x. But they have no idea how difficult we are to work with, I have built the business case on $2x".

Your business processes are ingrained, often with no real understanding why you do the things that you do. Don't be surprised by the information silos, data duplication, re-work and the use of unstructured tools in the business This is typified with heavy use of excel spreadsheets, macros and databases that pervade, largely to support reporting and reconciliation of everyday business process. This differs with every business, know thyself.  

Business process understanding evolves 

Sometimes business processes thought to be set in stone are re-designed on the fly as and when the users get their hands on the new system. Often this is as much about the different interpretation of stated requirements, as it is driven by increased user understanding of the true nature of the solution. Work through processes early and do not assume because your current system does something a certain way that the new system will do the same. Make sure that you make it real for your key users, tell-them, show-them, let-them early in the requirements gathering and design process to familiarise with new capabilities. And remember: "Good design can't fix broken business models".

Get the right people on board 

Change is hard and your people will react to it differently. Recognise your champions early, empower them. Manage others according to their capability and attitude. I find it useful to describe people in four broad categories: 

  • Willing and able – find these people early, they are your solution owners and key users. They will champion the new solution, resolve problems, refine and streamline processes, challenge the project team to deliver more value. They see this change as an opportunity.  
  • Willing but not able – keen doers, but recognise the limited capability, allow them to contribute as they can, but we careful not to burden them with overly complex or critical-path activities. 
  • Not willing, but able – these folk are very dangerous indeed. Identify them early, they are sometimes easy to spot, sometimes not. Typically, they are highly critical and find fault every step of the way. In the worst cases they will act as if they are supportive, but deliberately withhold critical information, knowing it will add significant challenge later down the line. If you cannot motivate these people to demonstrate support for the project, marginalise them.  
  • Neither willing nor able – For these people keep the communication open, take them on the journey, make them feel involved without taking any direct action. 

Resource availability  

Implementing an ERP solution is not a part-time job. To be successful requires your brightest and best. These are the go-to-people in your organisation. They have the deepest domain knowledge about their function and why they do what they do, how it impacts other functions and how other functions impact them. Assign them part-time at your peril.  

Usability and user training 

It amazes me how this seems to slip through the cracks in so many projects. Arguably one of the most important aspects of any system implementation is that your people use it. Design your new system with your users in mind, plan and stick to your training schedule. Do not shortcut either.  

Unanticipated delays in data conversion 

Understand you data, where it comes from, other systems and spreadsheets, how clean it is, where the gaps are, recognise that the data will need to be extracted, cleansed, transformed, mapped, loaded and reconciled. Data conversion is a skill and should be undertaken by people that really understand how it supports your business. It is an iterative process and rarely completes at a first pass. Plan at least two trial cutovers and you will probably need more. 

Testing is delayed due to user or system readiness  

Often it is not until user acceptance testing that usability, new requirements, bugs, unexpected features and re-testing are identified. The corrective action required at this late stage can lead to significant pressure on the planned go live schedule. One approach that I have seen work here is to run a conference room pilot at the conclusion of the design phase. Done right this should flush out many of those unstated requirements early, as well as engaging end users and their managers early to get that all important 'buy-in' to change. This will reduce the cost of change.  

Delays can and do occur 

They are exacerbated by holidays, busy periods and activities that can take longer than expected. In reality this means that a two week schedule shift means a one month actual delay. Plan and manage this, but also set expectations around managing this scheduling risk early.  

Artificial Go-Live date  

Missed deadlines and delays inevitably mean that project team pressure grows, documentation tasks are cut short or eliminated completely as are handovers to support. This risk is often under-stated on projects. It often results in promised capability being pushed into future phases. Be prepared to move Go-Live if it means that you get more value.  



You can find Simon Rhodes on LinkedIn.

Posted by: Simon Rhodes, Client Director, Dunedin | 23 March 2017

Tags: ERP, enterprise resource planning, Enterprise Resource Management

Related blog posts

Blog archive

Stay up to date with all insights from the Intergen blog