So... Your organisation has decided that it wants to transform and change their ERP or computer system from whatever it might be now to something different and innovative. Its willing to make the Investment and its raring to go… What could possibly go wrong? Plenty... is the short answer.
In my experience, these types of changes all start off with the right intention, but somehow it all goes pear-shaped as we enter the execution phase. And it doesn’t really matter what ERP tool it is... the failures are not really about the tool, which is interesting and should tell us all something – the constants are the process, and the people. How the tool is adapted or applied, and the Mgmt. of the Change or Gaps is the key piece in all the examples that I have been privy to in my career. More on that later…
I recently was involved in improving an implementation of an ERP in the fulfilment and supply chain part of a very large manufacturing business. The business had been operating close to two years on the platform, and despite the challenges, was making the tool work the best it could. The desire of the organisation was to minimise any bespoke developments and reengineer the processes – sounds reasonable, I guess.
The question is… HOW?
Well, initially this was achieved with a myriad of workarounds in process and a very confused RACI, i.e. Everyone not operating in their lane but operating in somebody else’s lane… and a whole bag of band aids on the processes…What was the current state? Tired people, a very tired business, and a lot of upset customers – both internal and external.
Coming into this was as difficult a situation as it was challenging. The first barrier was understanding what everyone’s challenges were… not surprisingly everyone mostly wanted the same thing… easier to use, more productivity, easier to understand and a better outcome for the customers. Ah yes, the customer it is.
No one disputed “THE WHAT”, but there was a very different view of ”THE HOW”.
What this suggests is that the core work on GAP analysis and HOW the gaps would be managed, is the piece of work that was either missing or glossed over in the planning stages of the project. This is not uncommon and is really what can make or break the change readiness of a project of this scale and magnitude.
There was an ASIS review and a TO BE review – so we can tick those off our task plan… but the vital bit missing was … what changes are we going to make to People (role) or the Process (ways we work) in the absence of the tool automating the business need/requirement.
This is the essence of the Transformation - and it’s not really part of the IT (technical) teams work to enable – it is part of the Business Owners and leaders to land this before they start the move over or whilst the technical build is in play.
That all sounds easy enough… what’s the problem? Well, the issue is Time, Resource and Cost. How do you quantify a benefit that you are planning to have – minimal disruption and maximise adherence to the change, before you have executed the change?
There are many case studies that you can all read about that clearly show that the INVESTMENT in the Front-end loading and GAP readiness pieces , and the projects that do this well, usually have a better implementation and whilst there may be a change impact, the ride down the change curve is not as steep and the stakeholders can generally workout themselves how to get back up the mountain and out of the valley. This is because the TEAMS have already had to collaborate and work out a way forward - this includes roles, process, and how the tool will be used AHEAD of the change. The mindset for the adaptation to change is already being embedded, well ahead of the change implementation.
A few years ago, I had a similar experience on a project of similar scale and difficulty. This time it was in a Distribution business – many sites and geographically spread out.
However, in this business the Change impacts were clearly understood upfront, and two teams ran parallel to the Go live date. One team was building the technical solution, build, scenario testing, master data – these were all facets of making the agreed technical solution work. The other team (some cross over) was performing process map re-design for the future state processes and changes to RACI and role definitions given the changes.
Not surprisingly this Change was well executed and had minimal disruption to the business and or customers. What are the lessons here? Here is my summary:
Whatever the technical costs are for the implementation – take that number and double it for the change effort – especially if the business has not gone through many changes in its recent history. This is difficult for the Investment committees to accept and will increase the cost of the transformation – it will cost this plus some if the change is managed badly.
Make sure that there is REAL RIGIDITY to the change adaption process ahead of or alongside the technical build. Ensure that process maps are done – they are signed off and that they are tested in the new future state landscape. They are no good on a wall or in a drawer if they are not being put into practice.
Training needs to be focused on WHY we do things this way... not HOW... most people these days can follow a video on how to do something; We all use YouTube…but the success lies in getting everyone to understand what will happen if it’s not followed. Allow time for this in the training phase of the change.
Change readiness is crucial – so how do we assess? There are many ways to do this in the various change management methodologies. However, the challenge is to embed and make sure the people are ready. Test their understanding of the process, tool, and the changes in role as part of the UAT of the project. If there is a RED flag call it out.
Resist the urge to hit the deadline if the risks to success are too high. This is a hard one as NO project manager wants to tell the Steering Committee that it’s a No GO. If the change readiness is throwing up red flags and these are known early in the build and planning – there will be more support to ensure that the change stays on track and is successful. DON’T Bury Change and Highlight change issues early in the project lifecycle.
Despite how difficult these types of projects can be, the results are rewarding when they are successful, and there are plenty of successful ones, but no one talks about the successful ones only the failures. Plenty can go wrong and more than likely will, without respecting the need to manage the Human element in change – People.
Kommentare