SCM2 - a modular system

In my last article, I illustrated why an SCM2 system should be one holistic solution, and touched on the modularity of such systems. In this article I will dive a little deeper into the modularity aspect. The first half will discuss why it will be modular, the second half will discuss how this modularity will need to be structured.

As I mentioned in the previous article, there are two main reasons a holistic SCM2 system will and should be modular. First, it will be modular, simply because departmental boundaries exist and each department focuses on subareas within SCM. It is usually a single department within a company that has a compelling need for a SCM solution that triggers the search for a vendor that can address that need. The point-solution vendors for that area and the SCM2 vendors that provide a module dedicated to that area will be considered for purchase. Any vendors that only have larger solutions than the problem area will typically be considered overkill and will be ignored. Hence, SCM2 will be modular due to the vendor’s requirement to survive. Second, it should be modular, to allow incremental implementations of more encompassing solutions. From the customer’s perspective it is much more difficult to get project approval for a single 2 year project that costs $800K than it is for 8 smaller projects that build upon one another and each take 3 months and cost $100k. In the former scenario all the project risk is accumulated upfront, and the return will start no sooner than 2 years. In the latter case, the risk is limited to the smaller upcoming project and each project can be fully or partially funded by the return of earlier projects. The remainder projects can even be abandoned if earlier projects fail to deliver on promise. This provides significant risk mitigation and a much reduced impact on cash flow.

Obviously, the second point is also driven by the vendor’s need to survive, since it helps get the project approval and close the deal. Smart prospective buyers will recognize that even when they are at this time only interested in one point-solution that implementing a module of a holistic SCM2 system is much preferable over implementing a point-solution application. Implementing a module of a larger system provides a road map for future projects into related domains. Implementing a point-solution will force you to start the entire selection process over again with the next project and likely triple the implementation time due to the extra integration requirements. Even if at the current time no such project is planned, it is a fact of life and business that plans change. In the future a new solution may be required and you will be happy a visionary in your company made the right decisions way back now.

The fact that a vendor provides a modular SCM2 solution, not just a suite of loosely related SCM point-solutions, let alone just a single point-solution, speaks well of that vendor (see our first prediction). It means the vendor is a visionary company. From a customer’s perspective, if you want to be competitive, would you rather trail your competitors and buy the same thing they bought, or would you try to get or stay ahead of the curve and buy a more innovative product? The visionary customers, the early adopters, will drive the emergence of SCM2. The main market segment that play it safe and purchase proven - but possibly new - product will make or break this new paradigm. Modularity is key to show early success of SCM2 with the early adopters and persuade the main market segment to follow suit. By showing that the first project is at least just as quick to implement as with SCM old-style, and follow-up projects are completed in a fraction of the time, repeatedly for every customer, the proof is provided that the main market requires. Without modularity, SCM2 vendors will fight for the same stake in the same market as their comfortably settled SCM competitors, since they can only show equivalent results.  Of course there are many functional reasons to merge SCM applications into one coherent solution, but these are near impossible to convince prospective customers of with all the marketing hype all around. Who knows what is true and what is hype these days? The only market share that a non-modular vendor could hope to achieve is that of the early adopters. For completeness, I would like to mention the segment of the market commonly known as the laggards. This segment will prolong the survival of SCM old-style vendors for a while, maybe even for ten years, but at some point SCM2 will be out of date and the laggards will move on and in turn keep SCM2 hanging on for a while longer. History repeats itself. It always does.

Now for the interesting part. What form does this modularity take? What is the difference between different products integrated in a single suite and a single modular product? The first and foremost aspect is technology. Most suites of SCM products on the market today became suites through acquisition. Each of the products has a different code base and typically different technologies altogether. Some vendors have taken steps to reduce the distance between these products. In most cases though, unfortunately, they have only changed the user interface so that the products at least look alike. But behind the scenes they are still very different. A rare few vendors have re-written entire products to move them to the same technology as other products within the same suite. These truly are exceptions to the rule and hard to find (did I mention marketing hype already?). Even products built from the ground up by the same vendor frequently have different code base and different technology. A first product is typically mature before a second product is developed. By that time technology has evolved and for the second product a newer technology is chosen than the outdated technology of the first product. Typically also the development teams of the two products are different, and each have their own preferences, and usually there is some friendly competitiveness between teams. For existing products, re-implementing with a new technology is a huge investment. It halts - usually even reverses - the functionality improvements for years, leaving the current customers wanting and unhappy. It also introduces slews of bugs that were already ironed out in the mature release on old technology. At the same time competitors are functionally enriching their products and competitiveness and market share are at risk. Even with the best intentions technology shifts rarely take place in practice. As a result technology differences are first and foremost the reason suites of products do not ever move to becoming single modular products.

