The Myth of the Integrated Vendor: A Brief History of MRP/ERP, Applications Networks, and Platforms

Although Friday is when we write our weekly rants, this one is perhaps more of a eulogy as I bid adieu to the romantic notion of the integrated ERP suite / vendor.  I combine “suite” and “vendor” here on purpose. Back in the late ‘80s and early ‘90s, I had developed some custom systems for MRP I, finite scheduling, and a simple product configurator (using 4GL tools like DBASE and FoxPro). And I remember distinctly when I first started learning about packaged MRP II systems running on 4GLs, from a cool little vendor called Fourth Shift (now Infor) that you could run on a high end PC.

And of course there were a bunch of newer vendors that were moving functionality from products (for example, ASK Computer Systems’ MANMAN or SSA’s BPCS) running on mainframes and mid-range platforms to client-server architectures running on relational databases such as Oracle and Microsoft. Talk about what rapid progress (no pun intended) in a short MRP time frame!

These supply chain products slowly evolved into business suites (i.e., MRP to ERP) by adding back office functionality while other vendors like European up-and-comer SAP were moving the other way. Regardless, the golden age of ERP had begun in earnest. The game became one of “Feature 500 lists” and trying to keep up with innovative best of breed vendors, but all the while touting the benefit of an integrated data model supporting an increasingly broader set of business processes. Of course the spoils from this era ultimately ended up not necessarily going to Waldorf and Redwood Shores but rather primarily the consultants – Accenture (Andersen Consulting) being perhaps the biggest beneficiary throughout the ERP/MRP cattle drive.

Alas, things would not last as they were. Then came the Internet and multi-tier B2B networks. As 2-tier client servers became 3-tier client servers to support the new UI called the web browser, ERP vendors and their integrated ERP products underwent a serious re-tooling. But the data models and processes they supported were still basically intact. B2B marketplaces also became big, but their commercial hubris clearly outstripped the technology and realities of implementation, and so the bubble burst.

As a side note though, the design concept of multiple private business networks being powered by a common technology platform offered as a service was a good one and is more relevant than ever. When I was at AMR Research, we called them Private Trading Exchanges, and I actually dug up an impressive piece of work here that IBM did based on the idea over 10 years ago that dives into some of the architectural details of making it work – albeit on an older and IBM-centric technology stack.

Alas, we were too early though, and so was Commerce One, whose business model had morphed to powering multiple private business networks on a single scalable virtual business network platform. We call this a Procurement [application] Platform as a Service, but I’m sort of getting away from my story (but not completely as you’ll see). Interestingly, in retrospect Mark Hoffman and his colleagues completely had the right vision, if not the right technology and business model.

Then the multi-tier supply chain came into play. This was harder, but even this could be overcome, albeit not easily (take SAP’s Supply Network Collaboration product as a great example). It has only been partially solved (at best) in the existing ERP data models. But, when cloud computing came along with the many-to-many data models inherent in SaaS applications and the infrastructure (database, network, OS, hardware, etc.) needed to massively scale them, the chasm became clear and had to be crossed. But even here there was hope. For example, NetSuite is the best-known cloud ERP vendor, and in procurement, it’s very ERP-like in terms of its basic purchasing functionality. But it’s clearly no Coupa in terms of having eProcurement steak and sizzle.

The biggest problem though has been the issue with the firms being “too big to fail” for shareholders, and that means using the war chest of cash to fund acquisitions and fuel growth. This growth, however, comes at a cost, and in the next edition of this post, I will discuss which chickens are coming home to roost – and while I’m on this analogy – the dismal state of parts of the chicken coop and how a new phoenix may rise.

Bird, after all, is the word – even if too many IT and procurement organizations have been left both paying for and cleaning up the droppings until now. But, most of all, I will seek your opinion.  Stay tuned.

Related Articles:

  • No related articles found


Join the Conversation

* Required fields  [email address will not be published]