Part Two: Evaluating ASDA Solutions · 2021. 1. 31. · third-party service providers (e.g., 3PLs,...

© ChainLink Research 2021 – All Rights Reserved

Agile Demand-Supply Alignment:

Responding to Demand Volatility

and Supply Disruptions

After Plans Are Set and Orders Placed

Part Two:

Evaluating ASDA Solutions

By Bill McBeath

January 2021

© ChainLink Research 2021 – All Rights Reserved

Table of Contents

What Problem(s) Are You Trying to Solve, Now and In the Future? ........................................ 1

Questions to Ask Solution Providers ...................................................................................... 3

Data and Supply Chain Visibility—Getting the Complete Picture ............................................................. 3

Detect, Contextualize, Prioritize—Finding the Needle(s) in the Haystack................................................ 4

Scope of Issues Detected ........................................................................................................................ 4

Prioritization Methodology and Capabilities........................................................................................... 5

User Experience ...................................................................................................................................... 5

Root Cause Analysis ................................................................................................................................ 5

Predict and Prescribe—Receiving Early Warning, Quickly Finding Solutions ........................................... 6

Multi-Enterprise Network Architecture—Foundation for ADSA and More.............................................. 6

Visibility-only Control Tower vs. Supply Chain Application Network ...................................................... 8

On-Platform vs. Off-Platform Data and Intelligence ............................................................................... 9

On-Platform vs. Off-Platform Optimization .......................................................................................... 10

Functional Scope ..................................................................................................................................... 11

ADSA Solutions Have Vastly Varying Functional Focus, Scope, and Internal Integration ..................... 11

Sourcing and Supplier/Production Functionality .................................................................................. 11

Quality Functionality ............................................................................................................................. 12

Logistics and Global Trade Functionality ............................................................................................... 13

Demand Management Functionality .................................................................................................... 14

Collaboration Capabilities ..................................................................................................................... 16

Analytics .................................................................................................................................................. 16

Implementation, Services, Pricing, ROI, TCO .......................................................................................... 17

Implementation—What Does it Take to Get Started? .......................................................................... 17

Value-Add Services ................................................................................................................................ 18

Solution Pricing ..................................................................................................................................... 20

Financial Assessment and Comparison of SaaS Systems (ROI, TCO, et al) ............................................ 22

Evaluating Potential Solutions ............................................................................................. 23

Discovering Potential Solutions .............................................................................................................. 23

Shortlisting Potential Solutions ............................................................................................................... 23

Industry Focus ....................................................................................................................................... 24

Other Factors......................................................................................................................................... 24

Selecting a Solution ................................................................................................................................. 25

Requesting a Demo ............................................................................................................................... 25

Due Diligence, Increasing the Chances of Success ................................................................................ 25

Agile Demand-Supply Alignment: Part 2— Evaluating ASDA Solutions

© 2021 ChainLink Research, All Rights Reserved. Pg. 1

This is Part Two of our research series on Agile Demand-Supply

Alignment (ADSA). We define ADSA as “the capability to effectively

realign supply and demand, during execution, in the face of

demand volatility and supply disruptions.” Regardless of how good

companies get at planning, ‘stuff happens’ and companies then

need to be able to rapidly adjust to the evolving actual situation on the ground. Part One describes the phases of

supply chain planning and execution and lays out a framework for understanding the Elements of ADSA, as

shown in Figure 1 below. Part One also includes examples of specific ADSA capabilities, such as In-Season

Reordering, Agile Customer Mandate Compliance, and Opposite Hemispheres Strategy.

Here in Part Two, we look at how to evaluate ADSA solutions, what questions to ask solution providers, and how

to shortlist providers.

What Problem(s) Are You Trying to Solve, Now and In the Future?

Agile Demand-Supply Alignment (ADSA) is not a category of software, per se—rather, it is a set of capabilities

(systems, processes, and practices) to better align demand and supply. Nevertheless, in this report we talk about

‘ADSA solutions,’ i.e., software and services that help companies achieve Agile Demand-Supply Alignment. Most

of these are not marketed or sold as standalone ADSA solutions,1 but rather the ADSA functionality they provide

is a portion of some broader set of functionality, that may be an ERP suite, or a supply chain suite, or some best-

of-breed software such as a sourcing and procurement system, quality, issues resolution, or demand

management/forecasting software.

Thereby, buying ADSA solutions is usually wrapped up within an initiative to buy one of these broader or more

focused enterprise software solutions. Users are often looking for solutions for their particular functional area,

such as a logistics manager buying a transportation management system or a demand planner seeking a better

forecasting system. These functional systems can help solve demand-supply mismatch because you need to

1 One exception to this statement is ‘control towers’, an emerging category of solution. Control towers have been evolving and expanding beyond the initial definition to include to more predictive and prescriptive platforms, and more integrated planning and execution. Agile demand-supply alignment is one of the main purposes of control towers and their next generation iteration (sometimes called autonomous supply chain platforms). We discuss this evolution more in the section below, Visibility-only Control Tower vs. Supply Chain Application Network.

Acknowledgement We are grateful for the support and par-ticipation of the Retail Value Chain Federa-tion and the National Retail Federation in making this research study possible.

Figure 1 - Elements of Agile Demand-Supply Alignment

http://www.chainlinkresearch.com/research/detail.cfm?guid=598D698B-B3AE-85FD-17B7-29AC8F5577D9

http://www.chainlinkresearch.com/research/detail.cfm?guid=598D698B-B3AE-85FD-17B7-29AC8F5577D9

http://www.clresearch.com/research/detail.cfm?guid=BD159C7B-FAEF-C127-522A-C25BDD63EE76

https://www.rvcf.com/page/About_RVCF

https://www.rvcf.com/page/About_RVCF

https://nrf.com/about-us



know when a shipment is delayed or how actual demand differs from the forecast. However, each of these

solutions only provides a piece of the puzzle. Supply chain processes are inherently cross-functional2 and inter-

enterprise so these systems should be integrated together to provide holistic situational awareness and identify

and execute a globally optimal response to issues that arise. To achieve an optimal response requires a holistic

platform that can see and execute actions across processes. Buying functional solutions without regard for how

they will be integrated into a holistic platform is shortsighted. When evaluating enterprise solutions, immediate

needs should be balanced with the longer-term needs and vision for the future.

Agile Demand-Supply Alignment encompasses a broad range of organizational functions, processes, and systems

across the enterprise and between trading partners, as shown in Figure 2 below. This is not just about the

technology; it includes the people, practices, and systems within each functional area. Ideally, an ADSA solution

integrates teams, data, workflows, and systems from across all these areas, incorporating trading partners and

third-party service providers (e.g., 3PLs, forwarders, etc.) as well.

Figure 2 - Many Organizational Functions and Systems Required to Achieve ADSA

2 For example, a procure-to-pay process involves order management, supplier management, transportation management, inventory

management, global trade management, warehouse operations, and more.



Questions to Ask Solution Providers

Data and Supply Chain Visibility—Getting the Complete Picture

ADSA requires network-wide data about inventory, demand, supply, and logistics:

• Inventory—An accurate and up-to-date picture

of per-SKU, per-location inventory across the

network. This starts with data feeds from a

company’s own perpetual inventory systems, for

their factories, DCs, and stores. But it really

should also include partners’ inventory, including

upstream finished goods inventory at suppliers’

locations, in-transit inventory in containers and

trucks, inventory at service partners such as

3PLs, and downstream inventory at channel

partners, retailers, and customers’ stocking

locations. A broader network-wide picture is

harder to attain but provides a more complete

picture of supply and enables finding many more

options for resolving shortages (such as using

inventory from one dealer to fulfill demand at

another).

• Demand—At a minimum, a company’s own

forecasts should be used to understand expected future demand. On top of that, demand sensing can help

detect when there are changes in demand that are deviating from the forecast. Ideally, the solution helps

enable a demand-driven supply chain, where visibility into end-user consumption and downstream3

forecasts, consumption, and inventory data enable more accurate supply-chain-wide forecasting and

execution. This is part of what CPFR was trying to accomplish. This turns out to be hard to do for a variety of

reasons, so not many companies are able to pull it off. However, FMCG companies and some others are

leveraging tools to pull together POS,4 syndicated retailer data, and other data, combined with analytics, to

give them a demand sensing capability that incorporates end consumption. Demand sensing can include

both the actual consumption information from the most downstream point possible (ideally end demand –

such as POS or stock room withdrawals), as well as casual factors that have arisen that might not be

considered by the traditional forecast tools (such as weather or major relevant events).

• Supply—This starts with full visibility into all supply-side orders, including purchase orders and/or material

releases being sent to suppliers, as well as work orders for internal manufacturing. The ability to track the

status of an order throughout its lifecycle (issuance to receipt and payment) should include both production

and shipment phases, thereby encompassing the logistics visibility described below as well. Ideally, there is

visibility into product status at each stage, including knowing about delays in inbound raw materials to the

3 Including visibility through multi-tiered distribution channels 4 POS = Point-of-Sale

Data and Visibility Potential Questions for Solution Providers:

• What data does your platform ingest to provide visibility? How is that data obtained (e.g., via EDI, supplier portal, API, XML, etc.)?

• Does your solution incorporate network-wide inventory (across multiple tiers)? At what level of granularity and scope—down to the SKU-location level? For which locations and entities?

• Does it incorporate forecast data? Near-real-time consumption data?

• Does it incorporate near real time order and production status? What data is incorporated and how is that obtained; from what sources?

• Does it incorporate near real time logistics status? What granularity of status and what milestones are incorporated? How is that data obtained?

• Which external systems (e.g., SAP, NetSuite), service providers (e.g., 3PLs), and trading partners (e.g., Walmart) do you provide pre-built connectors for? What is the effort required to implement pre-built integrations?

• Do you integrate data from proprietary systems?

• How is all of this data presented and visualized?

https://en.wikipedia.org/wiki/Point_of_sale



suppliers’ or your own factories. Most firms have some level of visibility into their own factories, but often

have poor visibility of the status of orders at suppliers’ factories. More broadly, it is valuable for the platform

to incorporate visibility into Industry-wide capacity constraints and material shortages, as well as disrupting

events, such as storms or political upheaval or pandemics, with insights into how those events will impact

supply for the company using the solution.

• Logistics—ADSA requires the ability to see the status of shipments correlated to the purchase orders, sales

orders, and stock transfer orders that the shipments are fulfilling. This includes seeing when shipments are

booked, tendered, and have passed various milestones on their journey such as ‘left factory’, ‘arrived at

consolidation center’, ‘loaded onto ship’, ‘departed origin port’, ‘cleared customs’, and so forth. More

advanced platforms will also ingest data to provide a more precise ETA,5 such as weather, port and road

congestion, and major events.

Understanding the sources, granularity, and accuracy/reliability of the data is important. For example, the

platform may show the date that the order is estimated to be shipped from the supplier’s factory. If that date is

based on the expected ship date stored in the buyer’s ERP system, it might be out-of-date and inaccurate by

days or even weeks, and not reflect the actual delays that have happened after the order was placed. At the

other extreme of advanced visibility, the supplier’s factory might be instrumented to automatically track each

production step, and that data automatically sent in near-real-time to the buyer’s supply chain visibility

platform. In that case, the buyer will have a highly accurate, granular, and up-to-date picture of the current

status of their order. They will know within hours, or even minutes, when a milestone has been missed and a

delay has occurred. Most implementations will be somewhere in-between those extremes. For example, a

common approach to supplier visibility is using a supplier portal, relying on the supplier to update the status of

their order in a timely manner.

Detect, Contextualize, Prioritize—Finding the Needle(s) in the Haystack

Collecting all this raw data in one place is not enough. To be effective, especially as supply chains grow larger

and more complex, the platform needs to continuously monitor and correlate those potentially massive flows of

data, to detect delays and disruptions to supply, as well as spotting when actual demand deviates from the

forecasted demand. These data should be put together, in context, to understand where there will be a

demand-supply imbalance that matters. Preferably the platform has enough intelligence to prioritize the

imbalances, so users can focus their attention on those imbalances that have the biggest impact. It should

predict future shortages and overages, and ideally prescribe resolutions to those problems. There is a lot to

unpack here in order to understand how a platform does all of that and know what questions to ask of the

solution provider.

Scope of Issues Detected

First is to understand what scope of disruptions and imbalances a platform is designed to detect or predict.

Some platforms focus primarily on supply chain disruptions. Others focus primarily on detecting demand

deviation. Others bring together forward-looking supply and demand analytics to predict imbalances (shortage

and overages).

5 ETA = Estimated Time-of-Arrival



Prioritization Methodology and Capabilities

Next is to ascertain how the platform prioritizes

whatever issues it has detected. If the platform does

not prioritize the disruptions or deviations it

discovers, then prioritization will have to be done

manually.6 Understanding the prioritization

methodology and algorithms the platform uses is

important. For example, if the inbound supply is

feeding the user’s own in-house factory, then it is

important to know the production schedule for that

in-house factory, in order to understand which

delays are most significant. A shipment of parts or

materials may be running behind schedule, but if it is

still going to arrive in time for the production run it is

scheduled for, then nothing special needs to be done

about it at this time. The delay of a different part

may cause a vital production run to be postponed and thereby shipments to a key client to miss a critical

promise date. The priority of that delayed part should therefore be elevated, and effort put to resolve it. The

platform should also present the cost and service level implications of disruptions and their potential

resolutions.

Those kinds of insights into relative priorities require that the platform not only detects the delay in the

shipment, but also understands how that shipment fits into the factory’s production schedule and customer

priorities. Not all platforms have the production schedule data and/or the intelligence to understand the

context, correlate it, and determine the impact on production. This same kind of context is needed across many

dimensions, such as whether or not a shipment will miss a sailing just because the truck is running late, how

much revenue or profit is at risk for a given delay, which customers are more important than others, and so

forth.

User Experience

Another thing to look at is how the system visualizes and organizes all that information—the UI paradigm used

to navigate (such as map views, graphical supply chain flows, time-phased inventory-level diagrams, and so

forth), diagnostic and analytic options it offers, and the workflow presented to find and weigh different potential

resolutions to the issue. The elements of the user experience make a huge difference in how productive users of

the system will be in identifying high-impact issues and quickly resolving them.

Root Cause Analysis

Some systems can analyze and highlight underlying root causes. For example, the system may notice that many

orders that are running late all flow through the same distribution center. It could then highlight that there is a

6 In any case, prioritization of the issues is required because there is not enough time, nor the need, to address every production delay, late shipment, or surge in demand. If no prioritization is done, then members of an organization are in constant firefighting mode, addressing whatever latest noisiest issue happens to land on their desk.

Detect, Contextualize, Prioritize Potential Questions for Solution Providers:

• What kinds of supply disruptions, demand deviations, shortages, and overages does the platform detect and predict? How does it do that?

• How does the platform prioritize different disruptions and imbalances it has detected? What are the criteria or algorithms used, and how are the priority issues displayed or presented to the user?

• For each issue (demand/supply imbalance), what information is brought together to help the user understand the situation? What UI paradigms, visualizations, and mechanisms are used to navigate this information, such as map views, graphical supply chain flows, time-phased inventory-level diagrams, cost and service level implications, and so forth?

• What kind of root cause analysis capabilities does the system have for diagnosing issues? Can it recognize common bottlenecks or root causes across an aggregate set of disruptions, such as congestion at a port or DC?



potential problem at that DC and, with the right information (possibly fed from the WMS system for that DC), it

might deduce that the facility is over capacity or having a problem with labor scheduling. By identifying the root

cause and addressing it (such as routing deliveries through alternative DCs and/or fixing the labor issue) many

individual delays are resolved all at once, rather than continuing to treat the symptoms and fixing problems one

at a time.

Predict and Prescribe—Receiving Early Warning, Quickly Finding Solutions

An emerging battleground for ADSA platforms is their

ability to predict disruptions and demand deviations

in advance, and their ability to prescribe effective

recommended actions to resolve the issues.

Predictive analytics uses advanced algorithms and

AI/ML7 to look for patterns in the real-time data

received to provide much more accurate ETAs,

predict early or late deliveries, demand surges,

production delays, and various upstream supply and

downstream demand deviations across multiple

tiers. AI/ML also learns from the actions taken for

past issues. It looks at what worked in previous

similar situations and prescribes the most effective

resolutions. The platform may present multiple

options for resolving an issue, ideally with a side-by-

side comparison of the impact of each option. This

impact analysis may include a time-phased view of the impact on inventory levels at specific locations in the

network. In some cases, a short out-of-stock situation may be tolerated for the sake of choosing a much less

expensive resolution option. Issues may be resolved to prioritize more strategic customers or to implement an

industry allocation approach across a segment.

Multi-Enterprise Network Architecture—Foundation for ADSA and More

The architecture and infrastructure a solution is built on determine a lot about what it can and cannot do. Most

of the systems we included in our research are architected as multi-enterprise platforms, but that is not the case

for most enterprise software. Most enterprise applications are architected for use within a single

enterprise, including virtually all major ERP systems and most best-of-breed applications. There is a big

difference between single-enterprise and multi-enterprise architectures in many areas such as:

• Shared ‘Single-Version-of-the-Truth’—The most central difference is where data is stored. In single

enterprise systems, each enterprise has their own copy of data and uses messages between trading partners

to keep those data in synch. For example, a buyer’s ERP system generates a PO which is sent to the supplier

and becomes a sales order in the supplier’s ERP system. Now there are two copies of the data

7 AI/ML = Artificial Intelligence/Machine Learning

Predictive and Prescriptive Capabilities Potential Questions for Solution Providers:

• What kinds of predictions, if any, does the platform make? Can it provide more precise ETA, predict production delays, predict demand deviations?

• What is the scope of these predictions? Does it cover multiple tiers? Can it predict the cost and service level implications?

• How are these predictions made? Have you measured the accuracy of the predictions?

• Is the platform able to prescribe resolutions to demand-supply imbalances? How does this work? Have you been able to measure the effectiveness of prescribed actions?

• Are multiple disruptions resolved simultaneously or are they resolved one-at-a-time in a ranked way? Across what scope are multiple disruptions simultaneously solved?

• How does the platform help users compare the expected outcome and impact of the different resolutions being proposed by the platform?



about the same order. The process of exchanging data creates delays and errors.8 In a multi-enterprise

network system, there is a single copy of the data shared between everyone on the network, with

appropriate security controls so parties can only see data they are authorized to view. This means everyone

is looking at the same data. When the buyer

uploads a PO onto the network, there is now a

shared copy of that order that both the buyer

and supplier use for execution. Depending on

the scope of the multi-enterprise platform, a

single-version-of-the-truth is also maintained for

data about inventory, demand forecasts,

logistics and shipment data, manufacturing

status, and so forth. Since this data is being used

to drive multi-enterprise execution, the accuracy

and timeliness of the data is critical. Ideally data

is near-real-time and there are quality check

mechanisms in place.

• Master Data Management—A multi-enterprise

network needs to accommodate a much higher

velocity of changes to master data, coming from

many different companies, with mechanisms to

allow enterprise-specific variants, while still

ensuring harmonization between the master

data coming from all the different enterprises on

the network.

• Security—There must be mechanisms for data

owners to grant access rights based not just on a

person’s role, but also the trading partner

relationship (does the person work for a supplier, a customer, the government, etc.). This typically includes

the ability to grant administrator rights to someone within the trading partner organization, so that they can

do self-service onboarding and offboarding of users within their own company.

• Process Flows—Multi-enterprise platforms embody multi-enterprise processes and workflows which may

involve not only a buyer and seller, but also 3PLs, carriers, inspectors, banks, insurance companies, customs

agencies, and more. This will include partner-specific sub-workflows for each participating party.

• Network of Trading Partners—Multi-enterprise platforms often have pre-connected networks of trading

partners. Participants are typically onboarded on an as-needed basis, as each new customer brings their

trading partners (suppliers, customers, and service providers) onto the network. Often a trading partner

8 The delays mean each party has an out-of-date picture of what is happening. Errors cause incorrect execution and costly disputes about

what actually happened. These problems are especially acute when manual processes are used for sending transactions back and forth—e.g., PDFs or spreadsheets are sent via email, with data entry on the receiving side. Even with EDI, there can be days of delays between the time a transaction is entered in one system until it finally appears in the trading partner’s system.

Multi-Enterprise Network Architecture Potential Questions for Solution Providers:

• Does the architecture provide a shared single version of the truth for all parties on the network—a shared, near-real-time view of demand and supply, including inventories, orders, forecasts, shipments, manufacturing, and logistics?

• How does the platform handle master data updates from multiple enterprises and systems?

• What is the security architecture and how does it handle multiple enterprises?

• What networks of trading partners are already on the platform? What are the tools, processes, and services for onboarding new trading partners onto the network?

• Does the solution provider monitor and detect quality issues for the data being passed back forth between trading partners? What kinds of problems can be detected and what does the platform do once a problem is detected?

• What is the integration infrastructure? How are internal systems and external trading partners integrated?

• Is the platform capable of cross-functional and multi-enterprise optimization, such as trading off the impact between transportation and warehouse labor and inventory costs? Does it consider the tradeoff impact to all the different players in the supply chain? If so, how does that work?



network is concentrated in a particular industry. Most networks rely on customers to vet their own trading

partners, but some solution providers do vet, audit, and certify a subset of suppliers on the network.

• Onboarding—Network platforms need mechanisms to streamline onboarding9 of new trading partners to

the maximum extent possible.

• Data Quality—Transaction flows are the lifeblood of business activities between companies. Multi-

enterprise platforms should have the ability to monitor the quality, integrity, and timeliness of data flowing

through the platform to immediately correct malformed or missing data. This is described in more detail in

the section below, Data Management and Monitoring.

• Integration—The platform needs to integrate both existing internal applications, as well as trading partners

and their applications.

• Analytics & Optimization—Most existing optimization engines focus on a single functional area such as

transportation route optimization, manufacturing production optimization, inventory optimization, or

warehouse labor optimization. Multi-enterprise, network-level optimization is inherently different, as it

requires coming up with globally optimal answers, incorporating orders of magnitude more data. This is

needed to truly understand the network-wide tradeoffs and prescribe optimal resolutions to issues at

enormous scale and complexity.

This last point on cross-functional, multi-enterprise analytics and optimization is an important one in the context

of ADSA. Some form of analytics or intelligence is needed for almost everything an ADSA platform does,

including predicting future shortages and overages, prioritizing issues, prescribing resolutions, and comparing

the impacts of different disruptions and resolutions. This has implications for the platform architecture and

where functionality resides.

Visibility-only Control Tower vs. Supply Chain Application Network

Initial iterations of supply chain control tower technology were created to provide ‘end-to-end’ visibility across

functions and across a multiple-enterprise supply chain by being a central collection point for a wide array of

disparate information from many systems and sources. This data is then displayed in supply-chain-wide

dashboards, providing an overview of purchase orders, production, shipment, inventory, and in some cases

demand. A Visibility-Only Control Tower does not do any planning, optimization, or execution. It relies on other

existing systems to provide those functions. In contrast, a Supply-Chain Application Network has all the data

gathering and synthesizing capabilities of a control tower, but also has built-in capabilities to perform multi-

enterprise planning, optimization, and execution. Networked platforms are designed with the flexibility to allow

some of the functionality that they normally perform on the platform to instead be performed off-platform,10

thereby not forcing users to switch from their existing planning and execution systems that they already use.

9 For example, some platforms allow self-service onboarding to be integrated into an auto-generated email when the platform is sending a document or transaction to the trading partner, such as an RFQ or an invoice. The trading partner clicks a link to do self-service onboarding and the platform pre-fills as much information as possible. This way the trading partner is confirming rather than entering data and the onboarding happens in a few minutes. The trading partner is motivated to complete the process at that moment in time because they want to respond to that specific business request or transaction—i.e., they want to bid on the project or get paid. 10 Some platforms do this division of labor more elegantly, allowing more granular division of responsibility with legacy applications and

easier migration to the platform.

https://www.supplychainbrain.com/articles/30848-solving-multi-enterprise-supply-chain-challenges-with-supply-chain-application-networks



Type of Platform Main Purpose Integration/Data Source Embedded Functionality

Visibility-only Control Tower

Provide end-to-end visibility.

Loosely integrated enterprise applications (off-platform), trading partners, 3rd party sources.

Limited to visibility and simple alerts.

Supply Chain Application

Network

Provide end-to-end visibility, planning, and execution.

Tightly integrated, built-in on-platform functionality and loosely integrated off-platform enterprise applications, trading partners, 3rd party sources.

Depends on the platform. Some focus on production, others logistics/GTM, demand/channel management, etc. or combinations of these.

Table 1 - Visibility-only Control Tower vs. Supply Chain Application Network

What’s in a Name?

This is not about whether a solution is called a Control Tower or not. Some platforms that have Control Tower

in their name have significant built-in planning and execution functionality. Some Supply Chain Application

Networks have a module within their suite that has control-tower-like functionality, which provides end-to-end

visibility, tightly integrated with their own planning and execution functionality, and the ability to integrate

external data. That module or capability may or may not be called a ‘Control Tower’ by the solution provider.

Pure visibility-only control towers have generally not succeeded in the marketplace—they have either evolved

to include some application functionality or have morphed into something else altogether. Those that survived

can map orders, shipments, suppliers, and parts together, and add other planning and execution functionality

and analytics to that data.

Rather than seeing a black and white distinction between visibility-only control towers and supply chain

application network, solutions can be viewed as sitting along a spectrum from having less to more functionality

and intelligence embedded in the platform. To understand this spectrum, it is useful to look at what data is

needed, what intelligence is needed, and where that data and intelligence resides.

On-Platform vs. Off-Platform Data and Intelligence

As described in Figure 2 - Many Organizational Functions and Systems Required to Achieve ADSA, data needs to

be ingested from many different sources. For data sources that are already built into the platform (i.e., data that

is part of the built-in planning and execution functionality), the integration is inherent, saving not only a lot of

upfront integration effort, but ongoing maintenance of those integrations. Reducing the number of external

integrations required increases the agility of the platform to evolve over time. For data sources that are

external, the amount of integration effort, cost, and time required depends on the extent and nature of pre-

built connectors available.11

Once the platform has the data, it can detect disruptions and deviations, but in order to prioritize those, it needs

context. For example, to prioritize disruptions to materials flowing into a factory, the platform may need to

11 We are seeing three different levels of data integration for these platforms, with many platforms providing some hybrid combination of these: 1) the data is internal because it is part of the planning and execution application functionality of the platform, 2) the platform has pre-built connectors and data models to get external data, and 3) the platform does not have pre-built connectors but has mechanisms for creating new integrations to external data. For #1, there is no integration work required as the data already exists in the system. For #2, there is some integration work required (setting up and testing connections), but it is a relatively modest effort, and you can reasonably expect the vendor to update the mappings when the destination data changes. For #3, there is a significant amount of upfront work required to get a new integration to work and the user’s IT group is on the hook for maintaining that integration, which entails a lot of ongoing investment, unless the solution provider explicitly agrees to take on that responsibility (usually for a non-trivial fee).



