Supply Chain Networks Revealed: What They Do — Part 1B

This article is an excerpt from the report: Supply Chain Networks Revealed—Part One: What They Do
A copy of the full report can be downloaded here.

In Part 1A, we examined the evolution of architecture, a definition of what a supply chain network is, and different approaches we’re seeing to solve multi-party challenges. Here in Part 1B, we look at how a supply chain network can support end-to-end demand through fulfillment processes.

What Do Supply Chain Application Networks Do? What Approach Do I Need?

As mentioned above, there are some major differences in how different supply chain application networks work. Hence, the question becomes, which option applies to my circumstances? Here we will review specific processes.

Building Our Network

We will start with some basic supply chain tasks and build the transactions as we go. Figure One and Figure Two highlight an end-to-end process of demand through fulfillment.

So what does this chart above say to us?

An activity like demand sensing is a good example where application networks really provide an advantage. Demand sensing is an example that blurs the lines between planning and execution, as it requires a continuous ecosystem of the freshest, most accurate information, to be acted on swiftly.²

In a supplier/buyer relationship, changing demand should reset the network, with simultaneous signals and subsequent mutual recalibration of everything from scheduling dates to logistics routes, prices, and so on.

But for this to work, all network partners need to be included—not just as spokes receiving serial messages, but as participants in a multi-directional negotiation to create an achievable response.

In a participative, reciprocal relationship between buyer and supplier, both parties can benefit! In a participative network, multiple and mutual objectives may be achieved. That is network-wide optimizing. It goes beyond changing local parameters such as resetting a safety stock level. It involves mutual-optimization across multiple functions and multiple enterprises. There is a widely accepted axiom that local optimization is sub-optimization. A solution that optimizes across functions and enterprises will produce superior results across the chain, rather than just pushing the problem to different systems and players, up or down stream. For that, we need readily available, simultaneously shared data. Let’s look at an example of network-wide optimization here (Figure Two).

Application Considerations

In a supply chain application network, the applications, as well as how those applications are integrated or shared, both need to be considered. In Part Two we will discuss ‘the how’—the technology capabilities that set networks apart. Here we provide a brief comparison of several leading supply chain application network providers and their functional capabilities. Along with considering which applications a solution provider offers, we need to understand whether the applications are provided as a single shared network service (the RSN) vs. a set of standalone networks integrated by the common platform (the IN). Figure Three and Figure Four provide these views. We provide further comparisons in Part Two of this report.

Adopters of these solutions can take a functional application approach or alternatively first consider the network as their new end-to-end operating model. That choice will vary depending on their business. For example, a carrier may just need their own cloud TMS or more broadly a networked TMS to have their entire transportation and logistics business model supported. As well, the shipper may also just be looking to upgrade one function. Bear in mind that for trading partner processes to fully interoperate with one another, there can be dozens of processes that ultimately need to be shared and interoperate. This transcends a single functional application. And historical trends in tech acquisition and adoption have shown that users tend to look for more functionality on the same platform over time. Over the years, our view of supply chain has expanded from limited one-up/one-down³ visibility in our supply chain to a multi-functional, multi-stage view. As the demands of supply chain expand to include more and more partners and modern data, the complexities of synchronization become overwhelming. Networks can provide the supporting services required. So the question then, is how is this done. We answer that in Part Two of this report.

* For Demand/Supply Matching and Optimization we mean a network-wide capability as described in Figure Two. Optimization can be for transportation such as routing (T in this chart), inventory, space utilization in warehouse, and so on or inclusive of all elements (network-wide).

____________________________________________________________________________

¹ Most companies use one of the many B2B networks, or log into customer’s site, or use on-premise B2B. — Return to article text above
² For example, retailers often change ticket prices, ship-to addresses, quantities, and so on, up to and after ship dates. — Return to article text above
³ Such as customer/supply product/inventory planning, or logistics, coordination of transport, and inbound receiving.
*SAP and Oracle have pursued a strategy of both acquisitions as well as organic development resulting in many network solutions. As examples, SAP has Concur, for expense/financial, and Ariba for eProcurement (which uses SAP Ariba Cloud Integration Gateway to integrate to other SAP or external systems; plus, there are many third-party integration platforms that also integrate to Ariba); Oracle has OTM for transportation management, and Oracle Supplier Network which works with and between various Oracle ERPs and external suppliers (these use Oracle’s AP libraries or rely also on third-party integration platforms.) There are many other Application Master networks. These are just two prominent examples. — Return to article text above
⁴ And a reminder that INs are based generally on acquisitions and RSNs are mostly organically developed. We have color coded the functionality indicators above, showing acquisitions in purple text and organically developed in green text. — Return to article text above

To view other articles from this issue of the brief, click here.