Supply Chain Needs Programmable Systems, Not Configurable Products
I have recently published Introduction to Supply Chain as a free, online book. In it, I argue that supply chain decisions should be produced by programmatic systems rather than by “configurable” software products. Since the book is intentionally broad, I want to use this post to focus on one specific idea: why Lokad has embraced a deeply programmatic stance, and why this puts us at odds with the mainstream view of supply chain software.
I will not discuss specific vendors. What interests me is the underlying philosophy: what kind of software is even appropriate for supply chain?
Why generic software struggles with concrete supply chains
Most software sold into supply chain today follows a similar storyline.
First, you start from a transactional backbone: something that records orders, receipts, stock movements, invoices, shipments. This layer is relatively standardized. It works with familiar entities: customers, purchase orders, SKUs, locations. It is expected to be generic and reusable across many industries, which it largely is.
On top of this backbone, you add “planning” or “optimization” modules. Those modules promise to transform past and present data into better decisions: purchase orders, transfers, production plans, allocations, prices, and so on. Vendors typically present these capabilities as configurable applications. You don’t write the logic; you configure it. You define rules. You set parameters. You tune models. You adopt “best-practice” processes.
At first glance, this approach seems entirely reasonable. We do, after all, see broadly similar problems everywhere: how much to buy, where to put it, when to move it, what to promise, what to discount. Surely a generic platform can address those problems in a reusable way.
Yet, when one looks closely at real-life supply chains, something stubborn gets in the way: the idiosyncrasies.
A cable distributor discovers that ten thousand meters of cable is not “one number”; it depends on how those meters are split across reels, what lengths customers actually order, what cutting waste is acceptable, and which cuts can be promised without ruining margins.
An aerospace company finds that “one piece in stock” may conceal a serialized component with its own maintenance history, certification constraints, and complex substitution rules.
A fashion retailer learns that demand is not just for “SKUs” but for assortments: certain size–color combinations must be present together, otherwise the entire category underperforms, no matter how much individual pieces are in stock.
When we try to cram these situations into a generic decision engine, they do not behave like edge cases. They are the core of the business. Every company has its own version of these “cables”: constraints and economics that do not fit a template, yet determine the profitability of the whole operation.
The result, in practice, is familiar: configurable planning modules at the center, spreadsheets at the edges, and human planners constantly patching the gaps.
Why configuration is not enough
The dream behind configurable planning software is that complexity can be tamed by options: more parameters, more toggles, more rule types, more templates. You should not have to program; you should be able to “teach” the software what to do through configuration.
Unfortunately, configuration has strict limits.
Configuration works when you already know the shape of the problem. If every company shared the same structure of constraints and economics, the same conceptual model of how demand behaves and how inventory responds, then choosing values for a predefined set of rules would be sufficient.
But a real supply chain is not a fixed puzzle waiting for the right parameters. It is a moving target, shaped by competitors, regulations, logistics networks, and customer habits that are constantly changing. Moreover, the most impactful constraints are often precisely those that do not fit anyone’s standard model.
When the model of the world embedded in the software does not match the world you operate in, you have only two options.
Either you change your business to conform to the software. This is occasionally sensible for purely administrative processes, but perilous when it touches your competitive edge.
Or you compensate outside the system: side spreadsheets, manual adjustments, exception handling, last-minute overrides. The core software becomes a kind of elaborate suggestion engine, while real control moves back into human heads and Excel files.
The more you try to stretch a generic planning product to accommodate your specifics, the more you end up with a tangled configuration that nobody fully understands, and that is difficult to evolve. You haven’t escaped complexity; you have buried it in metadata.
Why programmability is unavoidable
If configuration is not enough, what remains is programming.
The word “programming” is often misunderstood here. I am not advocating that every planner should become a software engineer, nor that every company should build an entire stack from scratch. I am simply stating something that I believe is inescapable:
If you want a system to take responsibility for your supply chain decisions, you must be able to express, precisely, the logic by which those decisions are made.
That logic includes:
- How uncertainty is treated: demand, lead times, supplier reliability, promotions, disruptions.
- How economics are encoded: cost of stockouts, cost of excess, holding cost, capital constraints, service commitments, penalties.
- How constraints are enforced: packaging, minimum order quantities, truck and container capacities, shelf-life, substitution rules, regulatory restrictions.
- How trade-offs are made among conflicting objectives.
Each of these elements is specific to your business. Each changes over time. And each interacts with the others in ways that no catalog of configuration options can anticipate.
This is why I say that programmability is not a stylistic preference. It is an acknowledgement of reality. The question is not “Should we program?” but “Where, and using what kind of tools?”
Spreadsheets are a form of programming. They are wildly popular in supply chain precisely because they let practitioners express logic that does not fit into any standard application. Unfortunately, they scale poorly, they encourage duplication of logic, and they do not lend themselves to robust automation.
General-purpose programming languages can express anything, but they come with another problem: if you try to build your entire supply chain intelligence in a generic stack, you quickly find yourself running a software product company in disguise. You have to assemble and maintain databases, distributed compute, interfaces, security, and deployment pipelines that have little to do with your actual business.
The challenge, then, is to embrace programming while avoiding both the brittleness of spreadsheets and the overhead of building a generic platform from scratch.
How this shapes Lokad’s technological choices
Back in 2012, we made a deliberate choice: we would not try to produce a universal “planning product” that claims to work out of the box by configuration alone.
Instead, we set out to build an environment where supply chain decision logic can be expressed as code, in a way that is:
- Powerful enough to encode the real complexity of a business.
- Compact enough to be understandable and auditable.
- Operational enough to run every day, at scale, on top of existing transactional systems.
Concretely, this led us to a few principles.
First, we treat the data coming from ERPs and other transactional systems as raw material, not as something to be merely reported on. We assume that the real value comes from transforming that data into concrete decisions: purchase orders, stock transfers, production schedules, pricing and discount policies, assortment decisions.
Second, we express that transformation as a collection of scripts, written in a domain-specific language designed specifically for supply chain: large tabular datasets, probabilistic demand, economic optimization, and so on. This language is not a generic enterprise programming language; it is a focused environment aimed at making numerical decision recipes concise and readable.
Third, we insist that the output of our computations is not a dashboard, but a set of proposed actions that can be applied to the transactional systems. If our work does not translate into changed orders, changed stocks, changed prices, then it has no reason to exist in production.
Finally, we structure everything so that it can be rewritten. If the world changes, if a pandemic reshapes demand, if a new product category behaves unexpectedly, we aim to change the code quickly and safely, not to wait years for a new version of a product.
This is a very different mindset from trying to accumulate more and more generic “features” in a software product. We are not trying to be everything to everyone. We are trying to provide a sharp instrument that can be used to express the logic that truly matters for a given company.
The mainstream view and where we diverge
The mainstream approach to supply chain technology is built on a reasonable aspiration: to standardize and industrialize planning processes. It emphasizes integrated suites, pre-defined best practices, and user-friendly configuration. It promises faster deployment and reduced reliance on scarce technical skills.
There are situations where this approach delivers value, especially when the business is relatively close to the standard models assumed by the software, and where the primary goals are visibility, governance, and basic coordination.
Where we diverge is in the answer to a specific question:
Where should a company put the intelligence that actually decides what to do?
The mainstream answer is: inside a configurable product, maintained by the vendor, adapted by parameters, workflows, and extensions.
Our answer at Lokad is: inside a compact, programmable layer, operated by a small team that owns the decision logic and can change it as reality changes.
From this difference flow many practical consequences.
In a product-centric view, the central difficulty is choosing and implementing the right product, then aligning the organization with its processes and functionalities. Once the product is in place, attention shifts to using it correctly: making sure people look at the dashboards, follow the workflows, fill in the inputs.
In a programmatic view, the central difficulty is building and maintaining a good numerical recipe: one that reflects the real economics of the business, handles uncertainty meaningfully, and can be revised quickly when needed. The software platform is judged by how well it supports that endeavor: can we express complex constraints without turning the logic into spaghetti? Can we rerun yesterday’s decisions to understand what happened? Can we experiment safely with new ideas?
Both approaches feature algorithms, forecasts, optimization, and attractive interfaces. The difference lies in who ultimately controls the logic and how adaptable that logic is.
A narrow path, but a necessary one
The programmatic path is not the easiest to explain. “You will have code that expresses your supply chain decisions” sounds less glamorous than “You will have an intelligent system with configurable best practices.” It also requires a certain discipline: clear ownership, rigorous versioning, proper instrumentation, careful rollout.
Yet, after nearly two decades spent observing supply chain software in practice, I see no viable alternative if we take automation seriously.
If we want systems that do more than suggest and visualize; if we want them to take responsibility for decisions that move billions of dollars’ worth of goods; if we want them to survive shocks and adapt to newly discovered constraints, then we must give ourselves the means to express logic precisely and to revise it without fear.
That is what programmability offers.
Lokad exists because I believe that supply chain is too important to be left to opaque configurations and rigid products. It deserves software that acknowledges the messy, peculiar reality of each business, and that gives those who run the supply chain the tools they need to encode their understanding in a form that can truly act.
This perspective explains both the technological choices we have made and the way we work with our clients. We do not sell a box that claims to contain intelligence. We provide a way to build it, refine it, and keep it alive.