know the production schedule and deadlines at that factory, which customer orders and revenue are dependent

on each production run impacted by the delay, the value of those orders and potentially the lifetime value of

each customer, options for rescheduling production, and so forth. Trying to bring in all that data and build the

intelligence to understand it is daunting, due to the variety of semantics and the depth of logic needed to

interpret it. The platform would be practically replicating much of the intelligence and logic already embedded

in the external production planning and execution systems it is pulling the data from.

A visibility-only control tower, which does not have any planning and execution functionality, does not

inherently have the built-in intelligence and context required to prioritize and optimize. That doesn’t mean such

a platform cannot do any prioritization. With the right engineering effort by those solution providers, some

simpler prioritization can be accomplished by pulling in the right data, provided the platform understands the

semantics/meaning of the data and has ensured it is pulling in the right data from the source systems,

normalizing the values properly, and interpreting it correctly for the purpose.

However, the scope and sophistication of prioritization and optimization that can be done by a visibility-only

control tower is significantly constrained by the challenges inherent in doing all of the ‘reverse engineering’

work required and the lack of standard ways of expressing things like customer priority or lifetime value of a

customer or production schedules. Thus, as a generalization, the less built-in planning and execution a platform

has, the more rudimentary will be any prioritization or optimization it is able to provide. In contrast, a platform

