3 Strategies to Improve the ERP Global Template
I once had an old Italian neighbour. “La Nona” spoke in a mixture of Italian and Venezuelan Spanish that never got perfected because she didn’t need to. Most people understood her.
Both languages were close enough to guess what she wanted, even if the communication was not great.
It wasn’t perfect, but it worked.
The global ERP template – or the business template if the company is not international – is the combination of business processes, system configuration and custom enhancements implemented. It is what users can get from the ERP system.
The template is born out of the initial implementation crucible, a very costly and sometimes traumatic experience.
Since defining the template had a high – but sunken – cost, some companies see it as a valuable asset that needs to be protected.
Top management in those companies also see the template as a finished product, the outcome of extensive discussion between knowledgeable people that shouldn’t need further tweaking. Based on that view, change is suppressed with burdensome procedures and approval hurdles.
In reality, a template is an imperfect attempt to align business and system in a short time. An uphill race for consultants to understand the business while users try to understand the ERP product.
I have never seen a template that has not been born prematurely.
Like my neighbour’s language, the template “works” but has not reached its full potential. Many gaps remain between what the business needs and what the system can provide. There is little incentive to improve while business needs keep continually changing.
Other companies see the true nature of the template as a work in process, a starting point from where to build a robust and innovative integrated system.
Here are some of the most effective strategies I have seen in companies with strong templates.
Let it Go, Let it Go
Let the template evolve, not just by allowing change, but actively promoting it.
Without an initiative to improve the template, supported at the highest levels, the IT internal or outsourced team in charge of maintaining the template, will not risk it. The tendency will be to correct bugs to keep it running without changing anything meaningful.
I do not blame them because changing the template is risky. It requires doing it the right way and testing it to exhaustion before releasing it to the production environment. If management doesn’t promote change, introducing a modification with a negative business impact can get you fired.
Horror stories of changes to the template that have gone wrong are used to support a policy of “don’t fix it if it’s not broken”. Most of these cases happen when analysts push to production modifications half-thought and poorly tested. Changing the template is not free of risks (doing business is always risky), but risks can be managed, and the potential benefits are worth it.
Not changing also has dangers, like the cost of lower productivity or losing market share because the template is holding the organization back.
Take the Template to the Genba
Another effective action is to get the template to the place where things happen.
Integrated systems, by their nature, draw activities to the centre. There is a big incentive for companies to centralize, reducing headcount while maintaining operations running. A much smaller team of production planners can handle the work of a former army of local planners.
The quality of the work suffers in this process not only because the workload increases for the survivors but also because they move out of reach of critical decision-making information. A central planner works with fewer facts than the ones available to a local planner with an ear on the ground.
The distance to the centre also obstruct the flow of good ideas. An improvement to the template conceived by a local production manager may never reach the ivory tower where the global template resides. In many cases, the manager will find much less frustrating to design a local solution outside the system, usually a combination of extracting data or copy-pasting to an Excel-based tool.
Incorporating locally born improvements into the central template will benefit the whole organization.
I believe that a very effective way to get these changes into the template is to send analysts and developers to the shop floor. Periodic stays in local plants will allow them to understand better the pains of the users and make their own any workaround solutions to the system shortcomings. Using a continuous improvement coach to moderate the interaction can produce better results in a shorter time.
Make it Optional
I’m not suggesting that users should do whatever they fancy. But a global template also tends to be monolithic, forcing all regions to conform to the same level of system complexity.
In reality, different plants will have different levels of sophistication in their internal procedures or external requirements.
In those cases, the template could have two or more system options. A plant could them decide the option that better fits its current level. The plant can then move to the next level when the internal processes and user training allow a more complex way of working.
Maintaining multiple options is a lot of work for the IT team, but a company should never subordinate the making money departments to the inconvenience of the ERP support team.
There are many other tactics to keep a template adapting and innovating. They all spring from the realization that the global template is just the starting point of a neverending journey.