SCM2

Opposite Trends: Software and Business

2009-06-25T01:38:38Z

The first article written by our new author Vivek Sood on this blog immediately exposes some interesting tidbits. First, together with earlier articles Vivek has written (before he joined SCM2.org) he shows a clear focus towards the business side of the supply chain, where my own focus is on the software that manages those supply chains. Between the two of us there will already be a more diverse set of topics to be published here. As a result it is my hope that this in turn will draw a more diverse crowd of regular readers and spark discussions with more diverse opinions.

One very clear thing jumped up at me when reading his article: where the prediction on the software side is that they are becoming more holistic, the prediction for the business side is the opposite; the trend is to focus more on the core competencies and contract or outsource the rest. If both predictions are true the only possible conclusion is that collaboration between SCM software will not just become important, it will become imperative. Parties outside of your own enterprise will now hold even more of the information you need to make optimal decisions, and you need an easy yet secure way of getting that information on a continuous basis.

An interesting series of articles that discusses this very difference can be found at the Technology Evaluation Centers blog. It is a 3 part article written by P.J. Jakovljevic in this case specifically about the Retail industry (here are the links to part 1, part 2, part 3). The title is “Act Vertical vs. Go Extinct Retailers” but the important distinction as it applies to the opposite trends signaled above are what he descibes as “Act Vertical” versus “Be Vertical”.

Share/Save

The Coming Modularisation of the Global Supply Chains

2009-06-17T02:08:56Z

The field of international goods transportation has witnessed several great advances over the last 100 years. Of these, perhaps, none had more far reaching impact than the advent of containerisation. Before 1965, all packaged goods were packed into boxes of different sizes and shapes to be loaded on ships. General cargo ships themselves were small in size – no bigger than 20,000 tonnes or so – and stayed anywhere between 1 week and 4 weeks in any single port. About 70% of ship’s time was spent in non-value producing activities such as planning and loading boxes and crates of diverse sizes and shapes into the ships holds.

Containerisation changed all that. Ships are now built to carry standard containers of 20’ (or 40’). Containers are packed and unpacked in container yards far from ports – reducing the need for holding the ships in port, and costly warehousing space close to port. Size of container ships has increased greatly – the latest ones will carry nearly 10,000 TEUs (twenty equivalent units) or about 100,000 tonnes. These ships utilise more than 80% of their time on value-producing activities. No wonder the cost of shipping one meter cube of packaged cargo has gone down by nearly 75% to 85% in real terms over the last 40 years. This has made it possible to reconfigure the global supply chain in such a way that most activities are now carried out in the best place to do so. Manufacturing boom in China, super large container shipping companies, hub and spoke model of shipping, emergence of 6-10 global container terminals, are all partially a result of containerisation.

So what precisely is the magic in using standard shipping containers instead of boxes and crates? The answer is simple – modularisation. We believe that a similar move towards modularisation of global supply chains is emerging and it will have a far reaching impact on the organisations, nations and businesses. Before looking at its impact, let us examine what modularisation means in a wider context of global supply chains.

Imagine a supply chain which is able to instantly flex itself to the changes in your business structure and dynamics. Every time your company bought a division, you could seamlessly integrate its supply chain with your overall supply chain. Every time you divested a business, you could unravel the integrated supply chain without too much pain (and/or expense). Moreover, every time a trucking, freight forwarding, warehousing or shipping company proved itself incapable of meeting commitments made during the sales process – you could easily take your business to another one. Every time you reconfigure your manufacturing footprint, or alter your sourcing strategy, your supply chain follows closely. In other words, your business is not beholden to any one supply chain service provider or systems provider - because they are all interchangeable. The physical infrastructure, processes, systems and services involved in configuration of global supply chains are slowly but inevitably moving towards modularisation that will make this possible.

Modularisation, in this context, means breaking up of a greater whole into interchangeable parts that fit together seamlessly; and, together, in many different combinations and permutations, make many different wholes. The gradual evolution towards modularisation of supply chains is being spearheaded by the customers who demand control and flexibility in their supply chains coupled with low cost. Modularisation is preceded by Standardisation – achieving commonality in terminology, in measurements, and in activities. Standardisation is essential to modularisation because it helps simplify the complexity and bring uniformity. Imagine, if shipping containers were of many different sizes – rather than a standard container of 20’x8’x8’. Efforts to modularise general cargo shipping would have been seriously hampered.

Why is modularisation attractive? Because it helps us achieve homogeneity – a condition where products and services start looking more and more similar. Homogeneity, in turn, encourages substitution and/or switching between suppliers and hence commoditisation of the relevant market. This essentially leads to falling prices, and growing volumes – implications which we will analyse further after examining the causes of modularisation of global supply chains.

To further explore modularisation of supply chains let us examine each of the four components of the supply chains – physical infrastructure, systems, processes and services.