that has rich planning and execution capabilities built in, inherently has the intelligence that can serve as a

foundation to contextualize and prioritize the issues that arise.

On-Platform vs. Off-Platform Optimization

Once issues have been detected and prioritized, they need to be resolved. The ultimate goal is for AI/ML to

prescribe the optimal course of action. Several solution providers have started down that path, though we are

still early on that journey. Some platforms provide useful approaches that do not involve AI/ML-generated

resolutions. For example, they may gather information to show the user alternate sources of existing inventory,

alternate suppliers, expediting options and costs, tools to invite suppliers to collaborate on a solution, and so

forth. Saving the user the grunt work of finding, gathering, and organizing all that information, and making it

easy and convenient to convene a team of co-workers and partners to resolve the issues—these are huge

productivity boosters.

Still, a more powerful approach is when the platform does the optimization work required to recommend the

best resolutions. This enables supply chain professionals to make smarter, faster, more strategic decisions.

Organizations often already have very capable optimization engines running within best-of-breed applications

such as within their existing TMS, WMS, production, and inventory optimization applications. However, these

engines only optimize within their own domain. ADSA requires global optimization, where multiple optimization

engines12 iterate collectively to find the best overall solution, across functions and enterprises. The vast majority

of best-of-breed optimization engines are not designed to iteratively cooperate with other function-specific

