An Ode To Excel
Spreadsheets capture how businesses work, one two-dimensional slice at a time. What happens when those slices become a connected operational model?
A good friend of mine swears by spreadsheets and attests that he can build the most complex systems with just Excel. And he’s not alone.
“They run the business on Excel” often comes with an eye roll. Look inside the workbook, though, and you may find a detailed account of how that business works: what it owes, what it can deliver, which commitments depend on which resources, and what should happen when something changes.
Someone close to the work has made those relationships concrete enough to calculate with. They have decided what counts as available stock, how much work fits into a shift, and which costs belong to an order. They can change an assumption and see the consequences.
That deserves some respect.
A business spreadsheet often contains the beginnings of an operational model. People have been building these models for decades.
A model you can change yourself
Excel gives people a short path from understanding a problem to doing something about it. You can name a column, enter what you know, write a formula, and check the result against the work in front of you. Each new situation helps you see which assumptions or rules the spreadsheet still needs to capture.
Consider a simple inventory sheet. A column for quantity on the shelf is useful. Add reservations and expected deliveries, and you can start working out what will be available for an order. Add dates, and you can ask whether it will be available in time.
Each addition expresses another part of the business. The formulas make some of those relationships executable. When an input changes, dependent results can change with it.
What people have built
Planning work across 17 assembly lines
In a 2020 account of his work at an automotive sensor manufacturer, Gabriele Tettamanzi describes a planning problem: material shortages and unexpected production changeovers made delivery commitments difficult to meet.
He built an Excel system that combined demand, sales orders, forecasts, material availability, and scheduling for 17 assembly lines. It exchanged data with the company’s management system, and its schedule fed the material requirements planning process.
The interesting part is the knowledge captured in that arrangement. An order requires materials. Producing it consumes capacity. The sequence of work affects changeovers. Those relationships have to agree before a delivery plan becomes credible.
Tettamanzi also describes an earlier solver-based pilot whose logic his team found difficult to understand. That detail matters: the people responsible for a plan need to be able to understand and work with its assumptions.
Making validation repeatable at Globo
More recently, a 2025 Microsoft customer story about Globo described an employee using Copilot to create VBA routines for validating complex spreadsheets. Microsoft reported a 97% reduction in execution time for that validation process.
The employee’s practical knowledge became a set of checks that software could apply repeatedly.
One two-dimensional slice at a time
A useful spreadsheet is full of decisions about meaning. A row represents an order, a product, a person, or a shift. A column records something you need to know about it. A formula states how one value depends on others.
Then another question comes along. You need orders by delivery date, materials by production run, or capacity by shift. Each table offers a different slice through the operation.
Excel can connect those slices through lookups, linked sheets, external data, and sophisticated models. Calling a spreadsheet two-dimensional describes its familiar surface; it says very little about the complexity of the thinking behind it.
The business has many more relationships than any one table shows. An order belongs to a customer, requires products, consumes inventory, depends on suppliers, and carries a delivery commitment. Time changes the meaning of every one of those connections.
Eventually, the question you need answered crosses several slices at once.
Following a consequence across the business
Imagine a manufacturer learning that a component will arrive two days late. The purchasing sheet can record the new arrival date. The production plan can show which runs need the component. The order book can show the customers waiting for their output.
Now someone needs to connect those facts. Which runs have enough stock to proceed? Which orders will miss their promised dates? Is an alternative part approved for those products?
Production planning
Illustrative workbook=IF(Production!E2>D2,"At risk","On track")| 1 | Order | Production run | Units | Ship by | Outlook |
|---|---|---|---|---|---|
| 2 | |||||
| 4 | |||||
| 5 | |||||
| 6 | |||||
| 7 | |||||
| 8 |
The calculations matter, but so do the definitions. Does “available” inventory include stock already reserved for another order? Does an expected receipt count before it passes inspection? Is a delivery date a customer commitment or an internal target?
An experienced planner may know all of this. Some of it may be encoded in formulas. Some may survive as comments, conventions, or a conversation you need to have with a particular colleague.
As more teams and systems participate, keeping that knowledge consistent takes work. You need to know whether two records refer to the same thing, which source to trust, and when its information was current. A formula can be perfectly correct for the inputs it receives while the decision still rests on an outdated fact or a different definition.
This is the next step for an operational model: make the connections and their meaning explicit enough to follow consequences across them.
Inferal as a hyper-dimensional spreadsheet
Inferal extends this approach into an “always know” system, integrated into the business’s data plane. Source changes flow into the model, which maintains what follows from the available facts. Rules make decisions; integrations enact them by updating records, triggering workflows, or activating agents.
Ontologies make the relevant concepts and relationships explicit. They establish what the records mean and how they fit together, so decisions use the business’s own definitions.
Return to the illustrative component delay. A rule can identify a production run at risk when a required component will be unavailable at its scheduled start. Another can connect that risk to an order’s delivery commitment. A further rule can decide to escalate the affected order under the manufacturer’s policy. Inferal can then create an exception record in a connected system and activate an agent to investigate approved alternatives.
The action remains traceable: this order was escalated because this production run depends on this component, whose expected arrival has changed. Jeremy explores that idea in What Rules Know That Code Forgets.
The model supplies the agent with the relevant facts, relationships, and policy, including the distinctions the planner would otherwise have to explain. As new information arrives, the model reevaluates the consequences and the decisions that depend on it. This is an ongoing part of running the business.
Keep what people know
The person who built the workbook has done something difficult. They have taken a messy part of the business and given it enough structure to work with. Every useful formula records a dependency. Every well-chosen column makes a distinction someone needed.
My friend has also been the one person who could keep a complicated spreadsheet system working in any weather. Great for job security, as he points out. Less reassuring for the company.
The workbook captures part of the model. The person who built it often carries the rest: why a formula works that way, which inputs need checking, and what to do when the usual assumptions break down. That dependence is a form of technical debt. The business relies on knowledge it has never fully made transferable.
Moving to a new structure has to earn that person’s trust. Can it produce the same results? Can it handle the difficult cases they have learned to navigate? Working through those cases together helps make the hidden rules explicit and gives everyone a way to check the new model.
That is a practical test for an operational model: can someone else understand, run, and change it while preserving what the business has learned?
Start with the spreadsheet people rely on. Ask what its rows represent, what its formulas assume, and which decisions still require someone to connect it to another sheet or system. Those questions lead directly toward an operational model.
Excel helped people make the business calculable, one two-dimensional slice at a time. Inferal carries that idea into a connected model that stays current, makes decisions, and puts them into effect.