The Operations Map
First we map your operations. Then we route you to your goal.
Before we build anything, we make your Operations Map. It takes one session, it costs you nothing, and it's yours to keep — whether or not you ever build with us.
Why a map
Your software records what already happened. That's a rear-view mirror.
A report
It tells you last month's numbers, accurately, after the month is over. It cannot tell you whether you're going to hit your target, because it was never told what your target is. Every dashboard you've been sold works this way.
A destination and a route
Maps aren't useful because they draw roads. They're useful because they put a destination and a route on the roads — and a moving dot that says where you are. That dot is computed from your own data, never typed in. The moment someone types in where they think the business is, it's a report again.
This is also something a horizontal product structurally cannot do for you. Zoho doesn't know your destination — it was never built to. That's not a criticism of Zoho; it's the difference between buying a product and getting a system.
The test that makes it real
Goal → measure → event → record.
Every goal has to trace all the way down to something your system actually records. Follow the chain. If a link is missing, the goal isn't behind schedule — it's unreachable, and no dashboard will ever tell you that.
quantified, dated
revenue − true job cost
who records it, and when
where it lives, forever
Most of the time, we find a broken link. That's the point.
A margin target where nothing records what a job actually costs. A delivery promise where nothing records when the vehicle left. The map finds the missing road before anyone spends a rupee building software on top of it — and the first thing worth building is almost never the dashboard. It's the event nobody is capturing.
See that happen in a worked example →What we map
Eight things. Nothing about software.
None of this is a technology conversation. It's a conversation about your business that happens to produce something a machine can build from.
Who acts
Every role that touches the business, and exactly what each one is allowed to start, enter, approve or only look at. This is also what your access rules get generated from — so what we wrote down and what the software enforces can never drift apart.
What happens
The spine of the whole map. Each event names who did it, what had to be true first, what it writes down, and whether money moved. Everything else hangs off this list.
The sequences
Events in order — the happy path, plus the exceptions you actually hit. The rush job. The short delivery. The customer who pays in parts.
What's kept
Three kinds, and confusing them is why most systems rot: things that exist (staff, items, customers), things that happened (append-only, never edited), and things you look at — always computed, never typed in.
What's automatic
“When this happens, that must follow.” Order confirmed, so the job card opens. Invoice issued, so the advance is captured. Today these live only in someone's head or buried in code — invisible to you.
What you watch
KPIs belong to a workflow, never to a person — hang a number on a department and it will optimise its own number at the expense of the job. And no measure survives without an event that generates it.
What connects
Tally, your bank, WhatsApp, the marketplace — classified by direction, and each one carrying a written fallback for the day it isn't there. Nothing gets specified without answering that.
Where you're going
The seven above describe how a business runs. Without a destination that's an atlas, not navigation. Quantified, dated, and traceable all the way down to events your system actually records.
One map, three views
The owner and the operator need different things.
The classic failure is forcing one diagram to serve everybody. Same map, three zoom levels.
One screen
Your goal, where you actually are today, what's blocking you, and whether you'll make it. The only view that answers “are we going to hit it?”
Turn by turn
Not a map at all — one instruction. “Your next action, right now.” It's why your crew needs almost no training on what we build.
The full territory
All eight blocks, machine-readable. It generates your access rules, your staff guide and your dashboard tiles. Ours to maintain, not yours to read.
What the method is built on
We didn't invent this. We combined two bodies of work.
One gets your operations out of your head. The other decides what shape they have to be in to be navigable at all.
Alberto Brandolini — Introducing EventStorming
The practical method for extracting how a business really runs, from the people who run it, on a wall, in hours rather than months. Your mapping session is an EventStorm — which is why it takes an afternoon and not a six-week study.
William McCarthy (1982) — The REA Accounting Model
Resources, Events, Agents: every business fact is an economic event affecting a resource, involving people, and every give has a matching take. It is the ontology underneath ERP itself — standardised as ISO 15944-4.
Also drawn on: Evans and Vernon on domain-driven design (a shared vocabulary between you and us), Fowler on event sourcing (why your position is computed rather than stored), and Goldratt's The Goal (measure throughput, not local efficiency — the reason we don't hang a KPI on every department).
Tell us how your business runs. We’ll show you the system.
Start with a prototype of your actual system — see it, steer it, and know exactly what you’re getting before a line is built.