SCM2 - one holistic solution

There is an incredible amount to write about SCM2. In my previous article the focus was on how the future of SCM relates to the future of ERP. The latter already has an enormous amount of publications to its name, but whenever I read anything about the future of SCM it either is gobbled up inside this ERP II (and doesn’t actually get much attention within that bigger scope) or it is limited to the near future of SCM as whole, not the far future of SCM software in particular. That gap is the main reason I started this blog. That the notion of SCM2 seems to conflict with that of ERP II was something that I wanted to get out of the way before getting to the meat of SCM2 to not scare the ERP II believers away before I even got started.

This article will be a first very high level overview of what I think it takes for an application to be SCM2. Let’s take a step back from the last article where I already got into some technical detail about the database behind the application, and forget about that for the time being. I will still compare SCM to ERP since the latter has evolved much further in my opinion. Where the SCM domain is currently still split in many subdomains each with its own small point-solution applications, most current ERP systems are truly one coherent system. SCM has a long way to go before it can match ERP on that front.

To be clear, most ERP systems are nowhere near perfect themselves in terms of coherency. They may incorporate every functional area in a single application, but to implement an ERP system usually requires setting an enormous amount of parameters and flags. In all cases I am aware of, parameters in one functional area can have direct impact on related areas. This means careful alignment of which settings are chosen in each of the functional areas, so they do not conflict or information gets thrown over a fence and doesn’t get picked up on the other side. To complicate matters usually a different group of experts is implementing each functional area, resulting in a high amount of project overhead to make the alignment happen. The situation gets much worse when customizations are required as you can imagine. Most ERP vendors ship their product with a set of industry-specific or even industry vertical-specific templates that have the most common combination of parameters that have already been proven to work well together to mitigate this hazard. Still, business-specific parameters always need to be set, and customizations are still commonplace.

Compare this to SCM for which there is not a single vendor (as far as I know) that combines every SCM functionality in a single product, although there are a few that combine a handful of the dozens in one product. With the current state of both SCM and ERP that makes the case that ERP will evolve into ERP II including all the SCM functionality a higher likelihood than SCM evolving into SCM2. The ERP vendors that already have a pretty advanced coherent system will have an easier task stepwise adding to and enhancing the basic SCM functionality they already contain. However, I believe the ERP vendors will hit a major and fundamental roadblock before getting all the way there, that some SCM vendors will not, since they are already on the right path (see ERPII or SCM2). Because of this they may still catch up and pass the ERP vendors, at least on their own SCM turf.

So why is a single holistic and coherent system so important? Why is it even a prerequisite for SCM2?

Well, if you have ever done a software implementation of any single supply chain management area, you might have found that the SCM part itself is pretty straightforward if the software is well designed, but integrating all the data to other systems is a huge and usually grossly underestimated part of any such project. Some exceptions exist, where the SCM  application needs very few different kinds of data from any external system, such as a simple demand forecasting tool. For any application that deals with more core processes of the business, such as manufacturing, the data requirements are more significant. Even if products are sold as part of the same suite of products this applies, although most vendors do have some pre-built integration for products they regularly sell together. This helps. It does, but it is not as evolved as the various tightly integrated modules within a single ERP system. The fact that implementing an ERP system brings a huge requirement for alignment between modules is not so much an issue of lack integration, but rather of unawareness between modules of the settings in the neighboring modules, even though the quantity of different kinds of data passed between ERP modules is typically very high.

In my personal experience implementing SCM systems I would say at least 70% of any project is spent on integration and data issues. If multiple SCM applications are implemented together a lot of this time goes to integrating those SCM applications amongst each other. With more than a handful of SCM areas implemented this time exceeds that spent on integrating the SCM with other systems such as ERP. By pre-integrating the SCM applications within a single suite vendors can greatly reduce implementation times whenever more than one SCM area is sold. If SCM could get on par with ERP on this front it would be an enormous step forward. To be fair to SCM vendors it must be noted that the concepts of ERP are less recondite than those of SCM; for example Generally Accepted Accounting Principles (GAAP) can be implemented pretty standardized for any industry, but the intricacies of how to squeeze the most out of manufacturing capacity is different for every single manufacturer, and require a much more abstract approach to be able to apply to more than one industry vertical. Where ERP vendors could and did focus on building horizontally deployable coherent systems, SCM vendors focused on making small niche areas more powerful, accurate and intuitive.

So as a first step forward SCM vendors can take the lessons learned in ERP to combine and pre-integrate SCM applications into a tight suite. This will help significantly reduce implementation time, and not unimportantly in this economy, project costs. But then, ERP and SCM vendors alike will have to continue down this path, and transform their suites of tightly integrated products in a single modular system, removing internal integration from the picture altogether. The difference between the two is a lot larger than one might think. If we limit ourselves to just data, as I have done so far in this article, it means that any settings and customizations in one module are automatically recognized by surrounding modules, removing the requirement to build and customize internal integration whenever that happens. Besides the time and immediate cost benefit, this leads to long term benefits such as being able to upgrade the system and still having standard product that allows you to get standard support. Note that the difference between a single modular system and a suite of products is not simply that the integration is transparent, it actually means that integration dissolves. Two products in the same suite that share the same piece of data will each have their own copy, whereas two modules within the same system will each look at the same single data location to pick up that shared piece of data. Ownership of such shared data is uniquely determined by the modular system, whereas in a suite of products the implementors will have to make sure they implement it correctly.

One holistic coherent system involves many other aspects than just one common data set, although data is undeniably the most crucial. I will leave the discussions about holistic user management, single sign-on, security, logging, auditing, validation, transactions, messaging and workflow to future articles.

The attentive reader may have noted that I make the case for removing all integration and making SCM one single system, but that the arguments for modularity have not yet been made. I do not think we could ever have a SCM system that does not separate the various areas of SCM. I think some of the historic delineation will fade somewhat, but will not and cannot dissappear altogether. There are a few reasons for this. First, companies are departmentalized. The software solutions they implement are usually championed by one or at most a couple of departments, unless they are championed by the CEO. The solutions will as a result also be departmentalized. This will not change. And rather than force prospective software customers to restructure their entire business to fit any given software solution (even in those cases where it would make sense), the prospective software solution should adapt to fit the business. Second, modularity allows for small incremental solutions to be implemented and built upon one another, rather than one huge implementation with huge upfront costs and risk before any return can be measured. Together these drastically lower the threshold to purchase and implement a modular system over a non-modular one, giving the former a competitive advantage in the market.

In a future article I will delve deeper into the requirements for mutually aware modules within a single SCM2 system.