optimization engines to mutually analyze the tradeoffs. Some solution providers are building exactly that

12 In theory, a solution provider could build a single cross-functional, multi-enterprise optimization engine that works on an entire end-to-

end supply chain model, but we know of no provider taking that kind of monolithic approach.



capability into their supply chain application network—the ability to iteratively optimize across multiple

different functions and enterprise nodes to discover globally optimal solutions.

Functional Scope

ADSA Solutions Have Vastly Varying Functional Focus, Scope, and Internal Integration

The functional focus and scope of ADSA solutions

varies widely. Some focus on supplier and

production management, others are logistics-centric,

while others focus on monitoring downstream end-

point consumption. Some solution providers offer a

complete suite of supply chain applications for

planning and execution, while others are ERP

companies that happen to offer ADSA-related

solutions. Assessing the functional scope and

integration of the solution provider is important.

Even when seeking a solution for a specific problem,

it is wise to step back and look at the bigger and

longer-term picture, considering what else the

solution provider and their platform have to offer

and how well integrated the platform and its

components are.

Some providers have grown by acquiring best-of-

breed applications while others have built most of

their capabilities inhouse. In general, solutions that

are entirely or mostly developed inhouse will be

better integrated with a more seamless workflow

than those consisting of stitched-together acquired

applications. However, amongst solutions that have

grown by acquisition there are big differences in how well integrated the applications are. Some have become

quite good at integrating the data, user interface, and processes of acquired applications. Some have even

rewritten acquired applications from scratch, essentially building an in-house developed application that

incorporates the domain knowledge and functionality learned from the acquired application.

Sourcing and Supplier/Production Functionality

Some solutions provide no visibility into the status of production at the supplier’s factories while others provide

extensive, granular, near-real-time visibility, including visibility into the ordering and receipt of raw materials at

the supplier’s factory, granular updates on work-in-progress steps, finished goods inventory movements, and

packing and shipping activities at the factory. This is often accomplished via a supplier portal, but some

platforms also allow instrumentation of the supplier’s factory, such as the use of RFID tags to track materials and

Functionality Potential Questions for Solution Providers:

• What is the primary purpose of the solution? What problem(s) is it trying to solve?

• What portion of the solution functionality was acquired and what portion was developed in-house? What is the approach to integration for the acquired functionality?

• What sourcing and procurement functionality, if any, is included?

• What outsourced production management functionality is included? How is production status tracked?

• Is there any quality management functionality included? How are product quality issues addressed?

• What logistics/transportation functionality is included?

• Is any global trade management functionality included?

• Are there capabilities for full traceability and chain-of-custody?

• What is the scope of demand-side visibility, if any? Does the platform ingest forecasts, the user company’s own inventory, channel inventory, channel consumption, and endpoint consumption (such as retailer POS data, or stockroom withdrawals)?

• Are demand forecasting or demand sensing capabilities included?

• Does the platform support omnichannel business models, including ecommerce, physical store, consumer-direct, and distributor models?

• Does that platform provide time-phased views of predicted

shortages and overages? If so, how are those presented and

what data goes into those predictions?

• What collaboration tools are provided and how do they work?



processing steps at the supplier. The more capable platforms can often provide alerts when raw materials are

late or individual process steps have fallen behind schedule.

There is also wide variation in supplier-enablement tools provided by platforms. Many (but not all) ADSA

solutions have some sort of supplier portal and/or EDI capabilities to let suppliers negotiate and accept purchase

orders, update production status, request pickups/book shipments, issue invoices, and in some cases receive

payments.

This may include sophisticated transportation management tools for suppliers. For example, one platform we

reviewed lets suppliers create requests for transportation for order lines ready to ship from their origin. An

automated scheduled job can be run on an optimization engine that looks across multiple of these requests,

considering carrier options, lanes, legs, service level, equipment type, transit time, rates, and mode constraints

to find the least cost, best service level option respecting promised delivery dates on each order. While this may

not strictly speaking be ADSA functionality, it is an example of the kind of additional, closely related functionality

some ADSA platforms may provide, which will be part of the overall consideration of which platform best serves

a set of needs.

Some platforms provide various supplier compliance tools, such as enforcing the packing requirements outlined

in a P.O. by calculating carton weights & measurements, as well as enforcing the actual packing of the physical

product during the packing process. Platforms that let suppliers request transportation may improve compliance

by using the buyer’s enterprise’s routing guides and allocations, with routing guide rules and desired outcomes

configured on the platform.

Some platforms provide sourcing and procurement tools, such as supplier discovery, RFQ management, contract

management, PO management, invoice reconciliation, and payments/settlement. Advanced ADSA platforms

allow suppliers and their customers to collaborate on orders, shipments, transportation, inventories, forecasts,

and plans on a single network-based platform.

Quality Functionality

Supply disruptions and delays are sometimes caused by quality issues at the supplier. The timeliness with which

quality issues are identified and mitigated has a huge effect on the financial impact of the quality problem. It is

strongly preferred for suppliers to have robust quality processes and systems that catch problems before any

components have been shipped, rather than after the component has been received and assembled into a

finished good, or in the worst case already shipped to customers. Problems discovered at these latter stages can

be hundreds or thousands of times more expensive to correct than if those same problems were resolved early

on.

Some ADSA platforms include tools to help detect, identify, track, and resolve quality issues. These include a

wide range of capabilities from direct connections into the suppliers’ MES systems to mobile quality applications

for use by suppliers’ and buyers’ quality personnel to enter and track quality and compliance activities, capture

and document quality defects on the factory floor, including sample photos, and upload that documentation for

sharing and collaborative resolution. Some have approval and escalation workflows, as well as root cause

analysis tools. Some let customers configure custom milestones for tracking such as when inventory is put on

hold and quarantined, root cause discovered, fix proposed, fix tested and approved, fix implemented, material



taken off hold, and so forth. Others have serial number and/or lot-level traceability capabilities to trace the

origin and chain-of-custody handoffs for any ingredient, product, lot, or batch, as well as identify quality

violations during transport such as temperature excursions for the food or pharmaceutical cold chains. This

traceability can help in managing recalls, including commonality analysis algorithms to identify common points

of failure and the associated lots.

Logistics and Global Trade Functionality

There is wide variation in the degree and granularity of logistics visibility and functionality included. Most

platforms provide a basic ETA13 and many can ingest EDI data from LSPs or carriers with updates throughout the

journey, though these data can be delayed by one to two days, or more. Less commonly, some platforms ingest

IoT/GPS data or updates from one of the tracking networks,14 to provide a near-real-time view of where the

vessel or vehicle is, and thereby a more dynamic ETA. The more sophisticated platforms use AI/ML to factor in

other elements, such as weather, traffic, port congestion, and major events (e.g., conventions or sporting

events) to develop a more precise dynamic ETA. This is an area of competition that many solution providers are

