Agile and ERP: Part V - Conclusion
Agile and ERP: Part V - Conclusion
Allan Kelly concludes his series on the challenges of using Agile practices in ERP environments.
Join the DZone community and get the full member experience.Join For Free
The story so far…
- Agile & ERP?
- The Good News about Agile & ERP
- ERP Culture v. Agile Culture
- The Bad News about Agile & ERP
Where does this leave us?
For a modern software developer who understands Agile and is well versed in the current ways of working, encountering an ERP system is like stepping back 20 or perhaps 30 years.
The mindset in ERP is more akin to the software development mindset that existed when I started working in IT. It is as if the last 20 years have passed them by - the technology is dated, the Agile revolution hasn’t happened, users should be grateful for what they are given, and the vendor is all powerful.
The deal with ERP is this: if the ERP system does so very much, why reinvent the wheel? Writing software is expensive (and fraught with failure), so why not use what we made earlier?
It’s the software reuse argument written BIG.
The downside is: the ERP is all encompassing. You need to use particular technologies, and these technologies haven’t really advanced in 20 years. The skills are in short supply. Most importantly, all the ways we have found to make software development more effective are absent.
Let us be very clear: there are massive benefits from using an off-the-shelf system. ERP systems are big, really big, complex, general ledgers, multi-country/multi-currency payroll, etc. Why would you want to rebuild this stuff?
But there are also massive costs.
The ultimate question is: are the benefits greater than the costs?
It's worth repeating what Capers Jones says at this point:
“As a rule of thumb, if COTS [Common Of The Shelf] packages require modification by more than 25% it may be less expensive in the long run to build the same kind of application.” Applied Software Measurement, Jones, 2008
Unfortunately, he doesn’t elaborate on how the 25% is calculated. He probably means function points. He continues:
“Package modification is a high-risk activity with a significant change of failure and disaster. Not only is productivity normally low for modifying purchased packages, but if the vendors are reluctant to provide support, modification can easily be more expensive than customer development.” Applied Software Measurement, Jones, 2008
When answering this question, please remember that licenses for ERP systems are far from cheap, and they reoccur. Plus, vendors may well charge extra fees to support parts of the system which have been changed or to ensure backward compatibility.
Once installed, clients can be very, very, reluctant to update their ERP system. This is hardly surprising once you realize that “configuring” a system like SAP may mean having developers change SAP code in the base system. If SAP releases a new version they may have changed that code, so you are lucky if you can get away with a merge from hell.
When you buy an ERP system, you buy an existing legacy system. You then attempt to configure it to be your legacy system. (See my Peugeot post.)
This sounds like a bad deal, but it's a deal that makes sense for a lot of companies and has been for 20 or 30 years.
Now, here is my conclusion:
20 years ago, buying a legacy ERP system and configuring it to be your own legacy may well have made financial sense.
But in the last 20 years, technology has advanced - not just the CPUs, but the programming languages, the programming tools, and even the programming processes.
Buying a legacy ERP system today means buying into a legacy development process with legacy tools. You step back 20 years.
In the last 20 years, the tools and techniques have got a lot better. While buying an ERP system may look like a sensible decision, you also shackle yourself to 20 year old tools and processes.
The tools and processes have improved so much in the last 20 years that the equation has changed. Modern approaches (i.e. agile and test driven) using modern technology means the cost and time gap between a) developing your own system using modern techniques (including microservices, existing libraries, open source, etc.) and b) choosing legacy ERP system (reoccuring license fees plus configuration costs) is far smaller than it was.
I conjecture that the gap is getting smaller as we speak.
Since ERP systems last decades, the 20 year old ERP system you are buying today might be expected to last another 20 years. Who knows how much better things will get in two decades?
Finally, one might ask: given all these problems and the changes in technology, why do companies buy these products?
Nobody ever asked my opinion on this so I can’t really say, but let me float an idea.
Only companies of a certain size, say $1 billion revenue, can afford these systems. When a company reaches that size, they are expected to buy such a system because having an expensive system is a sign that your company has arrived.
These systems are driven by the finance departments, the CFO. As companies get big, they need such systems to control the company. But also, the CFO of a $1bn company wouldn’t look serious if he or she didn’t have one. After all, all the other $1bn companies have an ERP system, so why not yours?
If you are the CFO of a $1bn company without an ERP system and something goes wrong, it will look irresponsible. Having an expensive ERP system allows the CFO to say, “we followed best practice and bought Oracle.” It reduces the risk of the CFO losing their job.
Buying an ERP system also allows the CFO to claim more resources for his department and allows the CFO to say at his or her next job interview, “I introduced an ERP system to a $1bn company.”
So the next time you get appointed CFO of a company which has just broken the $1bn revenue barrier and you find there is no ERP system in place, what are you going to do?
Engineers might think, "I’ll set up a small team and start growing our own ERP system using modern technology."
To the engineering mind, that stands the best chance of working and is financially the best route.
But it is also high risk simply because nobody else does it.
Everyone else says, “I’ll call SAP. I’ll spend a lot of money with them, Accenture, Cap-Gemini, and CSC. When it goes wrong, I can blame them. After all, that's what everyone else does, so doing anything different would be high risk.”
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.