ERP RIP ?

We have just completed a fairly major piece of work for a client that had as a major component the development of the SaaS / SOA market (but never call it ASP, thats sooo Web 1.0), so it was with some interest I read Nick Carr's blog on the death of ERP. In essence Nick is arguing that traditional ERP may be blindsided by ERP as a Web Service, mainly due to new services such as Workday, which is apparently a first "ERP SaaS" - to quote Nick:

It's an alternative to ERP, rather than a Web-delivered version of ERP, because the system's software guts are entirely different. Rather than being tightly tied to a complex relational database, with thousands of different data tables, running on a separate disk, the Workday system uses a much simpler in-memory database, running in RAM, and relies on metadata, or tags, to organize and integrate the data. Having an in-memory database means that the system can run much faster (crucial for Web-delivered software), and using metadata rather than static tables, gives users greater flexibility in tailoring the system to their particular needs. It solves ERP's complexity problem - or at least it promises to.

This will blindside "trad" ERP because it gets rid of the Complexity Problems:

In The Trouble with Enterprise Software, an article in new issue of the MIT Sloan Management Review, Cynthia Rettig deftly lays out the case for the latter view. Enterprise systems, argues Rettig, not only failed to deliver on their grand promise, but often simply aggravated the problems they were supposed to solve. "The triumphant vision many buy into is that enterprise software in large organizations is fully integrated and intelligently controls infinitely complex business processes while remaining flexible enough to adapt to changing business needs," she writes. The reality is very different, says Rettig:

But these massive programs, with millions of lines of code, thousands of installation options and countless interrelated pieces, introduced new levels of complexity, often without eliminating the older systems (known as “legacy” systems) they were designed to replace. In addition, concurrent technological and business changes made closed ERP systems organized around products less than a perfect solution: Just as companies were undertaking multiyear ERP implementations, the Internet was evolving into a major new force, changing the way companies transacted business with their customers, suppliers and partners. At the same time, businesses were realizing that organizing their information around customers and services - and using newly available customer relationship management systems - was critical to their success.

The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus, many companies ended up having several instances of the same ERP systems or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.

This is - imho - a bit over-egged - ERP systems are after all just software simulations of most of the "stuff" that is done in any Enterprise, this software will exist one way or another - ERP systems arose in a previous generation of architecture to allow multiple functional modules of software to inter-operate with the same data. Prior to that the Inventory, HR, Logistics, Billing, CRM, VRM, SFA etc etc all came from different suppliers with different databases, and that was a real nightmare

However, as veterans of quite a few ERP, OSS and similar sorts of big database systems, our experience is that the major complexity in implementing and operating ERP systems and similar is not really in the software, or in the database used. Its in setting the whole thing up as a model of the Enterprise in the first place:

- the business rules (processes, workflows, policies etc) within any one Enterprise are complex, and mapping that onto software and databases to get a fairly good model of reality is non trivial, irrespective of the actual technology used

- getting accurate data into these systems - and keeping it accurate - is actually quite hard and time consuming.

- getting users to use (and not abuse) systems is always a challenge

The move from indexed sequential file databases to relational databases in many ways reduced efficiency as it allowed enterprises more flexibility in how their data was structured - which of course increased the complexity of the implementation, thus increasing the difficulty of maintaining it and changing it. One could argue that the software influences the ease of modelling the enterprise, and there is some truth in that - but my experience was often that complex software was used more as a way to map existing (archaic, politically expedient, not best practice) practices than to go to the huge effort of actual Business Process Redesign etc etc (the Simplify, then Automate mantra you may recall). As anyone who has tried to put in any form of Lean Operations will testify, the intra-company political battles can be immense. Automate then Complicate was a frequent result.

In-memory databases using metadata are no doubt a step forward performance wise, but this is not the critical path for ERP success - its a processes, disciplines, GiGO issue - thus its hard to imagine that the software architecture per se will make a critical difference. Yes good software helps, but its really not the key to success - Japanese companies can just about run entire manufacturing plants on pieces of coloured paper card and 60W lightbulbs.

In fact, often one got most of the benefits in the implementation from just sorting basic data and processes out, before sticking in any software.

Where SaaS does make a major material difference is in the business model - given that its hard and expensive to make ERP work, then not buying the whole software kit and caboodle upfront but renting it has huge benefits on cashflow in the short to medium term (ie the average tenure of the responsible C level exec in the hotseat). But this still does not solve 3 fundamental problems:

- The Data is in Someone Else's system format, exporting it to a new supplier is hard
- Ditto the processes, workflows, policies etc etc
- In Saas models, there is the risk of (i) losing connection or (ii) supplier shutdown (at least with bust software companies your package was on your machines)

Now where it could get really interesting is if the in-memory database models could de-risk these sorts of problems by separating data from application, and even better if modules (CRM, VRM, etc etc) within those verall Enterprise applications were then interchangeable - if the Enterprise could own all its data and metadata, and could just switch application supplier in a (relative) heartbeat, while keeping its data models intact. This of course needs a rethinking of how the low level messaging data layer interacts with applications, but if one could make software module that were open, re-usable and data independent that would be really revolutionary.

Postscript...saw this note re Workday:

Workday is using REA (Resources, Events and Agents), a 25 year old idea to develop modern software. In REA theory, the economic data surrounding accounting entries that gives context to those entries is captured. It goes way beyond simply recording of debits and credits. REA defines a way to capture entire processes or process parts, depending on the extent to which the process designer wishes to develop or expose process. The way Workday has interpreted REA allows them to atomize process objects so they can be assembled to represent pretty much any view a user requires.

Blimey....deja vu 2.0 Issue then as now is allocation of overheads......