The system of record isn't where the work happens

Over the past two decades, I've transformed operational flows and boosted supply chain performance across eighty countries. My experience spans consumer goods, pharmaceuticals, industrial materials, and soft commodities sectors. I developed and coached more than 300 individuals. Six post-merger integrations challenged my transformation and change-management skills. To complement this, I had the opportunity to shape overall capabilities by deploying AI, Machine Learning, technology integrations, and end-to-end operating model re-engineering.

Such a career trajectory exposes the reflective practitioner to many insights and practices. I want to share a few and hope you find them applicable to your daily operational realities.

This notebook starts with a common case I've seen across various supply chain sub-functions. Whether it's logistics, production, or procurement, teams constantly rely on spreadsheets and email trails. Those serve as a daily system for managing operational priorities and supply chain exceptions. Some of them do it with remarkable skill.

This happens despite companies spending millions on enterprise and supply chain technology solutions. These investments often come with additional costs: expenditures on consultants and system integrators, and the purchase of middleware to enable interoperability between new and legacy systems.

Those two observations lead to one key insight that I would like to reflect on:

Every supply chain runs on two distinct technology landscapes. The official one records what happened: every transaction, supply chain event, and data point. Alongside this, there's another- a second landscape that enables daily operational decisions. The last one also defines what happens next.

1.1 The two landscapes facing the same reality

The official one first. During site tours triggered by technology initiatives, I always ask for the systems architecture. It's a useful starting point: existing capabilities, blind spots, and readiness to face uncertainties of tomorrow. What I get back is a standard library of acronyms every practitioner recognises: ERP for records and finance; APS for production planning; TMS for logistics and freight; WMS for warehousing. Sometimes, a control tower stitches those systems together.

The systems I list earn their licence fees by programmatically enforcing workflows with structured records, data, and ledgers. I've implemented more than fifteen digital solutions across global operations, and faced every case any business could throw at us during the projects.

In this and the following chapters, you will find no argument against operational technology - it's indispensable. However, for the benefit of the second landscape, I prefer to ground the thesis in the daily realities most supply chain practitioners face.

I'm a big fan of quantum physics, and the concept of superposition there is quite astonishing. Applied to our discipline, this suggests supply chain exists in two parallel states: when the operator is away from the office and when they return. So, it's Tuesday morning, 08:30. A supply chain operator gets a cup of coffee and logs in to the PC workstation in the office. In that superposition, a vessel skipped a port call in Mombasa, a major buyer changed the order value, and a truck carrying high-value products got stuck at the Mexican border. I'm pretty sure that all these scenarios are familiar to the reader.

In most cases, none of these events fit the screen that the sanctioned technology system or solution provides. After all, these incidents weren't supposed to happen.

What happens next? Our operator turns to Excel. They export data from the system and merge it with three other reports. By 10:30, the challenges get compressed into columns and tables. A few cells point to who owns each highlighted action - for example, an alternative supply strategy to deploy or a safety-stock allocation decision to make. It can be anything.

We should pay close attention to those two hours because that's where the friction between an ERP system and an Excel workbook that triggers actions appears. It's kind of a gravity centre, where the enterprise system of record runs separately from the daily system of work. The day continues, issues pile up, and so do the workarounds.

Figure 1.1. visualises the existing differences between the two systems. Side by side.

Both landscapes are real. Each is part of the same physical flow, whether vessels, trucks or cargo in a container. When the project team requests a systems diagram before the initiative starts - it normally receives only one. No surprise that when deploying new technology solutions, the part of operations that's executed daily via the workbook is frequently overlooked. This creates an asymmetry that grows year after year.

Such asymmetry comes at a cost: a. resources flow toward the visible part; b. it gets the upgrades and further improvements it needs. The invisible one gets nothing because no one plans to replace the workbook that supports customers' volume allocations. Basically, you can't budget for what you don't see, and the organisation doesn't understand - when it's in the operator's head.

...you can't budget for what you don't see...

1.2 Size of the second landscape