investing in—trying to provide more precise dynamic ETAs, providing more advanced and reliable warnings

about delays—and there is still room for a lot of improvement. More advanced and reliable warnings of late

arrivals enable a broader range of mitigation options.

Beyond precise ETA, ADSA solutions offer a wide variety of logistics management functionality. Some offer full

suites of tools such as RFQ and spot bids, contract management, booking tools, load boards and freight-

matching marketplaces, rating, freight invoicing and payment, and freight audit tools. Some providers offer

Global Trade Management (GTM) functionality with regulatory export and import compliance and transactional

functions. GTM functionality may include automated harmonization code classification, country customs

controls, restricted party screening, license determination and tracking, automated document generation, and

automated filing with various government systems.15

Less commonly, a few providers offer Container Freight Station (CFS) functionality, such as receiving,

comparison of receipts against Shipping Orders and FCRs,16 consolidating shipping orders, transportation/

shipping plan creation and approval workflow, and so forth. These can be used to run a cross-dock or transload

facility while providing visibility to the inventory passing through. This added visibility can help provide more

precision in the end-to-end tracking of goods and notifications when things are running late. A sophisticated CFS

system can provide capabilities to modify in-transit shipment plans, such as changing the destination to a

location that has a critical shortage, to help deal with demand-supply misalignments.

13 ETAs (Estimated Time of Arrival) are often based on an estimate from the forwarder or carrier, which is typically just the average transit time plus some buffer of time so that most trips arrive on time or early. A static ETA does not reflect any updates during the trip as conditions change. 14 There are a number of increasingly capable transportation tracking services that combine data from many sources to provide updates

on the status and location of in-transit shipments. Examples include MacroPoint, FourKites, Project44, and MobileSTAR. 15 Some solutions interface with various customs and border control agencies’ electronic interfaces for automatic filing such as US AES, US ACE, US ISF, US FTZ, DE ATLAS Export, BE PLDA Import & Export, CN GAC (CTM), and others. 16 FCR = Forwarder’s Cargo Receipt, aka FIATA Certificate of Receipt

https://www.macropoint.com/

https://www.fourkites.com/

https://www.project44.com/

https://www.blujaysolutions.com/solutions/network-gtn/mobilestar/

https://www.freightos.com/freight-resources/what-is-a-forwarders-cargo-receipt-fcr/

https://www.incotermsexplained.com/freight-forwarders-receipt/



Demand Management Functionality

Scope of Demand-Side Visibility

Some ADSA systems focus exclusively on supply side disruptions and do not consider demand side data at all.

Others ingest forecasts, but do not monitor actual consumption. Solutions with the most complete demand-side

visibility monitor end-point consumption, as well as inventory at all downstream tiers between the enterprise to

the end consumer.

Figure 3 - Different Solutions Provide Different Scope of Demand-Side Visibility

As shown above, a solution that includes downstream inventory and end-customer consumption provides a

picture that more closely matches the reality on the ground and is more complete and up to date than ones that

only look at the forecast or sales/deliveries to the immediate customer. The higher up this demand-side visibility

stack a solution is, the more precise and earlier are the warnings of shortages and outages it can provide.

Time-Phased Views, Simplifying High-SKU Large-Network Visualization

Some of the systems will display a forward-looking time-phased view, making it easier to visualize which SKUs

will run out or have excess, including when that will happen and how large and prolonged the imbalance will be.

Visualization is trickier when there are thousands of SKUs and hundreds of locations across the network,

creating potentially millions of SKU-location combinations. An excellent UI/UX design is required to help the user

to easily monitor those millions of combinations, aggregating the related ones and bringing the most important

ones to the top. A good UI helps the user intuitively navigate the data and find the required information to

resolve the issues. This is one of the areas where various ADSA platforms tend to be differentiated. That is why it

is important to get demos of scenarios with high-SKU/location counts within large, complex network settings to

evaluate the platform’s UI/UX’s ability to make those scenarios manageable.



POS and Channel Data Visibility

The ability for a supplier to obtain and use retailers’ POS data is not trivial in either the value it brings, or the

effort required to realize those capabilities. Services such as IRI and Nielsen syndicate data from multiple

retailers, but that data is not as timely or granular as getting daily POS data directly from retailers. Two of the

solution providers we reviewed provide services and systems to obtain retailer’s POS data, cleanse it, format it,

and bring it into a common canonical data structure so that it can be used in ADSA processes.

Another specialized area is channel inventory data. This is frequently a blind spot for manufacturers selling

through distribution channels. Only one solution provider amongst those we reviewed has the capabilities and

preconnected network of channel partners required to provide channel inventory visibility off-the-shelf.

Order Pegging

Some platforms provide the ability to peg available supply (purchase orders, inbound shipments, and on-hand

inventory) to demand (customer orders and/or store or DC locations replenishment).17 This lets users know

ahead of time how many unallocated units there are in each stage of the pipeline. As soon as units get allocated

to an outbound customer order or to a specific location and purpose,18 those units are no longer available for a

different customer (unless due to significantly higher priority of the new order, the units are reallocated and

'taken away' from the first customer’s order or location’s allocation).

Demand Sensing

Some solution providers offer forecasting and demand sensing capabilities. Demand sensing is particularly

relevant to ADSA as it provides a more accurate short-term prediction of demand, incorporating a variety of

casual factors such as weather, competitor’s actions, and other events. Demand sensing thereby helps better

predict when demand will deviate from the plan which makes the time-phased views of future overages and

stockouts more accurate. Some solutions also have specialized demand capabilities, such as managing limited

time offers (LTO) for the restaurant and food service industries and the impact on the supply chain of associated

promotional programs.

Retail Planning Capabilities

Some platforms support Open-to-Buy and/or WSSI19 planning capabilities, which helps ensuring demand-supply

alignment. A few have deep retail suites, including capabilities such as category management, assortment

planning, allocation and replenishment, promotion planning and execution, and product transition planning and

execution. These tools all play a role in keeping demand and supply balanced, which is particularly challenging

for retailers trying to get the right inventory levels for a mix of size, color, and style at each location across a

large and diverse network of stores and ecommerce fulfillment centers.

17 For example, if a brand owner gets three orders from different retailers for 1,000, 5,000, and 10,000 of a specific item, and the brand

owner has 5,000 at their DC, 5,000 in transit, and 5.000 on order (in production at their supplier), they could allocate those units against the orders, based on expected receive dates and the priority of each retailer. In this hypothetical scenario, the brand owner would still be 1,000 units short as the total on order (PO to supplier), inbound, and on-hand is 15,000, whereas the orders from the brand owner’s customers total 16,000 units. 18 Such as anticipated replenishment for an ecommerce DC or store location. 19 WSSI = Weekly Sales, Stock, and Intake, a process whereby retailers monitor actual consumption and perform planning to ensure the right inventory will be in stock.

https://www.thewbe.co.uk/wssi-weekly-sales-stock-intake



Collaboration Capabilities

Every one of the ADSA solutions we looked at allows trading partners to collaborate in one way or another. Most

provide a way to invite trading partners into an online conversation, often via an email address. These

collaboration conversations are often tied to a particular order, shipment, or issue (e.g., shortage or delay), so

that participants automatically see all the relevant information displayed in the context of the discussion. Some

have case management functionality, providing a more structured approach to creating and tracking issue

resolution, including tasks and escalation when steps are not being completed on time.

Analytics

An ADSA platform brings together a tremendous

amount of information about demand, customer

orders, POs, production status, shipment status, and

more. These platforms essentially create digital

twins20 of the supply chain. Having all of this data in

one place, correlated together, presents enormous

opportunities to gain value and intelligence via

analytics. Some examples of what we see solution

providers offering include:

• Supplier Performance—Near real-time KPI

reporting on manufacturers’ and suppliers’ performance, such as perfect order rate/trend, compliance,

product quality, response time for issue resolution, on-time in-full (OTIF) performance,21 and so forth. These

can be incorporated into a supplier dashboard, inform ongoing improvement discussions with suppliers, and

aid in contract negotiations.

• Forwarder and Carrier Performance—On-time delivery performance, delay reason breakdown and analysis,

exception-free/claims-free delivery rate analysis, carrier load preferences, tender response time, tender

accept/reject rate, customer service responsiveness, and information sharing by the carrier (e.g., do they

provide accurate real-time location and status, ePoD, etc.). This information can be used to drive

performance improvement discussions, as well as aid in carrier selection. Sometimes the data reveals that

certain carriers are better at specific routes or handling specific cargo, enabling a more nuanced and

targeted approach to selecting the best carrier for different parts of the business.

20 Digital twins are a lot more than just the raw data. To provide a high-fidelity representation of what is happening in the real world,

solution providers continuously update current and predicted supply chain flows. Some build out and maintain up-to-date knowledge graphs of the network, using transactional data flowing through the network. These graphs model and represent all of the products, parties, and places in the network, and the constantly changing relationships between them (e.g., this product is now at this location). Sophisticated modeling is required to get a more accurate representation of the real world, for things like understanding the feasibility of various solutions. Some solutions use process mining to understand typical patterns in the network and detect anomalies, such as a stalled shipment. Intelligence is needed to filter out noise in the data as well. Furthermore, an intelligent supply chain digital twin includes the policies, targets, rules, and constraints to identify deviations (e.g., stock threshold breached), as well as prescribe the best course of action. Thus, an advanced digital twin encapsulates a tremendous amount of knowledge and intelligence about the supply chain network. 21 This is especially important when the supplier is drop-shipping to large important customers. Over the past three years, Walmart has been progressively raising required OTIF performance for suppliers from 70% to 98% and is now levying a fine of 3% of COGS penalty for non-compliant shipments. That kind of customer mandate makes OTIF analytics even more important.

