Horn Software ArchitectsHorn Software Architects

Diagnosis

How to Audit Your Own Operation for a Single Constraint

A rough version of the method, in case you want to try it before calling anyone.

Step 1: find the one thing that's actually measured

Every operation has something that gets tracked reliably — a weight, a count, a timestamp, an amount. Start there, not with the things people assume are being tracked but nobody has actually checked recently.

Step 2: trace what depends on it

Follow that measured fact forward through the operation. What gets calculated from it? What decision gets made once it's known? Where does a person have to manually intervene before it can move to the next step?

Step 3: find the worst ratio in the chain

Somewhere in that chain, one step will take disproportionately longer, or fail disproportionately more often, relative to what it actually accomplishes. That's usually the real constraint — and it's often not the step people complain about most, since the loudest complaint tends to go to whichever step a person is stuck babysitting, not necessarily the one actually limiting throughput.

This is a simplified, self-service version of the same reasoning a Constraint Discovery Engagement runs more rigorously and from direct observation rather than self-report — useful as a first pass, not a replacement for actually watching the process.

Have a specific operation in mind?

This is general analysis. Confirming what's actually true for your business is what a Discovery Engagement is for.