Operational Systems
How organizations turn people, workflows, decisions, data, and technology into actual work.
The system is already there
Every organization runs on an operational system, whether anyone designed it or not. When the arrangement of people, workflows, decisions, data, and technology is accidental, the organization pays for it every day in rework, waiting, escalation, and hidden coordination.
The word system is slightly misleading, because it suggests something assembled on purpose, and in most organizations it accumulated instead, one local decision at a time, the way a kitchen drawer fills up, as people solved the problem in front of them with whatever authority and information they had. Someone added a check after an incident. A step got skipped once it stopped producing anything, and a spreadsheet appeared beside the platform because the platform couldn't hold a field somebody needed. None of those felt like system decisions when they were made, and together they're the system.
So the useful question is whether the operational system an organization has was designed or inherited, and when anyone last stepped back far enough to see it whole, past the set of functions each performing adequately on its own terms.
Five parts, one behavior
Each of the five carries something different: people carry judgment, workflows carry sequence, decisions carry authority, data carries memory, and technology carries leverage. How the organization behaves comes from the way those five are wired together, and the quality of any single one matters less than people tend to expect.
The wiring is the part that goes unexamined, because every one of the five has an owner and the relationships between them don't. A function owns its people, a process owner owns the workflow, governance owns the decision rights, a data team owns the data, and IT owns the technology. Nobody owns the question of whether a decision has the data it needs at the moment the workflow reaches it, and that's where most operational failure actually lives.
The same gap explains a common and expensive pattern, where an organization improves one part in isolation and gets nothing back. Put better people inside a workflow that routes badly and you get the same result, delivered more conscientiously. Better data feeding a decision made three steps too early produces a well-informed guess. And leverage applied to the part that wasn't the constraint just multiplies the part that was already fine.
Design for the actual work
Useful systems design starts from work as performed, the way it actually happens on an ordinary Tuesday. The workaround, the spreadsheet beside the platform, the informal approval, and the missing handoff all belong to the real specification.
The documented version was an accurate description at some point, much like a street map of a town that kept growing after it was printed, and it has since drifted unevenly, with nothing to mark which parts are current and which are archaeology, so treating it as a lie is its own mistake. Reading it tells you what the organization intended, and watching the work tells you what it does. The distance between the two is the brief.
Starting there is slower, and it's the only start that survives contact. A redesign aimed at the documented system can be delivered in full, adopted with enthusiasm, and still change nothing, because the people doing the work will map the new instructions onto whatever they were already doing and keep the parts that were load bearing. What looks like resistance is people protecting repairs that nobody else knows exist.
Where it becomes practical
None of this needs a program. What it needs is one flow of work with a clear beginning and end, followed through a real instance, the actual one with all its quirks, and a written note of where the work waited, who decided, and what a person supplied by hand that the system should have supplied.
What comes back is rarely a technology gap and far more often a seam: a point where responsibility changes hands and the transition belongs to nobody, or a decision sitting at a level that doesn't have the information, or a check that only happens once the work is already done. Those are design problems, they're cheaper to fix than to staff around, and they're invisible in every report drawn along functional lines.
How organizations turn people, workflows, decisions, data, and technology into actual work.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
