Industry
Part of Operating processes: a clear guide with practical examples
Operating processes framework explained with examples
Operating processes scoped before they are mapped: where the clock starts, which level the problem sits at, four boundary errors, and the authority test.
Most process work fails at the edges rather than in the middle. The steps get described accurately, the diagram is correct, and the improvement changes nothing, because the problem was sitting just outside the boundary somebody drew on the first day.
This page is about that first day. Three decisions determine whether the rest of the work is useful: where the process starts and stops, which level of the work you are actually being asked to fix, and whether the person doing the work has the authority to change what they find.
What to take away
- Draw the boundary around the delay, not around the department. A process scoped to one team will show that team performing well while the customer waits.
- Decide which level you are working at: the flow between people, the task inside one person, or the rule constraining both. Fixes at the wrong level are wasted.
- Never scope a process wider than the sponsor can change. Beyond that line you are producing recommendations, and recommendations are not improvements.
Where the clock starts
The single most consequential choice is when you decide the process has begun. Scope is the first move in business process mapping for the same reason: it determines what the rest of the exercise is able to see.
Ask when the person who cares started waiting. That is almost never when the work formally entered your system. It is when they sent the first message, filled in the form, or realized they needed something and started looking for how to ask. Everything between that moment and the official start is invisible in your records, is often the largest part of the elapsed time, and belongs to nobody.
The same applies at the other end. A process that ends at "sent for approval" hides whatever happens next. A process that ends at "issued" hides the ones that come back.
A practical rule: put the boundary one step earlier and one step later than feels natural, look at what appears, and then decide whether to pull it back in. What appears is usually a queue nobody had named. Work sitting between steps is stock rather than progress, which is what work in process means in a production setting and means here too.
Which level is the problem at
Three different things get called process work, and they need different people, different evidence and different fixes.
| Level | What it is | Symptom that points here | Who can change it |
|---|---|---|---|
| Flow | How work moves between people and teams | Waiting, rework at handoffs, nobody owns the gap | Whoever spans both sides |
| Task | How one person does one piece of work | Variation between people, long training, error clusters | The person and their manager |
| Rule | A constraint on outcomes, such as an approval or a limit | Frequent exceptions, quiet workarounds, arguments about authority | Whoever accepted the risk |
The common error is treating a flow problem as a task problem, because tasks are easier to examine and the people are easier to reach. You end up training individuals to be faster at a step that spends most of its life waiting.
The second error is treating a rule as flow inefficiency and streamlining it away. Rules cost time deliberately. If you remove one without the person who owns the risk agreeing, you have not improved a process, you have transferred an exposure to someone who does not know they now hold it.
Sort the problem before you gather any evidence. Ten minutes here saves a week of the wrong investigation.
Four boundary errors and what they cost
Drawn on the organization chart. The most common. Each team's segment looks healthy, all the delay lives in the joins, and the joins are outside every boundary. If the complaint is about total elapsed time, the boundary has to cross at least one team edge or you will not find the problem.
Drawn too narrowly to contain the cause. You can only fix what is inside the boundary. Scoping to the three steps you control means the answer will be to optimize those three steps, whatever the actual cause was.
Drawn too widely to be changed. An end-to-end scope covering four departments and two systems produces a map, a steering group and no changes. Big enough to include the problem, small enough that one person can authorize the fix, is the target.
Drawn around a system. "The invoicing process" defined as what happens inside the invoicing software excludes everything people do before and after to make the software workable, which is where the effort actually goes. Follow the work, not the application.
The unit of work
Decide what one item is, and be explicit about it, because every measure and every improvement claim depends on it.
The candidates are usually a request, a batch, a customer, or a period. They give different answers. A process that looks efficient per batch may be terrible per request, because requests wait for the batch to fill. A process that looks fine per customer may be hiding that a few customers generate most of the items.
Two checks. Pick the unit the person waiting experiences, since that is the one that determines whether they are satisfied. And check whether items are genuinely comparable. If a single unit covers both a routine case and one that takes days, an average across them is a number with no referent, and you will make decisions from it.
Where items vary that much, split them into two processes with the same boundary and compare them separately. Most operations turn out to have two or three genuinely different classes of work wearing one name, and separating them is often the whole improvement.
The authority test
Before starting, name the person who can approve a change to each part of what you have scoped. Write it against each segment.
Where a segment has no such person available to you, you have a choice: shrink the boundary, or get the sponsor. Proceeding anyway produces a document that says another team should do something differently, which is the standard output of process projects and changes nothing.
This is also the test that keeps scope honest. A boundary that requires four sponsors will get none of them reliably. One that requires one is a project that can finish.
Where the change does need to cross a team edge, treat the agreement as the actual work and the analysis as the easy part. What people are told, when, and what they are asked to give up is covered in change management, and the negotiation itself is a team management problem rather than an analytical one.
Putting it together
An hour, before any mapping:
- Write the complaint in one sentence, in the words of whoever is complaining.
- Mark when they started waiting and when they stopped. That is the boundary.
- Sort the problem into flow, task or rule.
- Name the unit of work, and check whether it contains two different classes of case.
- Name who can authorize a change to each part inside the boundary. Adjust the boundary until that list is short.
- Only now go and look at the work.
Steps one to five are usually skipped, and skipping them is why step six produces a large amount of accurate description that nobody acts on. The four fields that describe a process once you have scoped it are set out in operating processes, and the symptom-first diagnostics in operating processes examples will often tell you which level you are at before you start.
One more thing worth deciding early: what capacity exists to act on whatever you find. Investigation is cheap and change is not, and a queue of accepted findings with nobody to implement them is its own morale problem. The arithmetic of who is actually available belongs to strategic planning, and it applies to improvement work as much as to anything else.
Common questions
Should the boundary match how we report internally?
Only by coincidence. Reporting boundaries follow accountability, and delay follows the work. If they happen to agree, you are fortunate. When they do not, use the work boundary for the investigation and translate at the end for the audience that needs the reporting view.
How do I decide the level when the problem seems to be all three?
Look at where the evidence would come from. If you would learn most by watching one person work, it is a task question. If you would learn most by following one item across people, it is flow. If you would learn most by asking who accepted a risk and why, it is a rule. Whichever answer is clearest is where to start, and the others usually shrink once the first is addressed.
What if the sponsor wants the wide boundary?
Agree the wide boundary for the description and a narrow one for the change, and say so explicitly at the start. Mapping widely is cheap. Committing to change widely is what fails, and the failure is usually attributed to the people rather than to the scope they were given.
