The Box and the Wiring
Operations and operational systems work sound like the same job from a distance. Up close, they answer different questions. One keeps a given arrangement running well. The other decides whether the arrangement is the right one.
What operations optimizes
Traditional operations management takes the arrangement as fixed and optimizes what moves through it: hitting throughput targets, covering shifts, holding service levels, catching an exception before it turns into an incident, and doing that well is a real skill. On most days it's the right one, too, because the trouble in front of a person is the work itself, and the arrangement around it is doing fine.
Nothing in what follows argues otherwise. On most days, for most teams, good execution inside a flawed arrangement still beats poor execution inside a well-designed one. I don't think of the two disciplines as ranked at all, they're answering the same question at a different scope.
Two views of the same floor
Operating the box means managing what goes in and what comes out without ever having to touch how the inside is wired. The people, the workflow, the decision rights, the data and the technology all stay exactly as they were handed down, and the job is to get more through the box, faster and with fewer errors, using the arrangement that's already there.
Opening the box means picking up those same five parts and making them the subject of the work, where before they were the fixed container around it. The demand coming in and the output going out don't have to change for this to matter. What changes is the question, which moves from how to push more through to whether this is the arrangement that ought to exist at all.
What breaks the boundary
Some problems won't move no matter how well the box is run. You watch the same escalation come back every quarter under a different name, or a metric improve in one function while it gets quietly worse in the one next door, and a fix that worked cleanly in the pilot evaporates within a month of full rollout. None of this means the people running the box did their jobs badly. More often they did exactly the job the design asked of them, and the design is where the loss comes from.
What you're looking at are wiring failures: a decision sitting at a level that doesn't have the information it needs, a handoff nobody owns, a check bolted on after the work when it belongs inside it. Fixing them means changing the arrangement, which is a different kind of intervention from running it well, and it usually crosses functional lines that no single operations role has the standing to cross on its own.
A quick way to tell which one you have
Three questions will separate a wiring problem from an operations problem, and you don't need a diagnostic engagement to answer any of them honestly.
A yes to any of the three means running the box harder won't fix it, because the box was never what was broken. Three noes and the arrangement is very likely fine, and what it needs is better execution, which is a real job and every bit as large.
One assumes the other
Operational systems work sits on top of operations management and assumes it as a baseline. A system that's been redesigned well still has to be run well every day, by people who are good at exactly the discipline this essay started with. Where the two roles differ is in where they're willing to look. One holds the arrangement steady and makes it perform, and the other asks, on a schedule or when the numbers force the question, whether it's still the right arrangement to be holding steady.
Organizations that only ever ask the first question get very good at running an arrangement nobody has looked at again in years, and they rarely notice, because every function inside it is reporting exactly the success it was built to report.
If the same problem keeps coming back under a different name no matter how well your team executes, that's a wiring question, and it can be diagnosed.
How engagements begin
