There are a few different variations of agility when it comes to supply chains. These different variations exist due to our obsessions with buzzwords. Keeping buzzwords aside, the core capability we want is what is dubbed as “supply chain as as-a-service.” Only an agile supply chain, which, in my perspective, has to be flexible, can “flex” as the parameters in the supply chain evolve.

But in today’s age of system-driven supply chains that leverage systems and solutions, the core of that agility lies in the underlying technology platform. Hence, when marketers argue that the digital transformation of the supply chain will help build agility and flexibility, they are not wrong. Peel the layers of the onion of a few examples, and you will realize that the first step of flexing any specific supply chain process starts with a system. Whether reallocating raw materials for manufacturing or rerouting using a different mode, it happens within a system before it gets executed in the real world.

But then why do supply chains still struggle, despite systems providing the core capability to initiate the “flex” process?

Because we confuse visibility with visibility. The solutions, the way we use them today, provide us visibility, whether in terms of current state or prescriptive analytics. Even the prescriptive and predictive analytics insights provide visibility into the options we can execute. Then comes the actual execution. Leveraging the people, processes, and technology triad gets executed by:

• Flexible floor execution systems
• Flexible process
• Trained people

The crux of the successful recipe of flexible supply chains is flexible processes aided by flexible execution systems. This is where the gap is, in my opinion. The gap is because we have static execution solutions vs iterative tools. This article series will explore this concept and understand why this iterative execution layer is imperative.

The core systems that we use for supply chain management are primarily transactional. These solutions are designed to capture information about the flow within the supply chain, whether it is the movement of physical material money or activities associated with these movements. These solutions come in a predefined format, and as you may know from experience, in many cases, even to align them to your specific flows, you have to do custom development work on these tools.

True supply chain flexibility and agility can never be attained until the underlying technology also can “flex.” The good news is that transactional systems do not need to be as flexible. After all, they were designed to capture transactions once they were executed. The “maximum flexibility” level needs to be embedded in the execution layer. Unfortunately, most execution systems today are designed like transactional systems.

This transactional system-like design means that if there is a need to flex a process in the real world, mimicking this process in the tool becomes a challenge.

Assume a scenario where there is a surge in demand. Also, assume that your supply chain processes are not designed to be “as-a-service” like most supply chains. So obviously, there will be a rush to make “alternative” arrangements and tweaks to processes to fulfill as much of this increased demand as possible. While this itself becomes a challenge in non-optimally designed processes, another challenge that you have to endure is to work on executing these transactions in the system because executions did not happen the way processes have been captured in the static execution systems. Rather than aiding the flexibility needs, these systems end up making the situation more difficult.

In the second part of this article, to be published on 11/7, we will start with a proposed high-level architecture of how the supply chain solutions stack should look to have a stack that truly aids in building flexible and agile supply chains. In the third part, we will delve deeper into the need for an iterative software approach to execution systems. In the fourth part, we will start discussing how to build fluidity using technologies available today and conclude that in the fifth and final part.