The following is a guest post by ————-, an expert in ERP and business process currently in the ERP witness protection program. His opinions are his own.
Traditional ERP has served us well but has built-in limitations that make it a dinosaur. I’m not the first person to make that observation. Legacy ERP, just like the PC, started out as a way to provide business processes to customers using the latest technology. But businesses aren’t upgrading their MITS Altair 8800′s. They are starting to realize that they need a completely new ERP solution, too.
First, a little of my history. As an ERP implementer and development manager for the past 14 years, I built my career around upgrades to ERP hardware and applications. Besides doing upgrades, I served my customers by discussing, designing and developing: customizations, bolt-on applications, and features in the next release. Legacy ERP was all I knew and I loved it
I always tried to focus on the customer’s business process and how to improve it, but the day-to-day of ERP held me back. This led to a decision.
Why I gave that up
We’ve all heard the “we are staying vanilla” pronouncements. It doesn’t work because ERP systems are too easy to customize. Customers and implementers are like the kids on the hidden camera show that are first taught what to do when they find a gun. They’re left alone in a room, camera rolling, where they find the hidden gun, promptly break all the rules of gun safety.
While not as dangerous as a gun, customizations fork the delivered software away from the ‘vanilla’ version, requiring a team with deep understanding of application code to maintain the customized system as patches and upgrades arrive. Even ERP-supplied bolt-on functionality requires months of system babysitting to get right. As a consultant, it’s great work if you can get it.
Oh, and that team of people required to dig into the application? They all have access to data with essentially zero audit capability. The solution I employed was database-level security. Vendors have change management products as well but this ads up to even greater complexity that doesn’t solve the underlying problem.
Paraphrasing Forrest Gump, “I’m not an architect…but I know what fast is.” You could insert several different words and it would still work because legacy ERP is a kluge of servers and technologies. It can’t be fast as it is too tied to the past and has become obsolete.
Does that seem unfair? Just one example…the database itself is a traditional relational database that has tens of thousands of tables. This kind of problem isn’t at all hidden from the customer. Hosting a system like this doesn’t hide the problem, either. To qualify as hidden, the applications would run fast and upgrades would happen frequently, automatically, and on schedule.
Where to go instead
Instead of customizing legacy ERP, the enterprise should provide access to ERP applications that allow configuration and integration without customization. New features needed? That should come through conversations with other customers and the vendor. Release cycles? Should be months and not years.
The real payoff? Time spent focused on labor-intensive ERP upgrades can be refocused on refining business processes. That’s where the competition gets beaten.
All Things D
ARS Technica
Engadget
GigaOM
Mashable
TechCrunch
The Verge
Venture Beat
Wired
Chris Brogan
Brian Solis
Chris Dixon
Clay Shirky Blog
HBR Blog
IT Redux
Jeremiah Owyang
Radar O'Reilly
Seth Godin Blog
SocialMedia Today
Solve for Interesting
The TIBCO Blog
Lifehacker
ERP should be seen as a SUPPORTING SERVICE TO PROCESSES ….nothing more
Brian in Sweden
Spot on with “..provide access to ERP applications that allow configuration and integration without customization. New features needed? That should come through conversations with other customers and the vendor.”
The unfortunate reality is the problem is not so much with legacy ERP (these and the vendors who sell these will stay around so long as there are buyers)but rather with legacy customers who fail to assess their current states of affairs (inefficiency, ineffectiveness), define for themselves a new future that includes switching away from legacy ERP and moving forward.
Well stated, Karl. Unfortunately, some of the legacy customers will find that their ERP has the anti-midas touch and turns companies that rely to heavily on their version of technology into dinosaurs as well.
These problems of ERP (high cost, rigidity and long installation & customization periods without any assurance of results) were well known but how did they come into existence and continue to thrive?
Because the problem is so large that only large systems will work. That is also the recipe for disruption.
Jeanne:
AA: That must be true. Not many take on “Large Systems” for experimentation because of cost and complexity.
BB: AA must be true of non-IT systems too. Do they also suffer similar setbacks?
CC: I think that General Systems Theory, OOAD, SOA, Machine Learning, Emergent Systems Principles.. etc., have potential answers. I do not know if they have been applied and evaluated.
DD: In small systems, I have used ” Default, built-in-DEAUTOMATION and MANUAL-OVERRIDE option” for all authorized users to “get on with most business processes” if automation does not work or address the specific cases / conditions.
EE: This allows the business to progress, of course, in a slow manual mode. Human consultation / judgment processes can easily and SAFELY be interleaved since the this is a default design feature.
FF: EE is logged by design and all the interventions can be categorized and logged for bug fixes or modifications or enhancements. This enables less than perfect and non-complete systems to be used SAFELY.
GG I learnt that the approach of DD / EE is used in healthcare systems. I do not know if it is used in ERP Systems but I think it is eminently suitable. IMO this can mitigate some of the problems of ERP till some breakthrough redesign emerges.
[email protected]
26AUG12
To whatever extent anyone can really be declared an “expert” in anything, I suppose I could declare myself an expert in ERP software. My background is more more diverse than many because I spent a good portion of my time in the industry combining my knowledge of BPM with my broad knowledge of many different ERP systems to help companies select the right one.
This has resulted in me having seen dozens of different ERP systems in operation and having fairly detailed awareness of about 100. I’m sure I can speak for some of the many find vendors out there who would say these arguments are “mostly” untrue across the board. I will say that I have yet to come across an ERP system that uses a NOSQL database. Given the highly transactional nature of ERP system functionality, I’m not sure this is such a bad thing.
However, there are two trends that fly in the face of these anonymous claims: 1) many ERP system developers have found ways to allow users to develop customizations that can be easily incorporated into future releases of the products, thus removing the “red headed step child” syndrome that made customized systems such a pain, and 2) many ERP software developers are adding robust BPMS capabilities into their systems such that they can be tailored to handle any unique processes that come along. I wrote an article about these a year or so ago (http://tinyurl.com/8unl5sm).
The bottom line: the ERP software industry is not monolithic. Plenty of developers realize the world is changing and their products must evolve to support it. I also believe that some of the BPMS tools have reached a level of sophistication that they could begin offering ERP templates as a starting point for their products. Even if the dinosaurs were not wiped out in a single cataclysmic event as is commonly assumed, but died out because the failed to evolve, they make a bad metaphor for the ERP software industry.
Tom:
Your post and BP Trends Article are informative.
If possible please provide links to
any of the points AA to GG of my post 26AUG12,
privately if you prefer.
Ya…you are right, there are many limitations of traditional ERP systems, as specially customization and configuration, so we need to migrate old data from legacy system to new ERP system and that is quite tedious task.
I accept that ERP’s are dinosaurs. However, don’t kill the dinosaur. Just keep it in a cage chomping away in the manner in which it was made to chomp. If you upgrade, replace or modify this system you are chasing yet another dinosaur down a risky, expensive and disruptive path.
Changes to the process of employees, vendors and customer should happen outside the dinosaur cage (i suspect the analogy is now completely overplayed). Decouple the data, technology and process from the ERP using the ‘native’ connections already in place. In other words, throw it the chunks of data it requires as part of its diet and don’t ask it to learn any new tricks; its a dinosaur…its supposed to rip off your arm and eat you.
Now apply logic, sequence, new data & technology to the existing processes that require attention. Collaborating to achieve efficiency, accuracy and visibility delivers a harmonized set of processes that work to meet the immediate goals/opportunities of any company.
Steve, I couldn’t agree with you more. There is a need for data management that has the entities right for the things that need to be stored. Data also needs to be ‘freed up’ to be used for all of the most important moving targets. The best organizations are constantly vigilant for opportunity, risk and efficiency, which isn’t the modus operandi of an ERP. These moments are found when events happen, and those events can be in complex combinations. The analysis, vigilance and action cycles aren’t built into an ERP or aren’t sufficiency flexible to be modified in the timeframes necessary.
Thank you Chris for your insights. I agree that ERP software should continue to evolve but we also need to change our approach in how ERPs are deployed. ERP makes for an expensive custom solution. Configuration is less effort than software customization but in itself will not solve the root cause. For your consideration:
http://gbeaubouef.wordpress.com/2010/12/22/erp-expensive-custom-solution/
Any system that purports to “all-singing, all-dancing” it likely to collapse under it’s own weight.
Today we have ways and means of providing interoperability within and across systems.
It gets tricky when data has to flow in “real time” but otherwise a generic data exchanger can accommodate multi-directional data flows by and between any number of publishers and subscribers PROVIDING each has import/export capabilities.
Clearly, success with import/export increases when publishers and subscribers agree upon common data element naming conventions but that is not something we are likely to see.
Accordingly, at a practical level, we need to accommodate multiple publishers and multiple subscribers, each reading and writing using their own native data element naming conventions and we need the data that any publisher is willing to share to be shared on a need-to-know basis to avoid over-disclosure and data overload.
Karl:
Yes, for interoperability “publishers and subscribers have to agree upon common data element naming conventions.” Perhaps it is implied that the meanings of similarly named elements is also similar (with permissible variation within some limits). I understand that Ontologies have met this requirement. Perhaps they can be used.
ERP is a dinosaur indeed. Administrative organizations can easily be freed from the restrictions imposed by their current administrative processes.
How? Not by reducing complexity - as many suggest - but by embracing it. Complexity is a natural phenomenon. It is simply how the world works, with all its diversity and change. But there is a difference between what makes the world complex and what makes it complicated. Organizations stand out by the way they deal with complexity. By accepting it and taking advantage of it, by using it and profiting from it. But in order to do this, it is important to first reduce the complicated nature of the business processes.
Traditional business process methods have been aimed at capturing complexity in systems, logic and code. As a result, business systems have become overcomplicated and inefficient. The next wave in business operations is aimed at embracing complexity and profiting from it. The process is no longer key − the focus is now on the customer or, in more conceptual terms, on the ‘case’.
This orientation allows for mass customization instead of standardization, for empowerment instead of control, and for accepting complexity instead of denying it. So be model driven, goal oriented and adopt dynamic case management.
Thank you Chris for this excellent post….ERP becomes a back office more and more sophisticated in terms of features, because our customers follow the trends and become more international, more global…moreover they follow the technical trends and that’s creating a revolution in the way to use ERPs… ERP providers are looking for new features to simplify the ERP and make it simple to use….And I think some of them succeed in that challenge: for example business intelligence, mobility, pre sets elements, methdology are ways to simplify the use of ERP, like what was done for Sage ERP X3…But to be honest, the ERP is still the back office information system we knew the last decade, installed and deployed in companies, even if people using it, use it only via adapted transactions and processes.
Great comments, Sophie.