How ERP Systems Get in the Way of Continuous Improvement
If you are a production planning professional of a certain age you have witnessed at least 2 revolutions.
The first is the digital revolution. Everybody has.
The second is the production planning revolution of the last few decades. There has been a constant flow of methodologies conceived to improved throughput and reduced waste in the shop floor. Some of the most known approaches originated in Japan, like the Toyota way, JIT and Lean, with many other contributions from all over: TOC, reengineering, smart factories. The progress continues today, the new kid on the block being the Demand Driven Adaptive Enterprise.
Although continuous improvement (Kaizen) was a major part of the Toyota way, it is implicit in all these methodologies and their tools.
Both revolutions have progressed hand in hand. The digital revolution enabling the production revolution, from the 60s when computers become powerful enough to handle all the MRP calculations in a single night run, to the current advances in Factory 4.0 decentralized execution thanks to the IoT.
I was a production manager in my family business when my horizon was widened by Goldratt’s “The Goal”. It not only helped me save the business from a suffocating pile of work in process but also hooked me on production planning methodologies. I have been a nerd all my life (my first computer was a TRS-80) so sometime later I decided to follow a combination of operations and IT and become an SAP logistics consultant. How could someone like me resist the hinted possibilities of something called Advance Planner and Optimizer?
After 20 years of implementing SAP in a production context, I not as naive but still optimistic. I have developed a particular view of how ERP hinders continuous improvement and how to regain the lost opportunities.
The obstacle is not due to technical limitations. In SAP’s case, the product is well established and, in its standard form, can be configured to handle all kinds of production processes. It also includes an enhancement framework that allows modifying the standard behaviour in almost any way imaginable.
In my view, companies impose policies and have structures that make it difficult to use the ERP system for Kaizen support. As with many things in real life, these policies are well intended and prudent but become a problem when they are enforced strictly in all circumstances.
Summoning “best practices” is one of the most vilified consultancy tricks. It allows lazy or unknowledgeable consultants to trump any client request for a different functionality than the one being proposed.
Even when best practices are invoked properly they are based on the premise that if everybody else is working great with the standard approach there is no reason to reinvent the wheel.
However, the goal of continuous improvement is to reinvent the wheel, to make it better and faster. Innovation is by definition making things differently from the past and the rest.
Best practice has a rightful place in more standard non-core processes or that are highly regulated. Accounting, for example, greatly benefits from following best practices. In production best practices are just a good starting point.
Some companies impose an indiscriminate policy of best practice adherence that hurts its production system progress and adaptability.
The Global Template
A global template is a reasonable way to control the use and maintenance of an ERP system in a large organization. It is difficult to support the business if every plant or region uses the system its own way.
Templates are usually the product of a costly and traumatic implementation so the tendency is no to invest much more in them after go-live. Like concrete, the template settles and hardens after the initial implementation and it becomes increasingly difficult to modify it as the system is rolled out to additional plants and countries.
If parts of the organization are already working fine with the template why wouldn’t newly added branches be able to work in the same way? This argument is even used in conglomerates were divisions have radically dissimilar production processes, all in the name of harmonized systems and global financial consolidation.
It is so difficult to justify a change of the template to cover a local requirement that most users cannot be bothered and instead develop additional functionality outside the ERP system. Excel is the preferred choice but it depends on the programming abilities of the user. I have seen developments in all kind of tools and programming languages growing around and interacting with the company template.
Distance to the code
In the past, and still in small organizations, the IT team was quite close to the shop floor. In many cases, the production manager or engineer will be the one implementing or developing local production systems. Even if a software engineer was in charge of the system, the techie will have to walk through the shop floor to get to the production office and in the way will learn about the products and see first hand the processes.
ERP save costs by concentrating IT and programming in a smaller central team. As IT distance from production increased, the interaction became more difficult and the role of the business analyst was created; an intermediary that could translate needs and options between users and programmers.
With this detachment, the times the solution went forwards and backwards between the programmer and the user increased and the delivered speed was substantially reduced. As people got tired of this, they will settle for a suboptimal solution that “works” and stop the process of continually improving it. IT would concentrate on issue resolution.
One can argue that, regardless of the professional and technical level of the configurators and coders, the use of outsourcing and offshoring can amplify the problem just by adding additional layers between the user process the programmer.
Fear of upgrade
“Keep it standard” is another reasonable advice that can be taken to extremes.
It is certainly more difficult to maintain a system that is not standard and it requires additional effort to document it and train new IT personnel on the custom functionality.
One often-quoted reason to avoid custom code is the fear that the changes in the standard that are included in an upgrade would break the custom functionality. In that case, the custom code would need to be modified and SAP will not help to do it.
My personal view is that upgrade testing and the required changes are the cost of a system that has been tailored to the requirement of the business. If done correctly, improvements in productivity and quality are worth the additional difficulties during upgrades.
In my experience, most problems during upgrades are caused by brittle code and bad programming practices. Typically, code put in place in a hurry and no longer touched (refactored) as soon as it works. Good practices and defensive programming can reduce dramatically the problems during upgrades.
There is a lot more to discuss on this subject and I will be expanding on subsequent articles. I believe is not being discussed enough because it goes against the established dogma and the incentives of some stakeholders.
I want to finish on a positive note. Continuous improvement and innovation are possible in an ERP system environment. It is harder than going with the standard but it can be done right and many companies are benefiting already. Continually adapting your processes and systems will leverage the huge investment that an ERP system is.