Let me illustrate with another case. I led a global initiative to review supply chain processes. My team worked hard to identify 250+ workflows across order-to-cash, purchase-to-pay, and goods delivery. It wasn't easy because the team had to dig deep: we zoomed out to understand high-level process types, then zoomed in on the individual transactions our operators performed across twenty-plus countries.

We covered many operational territories in just twenty days (only a few team members were fully dedicated to the task). The landscape we navigated through included contract management, customer service, complaints handling, reconciliations, and many other transactions/activities that had never been formally identified or captured. None of them existed in PowerPoints, but they existed in workbooks, in macros, and/or SharePoint. We even reviewed email rule settings that routed shipping-information updates and vendor report emails into a system. To make things even more complex, our project repository held more than 60 separate Excel reports used by multiple departments.

When I follow any of those artefacts, I always think of archaeologists working at ancient sites somewhere in Peru or Egypt. Here is a spreadsheet that plant operators used to track quality incidents and rejections. The spreadsheet, created in 2016, survived two system upgrades and four team members. Four!

Its users added a new Excel function; later, they added a new pivot table. New joiners implemented additional updates - nobody challenged it. Teams' habits and protocols formed with time. Like paths that appear on a lawn from repeated use.

Here's a kind of provocative statement: Excel represents the most successful shadow IT platform ever shipped by the IT function itself. I use the term deliberately as I don't want to insult my cross-functional colleagues. In cybersecurity, "shadow IT" means unapproved/unauthorised tools on user's PC, and I fully agree those tools deserve scrutiny without compromise. I just want to point out that Excel reveals a deeper and broader issue - unmet demand, not unapproved software. It flourishes within the one tool nobody will ever ban.

Excel represents the most successful shadow IT platform ever shipped by the IT function itself.

Shadow implies an exception and in most supply chain functions I've led, this is the operating model. Most of the sanctioned applications run the deterministic supply chain - the flows that behave as designed. Excel runs the real ones: where the product certificate has just expired on its journey across the ocean in a forty-foot container.

1.3 Why IT cannot close the gap

But we have to resist blaming IT because it's a wrong reflex - IT function isn't the problem. All this is about the pure arithmetic every practitioner faces in leadership roles, including complex trade-offs. And those are often sophisticated ones.

A significant portion of any IT budget goes to maintenance of the visible landscape. It covers licenses, upgrades, ongoing integrations, security measures, and audits. What remains supports change requests that often flood in from every corner of the organisation.

In such an environment, the supply chain team isn't the only stakeholder fighting for IT resources and attention. Finance is busy wrapping up its period close, or the legal team is pushing implementation of the EU AI Act requirements. All demand immediate attention and priority.

Another case from my universe is when a merger comes: each acquisition doubles the systems landscape overnight. In one post-merger integration I've been involved in, we moved from 15 to 27 systems globally. Guess what happens? Such cases reset the IT integration roadmap for years to come. Yes, we're talking years here.

That is why I mentioned at the beginning of this sub-chapter that backlog is arithmetic. Run costs and integrations consume the change budget before a supply chain operator's request reaches the top of any IT requirements list. That's often one reason we turn our attention to a second, invisible part of the landscape.

And that also creates another problem. In my two decades of professional experience, I've never seen a supply chain professional leave the role because the ERP system was perfect. In the majority of situations, people resigned because they constantly had to fight with workarounds triggered by flawed technology deployments.

I've never seen a supply chain professional leave the role because the ERP system was perfect.

1.4 The law the spreadsheet obeys

Supply chain networking events are a useful source of knowledge and experience exchange. When I meet industry peers, they often bring up the point of getting specialists off the Excel needle. In those conversations, I tend to interrupt them mid-question. The reason is that there's a much better way to frame it by looking at the problem from another angle. Ask yourself: Why does the spreadsheet keep outperforming every system any company deploys? I hope you understand the difference.

An answer exists, and it's older than any ERP system. It also challenges a conventional way of thinking, as my question in the previous paragraph did.