Analytics Potential Questions for Solution Providers:

• What analytics capabilities are built into the platform? Which use cases are pre-built and pre-configured?

• What kind of analytics do you have for supplier performance, such as scorecards, trend analysis, etc.?

• Forwarder and carrier performance analysis?

• Network Lead-Time analysis, including supplier lead times, transit times, and dwell times?

• Does the platform provide historical data and statistics on the actual journey each SKU takes through the network, both inbound and outbound?

• Is landed cost and duty optimization included?

• Analytics for measuring and reducing carbon emissions?

https://www.ontotext.com/knowledgehub/fundamentals/what-is-a-knowledge-graph/

https://www.ontotext.com/knowledgehub/fundamentals/what-is-a-knowledge-graph/

https://en.wikipedia.org/wiki/Process_mining

https://talkbusiness.net/2020/09/walmart-demands-all-suppliers-comply-with-98-on-time-in-full-shipment-rule/



• Network Lead-Time Analysis—In most ERP systems, the lead time is just an estimate and is often very out-of-

date and inaccurate. An ADSA system can provide lead-time data, based on actual events happening within

the network, such as the true order-to-ship lead time from suppliers, transit times for each transport leg,

and dwell times at each node. The data on actual, up-to-date lead times can be sent to planning and

replenishment systems enabling more accurate optimization. Some systems let the user query, aggregate,

slice and dice lead time data in various ways--such as by SKU, supplier, lane, node/facility (e.g., CFS, port,

DC), carrier or combinations of those.

• SKU-level Inbound and Outbound Order/Shipment Flows—Historical views of the actual journey each SKU

takes through the network, from supplier to importer and outbound to the importer's customer or retail

stores can be informative. Analytics may show statistics by SKU, by lane, by node (DC, CFS, port), etc.

Providing data on actual origins and routes enables planning engines to create more accurate supply chain

models.

• Landed Cost Analysis and Optimization—Some solutions provide the ability to calculate actual and

forecasted total landed cost per unit. The cost components that are included in the total landed cost

calculation vary from one solution to the next, but almost always includes actual transportation costs. Many

include other costs such as duties and tariffs, insurance, and so forth. Analytics may roll up by product

category, business unit, geography, or other customer-defined segment to track VAT/duties for financial

management at the company. Two of the ADSA platforms we looked at also provide duty optimization tools,

to help users consider alternative approaches or locations of assembly and packaging, in order to reduce

tariffs and duties in a compliant manner. These can be particularly useful in today’s world of trade wars and

fast-changing tariff regimes.

• Carbon Footprint—A few providers offer tools for calculating the logistics contribution to the carbon

footprint. Only one provided broader CO2 data collection and reporting.

When selecting an ADSA platform, it is worth learning about the analytics provided, to get an understanding of

which specific analytic use cases are built in and pre-configured, what data sets can be exported to external

analytic tools, as well as whether the analytics are primarily for longer-range strategic decisions or provide in-

context near-real-time decision support within the window of execution.

Implementation, Services, Pricing, ROI, TCO

Implementation—What Does it Take to Get Started?

Implementation can be as short as a few days up to many months. The speed of implementation depends on

many factors, such as how many systems need to be integrated, how many trading partners onboarded, the

scope of functionality being rolled out, and the organizational scope of the rollout.

Integration

Some solutions provide a base level of value without requiring any external data integration, and thereby can be

implemented very quickly (as little as a day or two, in some cases). However, much of the kind of ADSA

capabilities we have been discussing requires ingesting many kinds of external data, as described in the section

Data and Supply Chain Visibility—Getting the Complete Picture and illustrated in Figure 2 above.



Most solutions provide some set of pre-built

connectors to common enterprise systems, such as

SAP, Oracle, NetSuite, and others, to integrate

things like purchase orders, supplier master data,

and SKU master data. Other platforms provide

prebuilt EDI-mapping/integration with major

trading partners, particularly large retailers such as

Walmart, Amazon, Costco, Walgreens, Kroger, and

others. It is important to understand not just which

pre-built connectors a solution has, but also the

extent and nature of those integrations—which

data elements and workflows are included. If there

are legacy systems that need to be integrated, then

an understanding of the effort involved to do custom integrations becomes important as well.

Time-to-Value—Agile Implementation, Templates, and Minimum Viable Implementations

Some solutions take longer to implement than others. It is a good idea to try and get a handle on what the

typical implementation time is, including understanding all the things that must happen after go-live before you

start gaining value. Most solution providers have some variation of an agile implementation22 methodology. One

element of this is templates or blueprints. These are pre-configured implementations, which act as starting

points, providing 70%-80% of what is needed in most cases. The idea is to get started quickly with a ‘good

enough’ solution to start getting value right away, then make customizations as needed. As the company uses

the system, it will become more clear which customizations are truly needed and will provide the most value.

The other major aspect of agile implementation is the ‘minimum viable implementation’ philosophy, i.e., don’t

try to boil the ocean, start small to start receiving value that can be used to fund further expansion of the

implementation.

Network Onboarding

ADSA solutions require data from suppliers, LSPs, carriers, channel partners, customers, and potentially others.

Onboarding of trading partners thereby is an important element required for gaining the full value. The time and

effort required to onboard trading partners needs to be considered both for the initial implementation and the

ongoing maintenance of the platform, as new trading partner relationships are formed. Some platforms have

large networks of pre-connected trading partners, which can help reduce the initial effort required for

onboarding, depending on how many of a company’s existing trading partners are already on the network.

Value-Add Services

Core Implementation Services

ADSA solution providers offer a wide variety of services along with their SaaS23 subscription services. Virtually all

offer core implementation services such as installation, configuration, training, and onboarding of trading

22 For more on this topic, see Agile ERP: Continuous Improvement Through Rapid, Incremental Implementation and Value Realization 23 SaaS = Software-as-a-Service

Implementation Potential Questions for Solution Providers:

• What are the steps and timeframe of a typical implementation? What needs to be done before value is realized?

• Which pre-built connectors do you have for integrating enterprise systems, service providers, and trading partners? What data and processes are included in those pre-built integrations?

• What is the effort involved to build a custom integration to a legacy system?

• Does the platform offer an SDK to enable the development of custom extensions that are guaranteed to work with future releases of the platform?

• What is the process and effort required to onboard trading partners? Do you have an existing network of pre-connected trading partners and if so, which of our trading partners are in it?

http://www.clresearch.com/research/detail.cfm?guid=6B952722-3048-79ED-99F0-BE6A4791D477

https://en.wikipedia.org/wiki/Software_as_a_service



partners. Onboarding services typically include supplier outreach, training, setup, and support. Some vendors

charge separately for the core implementation services, while others include some or all these services in the

SaaS subscription fee. Some will provide additional services, such as discovery, design, and customization for an

added fee. Some providers supplement the core services with more advanced training (e.g., for super users and

IT), and advanced services like process design and change management, typically for an additional fee.

Post-go-live Intensive Support

One provider we reviewed includes ‘Hypercare,’

which is a period of intense support to ensure a

successful launch for a period of one to four months

after going live. This support is provided by the same

team that did the deployment, who are therefore

very familiar with the client and the client’s systems

and supply chain by that point. This service is

designed to ensure that critical supply chain

processes running on the platform are working,

transactions are flowing, and workflows are running

as intended, so that the business continues to

operate uninterrupted during the transition to the new platform.

Data Management and Monitoring

Some solution providers offer data management and monitoring services. The more robust of these provide a

staffed network management center that monitors EDI and other transactional traffic 24 X 7, detecting

whenever there are integrity issues with data being passed back and forth with trading partners or missing

expected responses (like no acknowledgement message received within a specified period of time). Whenever

an issue is detected, the staff will take steps to resolve it, including, as needed, contacting the appropriate IT

personnel at the source of the data to help resolve it. This service helps keep transactions flowing—such as

customer orders, purchase orders, invoices, and payments—as these are the ‘lifeblood’ of the company.

Consulting

At least one ADSA solution provider we reviewed provides business strategy consulting, helping with strategies

such as how to become a more strategic partner to big retailer customers. However, most providers rely on

partners, such as system integrators, to provide consulting services.

Supplier Management, Sourcing Services

One provider we looked at offers fairly extensive supplier management services including supplier certification,

onsite audits, quality management (going onsite to fix quality issues), as well as new product launch services and

sourcing services (RFQ and selection assistance).

Custom Reports and Analytics, Benchmarking Services

Many ADSA solution providers offer services to create custom reports and analytics. All provide some

preconfigured, standardized dashboards and reports out-of-the box. A couple provide benchmarking services, to

compare various performance metrics and KPIs against the averages of peers in the network.

Value-Add Services Potential Questions for Solution Providers:

