This post has already been read 6872 times!
In the first article in this series, The Dead End of “Supply Chain” Thinking, we looked at the problem of traditional supply chain thinking, and how that reinforces invalid assumptions and leads to stagnation. This week in part two we examine a radical alternative that closely aligns with the real world and modern supply chain needs, and thus delivers much stronger and deeper benefits. A version of this article was first published in SupplyChainBrain.com.
The Network Solution
In part 1, I discussed the two major flaws in the old supply chain paradigm:
1. Single Enterprise Silos: Thinking in terms of chains has led users to build single enterprise silos, linked in pairs as an afterthought.
2. Sequential Batch Processes: Thinking in terms of chains perpetuates batch processes with sequential waterfall information flows.
The problem of course, is that a supply chain is inherently multi-party. It is a network of retailers, suppliers, distributors, logistics providers, manufacturers and contractors all collaborating to product the final product and move it to the end consumer. A technology platform to be effective has to recognize these basic facts, and facilitate all the operations within and among the multiple parties.
Four Criteria to Ensure a True Network Environment
In addition to fixing these flaws that linger from the chain paradigm, it is also important to understand what the architecture of true networks looks like. A good place to start is by understanding these four defining characteristics:
1. A network representation
Multi-party business systems must maintain the persistent and transient relationships between parties to pull together the bigger picture of the business network and enable win-win solutions for all involved. As an example, a supply chain network should be able to understand relationships of each partner in the value chain and consider cost-service tradeoff in relation to serving the end customer. Myopic approaches can naively push inventory and cost burden to weak suppliers that actually end up hurting the value chain. When done correctly, waste is eliminated in the value chain as a whole and everyone wins.
2. Hub-to-hub architecture
Multi-party solutions can’t be one-sided, and many networks today are implemented as hub-spoke architecture. The solution is designed with the hub enterprise as the focus and other enterprises and partners are on-boarded to serve the hub as “spokes.” True multi-party networks, on the other hand, provide value to each participant in a transaction through each one’s own vantage point. Everyone is a hub and everyone gets value.
3. Multi-party data management
As illustrated with the phone contacts example, single-party solutions to multi-party problems end up creating redundant data that need to be maintained separately, integrated and reconciled after the fact. A buyer’s purchase order and the seller’s sales order for the same transaction are really two views of the same data object. Multi-party systems can greatly simplify data representation to a canonical form and significantly reduce the possibility of errors, system complexity and the proliferation of EDI messages and message types.
4. Permissibility and security
Finally, multi-party solutions cannot be possible without a proper permissibility and security framework that assures each party can retain their private data and allows data sharing only upon proper authorization.
Re-Engineering Processes for the Network Paradigm
Rethinking business applications within a multi-party paradigm in mind opens the door to greatly simplifying the solution, radically improving the resulting value and slashing the overall cost of ownership. There are three design principles that can guide an organization to re-engineer processes for a network paradigm in order to achieve disruptive innovations and realize breakthrough results:
Continuous Processes: Shift from sequential to continuous processes.
Event and Exception Driven: Shift from batch planning and execution to event-driven sense and response such that execution, monitoring and planning are concurrent and continuous.
Multi-Party Orchestration: Shift from the paradigm of single-enterprise silos to customer-driven multi-party, multi-tier collaborative orchestration.
As an example, let’s apply these principles to the design of sales and operations planning (S&OP) processes. Traditional S&OP processes involve a monthly cadence of 5 sequential steps that include Product Management Review, Demand Review, Supply Review, Integrated Reconciliation and Management Business Review. By applying the design principles step by step the process will look like the following:
First, rather than having a sequence of meetings the business can challenge why product, demand, supply and other functions can’t be continuous processes and ask critical questions such as: Why does each functional team need to wait for predecessor teams to publish their plan in order for them to proceed with theirs? Why is Integrated Reconciliation a separate activity? Why can’t the individual processes of product management, demand management and supply management be continuous processes with continuous and simultaneous reconciliation?
Typically, the reason is that different functional teams are working with different systems using different terminology and metrics such that there is no way to share common assumptions. This is why when the plans are stacked up after the fact, they need reconciliation. If the different business functions were continuously working on a shared set of facts — but viewing them from their own perspectives — then reconciliation can happen concurrently such that the Management Business Review itself also becomes an exception-driven continuous ongoing process.
Why should the business stop and wait for certain meetings to occur before taking coordinated action? Most companies have already gone from quarterly S&OP cadence to monthly, and some have even added weekly huddles. Why can’t they have uninterrupted processes along each function guided by continuous shared visibility and exception events escalated to management review on a continuous basis as well? In this way, they would always be executing, always monitoring and always be planning as needed in real time –simultaneously and across functions.
When exceptions are escalated on an event basis from continuous processes, users want a prescriptive approach to orchestrate its resolution. Typically, this will involve going across functional boundaries, so if a new product is selling better than expected and causing supply shortages, the resolution may involve coordinated action between product management, demand management, supply management and finance. Further, each exception may require its own sequence of analysis, exploration of alternatives and coordinated action. This is where having process orchestration across functional units becomes very powerful.
In the next article we’ll take this even further, and look at an example of the network in action and the benefits it delivers.
A version of this article was first published in SupplyChainBrain.com.
Adeel has held numerous roles, including Senior Vice President, Products at One Network Enterprises and Chief Science Officer at JDA Software.
Adeel was named as one of Supply Demand Chain Executive Magazine's "Pros to Know" in 2009, 2010 and 2015. He holds a doctorate in Industrial Engineering and Operations Research from University of California at Berkeley.
You can follow Adeel on twitter @AdeelNajmi and on LinkedIn.
- Why Your Supply Chain Needs Blockchain - March 7, 2018
- What Supply Chains Really are and Why it Matters - November 9, 2017
- What is Machine Learning? - September 29, 2017