In 1956, cybernetician W. Ross Ashby formulated a very interesting concept. I came across it during my PhD studies - the Law of Requisite Variety: only variety can absorb variety1Ashby, W. R. (1956). An introduction to cybernetics. Chapman & Hall. Principia Cybernetica electronic edition. source ↗. A regulator must carry at least as many possible responses as the disturbances its environment produces. Otherwise, guess what, the disturbance wins.

My peers in the community won't be surprised to hear that modern supply chains are machines for absorbing disturbances. Much of that disturbance is non-deterministic, such as port strikes, storms, and container booking rollovers. The variety of issues landing on an operator's desk each morning is wide (and sometimes just wild).

But what to do when the approved system landscape can only accommodate the variety its designers foresaw during the initial planning phase? The spreadsheet becomes justified because it's nothing more than a control response to variety that codified workflows can't handle.

We can certainly try to ban it, but the variety won't disappear - it will just move elsewhere. Into email threads, phone calls, contractors' databases and so on. That's probably why years of Excel elimination programmes achieved nearly nothing. And in such an environment, I doubt we can fully delete the second landscape right now. Most likely, we can only decide whether to keep it invisible.

We can certainly try to ban it, but the variety won't disappear - it will just move elsewhere.

1.5 What and where it is changing

The gap is old. The tools are new.

To summarise: for most of my career, the second landscape had one building material - the spreadsheet. What anyone could build was limited by what an Excel spreadsheet could handle: macros, external links, a SQL query (well, if someone had a licence and courage). The cap was real, and it kept the second landscape small and even fragile.

But over the past five years, that cap has been slowly collapsing at the speed of light. Drag-and-drop application builders (e.g. Canva) and workflow automation platforms (e.g. N8N) moved software-building capabilities down the skill curve. On top of that, AI assistants pushed it far enough that the person who owns/faces a problem can build a working tool in a week or two.

Gartner identified this movement as citizen developers back in 20092Computer Weekly. Gartner urges IT departments to support end-user application development (Ian Finley, Gartner). source ↗,. In my opinion, little has changed since then. The tools and technology are real, while subject-matter experts increasingly build rather than coders. And here is a recent case: Anthropic ran a global hackathon in 2026: more than 20,000 applicants, 500 selected, one week to build with Claude Code. The top three places went to a doctor-turned-engineer in Istanbul, a former technician in the French Alps, and a computer science teacher in Chile3Anthropic (2026). Meet the winners of the Built with Opus 4.7 Claude Code hackathon. source ↗.

It excites me because people who own problems are becoming able to ship tailored solutions. Supply chain and logistics, for example, have the broadest variety gap in any company powered by rooted spreadsheet culture, the most hazardous data, and the most to gain. A citizen developer in marketing builds a campaign tracker, but a potential citizen developer in supply chain is going to touch the physical flow of goods, contracts and customs declarations. The impact is certainly different.

1.6 Potential way forward

Building where problems reside...

Supply chain planners and operators have already created the second landscape I've covered previously. The game rules are changing, so we should start giving them tools and guardrails, not constraints they'll likely ignore. The only question is whether it'll compound or corrode.

But I'd like to clarify one critical point - no corporate citizen developer will rebuild (or should be allowed to) ERP, APS, or a customs filing system. We still need systems (auditable systems of record) designed for deterministic processes and based on configurable, industry-accepted standards. That's their feature and expectation, and I'll defend it.

The territory that we're stepping into is the waystations. I define term "waystation" as a stop between systems where work arrives in one format, is checked by a human hand, and leaves in another with a new name. Waystations are where variety leaks and spreadsheets breed. This territory is much narrower than some low-code platform vendors claim and much larger than corporate systems diagrams admit. I'll try to map it properly in the following chapters.

1.8 Key takeaways

• Every supply chain runs two IT landscapes: sanctioned and unsanctioned. Second is often a real system of work in operations.
• The spreadsheet represents a control response, not a bad habit of a specific individual.
• The IT function struggles to close this gap. The main reason is that it constantly has to manage backlog trade-offs.
• New tools and solutions emerge. We are entering an era where problem owners can ship real, tailored applications.

© Aleks Sidorecs.md