For over a decade, many companies have attempted to build elaborate networks by connecting supply chain partners and their systems. Unfortunately, most have simply re-implemented the same old business processes that have been designed for the chain paradigm. While connecting partners in this traditional sense may have resulted in modest incremental performance gains, there are huge opportunities yet to be seized. This is because most are still locked into the chain paradigm and are held back from realizing the full benefits of networks.

More specifically, there are two fundamental flaws from the old “chain” paradigm that linger on:

Single Enterprise Silos: Thinking in terms of chains has led users to build single enterprise silos linked in pairs as an afterthought.

Sequential Batch Processes: Thinking in terms of chains perpetuates batch processes with sequential waterfall information flows. 

Let’s use a familiar cell phone contact management apps example to illustrate the limitation of designing for single-party silos. Most phone contact apps are designed for a single individual. If you happen to update a contact on your phone, all the people with whom you may have shared this contact previously will be stuck with the obsolete information. In contrast, a social network app such as LinkedIn lets everyone keep their own information current, and contacts are shared by simply making connections. Individuals do not have to share updates to their contacts, as it just happens through the network naturally. There is no duplicate information that needs to be synchronized, and there are no silos to connect, as the social network app was designed for a network of multiple parties from the ground up.

If a problem is inherently multi-party, then solutions designed within a single-party paradigm create unnecessary complexity and involve excessive maintenance costs. Multi-party solutions require different information models and fundamentally different architectures, so users often find these single-party solutions unable to meet their real world requirements. This is the fundamental flaw in the design of most supply chain systems today, as they are designed as single enterprise systems even though supply chains are multi-party in their very nature. In today’s environment, just a single business transaction can involve a mix of buyers, sellers and various service providers. Yet, many systems still treat each enterprise as an island and companies are forced to integrate between these islands as an afterthought.

The second major flaw is in breaking down supply chain planning into a sequence of en-masse decision silos and then throwing the resulting plans over the wall to an execution in its own silo. Planning, execution and monitoring are treated as distinct activities running in different systems and running on a periodic cadence. This is akin to going on a journey and periodically stopping to ask where you are and getting fresh directions.

Batch processes require large amounts of data to be copied from one silo activity to another. Typically, these take several hours from where data snapshots are taken to when plans are generated and then copied yet again to execution systems. Several hours may pass by the time the batch jobs have finished, and the resulting input data is already obsolete. In today’s dynamic business environment, companies simply cannot afford to stop and wait that long. Furthermore, for global companies there is no convenient nightly batch window where the business can take a pause.

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.

However, true disruptive value is unleashed when process designs extend this event-based process orchestration beyond the four walls of an enterprise to include partners across the value network. The traditional S&OP process takes an inside-out approach that engages customers and suppliers only on a peripheral basis. Now, imagine a new world where the organization, its customers, suppliers and logistics providers are all connected to a multi-party network giving real-time visibility to the status and plans to the level that you have agreed to share with each other. Also, partners can simultaneously collaborate to resolve exceptions together rather than waiting for each company’s S&OP calendar. Process orchestration can also support appropriate escalations, and approvals from individual company executives. The resulting S&OP process would be real-time, multi-party and collaborative across enterprises.

Let’s revisit the example of the over-performing product launch in more detail to see how a continuous event-driven S&OP process in a multi-party network would actually play out:

A multi-party network in action

Imagine that a CPG company has just launched a strategic product and sales are far exceeding expectations. In a network paradigm, the network will sense uptick in point-of-sale trend in real time, revise sales forecasts and predict stockouts a few days out based on current inventory status and replenishment plans that are already in execution across the network. This stockout alert would then go to both the retailer buyer and the customer service manager simultaneously.

The retailer buyer may review the significant update to the forecast and approve the additional purchase orders suggested by the network, and the CPG company would see these new purchase orders immediately. Meanwhile, the customer service manager would have already escalated the significant uptick and projected stockouts for the strategic launch as an S&OP exception issue requiring all hands on deck. The S&OP board chaired by the vice president of supply chain would evaluate alternative mix changes and surge production scenarios to support the increased demand.  Overtime production and significant mix changes could be approved after evaluation of tradeoffs between additional revenue and increased operational costs.

However, while the CPG company was getting its supply in order, the network would be simultaneously detecting and alerting the retailer that it will not have sufficient dock capacity to receive the increased traffic of shipments into its warehouse. This operational exception prompts the retailer to consider alternative courses of action, such as requesting direct ship from the CPG company for a portion of the orders even if at a premium price. This would, in turn, trigger another S&OP analysis loop at the CPG company before they finally agree and mobilize to do so.

Now, in this network paradigm example, all of the above could happen within the course of a few hours with real-time communication back and forth across demand planning, supply planning, logistics and S&OP Management Review.  It would also take place across multiple roles at multiple companies spanning Retailer, Buyer, CPG Customer Service Manager, Retailer’s Logistics, CPG company’s Logistics, Retailer Executives, and CPG company’s executives. In a traditional, sequential batch process world with single-enterprise silos this would be simply impossible as none of the parties would be able to respond in time.

Vision or reality?

The fact is that multi-party network technology already exists to make such processes possible. Companies no longer need to be locked in a paradigm of single-party, batch-sequential processes that were developed in order to cope with technology limitations that may have been around two decades ago. Supply chain leaders need to think outside the box to seize the opportunity for breakthrough performance improvements. Just imagine the competitive advantage that can be realized, by eliminating the traditional divide between planning and execution and enabling visibility and data to flow across the entire value chain of business partners – in real time. Sounds like the definition of supply chain disruption to me.

Source: One Network Enterprises