• What value-add services do you provide? Which are included in the subscription fee and which have a separate fee?

• What kind of implementation services are provided, such as configuration, training, and onboarding?

• Do you have any special or extra services to help ensure the smooth launch and success of the solution adoption?

• Do you provide services to monitor and ensure the integrity and continued flow of transactions and data from trading partners?

• What services to you provide to help create custom analytics and reports?

• Do you provide any benchmarking services?



Solution Pricing

SaaS Subscription Pricing

All of the ADSA solutions we reviewed are sold as

SaaS, paid for primarily via a recurring subscription

fee. Most also have one-time charges for some of

the implementation and value-add services, such as

integration with other system or data management

services. The SaaS subscription fee is typically based

on pricing factors designed to try to scale with the

value being provided. Below are some of the pricing

factors we have seen used to calculate the subscription fee. Keep in mind that no provider uses all of these

factors, but most will typically use between two to five factors as the basis for their fees:

• Functionality Used—The scope of functionality available to the user is the most common basis for pricing. A

couple of solutions give all users access to all functionality—i.e., they do not charge a different amount for

different modules. But most have per module or per application pricing, with anywhere from three to a

dozen or so modules. One provider charges per ‘network service’—their functionality is delivered as dozens

of fine-grained services integrated together and the customer only pays for those services they use.

• Number of Trading Partners—The number of trading partners the user’s company is connected to or

transacts with.

• Number and complexity of Integrations—The number of other systems integrated into the platform for the

user, how complex those integrations are, and whether or not they are custom integrations.

• Network Complexity—Measured as number of SKU-location combinations. Sometimes including frequency

or volume of transactions.

• Savings Realized—A percent of the savings realized by using the platform. Typically used when part of the

value proposition is a reduction in spend on materials or transportation cost, and that reduction can be

reliably measured and agreed to.

• Revenue Transacted on Platform—One provider charges suppliers a percent of the revenue those suppliers

receive through the platform. Another charges a percent of the value of goods flowing through the platform

or managed by the platform.

• Number of Users—Only one of the platforms we reviewed charges per user and even they charge per named

user, with unlimited guest users. Most ADSA platforms want to encourage widespread usage of the system

and thereby allow unlimited users at no additional charge.

• Revenue of Business Unit—A percent of the revenue24 of the business unit using the software.

• % of Spend Managed Through Platform—For things like sourcing and procurement, supplier management,

logistics, and global trade functionality, the charge may be a percent of the total spend being managed via

the platform.

• Transaction Volumes—Number of orders and/or shipments flowing through the platform.

24 Usually in tiers, like companies below $10M pay $X/month, $10M - $50M pay $Y/month, $50M - $200M Pay $Z/month, and so forth.

Pricing Potential Questions for Solution Providers:

• What is the basis for subscription pricing? What is the estimated monthly fee for our business and how is that calculated?

• What is the minimum commitment period? Timing of payments (i.e., monthly, quarterly, annually)?

• What are all the other costs outside of the subscription fee?

• What services do you offer and how do you charge for those?

• Do you offer to share performance risk/reward via gain sharing fees (based on whether the solution delivers the promised benefits) in exchange for a reduction in subscription costs?



Pricing of Services

Pricing for services—such as implementing integration to other systems, providing extra training, data

management, consulting services, and custom analytics development—are usually based on either time and

materials or a fixed fee. Some services are priced using different pricing basis (besides time and materials), such

as the complexity of an integration determining the price of implementing the integration.

Typical Annual Pricing Range

There is no ‘typical’ price for ADSA solutions because the range and variety of functionality is so large and varied.

Furthermore, ADSA functionality is often wrapped up in other broader solution functionality and wider

initiatives, as described at the beginning of this report (first paragraph in section What Problem(s) Are You Trying

to Solve, Now and In the Future?). This makes it quite difficult to do an apples-to-apples comparison. Ultimately,

a solution buyer must do their homework, looking at all aspects of the competing solutions they are considering,

weighing the cost and benefits of each different solution, and the fit for their unique situation. Once a

methodical evaluation has been done, the choice often becomes obvious.

In our research, none of the solution providers were willing to let us publish actual pricing information, though

most of them shared price ranges with us, off the record. Thereby we can provide some broad generalizations.

Solutions that are narrower in scope and smaller deployments tended to come in at subscription prices of

around $50K to $100K per year. For mid-sized companies and solutions with broader functionality, including

more execution and planning capabilities, the price ranges were in the several $100K range. At the high end,

large rollouts to F500, even of relatively narrow functionality, were over $1M per year. Looking at broader

functionality to large corporations, like significant portions of a complete supply chain suite sold to F500-sized

companies, the price tag was typically several million dollars per year.

Gain Sharing

Only one of the providers we spoke with offers gain sharing. This is where the solution provider offers to reduce

the monthly subscription fee in exchange for sharing the value of gains realized by implementing their solution.

Gains are measured based on one or more value-quantifiable metrics improvement. An example might be a

reduction in transportation spend or a reduction in spend with suppliers. Both parties must agree on how the

metrics and improvements will be measured, how the financial value of those improvements will be calculated,

and how those gains will be shared—i.e., a certain percentage of the value gained will be paid to the solution

provider. Gain sharing enables risk and reward sharing and better alignment of interests, but it is not so

common, in part because of the challenges in measuring and agreeing on the value realized. If interested, more

on this topic can be found in Outcome-based Business Models for Enterprise Software.

http://www.clresearch.com/research/detail.cfm?guid=BCA9FDEA-3048-78A9-2FF7-904AA12FD171



Financial Assessment and Comparison of SaaS Systems (ROI, TCO, et al)

When considering a new system, decision-making executives and financial managers often want to make a

financial comparison of the different possible investments and outcomes. Common financial analytic tools for

making these comparisons include ROI, NPV, IRR, and BCR.25 These have in common the need to understand 1)

the stream of investments or total costs involved and 2) expected benefits over time, quantified in monetary

terms.

Total Cost of Ownership

It is important for the buyer of the solution to

thoroughly understand all elements of the total cost

of ownership. Misunderstandings or surprises later

in the process (after a deal has been signed) can be

quite painful and disruptive. By far the largest

element of TCO for most of the solutions we looked

at is the monthly subscription fee. Most require

relatively little training and typically quite modest

ongoing administrative labor by the customer

(usually a fraction of an FTE). Some of the more

functionally extensive systems required a full-time

internal support person to provide front line help desk support.

The largest costs, other than the subscription fee, tend to happen during implementation. These may include

fees for implementing integrations to other systems, special or extra training, and other specialized services. We

found quite a large variation in the size of implementation and consulting fees.

An important consideration in TCO analysis for implementation of a new ADSA solution is to factor in the

avoided costs of maintaining and upgrading existing on-premise or hosted single-tenant enterprise-centric

legacy systems. The avoided future costs can be substantial, particularly when the ADSA solution replaces

capabilities across multiple legacy point solutions and ERP instances.

Calculating and Monitoring Expected Benefits

Most solution providers provide some sort of expected ROI or benefit numbers. Buyer should have some

skepticism and perform some diligence to make sure they understand how these numbers are calculated, what

the mechanism of value creation by the solution is, how well that mechanism applies to their situation, and the

extent to which the solution provider has derived their ROI numbers from actual measurements by their

customers vs. more theoretical exercises about expected benefits. Drivers of ROI can be quite varied. Converting

qualitative benefits into precise dollar value figures can be challenging. Some of the benefits and drivers we

heard about in our research include:

25 ROI=Return on Investment, NPV=Net Present Value, IRR=Internal Rate of Return, BCR=Benefit-Cost Ratio

ROI, TCO, Benefits Potential Questions for Solution Providers:

• What ROI or benefits-to-cost ratio can our business expect?

• What should be our expected total-cost-of-ownership?

• What benefits should we expect? What specific metrics improvements?

• How are those metrics improvements delivered by the solution? What are the mechanics?

• How do you calculate the value delivered by the platform?

• Do you have examples of specific metrics improvements for specific customers? If so, how were those achieved? Can we talk to those customers?

https://en.wikipedia.org/wiki/Return_on_investment

https://en.wikipedia.org/wiki/Net_present_value

https://en.wikipedia.org/wiki/Internal_rate_of_return

https://en.wikipedia.org/wiki/Benefit%E2%80%93cost_ratio



• Revenue increase—Due to fewer out of stocks, higher customer satisfaction.

• Higher customer satisfaction, fewer chargebacks—Due to more reliable performance (e.g., higher OTIF,

better compliance adherence, fewer quality issues, etc.), more strategic customer relationships, fewer out of

stocks, improved supplier performance.

• Improved competitiveness—From greater on-shelf availability and service levels.

• Margin uplift—From better markdown management, cost reductions, less spoilage and waste.

• Reduced total landed cost—By reduction in original product cost, transportation and expediting costs, duties

and tariffs, insurance, etc.

• Performance improvements—Higher speed and efficiency, reduced labor costs, fewer errors (by automating

manual activities), faster resolution of issues.

• Reduced inventory levels—Via better alignment of supply and demand, freeing up working capital while

maintaining or improving service levels.

• Reduced waste – By better matching of supply with demand (resulting in less expired or obsolete inventory)

