Postmodern ERP: the prediction that, in the foreseeable future, companies will run a collection of applications, each best meeting a subset of their functional requirements and all seamlessly integrated.  No longer will you be limited to the functionality of your chosen ERP; you’ll simply “bolt-on” a best-of-breed application to use and improve upon your existing data with the enhanced functionality this new App or website or desktop program provides.  Need a equipment maintenance program?  Bolt!  How about a Theory of Constraints scheduler?  Bolt.  Ah, and e-Commerce!  Bolt!!  Wait, don’t like your ERP’s financials system?  Unbolt it and bolt on another (actually, I kinda like this one, stay tuned).

Isn’t the future grand!

Well, maybe not.  The same folks that coined the term “postmodern ERP” have predicted a near 100% failure of postmodern ERP projects by 2018.

Why will these project fail?  Well, in a nutshell, because making different functionalities share rich data with different functional focus across different technology platforms is just as hard as it’s ever been.  Take a look at the image to the right. Every overlap of one functional bubble with another requires another data and technology interface.

2-Tier ERP (one for financials and one for operations), EDI, and other ERP integrations have always been a challenge, but one with a return.  Adding more vendors and more technologies and more interfaces to the party just makes the challenge much, much larger and the potential for a return far less likely.

But, more to the point, why even make the attempt?  Why should we have to bolt all these different tools together when ERP vendors have spent the last couple of decades telling us the a significant component of the return on an ERP investment comes from “having all your data in one place.”

The problem isn’t with the concept of ERP nor is the goal of “having all your data in one place” one that doesn’t have great potential.  The problem is with the available ERPs for small manufacturing companies or, for that matter, any company.  Almost all ERP’s have long strayed from their original promise: to provide tools to guide companies to operate in an increasingly effective manner.  The great grandfather of ERP, MRP, was hugely disruptive.  MRP-II integrated this technology with the rest of the supply chain.  Then came along ERP which is, well…, better than MRP-II.

And then we got lost.

First, ERP vendors concentrated on making better financial systems, not better operational tools.  Then ERP vendors concentrated on making more money and cut R&D efforts.  So now, “modern” ERPs are really good versions of what was released years ago: financially-based systems that are based on transactions and simple arithmetic with a little related data on the margins.

During this, er…, evolution (for lack of a better word) new philosophies and functionalities came to market: TOC, DMS, CMMS, Lean, and on and on. We tried to make these tools works with our really good old ERPs with marginal to dismal success.  The technologies didn’t want to talk to each other, the data was too different, and the TOC and Lean guys got so frustrated that, in many cases, they began to advocate against the concept of ERP.  It’s no wonder that we’re hoping that postmodern ERP’s are going to solve this, we need more than what current ERP’s are offering us.  But we don’t need it next to our ERP, we need it in our ERP.

I’m here to yell it from the mountain top.  A manufacturing ERP should have TOC and DDMRP concepts on every planning and scheduling window to tell us what we should be doing and what we shouldn’t.  An ERP should have a deeply integrated DMS to store digital information about items, customer, vendors, equipment, and everything else and make it effortlessly available.  An ERP should have an CMMS system to align the maintenance of work centers with production scheduling and provide the same support for MRO replenishment as for production and sales replenishment.  An ERP should have painless pull and paperless manufacturing to support Lean philosophies.  These functional requirements aren’t on the edge of the ERP, they are core to the ERP and to the business processes that it supports and require rich integration with complex data that only an in-place solution can provide.

“But you forgot (insert your favorite 3-letter acronym here)!”  Maybe, or perhaps that process can live well or even thrive on the edge of the ERP.  Maybe there is a good decoupling point between, say, a marketing tool and an ERP, where the marketing tool can draw sales history from the ERP and push forecasting information back.  Or maybe an e-Commerce site can draw stock availability and shipment statuses on demand and push sales orders while the ERP pushes new product information.  And maybe, with less data discipline and much more, well, let’s say “optimism”, the CRM should be decoupled from the ERP.  Maybe postmodern ERP should be a refinement of 2-Tier ERP (see image).

Postmodern ERP isn’t a solution looking for a problem.  Postmodern ERP is a proposal of how to add desperately needed functionality to a chuck of software that is still wearing parachute pants and white K-Swiss shoes.

It’s still about the ERP.  ERP’s aren’t off the hook.  ERP’s are in the hot seat.  We ERP developers shouldn’t design e-Commerce packages in an attempt to match the features of Shopify or Amazon or CRM functionalities that compare to SalesForce or SugarCRM; postmodern ERP suggests something else.  Postmodern ERP should remind all of us that we must focus our efforts on providing tools to guide and instruct our customers to further improve the effectivity of their operations, and, simultaneously, that we much enhance our ERPs’ technologies to make the edge of our ERP’s more porous to more easily connect to everything else.

And some of us are.