Supply Chain Physical Infrastructure:
Perhaps the most visible part of the global supply chain is its physical infrastructure. Shipping containers, air cargo containers, pallets, racking, forklifts, warehouses, ships, trucks, trains, ports, terminals – these are all gradually moving towards modularisation and standardisation. Many of these are already well advanced along the path towards modularisation and standardization. However, large amount of work still needs to be done to make sure modules all fit each other seamlessly. For example the pallets currently most used throughout Australia – CHEP pallets - are not sized suitably for loading into shipping containers. Their size does not allow for two of these loaded together, side by side, inside a container. However, because most of the trucks and warehouses are set up to accommodate these pallets it is not easy to switch standards, thus requiring costly double handling. Similarly, railway tracks in the various states of Australia are still in the process of being standardised after a long time spent double handling of cargo at state borders. Around the world, there are numerous examples of such inefficiencies in supply chains emanating from lack of standardisation and/or modularisation of physical equipment.

Supply Chain Systems:
The term modularisation originally emerged from supply chain systems. Most supply chain systems started off as trying to solve one single supply chain problem – which they did very well. As they expanded their reach through acquisition or product development, more modules were attached. While modules of systems from same company generally work together quite well, real flexibility emanates when the systems from different companies work together seamlessly. Whether it is demand forecasting system that needs to work closely with a inventory planning system, or a production scheduling system that needs to work with transportation route optimiser – the systems need to work with each other irrespective of the vendors. This is now becoming more and more easy. Use of XML and other open languages, web-based interfaces and standardised processes are leading to modularisation in supply chain systems to an extent where companies can choose variety of functionalities from a diverse range of vendors to form a customised best-of-the-breed solution that precisely meets their needs. Good CIOs are already saving their companies significant amounts of money by mixing and matching the right solutions. However, though they are willing to be a part of a best-of-breed solution, each of the major vendors of supply chain systems is still trying to sell itself as the best end-to-end system provider. This push, coupled with some of the disingenuous practices of the systems industry, leads to the conclusion that the level of modularisation in supply chain systems still has a long way to go before it becomes a standard accepted industry practice.

Supply Chain Processes:
Most business processes are increasingly being commoditized. (see article The Coming Commoditization of Processes by Thomas H. Davenport in Harvard Business Review June 2005 for more discussion on this topic). Supply chain processes, in particular, have an increasingly propensity for standardisation, modularisation and homogenisation. As supply chains, even for the smallest of businesses, are turning global in nature, standardisation is becoming necessary to reduce complexity. This in turn is leading to modularisation and an ability to outsource and offshore some of the low value-added processes. Finally, this modularisation is leading to homogenisation and thus commoditisation of the processes. That is because, while in their totality the standard processes of two companies may be sufficiently different from each other, but when broken up into smaller sub-processes or modules they are homogeneous enough to be carried out by many possible vendors – including internal incumbents.

Supply chain Services:
Supply chain services such as trucking, shipping, warehousing, third party logistics, railways etc. are always fairly homogeneous in nature. Control of supply chain assets does give temporary cost advantage in some locations, however, this advantage is neither universal not permanent. Supply chain service providers’ efforts to build barriers to switching by proprietary systems linkages have not proven very successful due to modularisation in the supply chain systems. Similarly, while size may provide some economies of scale and scope, and hence cost advantage, to the larger players in these industries – their claims to be uniquely qualified to carry out the supply chain task of a company rarely stack up. Moreover, it is self evident that none of the service providers have the physical capability to carry out all the supply chain tasks at all locations of a large multi-national organisation. More often than not they themselves use sub-contractors where it is expedient. While resisting modularisation by their customers, they tend towards it in their own operation. It will be fair to say that the supply chain services are fairly standardized and modularized. The customers only need to recognize and treat them as such while configuring their supply chain strategy.

Impact of Supply Chain Modularisation:
What will be the impact of this coming modularisation of supply chains? Firstly, Supply chain strategies will become increasingly important – something which could never be outsourced to your third party logistics (3PL) service provider in whichever avatar they present themselves. Secondly, modularisation makes it easier to homogenise and hence commoditise a market. Hence, whether it is the market for supply chain systems, or for processes, or for physical infrastructure or for services – these will be increasingly commoditised going forward. Companies will do well to prepare for this coming commoditisation and stay on the leading edge of the curve rather than grudgingly follow their competitors half-heartedly. Thirdly, this modularisation will change the face of global supply chains. All tasks will be carried out where it is most cost effective to do so. You can expect service factories to be the norm, working in unison with physical factories in different locations. Finally, this coming modularisation will consolidate supply chains’ position as one of the key drivers of the organisations’ competitive advantage. Supply chain strategists’ role will be viewed as much more than the dispatcher of trucks or the storekeepers – which have been the traditional forte of the logistics departments in most companies.

Case Study 1 - 1980s - Modularisation in the PC industry
Perhaps the clearest example of modularisation is the evolution of the Personal Computer industry in the last 25-30 years. 1981 saw the launch of the IBM Personal Computer. The IBM PC brought together all of the most desirable features of a computer into one small machine. It offered 16 kilobytes of user memory (expandable to 256 kilobytes), one or two floppy disks and an optional color monitor. When designing the PC, IBM for the first time contracted the production of its components to outside companies. The processor chip was from Intel and the operating system from Microsoft. IBM’s decision to outsource the two key components eventually led to the modularisation of the computer industry.

