ERPII or SCM2?

Much has been written about ERP II, which is the term coined to indicate the next generation of ERP systems. According to most experts SCM will become a part of this bigger better ERP. Personally I think this is only partially true. For certain industries that have mainstream SCM requirements this will be possible to a certain extent. For some industries the requirements for ERP and SCM are so fundamentally different across the board that I do not think these could successfully implement a single system that does both, at least not in the tightly knit form that is predicted for ERP II. As a consequence I believe for some industries ERP II will be the way to go, whilst others will be stuck with two separate systems: ERP and SCM2… Unless a revolutionary new form of ERP were to emerge that would be shaped more like SCM systems than present day ERP systems. I am very interested to hear about any such systems if they exist today. For this I will start a short posting on the products page, to keep the other pages completely free of sales and marketing speak.

The root of the problem lies with the fundamental difference between ERP and SCM. Existing ERP systems are all built on top of a database with its inherently relational structure and around pretty standardized processes, such as accounts receivable, accounts payable, order-to-cash, bills of material (BOMs), etc. Any differences between implementations are usually captured by setting a series of parameters or flags on the one standard model. The processes themselves are always done through sequential rules and heuristics, rarely if ever through an optimization. Simply loading the right data into this rather rigid data structure will make the ERP functionality come to life. For SCM a lot of point solutions exist that each tackle a small piece of the total SCM pie. These can get away with the same approach used for building ERP systems. However, for some point solutions, and for pretty much all more holistic tactical and strategic solutions this is not an option. Especially point solutions in the manufacturing area will already need to deal with many complexities and uniquenesses of industry verticals and individual companies to warrant less of a straitjacket. Sure, any system can be customized, but this leads to support and upgrade hell, and is certainly not part of the ERP II vision, nor the SCM2 vision.

A number of SCM systems exist today where the database is not central in the design considerations, but rather the performance of optimizations that need to be run. Some of these are highly flexible where in each implementation the unique supply chain is modeled into the standard software product. As a result the database that holds the data for these systems is usually not relational (RDBMS), but rather object relational (ORDBMS). It is these systems that are typically able to handle many more implementation scenarios without customization to the application, database, nor to a large degree to integration. These systems frequently boast tactical and sometimes strategic level optimizations that span multiple or all areas of the supply chain. It is these systems that in my opinion are best set up to evolve into SCM2 applications in the future. Why they are not yet SCM2 is food for a different article. Those systems that attempt to do it the other way around: design around a database and then make the best of the optimization afterward are stuck with a solution that does not scale. Where databases scale really well, optimizations do quite the opposite. If optimization and scalability are both requirements one better start application design around the optimization performance.

So let’s assume that an application were to exist at some point in the future where the SCM2 functionality were built on top of such an ORDBMS. In order for that application to be called ERP II the SCM2 functionality would have to be intimately integrated with the ERP side. From a business process perspective and user management perspective this is rather simple, so let’s ignore those for the time being. From a data perspective this is not so simple. First, let me explain what I mean with “intimately integrated“. Currently many systems exist that boast tight integration. Tight integration means that separate systems that are to be integrated have pre-built integration set up which needs to be set up and tweaked. This means that data structures in one application are pretty much aligned with data structures in the other application or an integration vehicle exists between them that can accommodate the differences. This is considerably easier than loose integration which means the technical aspect may be somewhat prepared, but the data structures still need to be aligned by hand. Intimate integration means it is completely transparant. Anything that is enabled in one system is immediately available to the other system, without user intervention. In most cases the data is not even copied from one to the other, but one system simply grabs it straight from the other when the information is needed. They share data sources, not clone them. With currently available ERP systems built on RDBMS databases this leaves all the integration work to be done on the SCM2 side or using pre-built integration vehicles that are “aware” of what happens in both systems and “knows” how to deal with any combination of settings in both applications. Some kind of Object Relational Mapping (OR/M)  needs to be done between them with all the potential hazards this comes with, such as the dreaded impedance mismatch. If the ERP side however is also built around an ORDBMS (in case of real ERP II it would be the same ORDBMS) an intimate integration becomes attainable.

For those readers that have not yet immersed themselves into the theory of ERP II, intimate integration is core to the concept. Where current ERP systems still need extensive integration to other enterprise applications even if such applications are sold by the same vendor, ERP II would make integration transparent. A suite of separate integrated products becomes a single system with mutually aware modules.

To sum things up, I see the following options for the future. Which one you could implement is dependent on your industry, your business’ unique and complex issues:

1. ERP II built on RDBMS including basic SCM functionality
2. old-fashioned ERP built on RDBMS integrated with independent old-fashioned SCM point solutions
3. old-fashioned ERP built on RDBMS integrated with SCM2 built on ORDBMS
4. ERP II built on RDBMS integrated with SCM2 built on ORDBMS
5. ERP II built on ORDBMS including advanced SCM2 functionality

Option 1 is going to be the most prevalent, since most ERP vendors are already a long way down that path. The current SCM functionality will be extended and improved, but without switching to an ORDBMS and focusing on optimization performance the tactical and strategic objectives will remain out of reach. Option 2 is what we see currently. Given that a lion share of the market is still running decades old MRP and CRP type applications, I think it will be a long long time before we see the end of this. Option 3 is the first big step forward on the SCM front, where SCM pulls up alongside ERP in terms of modularity and degree of intimacy of internal integration. As ERP evolves into ERP II with still basic SCM functionality and SCM evolves into SCM2 I expect to see a lot of implementations along the lines of option 4, where the SCM functionality inside ERP II is left unused in order to use the more advanced SCM2 functionality of a different product. We see this a lot currently with ERP and SCM, and there is no reason to assume this will change. Option 5 is the holy grail, both ERP and SCM evolved together to a single intimate, modular ERP II solution.