and better inventory and mix management for trend-sensitive industries such as fashion apparel, cosmetics,

and consumer goods (resulting in less discounted sales).

• Growth enablement— Doing more with same resources, via automation and performance improvements.

Evaluating Potential Solutions

Discovering Potential Solutions

There are many different ADSA-related solution providers in the market and there are different ways to discover

potential solution providers for whatever problem(s) an organization is trying to solve. Google searching is a

good place to start as most solution providers want to be found. They invest in search engine optimization to try

and get near the top of the list for searches using common phrases and concepts related to their solution.

Another source of potential solutions is analyst reports. Analyst firms frequently provide market reports26 for

different solution spaces. Part Three of this report series describes eight very different ADSA solution providers.

There are also enterprise software comparison websites27 that can provide lists and superficial comparisons of

solutions in different categories. These sites vary widely in their quality and completeness. Finally, talking to

peers to find out what solutions they know about or are using is often helpful.

Shortlisting Potential Solutions

There are a few questions or ‘filters’ that can be used to quickly narrow down the list of candidate solutions.

These include the functional footprint, industry focus, and other factors to consider about the solution.

26 For example, ChainLink Research has a two-part report called Supply Chain Networks Revealed which describes how Supply Chain Application Networks work and compares at a high level four different solutions. We also have part three of this series, Agile Demand-Supply Alignment—Part Three: ADSA Solution Assessments, which evaluates eight different ADSA solutions in depth. Gartner has reports and reviews on Multienterprise Supply Chain Business Networks, Nucleus Research released its Control Tower Technology Value Matrix, and Grand View Research published a Control Towers Market Report. 27 Such as Technology Evaluation Centers SCM Shortlist, Capterra’s Supply Chain Management Software listings, and G2’s peer-to-peer

reviews in Supply Chain & Logistics.

http://www.chainlinkresearch.com/research/detail.cfm?guid=C3A3C9F6-E20D-F905-4E55-35B5113FC18F

http://www.clresearch.com/research/detail.cfm?guid=9C25CAA1-BD80-C824-73B9-1A497CFE27EB



https://www.gartner.com/reviews/market/multienterprise-supply-chain-business-networks

https://nucleusresearch.com/research/single/control-tower-technology-value-matrix-2020/

https://www.grandviewresearch.com/industry-analysis/control-towers-market

https://www3.technologyevaluation.com/shortlist2/scm.aspx

https://www.capterra.com/supply-chain-management-software/

https://www.g2.com/categories?utf8=%E2%9C%93&q%5Bsearch_query_cont%5D=supply%20chain&q%5Bcategory_type_eq%5D=all



Functional Scope—Best-of-breed vs. End-to-end

Looking at the functional footprint and industry focus of the solutions first will quickly narrow the field. It is

important to look beyond the immediate functional needs and consider the needs of an integrated solution that

ties together all the functions needed for an end-to-

end view. You may be looking for a transportation

management or sourcing and procurement solution

today, but in the long run, an end-to-end, cross-

function, multi-enterprise approach is needed to

achieve true agile demand-supply alignment,

enabling delivery of higher quality and service levels

at lower landed cost. This does not mean

abandoning the immediate needs, but rather seeking

a solution that can meet both the immediate

functional needs while also providing a longer-term

platform for growth and end-to-end capabilities.

Industry Focus

Closely related to the functional scope is the industry focus of the solution. While there are some ADSA solutions

that are horizontal in focus, i.e., they serve most industries almost equally well, most ADSA solutions have

functionality and processes that are best suited or specifically designed for specific industries. For example, two

of the providers we looked at have functionality specifically designed to provide CPG brands with better visibility

into their retailer customers’ POS data. Some solutions focus on apparel and footwear retail, providing industry-

specific capabilities such as multiple product hierarchies and WSSI planning capabilities. Others offer grocery

retailer solutions that provide cold chain, fresh food management, intraday forecasting and deliveries (for deli

and bakery), and other grocery-specific functionality. Using industry focus as a filter should help narrow the field

considerably, eliminating many providers from consideration.

Other Factors

Besides functional and industry focus, there are other filters that can be used to further narrow the list. One key

factor is what size company the solution provider serves. Almost no solution providers sell to all size companies;

rather they will target small, medium, or large enterprises. Some solution providers will span small to medium or

medium to large firms. Others have one set of solutions for small companies and a different set of solutions for

large companies.

Another consideration is how mature the solution is. Solutions that have been around for a decade or more

have the advantage of being battle-hardened and usually have richer and more mature feature sets, as they

have had a long time to develop and hone the functionality, driven by customer needs. Solutions that are newer

may not be as functionally rich, but they have the advantage of being built on newer technology foundations,

with more modern user interfaces. Older solutions have often been updated to run on newer platforms and/or

more modern UIs, but nevertheless they usually are carrying some level of ‘baggage’ from their heritage.

Another key factor is how well the vision or direction of the solution provider aligns with the buying company’s

vision and direction. For example, if a company is trying to digitalize, and is striving for a more autonomous

Shortlisting and Selection Potential Questions for Solution Providers:

• What is the primary functionality of your solution?

• What industries to you primarily serve? Which industry-specific functionality do you have?

• What size are most of your customers?

• When were you founded? What technology is your platform based on?

• Can we have a demo showing how your solution addresses the specific problem(s) we are trying to solve?

• What is required to achieve the capabilities you demo for us? What data do you need from us and from other sources? What licenses do we need? What other dependencies are there to achieve what you show us?

[Questions from earlier in this report should also be asked.]



supply chain capability, it would be important to find out how the solution provider supports that vision, both in

the current product and on their roadmap.

The framework provided in Part One of this series and illustrated again at the beginning of this report in Figure 1

- Elements of Agile Demand-Supply Alignment, can be used to assess solutions as well. A buyer could ask what

capabilities a solution provider has for 1) becoming aware of supply disruptions or demand deviations from plan,

2) gathering necessary information together to understand the situation, 3) prioritizing the issues, 4) considering

different options to solve the issues and selecting the best course of action, 5) executing the selected course-

correcting action and, 6) monitoring to ensure the actions have been properly executed and the desired

outcomes achieved.

Selecting a Solution

Requesting a Demo

Once a shortlist of potential solutions has been developed, there are several actions a buyer can take to help

them select the best solution for their unique situation. With ADSA solutions, it is important to ask for a demo of

the specific types of problems the buyer is trying to solve. Seeing what information is brought together; how

information about the network, disruptions, and demand-supply imbalances is visualized; how those issues are

prioritized; how what-if analysis is done; how the platform optimizes and recommends solutions, and how the

outcomes of different courses of action are compared. Seeing these in action makes a huge difference in

understanding how effective ADSA solutions are in managing complex networks with large numbers of demand-

supply imbalances occurring every day. Ideally, a demo using the buyer’s real data is preferred, otherwise a

demo should be requested that simulates a company of similar size and complexity, solving issues similar to the

buyer’s issues. A demo of other capabilities, beyond the ones the buyer is seeking, can illuminate other potential

benefits and uses of the platform.

When viewing a demo, it is important to find out what dependencies are required to achieve the functionality

being shown. For example, what data is needed and what kind of integration efforts are required. If the demo

shows capabilities that require data from the buyer’s current enterprise systems that are not currently available

or that will be expensive to integrate, then it is important to know that ahead of time, rather than being

disappointed later. It is important to know what can be done within the constraints of the buyer’s currently

available systems and data, as well as the cost of any integrations needed to achieve what is being shown in the

demo. Similarly, it is important to understand exactly which applications need to be licensed to get all of the

functionality being shown.

Due Diligence, Increasing the Chances of Success

If the solution provider has a network of preconnected trading partners, it is useful to find out which of the

buyer’s trading partners and service providers (e.g., 3PLs, carriers, etc.) are already on the platform and what is

the cost, effort, and timeframe for onboarding those trading partners who are not on the platform. How much

training is typically needed and how is that delivered? Questions about the architecture and the other questions

outlined throughout this document should help buyers make an informed decision. By having a clear vision and

articulating what solution the buyer is looking for, and doing the proper due diligence, the chances of a

successful ADSA implementation are greatly increased.


© 2021 ChainLink Research, All Rights Reserved.

About ChainLink Research

ChainLink is a recognized leader in custom research and advisory services, with a focus on supply chain, Internet of Things, and blockchain. Founded in 2002, our emphasis from the start has been on inter-enterprise interactions and architectures (‘the links in the chain’). We have conducted over 75 primary research projects, interviewing and survey-ing over 10,000 executives and professionals. Much of our research focuses on industry-specific use cases, business cases and ROI, and drivers/inhibitors of technology adoption, and business change. As a result, we have developed a deep, multi-industry practice, founded on real-world, validated, supply chain-wide, end-to-end perspectives that have helped our clients understand, plan, and succeed as they move into the future.

For more information, contact ChainLink Research at:

321 Walnut Street, Suite 442, Newton, MA 02460-1927

Tel: (617) 762-4040. Email: [email protected] Website: www.clresearch.com

mailto:[email protected]

http://www.clresearch.com/

Date post:	11-Mar-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Part Two: Evaluating ASDA Solutions · 2021. 1. 31. · third-party service providers (e.g., 3PLs,...

Documents