Let’s assume there are SCM suites out there where the products that make up the suite share the same technology. These products can now communicate with one another in proprietary forms. The differences with these and standardized forms of communication are performance, security, ease of development, cleanliness of product code, and resulting maintainability to name a few. Naturally these products should also provide standardized forms of communication for the many scenarios where they are integrated with other products not in the suite, but to not have to go the extra mile within the suite saves a lot of work and time and yields a much better and faster solution.

This brings up the topic of integration between products. Different products represent different silos of information. To make one product aware of information owned by another product that information needs to be integrated. Even if suites of products share the same technology, each product still holds its own set of data. There are many valid reasons why this is so. To guarantee the integrity of internal data, even when the product is implemented side-by-side with legacy products and competitive products, the product needs full control of all access to its data. Even if the products share the same instance of a database, the data is still in separate tables. In the best case scenario, the vendor has created standard integration between the products inside its suite. This means, technically, during implementation of each product very little work is required to integrate within the suite. However, conceptually, it does not make any difference at all compared to integrating with arbitrary products. Any implementation choices - or worse, customizations - made in one product now need to be aligned in any integrated products and the integration itself needs to accommodate this variability.

On the other hand in a single modular product the data integrity is guaranteed by that one product, regardless of which internal module has access to the data. When multiple modules use the same data, they all see the exact same particle in the exact same location. There is no integration whatsoever. Only one module owns any given particle of data. Any implementation choices - and customizations - are transparent in integration, since there is no integration. One module does not care how a particle of data that it uses was populated only that it is there. Since in general over 70% of any SCM implementation is spent on integration and data integrity, the fact that there is no internal integration whatsoever provides huge ROI for SCM2 over SCM old-style.

A secondary reason many SCM products within the same suite use different technology is that they have very different requirements. A demand management application needs collaborative input from many parties internal and external to the customer’s enterprise. It also still needs statistical forecasting capabilities as it has needed for decades. This requires a web-enabled multi-user platform with batch statistical power on the back-end to boot. On the other hand long-term strategic planning is always internal and usually a single power-user endeavor, with possibly just reports for casual users. These systems require a powerful LP or MILP optimization engine to generate optimal plans, and the requirements for those historically conflict with multi-user requirements where it concerns performance. A short-term scheduling system is typically also a single power-user environment and mostly utilizes heuristics to generate feasible schedules. Where for long-term planning the focus is on the power of the solver and optimality of results, for short-term schedules the focus is on user interaction, feasibility of the schedules, and ability to step in and adjust rapidly when unexpected situations arise in the plant. As a consequence the best technology for one product would have been detrimental for another product in the same suite. And vendors have consciously chosen different technologies in many cases. For demand management most products are server based with a web server to serve ultra-thin clients such as browsers and a large database for historic data. For strategic planning most products are client-server with a powerful optimization engine on the server, but requirements for a database and optionally a web server are typically low. For short-term scheduling most products run on a schedulers workstation.

These approaches can now be pushed to the past. Modern technologies and computing power of modern computers allow for highly scalable and secure multi-layered, multi-tiered systems where a logical place can be found for every functional area. Any functional area of SCM could benefit from multi-user capabilities provided the proper security is in place. Any area requiring powerful computing performance can have a designated and dedicated tier - even parallel processing capabilities within a tier- if necessary to accommodate this. Rich clients can still be connected to provide highly responsive graphic-intensive user interfaces without detriment to scalability, security and requirements of the other functional areas. In other words, the state of technology today is no longer a prohibitor to full scale SCM2 as it has been up to the recent past.

So, SCM2 will be a single multi-layer, multi-tier product on a single technology where modules share the same data. Modules however, even where they do share the same data, usually do not share that data at the same level of aggregation. Long-term planning spans the entire supply chain, but regards only groups of product, pools of capacity and buckets of time, where short-term scheduling focuses on a single plant, or single product line, or single warehouse, or single distribution channel, but does so at high level of detail. Demand management, like scheduling, is limited to a point in the supply chain, but is applied to various levels of aggregation, such as market segment, warehouse, product group or in detail. As a result aggregation becomes a crucial aspect of SCM2. Modules are aware of other modules around them even if the data they share exists at a different level of aggregation. When data moves from high detail to low detail aggregation is unambiguous, and the product will take care of it behind the scenes. When data moves from low detail to high detail the mechanism of distribution becomes a choice that should be adjustable during implementation. But other than that the mere fact that multiple modules exist is sufficient to make them aware of each other and work together.

As a teaser for the next article, consider the implications of such a mutually-aware modular system for the Sales & Operations Planning (S&OP) process…