I want to get my head straight about Swiss army knife software systems like “Enterprise Resource Planning Systems” (ERP systems). These are really powerful tools, no question, but in some situations, they can cause more harm than good. So, I want to tell a fictive story, that shows how an organization can get deep into trouble. For this, I’ll try to use Nick Tune’s brand new Core Domain Patterns and Wardley Mapping (but be cautious about my use of Wardley Maps, I’m still learning ).
For understanding the context around ERP systems better, we first take a brief look at the role of IT systems in the past decades:
- 1970s: Automation of processes / rationalization
- 1980s: Achieving economic goals
- 1990s: Enabling new business processes
- 2000s: Differentiator in business models
- 2010s: Integration hub for reaching new markets
Especially in the last two decades are very interesting: Differentiation from other competitors via unique features with the help of IT systems in the 2000s and competitive advantage with flexible API integrations in the 2010s. Let’s think back to the early 2000s. Our company sold goods at online marketplaces like eBay. No other company could integrate APIs from various marketplaces as we did. We were the stars among the API integrators. Integrating was our core business! For faster time-to-market, we used a brand-new ERP system.
We didn’t have the ERP system just for API integration alone, but also for all this generic stuff like invoicing where we wouldn’t create our own separate application for this, of course (we were not stupid!).
But our salespersons had always special requirements for us ERP system developers. We just couldn’t deny a wish from them. This came with a cost over time: All this customizing was expensive and heavily dependent on the internals of the ERP system. Yes, there were things like interfaces and a vendor-specific database schema, but who cared? Nobody could pimp the ERP system as we did. As technical savvy developers, we even customized the base module of our ERP system (ERP v1′, green colored).
Some years passed by and suddenly (who had thought of this!) a change in the law regarding invoicing happens. A new version of the ERP system was released (ERP v2, red colored), bringing all compliance updates for the invoicing module for free (red colored, too)! We just would need to update to this version and everything would be fine.
But wait a moment. A few years ago, we changed the ERP base module so heavily with the cost of not being able to update to new ERP versions. It was a deliberate decision to enable the super cool API integration tool based on ERP functionality. It was totally OK past then. But here we are now, stuck in the past because of our massive adaptations of the ERP system’s internals. This creates huge inertia (red thick lines).
We’ve invested a huge amount of financial capital for this. So we don’t want to throw away all the investments. But even if we would want to pay the price, we wouldn’t be able to update because all modules in our system are now depending on an undefined mass of customized code in the base module. The risk of losing all the valuable micro-optimizations all over the place is simply too high. This leaves us with only one option: Ensuring that the old version of our invoicing module is compliant to the new law regulations. So here we are, programming our own module in the generic subdomain (red colored component on the lower left). This simply means wasting money!
But it gets even worse: With the new ERP system, there is also a new super cool API integration just out of the box (violet colored). All our competitors can now update to the newer system. Our differentiation vanishes completely in comparison to our competitors, leaving us behind because we cannot use this opportunity: We are still stuck in the past (violet thick line)!
We ran into “Table Stakes Former Core“: Our former core asset was degraded to a mere supporting function or liability, leaving us with maintaining ordinary supporting and generic subdomain modules. No new core, no new chance for differentiation but buried with the challenge to keep the old system running, because we have no more money to get rid of all the mess.
The Unhappy End.
So, what’s the moral of the story?
When using an ERP system, don’t mess with the ERP’s base module for creating a differentiator of the cost of not being updatable. Have in mind that you also have modules of other strategic (non-)significance that depend on the base module. In the worst case, the tide may turn and you are left with just supporting and generic modules that you have to maintain at high costs, leaving you with no differentiation on the market.
And on the meta-level, I hope that you saw how you can explain this situation with Nick Tune’s Core Domain Patterns and Simon Wardley’s Wardley Maps. These are great tools for strategic thinking!
Ohh, and please leave a comment to discuss if this all makes sense at all !
5 thoughts on “Some initial thoughts about ERP systems”
Really interesting article – but I don’t see the diagrams?
Thanks and thanks for the hint! Unfortunately, I cannot reproduce the issue. Can you please try again? Maybe my hosting provider just got a little hiccup? 🙂
Very interesting analysis. I was just about to start mapping a ERP upgrade at my company and I have some questions I’m thinking I need to address/answer including:
* Should we approach it as a heart transplant and leave all the dodgy middlewear in place
* To what degree should we pursue a purely vanilla implementation of our ERP
* What role should custom-built components (say API integrations or loose coupling) play
* To what degree should we apply CI/CD or DevOps techniques to make the overall system more testable
* How can we move away from a fully integrated test landscape because our existing system isn’t testable as subcomponents?
Thanks! Of course, there is no simple answer to all this. E. g. for your first bullet point, I would start to reverse engineering why those middleware components where created in the first place. What are the business’s needs that led into developing/buying those components? Are they really needed for differentiation or are they just components, that someone implemented because some other one told him/her to do so without seeing the whole picture? I think a Wardley Map is a good starting point to discuss these points. For the last bullet points, it seems to me that there is a need to clarify the needs for specific quality attributes (like testability or speed of delivery) with the business. Maybe this leads to the point that there are no requirements regarding those quality attributes from the business’s side (so you can stop thinking about them right now) or maybe this could even lead to the point, that an ERP system isn’t the right fit for some components (which could lead so a splitting/decomposition project).
Pingback:Awesome Wardley Maps – Massive Collection of Resources – Learn Practice & Share