I’ve seen a few articles, and I’ve been doing some wondering on my own, about what the future of ERP will be.  Maintenance costs keep rising (22% now for Oracle and SAP), the time it takes to install is being measured in years, not months, and once you get fully installed you’re too broke or exhausted to ever upgrade. 

 

I think the problem is there are two contradictory forces at work here.  First, ERP systems are now very functionally rich.  And that richness is built on a very robust and complex infrastructure which makes setting up that infrastructure a very time consuming and user intensive task – the main reason why it takes so long to bring a new ERP up. 

 

Second, even though these ERP packages are very functionally rich, they are not quite rich enough.  In fact they could never be rich enough to deal with the imaginations of our nation’s business leaders, and despite what we may wish, you can’t always (or hardly ever) just say ‘we are not going to do it this way anymore because our ERP system doesn’t support it’.  Many times there are very solid reasons, reasons that mean a lot to the customer base, why companies do the bizarre things they do.  And so for most ERP packages the customization phase starts almost before the first item master is created and goes on forever.  That’s what makes it so hard to upgrade. 

 

So, there you go.  We need a complex system to handle the complex business conditions we have but it will never get complex enough in just the right ways to make everyone happy without customization.  In addition, 80% of the complexity in the package is not something you need and it will just get in the way, and the 20% that is applicable doesn’t go quite far enough.   A slow creeping quiet fills the room and from the back a small, sad voice says simply, “We’re doomed.” 

 

To be honest, I haven’t a clue how this will all turn out.  Maybe we will get to the point where we just accept the fact that installing the ERP system will go on indefinitely.  Or maybe the ERP vendors will take things into their own hands and make their packages simpler?  All together now, let’s hold our breath.    

 

But I do know what should be done.  (If this has been suggested before, accept my apologies, I have not seen it.)  We need a simple, underlying, black box ERP engine that everything else could be built around.  No, wait, hear me out on this.  This would not be a full ERP system as we understand that term today, with every bell and whistle we can dream up.  It would be a bare bones MRPII model designed to store the company data base in a flexible format, perform the standard MRP calculations, provide the necessary feedback loops that distinguish MRPII from MRP, and track the heck out of the financial side.    

 

This package would not try to supply every user desire.  There are some areas it wouldn’t bother with at all.  It would be much smaller, much simpler, but it would do the heavy lifting an ERP system is supposed to do.  Even the files would be fairly simple and the emphasis would be to make an MRP Kernel that would be simple to install and which could not be modified even if you wanted to. 

 

But it would have something very important.  Much of what goes on in an ERP system is internal.  You feed demand in, you look at inventory, you calculate your requirements.  Internal.  I don’t care about no stinkin’ outside world.  But there’s other stuff that an ERP system does which depends very heavily on  external connections.  Where does your demand come from?  How did your inventory get entered into the system?  And at each point in the ERP kernel, where outside information is needed, there would be not an application but an interface point, a standard, simple to use, common interface to the outside world. 

 

Meanwhile, all around the kernel, independent software suppliers could build their applications that would bolt onto this kernel.  The interface would be standardized and you could pick and choose the particular applications you needed.  Now I know that sounds like chaos but I don’t think it would be.  Most of the major ISV’s would develop a general suite of applications and if your needs were not too bizarre you could just buy that suite and interface it in.  You don’t have to go to 15 vendors to buy 25 separate packages.  But if you did have a real specialty need, you could buy that app from that one vendor and interface it in too, because there would be a common interface and everything would fit in just like everything else. 

 

Because of the common interface, there would be a great deal of pressure on ISV’s to tailor the files in their package that are part of this interface to match those of the ERP kernel.  There would also be a great deal of pressure on these ISV’s to make their implementation as simple as possible because now that becomes a parameter by which you judge and separate the different contenders.   

 

You would start with a common kernel and then custom buy or build those special areas that make your business unique. 

 

Some people might say that with a simple file structure underlying the whole thing you could never build the complexity into it that the interfaced packages need.  I don’t agree.  I think that is a myth, the myth that we need to build every possible contingency into the base files.  I don’t think you need to.  Maybe once we did, back when we were scrimping and saving on every bit of disk space we used, or writing weird routines to shave milliseconds off the cycle time.  But today, I don’t think it matters.  I think it is possible to define a data base that is simple and which does not preclude the use of add on ‘complexity files’ in the interfaced applications to support special capabilities for those customers who need it.    

 

Now, I know what you’re thinking.  You’re thinking that maybe this is a good idea but it would never work because no one has enough leverage to make this happen, to build the Kernel and shove the standard interface down everyone’s throat.  And I almost think you’re right.  Almost.  Because I think there is one company that still has enough clout and enough breadth to do this – IBM. 

 

Yes, they may not be the IBM of the 70’s anymore but they are still very strong and a powerful force in the industry.  If IBM would build a very moderately priced ERP engine (think almost giving it away), with a standardized interface, maybe even simple interface apps for those who don’t need too much, and embed that into DB2 via one of the 10,000 versions of SQL, I think they would have enough leverage to make people think twice. 

 

Like I said before, I don’t know what will happen.  I know for sure that it won’t be what I have described above.  It just makes too much sense, and my experience has shown me it’s always the least logical ideas that see the light of day. 

 

But it is interesting to think about.        

 

Tags: Back office, ERP, future, IBM, MRPII, Oracle, SAP, Supply Chain