Dell utilised the emerging trend of modularisation in the PC industry to create a unique business advantage. While, it offers highly customized computers to its customers, the whole production chain and final assembly are highly standardized. This is because of the way a computer is built. All the components and sub components such as the motherboard, hard disk, graphics cards, memory etc. are available in a huge variety (e.g. for processors there are Intel Pentium, Intel Celeron, AMD Athlon, AMD Duron etc) and are essentially interchangeable modules performing essentially similar tasks. This makes it easy to offer the technical specifications that the customer wants. This and the fact that the computer chassis is easy to manufacture in different forms and colors and with the help of plastic “appearance parts” give it a wide variety of looks makes it very easy to offer a completely customized computer to the customers.

The below table shows the logical evolution starting with standardisation, via modularisation and homogenisation, through commoditisation:

Supply Chain Element	STANDARDISATION (emergence of common parameters – terminology, measurements, activities)	MODULARISATION (breaking up into smaller more manageable units)	HOMOGENISATION (creation of similarity between modules in order to facilitate switching	COMMODITISATION (multiple buyers competing on a level field to supply modules at best price	IMPLICATIONS
Physical Infra-structure	Use of standard shipping containers, pallets, warehouse designs, ships etc.	Containers, pallets, ships, tanks etc. become interchangeable modules	TEUs, pallets etc. are standard unit of carriage. Most business is carried out on these terms.	All buyers and sellers in the market become price takers. Massive growth in volume and ship size.	Massive growth in world trade as businesses carry out manufacturing where it is most cost effective.
Systems	Standard supply chain systems emerge with recognised functionalities and capabilities.	Systems are increasingly configured as modules which work together with other modules from same or different vendors.	Similar modules of different vendors become interchangeable. System modules become homogenised units of trade.	Systems become increasingly a commodity - conferring no particular competitive advantage. Prices start drifting lower.	- CIOs’ role in mixing and matching a best-of-breed solution becomes paramount. - Easier to configure systems that match business needs. - Systems aid rather than hinder process and service outsourcing, offshoring and switching
Processes	Standard supply chain processes with well articulated inputs, outputs and intermediary steps.	Sub-processes are configured as modules which work seamlessly with other sub-processes.	Sub-process modules are increasingly homogenised to effectively create a market in these.	No special profits to the business process outsourcing companies or the companies that outsource processes.	- With minimal switching cost sub-process will be carried out where they can be most effectively and efficiently done. - BPO will become a norm rather than exception. - Large process factories will emerge that allow the same economies of scale and scope that are the norm in physical factories.
Services (transportation and storage)	Standardisation of supply chain services with standard contracts, measurements, management mechanisms and prices.	Service components are broken up into geographical, asset based and activity based components to discover and engage best service provider for each module.	Service modules are homogenised in order to create and manage interactions with several service providers at same time.	Company mixes and matches service modules from a variety of service providers	- Each transportation and warehousing task carried out by the company with the best location, asset and scale advantage. - The customer manages multiple interactions with several service providers simultaneously, based on clearly agreed service parameters.

Case Study 2 - 1960s - Modularisation of the Ship building industry
During the 1960s, the shipbuilding industry reduced the cycle time for building a large ocean going merchant vessel from 3 years to 6 months by modularisation. The whole ship’s structure was divided and sub-divided into smaller and smaller modules that were produced simultaneously by a number of satellite suppliers just-in-time to brought together and joined together into a final assembly. The whole system is still one of the finest examples of a well-orchestrated supply chain in motion. Tremendous benefits in terms cost and production time reduction, increased throughput, flexibility and customisation ability accrued to the shipping industry as a result.

The Japanese ship building companies utilised this emerging trend to their great advantage. With their Kieretsu type structure, lean manufacturing processes (and government assistance) they rapidly built substantial cost advantage and market share that lasted till the Korean Shipyards (and now Chinese shipyards) copied them. A typical Japanese shipyard was surrounded by ancillary businesses that supplied modules and sub-modules to the shipyard, and were totally dependent for their business on the parent company. Close co-ordination eliminated waste, reduced cycle times substantially and led to significantly lower turnaround times.

Share/Save

The current state of S&OP

2009-06-10T14:24:05Z

As a prequel to my upcoming post about the future of Sales and Operations Planning (S&OP) I thought it would be good to at least once discuss S&OP as it stands today. Rather than re-invent the wheel on this much discussed domain I’ll refer to one of the acclaimed experts on S&OP, Tom Wallace.

Sales and Operations Planning has become somewhat of a confusing term. The domain has existed and evolved for decades. In the process it has changed considerably and of late has been hyped a lot. Nowadays when people talk about S&OP nobody really knows what form of it one means. In my opinion Tom Wallace explains it best in his book Sales & Operations Planning - The How-To Handbook, 3rd edition. For anyone who has to embark on an S&OP project, but has no hands-on experience doing so, this book is a recommendation as a starting point.

There is an interesting interview with him on the 21st Century Supply Chain blog. In my upcoming blog post I will follow the same direction Tom Wallace takes in his books and this interview.

Share/Save

New author: Vivek Sood

2009-05-21T05:26:52Z

We are happy to announce that Vivek Sood has joined SCM2.org as a regular author. He complements the team with his different industry focus, specialties and geographic location, which is sure to lead to more diverse reading.

Vivek has over 24 years of experience in strategic transformations and operational excellence within global supply chains. Prior to co-founding Global Supply Chain Group in January 2000, Vivek was a management consultant with top-tier strategy consulting firm Booz Allen & Hamilton, various other companies, and 11 years in the Merchant Navy. He has broad industry experience including in FMCG, food, shipping, logistics, manufacturing, chemicals, mining, agribusiness, construction materials, explosives, airlines and electricity utilities.

Vivek is a regular and accomplished speaker and author. He lives in Sydney, Australia.

His bio can be found on the about page. For his extended resume see his LinkedIn profile.

Share/Save

SCM2 - a modular system

2009-05-17T17:08:34Z

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…

Share/Save

SCM2.org Prediction #1: the Death of SCM

2009-05-12T19:46:23Z

This is the first in - more than likely - a series of predictions we’ll be making here on SCM2.org.

Prediction #1: The Death of SCM

At least as we know it today. There are two viable paths forward for SCM: ERPII or SCM2. But a standalone point-solution or a suite of loosely coupled SCM point-solutions are not going to be around ten years from now.

The vendor with a single point-solution is already an artifact from the past. If it hasn’t happened yet, at best it will be gobbled up by a bigger vendor in the foreseeable future, only to have its point-solution become part of a suite of loosely related peers. At worst, it may still be acquired only for its install base, or it will simply go out of business. In either of the worst case scenarios, as a customer you are stuck with an unsupported and stagnant product, or will be required to go through another expensive project. The status quo currently are the vendors that provide a suite of loosely related point-solutions. These vendors do provide a way forward after a first solution has been successfully implemented, and therefore are in general faring much better than the single solution vendors. The exceptions to this broad sweep statement are those vendors that sell a truly unique product. And these vendors will continue to do well until a more encompassing solution hits the market that covers their uniqueness, whether it be an SCM suite or a SCM2 solution. Our prediction is that the suites of SCM point-solutions will disappear over the next ten years just like the single point-solution vendors have over the last ten years, as more and more ERPII and SCM2 solutions hit the market.

The ERPII scenario is most likely for mainstream horizontal solutions for two reasons:

The mainstream scenario is much simpler and that makes ERPII a more attainable objective.
Many vendors are already on this path.

In this case SCM vendors are likely to be acquired into ERP companies, and their products likely to get a new life in a new form. A number of SCM vendors may do the opposite and instead acquire an ERP product to complement their footprint. A number of vendors exist that already own all the necessary products; sometimes multiple equivalent products. These vendors will simply merge their product lines to provide ERPII. Whether this merging is limited to product marketing only, simple technical integration, or true technological integration, will vary by vendor and time will tell which are which. The reasons the remaining single-point solutions will not survive in their current form are multifold. First and foremost, their smaller revenue make them easy acquisition targets for the huge vendors out there. Second, since they do not provide a clear road map for future implementations in related SCM areas, many prospective customers will choose vendors that do provide a road map, i.e. vendors with more related and integrated products in the same suite. These are not visionary statements; the trend is already clearly visible.

The SCM2 scenario is most likely for niche vendors and industry vertical oriented vendors. However, the acquired point-solution products -whether standalone or integrated in a suite - will have little to offer for the established SCM2 vendor. Those products were not designed from the onset to allow the kind of tight modular integration required for SCM2. More likely than not the vendors will be acquired simply for their install base, and their products will be retired.

The reasons SCM2 will co-exist with ERPII are twofold:

SCM2 will claim the industry vertical and niche market stake that mainstream ERP vendors currently and their future ERPII descendents cannot provide the right fit for.
SCM2 will be much quicker and cheaper to implement due to the modular structure than the integrated suits of ERPII products. This provides a huge value that has a similarly huge market appeal.

In summary, SCM will not truly die, but it will evolve into something else. The Neanderthals did likely co-exist with Heidelbergensis and Erectines before they died out, and those in turn likely co-existed with Homo Sapiens. Are we truly something new, or do we still have some Neanderthal in us? Like the Neanderthals got extinct, so will SCM as we know it. And like the Neanderthals are referred to as hominids like ourselves, so will future forms of SCM still be referred to as SCM.

Share/Save

SCM2 - one holistic solution

2009-05-12T19:44:35Z

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.

Share/Save

ERPII or SCM2?

2009-05-12T19:42:38Z

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:

ERP II built on RDBMS including basic SCM functionality
old-fashioned ERP built on RDBMS integrated with independent old-fashioned SCM point solutions
old-fashioned ERP built on RDBMS integrated with SCM2 built on ORDBMS
ERP II built on RDBMS integrated with SCM2 built on ORDBMS
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.

Share/Save

Supply Chain Management: what is it? - PART 2

2009-05-12T19:39:10Z

This second posting on our new blog continues the description of where SCM stands now. It is necessary in my opinion to write these postings on the status quo before I can start with the forward-looking articles that this blog is really about. This particular posting is part 2 of the article Supply Chain Management: what is it?

In the first part I delineated SCM within the enterprise application landscape at a macro level. I gave a broad definition of SCM and what is in and out of its scope in general terms, and how it is related to other enterprise domains such as ERP, CRM and MES. In this second part I intend to be more specific as to which known functional areas fall under the SCM umbrella. A warning to the casual reader: this will unfortunately involve quite a number of acronyms again.

Let’s make a short journey across the supply chain starting at the demand side and work our way towards to supply side. Along the way I’ll discuss the functional areas that exist at each step.

Demand

Undeniably demand is one of the most important, if not the most important, aspects of any supply chain. It certainly is the most important contributor to the livelihood of any production business. The roles SCM plays on demand are somewhat limited, hence demand may not be the most important focal point for any SCM implementation. For example, demand generation is owned by sales and marketing departments, and these seldom use SCM systems. Demand generation is a very involved process of reaching out to customers, prospects and other influencers in which relations are acquired, nurtured and demand is created. In contrast, SCM limits itself to the relatively laid back process of forecasting demand and at most influencing it. The first demand centric applications in the space now known as SCM were simple sales forecasting tools. At first these were limited to taking last year’s sales numbers and assuming this year’s numbers would be the same. Then they evolved into applications that could use any number of statistical and regressional methods to forecast future sales based on many years of historic data, using the best combination of methods for each individual product forecast. By the time more sophisticated functionality such as pyramid aggregation and distribution (or proration) were added these systems were commonly known as Demand Planning (DP) applications. These systems also typically output a safety stock to cover any underestimation in sales forecast and prevent stock outs. The next major improvement involves user collaboration. The impact of having the right experts enter their adjustments to a statistically calculated forecast is usually many times higher than the few extra percentage points that may be squeezed out of an already decent statistical forecast by improving on the methods. The right experts are however in the sales and marketing departments of your company and any number of people in your downstream supply chain partners’ companies. This means giving the option and the incentives for those experts to actually enter their knowledge on a continuous basis. The applications that provide that option are known as Demand Management (DM) systems. Frequently, these systems also cover the Promotions Management and Pricing & Revenue Management type functionality (thankfully, these areas do not have generally accepted acronyms of their own!). This is where SCM becomes more proactive on demand to actually influence it in order to increase revenue, rather than just forecast what it will be. For many industries this has a HUGE potential impact on the bottom line.

Once demand has been projected into the future the generated numbers can be used by many business processes. As a rule of thumb, all forward-looking uses are the domain of SCM. This can be at various levels of planning ranging from the very broad and high level Strategic Network Optimization down to operational point solutions such as Available to Promise (ATP). The high level processes will be discussed in more detail later in this article. ATP is where a sales rep (or a customer via a sales portal) asks the system whether an order can be delivered on time and in full if ordered now. The sales enquiry is checked against unconsumed forecast for that customer or group of unnamed customers. If the unconsumed quantity is larger than the requested quantity the product is available to order. This relatively simple process has more advanced counterparts and more simplified counterparts. Usually ERP systems provide an altered version where the sales enquiry is not compared against unconsumed forecast, but rather against unreserved inventory that is already on hand. The downside is that ATP in that form cannot look very far forward, which makes sense since ERP itself is not forward looking, and simply misses the required data to do the longer range version.

Note: One software application dealing directly with demand that is commonly mistaken to be part of SCM is Sales Force Automation (SFA). The only reason I mention this here is because this mistake is so common. SFA truly belongs under the CRM umbrella. It deals with relationships, not product flow.

Sourcing & Distribution

Demand trickles (or in good times, gushes) along the supply chain where one of the first stops is the distribution network. Demand from many customer locations is grouped into distribution centers and warehouses that supply those locations. This can be a multiple step distribution network where product may come from any number of plants to go to any number of distribution centers, warehouses, forward warehouses and satellite warehouses, and may in some circumstances allow inter-warehouse transfers. At each distribution step inventory may be kept of any product that flows through that warehouse, causing a decoupling of the demand patterns accumulated on the shipping end and the required supply patterns on the receiving end of each, and an inventory management requirement in the middle. Both of these cause issues that may need to be addressed. The pattern mismatches between supply and demand are the main cause for the so-called bullwhip effect (an article on this will surely be posted on this blog in the near future, wink to my wife). This negative effect is amplified when any or all of the demand, supply or inventory management is done by different parties and information not shared amongst them. A good collaborative system that allows every party to make their plans, even fuzzy far-future plans, known without immediate contractual lock-in can adequately address this. For the inventory management requirement many applications exist in the SCM space that address it ranging from strategic via tactical down to operational. The strategic and tactical ones are typically part of a larger solution that will be covered further down in this posting. On the operational side of the range the most notable functional area is Warehouse Management Systems (WMS). These frequently extend into executional detail, making it unclear whether WMS would fall under SCM or ERP. In my opinion, the more proactive, forward-looking implementations should fall under SCM, the more reactive, present-looking implementations would fall under ERP. Which type you implement is largely dependent on the industry you are in. Where distribution concerns itself with what goes where and how long to keep it on inventory, sourcing deals with where the product comes from. The two are typically optimized hand-in-hand.

Transportation

Once you know what product needs to supply which warehouse by when and where to source it from, you can plan how to get it there. The transportation functionality, like all other functionalities in SCM, is historically segmented, but combined solutions exist where the value of the combined solution is higher than that of the sum of the parts. The two well known areas are route optimization and load planning. The former tries to solve the infamous traveling salesman problem which answers the question what is the optimal route to deliver to all locations with the shortest total miles. A modern day version may optimize for the lowest total use of fossil fuels and emissions. The latter determines which orders to place where on a truck to ensure the unloading at each location is done in an efficient manner while keeping the load balanced for the next segment of the route. In certain industries product is shipped in bulk and trucks, wagons, or compartments within them can have complex rules on what product may use it after another one, even multiple loads later. Other areas of transportation planning (TP) involve minimization of total cost by optimizing on freight rates which fluctuate highly by time of the year, area, mode of transport, and transport company. On a tactical level transportation can be one of many influences that determine an overall optimal plan using a single solution.

Manufacturing

Manufacturing is for many industries undoubtetly the area of SCM with the most complexity. And as an extension of this, the area with the most opportunity for improvement in terms of cost reduction, and revenue, cycle time and service level increase. Those industries where this statement is untrue are typically well served with the basic SCM-type functionality available in most ERP systems. The industries for which the statement is true, are the prime reason SCM even exists as its own domain. Assuming either a strategic or tactical plan has already determined how much product to manufacture at each plant, or that there is only one option (single-sourcing), there are still a plethora of application types to fill in the plant-level detail. Age-old Material Requirements Planning (MRP) and Capacity Requirements Planning (CRP) determine unconstrained combined raw material requirements and a rough estimation on plant capacity utilization respectively. Usually the input for either is an even rougher Master Production Schedule (MPS). CRP evolved into Finite Capacity Scheduling (FCS) which has the same objective, but does it accurately, and combined with MRP evolved further into Advanced Planning and Scheduling (APS) to cover both material and capacity simultaneously and accurately. A number of industries also have a need for formula optimization, where the mixture of individual lots of raw materials or intermediates are determined to produce other intermediates or finished goods within certain specifications. For beverages these specifications may be sugar content and acidity; for chemicals these may be elemental specs or particle size distributions. This falls squarely within the SCM domain. In various scenarios the end specification may be met by choosing from a named number of predefined recipes, rather than the infinite options of mixing any amount from any lot with one another. In those scenarios a simplified version, commonly known as recipe optimization may be used. Some SCM and some ERP systems provide the latter, although strictly speaking this too should be owned by SCM.

Supply

Finally the pull of demand reaches the start of the supply chain via all the areas mentioned above (not necessarily in that order). For most businesses there is little at an operational planning level on this side of the supply chain. At a tactical level, most businesses incorporate a sourcing decision for particular suppliers. But once you know the requirements from manufacturing it boils down to getting the desired product at the desired quality at the lowest price, which is left to the purchasing department and formalized using ERP. Some industries however have to deal with seasonal supply; for example when the raw material is harvested. This seasonality has an impact not only on quantity available, but also on quality of the product and price. For these businesses it is important to forecast supply in similar fashion to forecasting demand. Both these forecasts would input into a Supply Chain Planning (SCP) optimization to determine optimal tactical plan to minimize overall costs.

Holistic

Besides the point solutions mentioned so far, there are also a number of holistic planning or optimization areas within SCM. SCP mentioned in the previous paragraph is one such. Along with demand forecast and possibly supply forecast it incorporates aggregate data on manufacturing, warehousing and transportation capacities, to come to its results. The results of these strategic and aggregate optimizations are the inputs to the various point solutions. The results could include suggested shift patterns or overtime, changing routes from default sources, along with the standard capacity allocations. These are all tactical planning decisions, although in many businesses the term “strategic” is used for some of its results (such as stratetic inventory buildup). Another area that potentially spans the entire supply chain is Capable to Promise (CTP). Where ATP looks only at demand forecast consumption (or only at on hand inventory consumption), CTP looks at available manufacturing, warehousing and transporation capacity to give a promise in certain cases where ATP cannot. An extension of that is Profitable to Promise (PTP), where the incremental costs of the freed up capacities are taken into consideration to determine if it is worthwile to promise even if there is a capability. A popular topic within SCM that spans multiple areas is Sales & Operations Planning (S&OP). This is very treacherous ground where representatives from sales teams and various operations departments battle over what is possible. Historically this business process requires all the team members to meet in a single room on regular basis to come to agreement on how to compromise mismatches between what sales has promised or wants to promise with what the supply chain can cope with. There is great potential in relieving this conflict using SCM software. Finally, there are some strategic optimizations of which Strategic Network Optimization (SNO) is the most formalized one. This optimization determines whether it makes sense to open or close facilities or reduce or increase capital capacity such packaging or production capacity in individual facilities. Outputs of strategic optimizations can be used when entering into long-term contract negotiations, rather than be constrained by them. Most other strategic optimizations are ad hoc custom solutions built for a very specific purpose.

Well, if you are reading this line, you got further that I thought anyone could come in this rather boring summary of what SCM entails. This was a difficult piece to write because there is just so much to say about each area. I sought to find a balance between clarity through extent of descriptions and providing examples and brevity to the point of significance to the real purpose of this blog: the future of SCM. The end result is more tedious than I like to associate myself with. But so be it. If popular demand persuades me to write in more detail about certain areas I may do so, but until then I will happily lay the past and present to rest and focus on the future.

Share/Save

Supply Chain Management: what is it?

2009-05-12T19:37:30Z

This is a first posting on our new blog on Supply Chain Management 2. I thought it would be a good idea to first set the premise, so everyone can put the discussions on where we are heading into a shared perspective of where we are now. I think this may become a multiple posting topic, since there is just so much to say. This topic also does run the risk of running amok with acronyms and buzzwords. Given that the industry is riddled with them, there is no easy way to avoid that when describing the status quo.

I can imagine that all the acronyms that are going around in the enterprise software space are confusing to many people. It gets confusing to me sometimes, and I am deeply immersed and have been for well over a decade. What is SCM? How does it relate to ERP, CRM, SRM, EPM, EAM, BI, SaaS, cloud computing, Web 2.0, sustainability? How about Value Chain Management or demand-driven supply chain? How are these different from SCM? These are just a few of the buzzwords going around. It is impossible to give a straight answer that will make everything perfectly clear, once and for all. If it were, someone would already have done it. Worse, I believe that at least a few of the buzzwords were introduced with the specific purpose to confuse matters; some of the more powerful vendors out there have in the past introduced terms for the simple purpose of hiding the fact that they lacked functionality and making the market believe that they had more, rather than less. Some of them stuck, and are here to stay to confuse an already confusing jumble of terms. In this article I will try to clarify as much as possible.

I’ll take a 2-step approach. First,I’ll introduce an overly simplified approach with which you may determine for yourself where SCM fits in your systems landscape, if at all. Then I will provide more generalized background and definitions. I find that it helps to take a step backward to more general concepts that apply to any process that we want to do well, and continuously improve upon. You may already be familiar with the schematic on the left-hand side of figure 1 below:

Figure 1: Concepts landscape versus an example of a systems landscape

To achieve continuous improvement of a process you need to plan it, execute the plan, measure the effects, analyze the measurements, and use the outcome of the analysis to plan better next time around. This schematic is only a simplification; in practice there may be many other influences, or additional links between steps, or shortcuts. For example, the result of an analysis may be to better execute upon a plan, rather than to better plan, which would result in a link between analysis and execution. Or, there may be no formalized measurement step, resulting in a shortcut from execution to analysis. In broad lines though, I find that this schematic works well, for decisions ranging from minor to major process overviews such as a systems landscape.

A common occurrence of a systems landscape that fits the plan-execute-measure-analyze-repeat paradigm is the example on the right-hand side of figure 1. ERP covering the execution aspect is almost universally applicable; and where it doesn’t one may ask themself, shouldn’t it? However, not for all businesses can the case be made for a Manufacturing Execution System (MES). Sometimes, a Laboratory Information Management System (LIMS) is more applicable, and there may be other types of measurement application that apply to certain industry niches. In either case, there may be additional measurement systems that facilitate these systems, such as RFID or barcoding. Similarly, Business Intelligence (BI) may be overkill for certain applications or industries. Or (Enterprise) Performance Management (EPM/PM) may take the place of BI in many cases. Arguably the latter may simply be specific approaches to BI anyway. Finally, depending on your industry and business process, SCM may or may not be the best type of system to cover the planning aspect of the cycle. For example, if you are planning introductions of new product, a Product Lifecycle Management (PLM) is better suited than if you are planning production for an existing product, even in the same industry.

To confuse things a little more, most enterprise applications do not strictly confine themselves to one of the functional domains above. This is a good thing! But it does not help in obtaining clarity. So why is this a good thing? Well, say you absolutely need ERP, but only need a very small portion of what fullscale SCM has to offer. You will be happy to learn that pretty much every ERP vendor out there provides basic functionality that should strictly fall under the SCM umbrella, at no or little additional cost. Not only can you get the functionality you need; it also prevents you from having to embark on yet another major project. The aforementioned is not just true for ERP covering basic SCM needs. In fact, most ERP systems boast basic functionality in almost any other enterprise application domain in existence (watch this blog for a future article on ERP II, discussing the continuation of this trend). Likewise, most systems that focus on any of the other domains cover basic needs in any related domains.

After this lengthy introduction the time is now right to pose a definition of Supply Chain Management:

Supply Chain Management focuses on planning, or managing the future of, anything directly related to the product flow within your supply chain.

Let me first add the disclaimer, that this will likely not be a universally accepted definition, nor will any one definition ever be. But it is general and broad enough to accommodate the most common intersection of opinions on the matter.

The definition begs for some explanation. First, notice the bold discriminators in the definition. These truly capture the essence of SCM:

planning - SCM is about making plans. Forecasts fall under this categorization too. Plans change. Plans change all the time. Until something is executed it is possible, even likely to change. Execution is the realm of ERP, and once something is executed, that is the way it went. This requires unique identifiers for pretty much everything captured. But the further out you plan, the less likely it will happen that way, and unique identifiers become less of benefit and more of a burden.

future - SCM applies to the future. The past and present are reserved for MES, LIMS, ERP, and CRM, to name a few. There will be some overlap of course. For example an order will exist within ERP before it actually takes place, but at that time it is a firm stated objective. Some readers may note that for example a planned production order exists well ahead of its planned date, but this happens to be one of those examples where ERP actually covers some of the SCM basics. Planned orders should strictly speaking be owned by SCM. Another example is Demand Management, which falls within SCM. It heavily uses demand history, but it does so for one purpose only: to forecast the future.

product flow - SCM is all about the product flow: moving the product through its various stages and locations from raw material supplier via manufacturing and distribution networks to the customer. Anything that deals with other kinds of information is out of scope, unless it can be influenced directly to impact product flow. For example, relationship information is owned by systems such as Customer Relationship Management (CRM) and Supplier Relationship Management (SRM). Deviations to accepted guidelines and CAPAs to address these are owned by Enterprise Quality Management Systems (EQMS). SCM may use some inputs of such systems to influence product flow, but does not own them.

your supply chain - This bullet can be subdivided in two parts. First, every company’s supply chain is unique. Even though a supplier may be in your supply chain, it does not share your other suppliers, and it may have other customers besides you. In other words, your suppliers supply chain has overlap with yours, but is not identical. The same applies to every other party in your supply chain. SCM is not about managing a supply chain, but about managing your supply chain. Your supply chain, albeit different from that of your suppliers, 3PL’s, customers, etc, still contains them. SCM does include those parties (i.e. it expands beyond the borders of your enterprise) and all parties benefit from sharing information where your supply chains intersect. Second, it applies to your supply chain, not your relationship network, nor your information flow. Systems that manage those can be tightly integrated to SCM to influence each other, but can easily be separated without negative impact on the end result. In other words, this discriminator highlights that SCM covers the entire span and width of your supply chain, but limits which aspects of it are owned by SCM.

Last, but not least, note that the definition states that SCM focuses on, not that it is limited to, the above. This is in line with the observation that most enterprise applications cover some basics of bordering functionality, typically owned by other enterprise application domains. Any given SCM system may very well contain functionality that is not strictly within scope of the 4 bullets above. Similarly, any given ERP, CRM or other enterprise application will contain functionality that fits squarely within the combination of bullets above.

The discussion up to this point covers aspects of SCM that are definitive for the domain. Whether we are talking about the current state of SCM or the future, the definitions above should apply equally. In cases of ambiguity in any of the articles posted in this blog we will refer to current state of SCM as SCM1 to distinguish it from both the envisioned future state (SCM2) and the domain as a whole (SCM).

By now you should have a general idea of how SCM compares to distinctly different domains, such as ERP and CRM. But what about those buzzwords you hear such as Value Chain Management and Demand-Driven Supply Chain? Isn’t most of any manufacturers value in the supply chain? And isn’t every supply chain demand-driven? Yes, and yes. Truth is, these terms and other terms like it are merely variations on the same theme. The problem is, the term “supply chain” is poorly chosen. Usually it isn’t a chain at all, it is a complex network of relationship-, information-, and product flows. More of a chainmail, rather than a chain, and with many irregularities in the weave at that. Also, it comprises not just supply, but also demand, and all the processes to make them meet. Many of the spin-off terms of SCM are simply due to the fact that vendors just did not recognize themselves in this ill-fitting term. And if one decides to distance oneself from the term, might as well pick a new one that highlights ones strengths and masks ones weaknesses.

Some buzzwords are clearly industry related. For example, the qualifier “demand-driven” would never be used by any vendor serving the process industries, because it indicates that the application cannot handle supply driving the supply chain. In process industries it is very common that supply has its own seasonality, forcing the supply chain to absorb peaks of supply, while demand follows a completely different pattern. When the harvest comes in, better purchase raw material while it is cheap and of high quality, and process it right away, rather than wait for demand to catch up only to have to purchase low quality material for a premium. To survive inside the enterprise application space one has to learn to see through the buzzword-screen. If you are selecting an SCM system, ask yourself why a vendor chose to stray from the common terminology. Ask about the positives and try to reveal the negatives. The buzzword may indicate that the product fits your business like no other, or it may indicate the opposite. Unfortunately, there is no clear road map that distinguishes one variation from another, or better still one application from another using the same variation. When choosing an SCM system, basic domain knowledge, detailed business requirements, common sense and perseverance will determine whether you buy a diamond or a lemon.

I think enough has been said about the various functional domains inside the enterprise application space. Very briefly I want to touch on some of the other terms mentioned in the first few paragraphs. In short, terms such as “SaaS” (Software as a Service), “web 2.0″ and “green” that you have been hearing about everywhere these days only apply tangentially to SCM. They apply. They just apply as much to any other functional domain within the enterprise application space. For example, SaaS, also known as on-demand, is merely a question on where to host the application, not what describes the application. The same with web 2.0. The general rule is: the newer the application (or more up to date) the more likely it allows you to choose between old-fashioned on-site deployment and modern day on-demand, rather than only allowing the former. Web 2.0 can easily be applied to an old application like a new coat, or a new application can be built from the ground up to support it. Neither is better or worse per se. Green or sustainability is a hot topic these days. And it certainly has application in SCM. Most businesses do not yet care about going green, or simply do not have the luxury to make that choice, especially in the current state of the economy. But if you do, plenty of vendors are now extending or building new systems that allow sustainability to drive the supply chain (not just demand ) Reducing waste, energy and emissions, increasing recycling and re-use are clear examples that can be driven via SCM. Personally, I am excited that this is finally getting some attention, and that vendors and manufacturers alike are making steps in the right direction.

All in all, they do not determine whether a product qualifies as SCM or not. But if any such objective is important to you, you’ll be happy to know that you have multiple vendors to choose from that support any or all of them.

I hope this first blog posting was useful to you. Hopefully the immense number of acronyms, buzzwords (including the buzzword “buzzword”) did not put you off, but rather helped make sense of the mess we call home away from home. As a first posting this may give the wrong impression, since I do not anticipate using nearly as many in future posts. I welcome any feedback!

Update March 17, 2009: Part 2 is now also available here.

Share/Save