Operating processes framework: scope before mapping

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 just outside the boundary somebody drew on the first day. An operating processes framework should begin by testing that boundary.

This page is about that first day.

Three decisions shape whether the rest of the work is useful: where the process starts and stops, which level of the work you are asked to fix, and whether the worker has the authority to change what they find.

What to take away

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 a need 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: set the boundary one step earlier and one step later than feels natural. Look at what appears, 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. That is what work in process means in production and 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.

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

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, because that unit decides whether they are satisfied. Then check whether the items are genuinely comparable.

If one unit covers both a routine case and a case taking days, an average across them has no referent, and you will make decisions from it. An average across unlike cases is the kind of figure that operating processes metrics warn you to ignore.

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. Candidate roles to verify locally include an end-to-end process owner and the managers who control each handoff for flow changes, a worker’s supervisor or functional manager for task changes, and a risk owner or compliance owner for rule changes. A formal policy change may also require approval from a change control board, where the organization has one. Write the actual approver against each segment; titles and authority vary by organization.

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.

For example, in invoice processing, define one invoice as the unit and start when it is received, not when it is entered into a system. Follow it across accounts payable and the approver, ending when it is paid or returned for correction. Treat a delay at the handoff as a flow issue, data-entry difficulty as a task issue, and an approval policy as a rule issue. Check whether the process owner or relevant manager can authorize the handoff change and whether the risk owner can approve a policy change; if not, narrow the scope or involve the sponsor.

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

Before detailed mapping, spend an hour on these six steps:

Steps one to five are usually skipped. Then even the high-level map in step six can be accurate without identifying who has the authority or capacity to act on it.

For a first process description, record four fields: the start trigger, the end condition, the unit of work, and the intended output and recipient. The broader process description is in operating processes. The symptom-first diagnostics in operating processes examples often tell you which level you are at before you start.

Decide early what capacity exists to act on what you find. Investigation is cheap; change is not.

A queue of accepted findings with nobody to implement them hurts morale. The math of who is available belongs to strategic planning, and it applies to improvement work as much as 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 learn most by watching one person work, it is a task question. If you learn most by following one item across people, it is flow.

If you learn most by asking who accepted a risk and why, it is a rule. Start where the answer is clearest. The others usually shrink once you address the first.

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.