Supply chain planning. A lot has changed. And much has not.

The analyst reports, vendor briefings, and conference presentations paint the picture of traditional supply chain planning, only better. My perspective is that we need to challenge the current state. I push this position for two reasons:

• The inadequacy of the current definition in a more variable world
• Emerging technology capabilities to drive great value

Here, I start a dialogue that I hope others continue on LinkedIn.

Custom Code Versus Packaged Applications

For years, the pendulum swung. Build custom code versus buying a packaged application for supply chain planning? While bespoke applications are appealing—requiring few user enhancements—the risk lies in maintaining the system throughout its lifecycle. Employees retire, jobs change, and code evolution may become an afterthought. As security issues escalate and process requirements morph, custom applications — once thought a good idea — may no longer be a good fit.

Why a packaged application? While the promise never achieved reality, let’s start with the promise. A packaged application promises to deliver proven business capabilities through prebuilt software, helping an organization achieve business outcomes faster, at lower cost, and with less risk than building a solution from scratch. The goal is to codify best practices, standardize work, and deliver business value without reinventing the wheel. But what if historic practices are no longer the state of the art and there is an opportunity to redefine work? I think that this is the current state.

The Promise Versus the Reality

The promise is strongest when the application delivers meaningful business capabilities out of the box. It weakens when organizations must customize extensively, reconcile incompatible data, build integrations, and redesign workflows around the software’s limitations.

As shown in Figure 1, while improving supply chain planning was important to digital transformation strategies, the industry largely failed. The reasons are many, which I have elaborated on in prior posts, but it boils down to line-of-business leaders understanding transactional systems more than planning systems.

Figure 1. Digital Transformation Project Effectiveness

The supply chain planning market is supported by an ecosystem — consultants, infrastructure specialists, and academics. As AI evolves, the ecosystem has moved to make historic processes faster and more efficient while largely ignoring whether traditional processes still fit today’s ecosystem. This leaves innovators with few alternatives.

A Possible Alternative

Is there an alternative? Satisfaction with existing planning solutions is low, and knowledgeable consultants are tough to find. Existing technologists sell tactically, with little innovation.

So, what if there were an alternative? An in-between option? With the evolution of cloud-based data and AI platforms like Databricks and Snowflake, organizations can bring data together, prepare and analyze datasets, build machine-learning and AI applications, and make data available across the enterprise.

With existing Supply Chain Planning (SCP) solutions, IT teams could build plug-ins to existing software, and the Supply Chain Planning applications, as we know them now, could then serve as a system of record, enabling customized applications to be built on top of existing platforms.

As requirements evolve — moving from tight integration to interoperability—and as we need to fill the supply chain planning “black holes,” this in-between option might be the answer.

My calls last week were full of end-to-end chatter. Let’s face it: we don’t have a suitable end-to-end supply chain planning process/technology for any industry. Let’s examine some use cases:

• Direct Procurement. Today, no good alternative exists to improve direct procurement (items on the bill of materials) today. Most procurement efforts have focused on building indirect (items not on the bill of materials) buying processes. Companies handle opportunities like alternate sourcing, reverse bill of materials, grade management, substitution, and hedging as one-offs, usually through custom code or spreadsheets. To examine these alternatives, a company must use strategic design technologies like Lyric and Optilogic, but these do not enable trade-off evaluation at a more granular level.
• Consumption Logic. In planning systems, plans are consumed in a funnel, as shown in Figure 2. Plans become more granular as they move through time horizons, trading off constraints. Lead time should define time horizons, but in most cases, it does not. Most of the effort in today’s planning systems focuses on minimizing manufacturing constraints outside lead time in the tactical horizon. Other constraints–labor, procurement, and transportation–are largely ignored, and there is no effective way in today’s technologies to translate plans in one horizon to the next. The fixed rules of the past don’t work, and as the plan moves across time horizons, it becomes more industry-specific, making it less attractive for a planning technology provider to scale.

Figure 2. Time Horizon Definition

• Bullwhip. Traditional applications optimized functional costs, while ignoring the obvious. What is the obvious? Making individual silos more efficient (operating at a lower cost) creates waste. No solution in the market helps us minimize waste and measure the bullwhip to measure plan effectiveness. Some new software solutions are entering the market. The struggle is that it is very hard to bring a new supply chain solution to market from a bootstrapped start-up. Using Databricks or Snowflake will enable market entry of this type of application as a “plug-in.”
• Operational Planning. The lure of agents and agentics is appealing. How can we maximize planner effectiveness and enable collaboration between business leaders and planners? The answer lies in automating the operational horizon. However, no established process flow exists for the operational horizon. While we talk about Sales and Operations Execution (S&OE), no solution exists in the market. Available-to-Promise logic is underused, and it rarely interoperates with Allocation processes. The traditional approach aligns functions and drives a functional response, but functional alignment does not ensure organizational alignment across make, source, and deliver. For example, in the KetteQ application, we see the automation of functional sensing and response, but the response is not aligned to a balanced scorecard or a strategic framework/definition of how to make trade-offs between source, make, and deliver to drive value. Without a canonical definition in the operational horizon tied to improved plan consumption and a balanced scorecard, agentics will drive a knee-jerk response, throwing the supply chain out of balance and increasing waste.
• Planning Master Data Layer. Supply chain planning operates using a number of factors: lead times, run rates, conversion values, price, yield, grade, etc. Most values are set in the system during implementation and then forgotten. In market-driven value networks, these factors are variables updated based on market data. The planning master data layer built on top of Databricks or Snowflake enables updates with each production planning run.

Orchestration

My final thoughts on the proliferation of the term orchestration in the supply chain vocabulary. I find that it is everywhere, but nowhere. I define orchestration as redefining process capabilities by combining data interoperability, aligning functional processes to drive value-based outcomes, and governing who should make a decision and when. I find that as we automate processes, not enough companies think about governance. In short, it is “who should make a decision,” and “what makes a good decision?”

As we automate, we must clearly define agents’ behavior and outcomes. I have seen regions sandbag demand plans, and collaborative programs degrade the forecast. And heaven help the 10-20% of companies that have not defined governance.

Despite popular opinion, organizations use demand planning technologies very differently, as shown in Figure 3.

Figure 3. Demand Planning Governance

So, the next time a technology provider comes to see you and talks orchestration, ask them three “hows”: As we automate work to collaborate with agents, it is even more important to define the behavior and workflow of humans and agents. We have to up our ante.

• How has your solution moved past integration to interoperability? How have you defined the semantic layer to make this possible?
• How are you driving and defining process canonicals? What role do RPA and Process Mining play in driving outcomes? How does this drive agent behavior?
• How do you ensure governance and analysis of the plan? How do you define a good plan? How do you inform the players about plan compliance and feasibility, and drive insights for the next plan cycle?

As we automate work to collaborate with agents, it is even more important to define the behavior and workflow of humans and agents. We have to up our ante.

Wrap-up

Happy fall. These are my thoughts as my feet scrunch through the leaves. I hope that you are doing well.

I find the evolution of technology exciting, but I find the potential to redefine work and unlock even more value even more exciting.

Please share your thoughts.