Reconciling Many Business Units Into One Process Model

Ask several business units how they do the “same” thing and you get several different answers: different steps, different names, different definitions of the same words. Getting them onto one process model is one of the most foundational things a transformation does, and it is a negotiation disguised as a diagramming exercise.

In any enterprise made of multiple business units, the same activity: selling, quoting, onboarding a customer, fulfilling an order, has usually evolved into several different processes, one per unit, each convinced it is the process. The steps differ. The stage names differ. And, most treacherously, the same words mean different things: one unit’s “customer” is the parent company, another’s is the individual site, a third’s is the person who signs; one unit calls a deal “won” at a point another would call it merely “committed.” There is no single model of how the enterprise actually works, and that absence quietly blocks everything that has to be shared.

Reconciling those units into one process model is unglamorous, slow, and easy to underestimate. It is also load-bearing, because almost everything else a transformation wants to do rests on it. And the reason it is hard is not the drawing. It is that a process model is a record of agreement, and the units have not agreed.

Why one model matters

A single, shared process model is the backbone that other work hangs off. You cannot build shared systems for a process the units define differently: the system would have to be all of the processes at once. You cannot coordinate across units without a common map of how the work flows between them. You cannot compare performance, or spot where a step is redundant, or trace a requirement to the process it serves, without one model to trace against. Standardization is meaningless until there is a standard to converge on, and the process model is that standard. Skip it, and every unit’s transformation proceeds on its own private map, and nothing composes.

The real difficulty: reconciliation is agreement, not drawing

The instinct is to treat this as a modeling task: interview each unit, draw each process, merge the diagrams. The drawing is the easy tenth of it. The hard nine-tenths is that the units genuinely disagree about what the process is, and often about what the words in it mean, and a merged diagram that papers over that disagreement is a diagram no one follows.

Two kinds of disagreement surface, and both have to be handled. The first is process disagreement: the units really do perform the work differently, sometimes for good reasons and sometimes out of habit nobody has questioned in years. The second, quieter and more corrosive, is definitional: the units use the same terms for different things. Until “customer,” “opportunity,” and “done” mean one agreed thing, or are at least explicitly mapped between units, any process model built on top of them is describing different processes in the same boxes. Reconciling the vocabulary is often the precondition for reconciling the process at all, which is why this work sits so close to the shared-data-contract problem: it is the same “what is a customer?” argument, fought at the level of process instead of data.

Leveling is the trick that makes it possible

The technique that turns an impossible reconciliation into a tractable one is leveling: modeling the process at successive levels of detail, from the high-level flow down through progressively finer steps.

The reason leveling matters is a pattern that holds almost everywhere: at the top level, the units usually agree, and the disagreement lives lower down. Zoom out far enough and most units really do share the same high-level flow: a need is identified, qualified, turned into a proposal, won, delivered. The divergence, the part each unit is convinced is essential and unique, almost always lives in the how, several levels down. So you reconcile at the level where agreement genuinely exists, and you let variation live at the level where it legitimately differs. Leveling lets you produce a real, shared standard without forcing everyone to pretend their real differences don’t exist, which is the move that makes the whole negotiation winnable. Agree at the top; vary, explicitly, at the bottom.

The reconciled standard flow

What comes out the other side is not one identical process imposed on everyone. It is a reconciled standard flow: a single agreed model at the levels that must be common, with the points where units legitimately differ marked as explicit, documented variants rather than erased. Everyone can see the shared spine, and everyone can see exactly where and why their unit diverges from it, which is far more honest, and far more usable, than a lowest-common-denominator diagram that matches no one.

Two things make that model operational. A responsibility assignment, a RACI or its equivalent, attached to each step, naming who is responsible and who is accountable, because a process with no owners is a picture, not a way of working; and the act of assigning it productively surfaces the ownership disputes that were hiding under the vagueness. And a terminology map, reconciling the vocabulary so that a term in the model means one thing, with each unit’s local usage mapped to it. Together the leveled flow, the variation points, the RACI, and the terminology map are the difference between a diagram and an agreement the enterprise can actually run on.

The method

The sequence that keeps this from collapsing is roughly this. Map each unit’s process at a consistent level of detail, inconsistent granularity is why merges fail, because you end up comparing one unit’s overview to another’s fine print. Find the common high-level base line, the flow the units actually share once you zoom out. Reconcile the vocabulary in parallel, because you cannot align steps whose words mean different things. Agree the standard flow at the levels where commonality is genuinely required, and document the legitimate variation below that as named variants rather than arguing it away. Attach responsibility to each step. Then validate the model with each unit and confirm they recognize themselves in it, the reconciled model is only real if every unit can find its own work in it, either in the shared spine or in an honestly documented variation.

The traps

Reconciliation fails in a few predictable ways, and each is a failure of judgment about where commonality should stop.

False uniformity is forcing every unit into one identical flow and erasing real differences. It produces a tidy diagram that no unit actually follows, because the differences it erased were load-bearing. False diversity is the opposite, treating every habitual difference as sacred and essential, so nothing ever gets standardized and the “model” is just several models in a shared folder. The entire skill is telling these apart: which variation is a genuine, justified difference in how a unit must operate, and which is merely divergence-by-habit that no longer has a reason. Over-granularity is modeling everything down to the finest level everywhere, which drowns the reconciliation in detail nobody needs and no one will maintain. And documentation theater is producing a beautiful, exhaustive model that was never actually agreed, it looks authoritative and changes nothing, because agreement, not artwork, was always the point.

Why it is political

It is worth being honest that this is political work, because standardizing a process asks units to give up their own way of doing things, and “one process model” is easily heard as “your process loses.” Each unit will defend its variation as essential; some of those defenses are right and most are habit, and telling which is which is the judgment the whole exercise turns on. The framing that survives contact with real units is the one leveling makes possible: this is a shared spine plus your genuine, honored differences, not the erasure of how you work, but agreement on the parts that have to be common so that the enterprise can build, coordinate, and compare. Units will give up divergence they cannot justify far more readily when the variation they can justify is visibly protected.

The real point

Reconciling business units into one process model is not a diagramming exercise, and treating it as one is why it so often produces a diagram nobody uses. It is a negotiation about what the enterprise agrees to do the same way and what it legitimately does differently, and the model is simply the record of that agreement, leveled so the agreement is reachable. Get it, and you have the backbone that shared systems, traceable requirements, value-stream maps, and cross-unit coordination all hang off. Skip it, and every unit keeps its own map, every system has to be all of the processes at once, and the transformation quietly discovers that it never had a shared thing to transform. The drawing was never the work. The agreement was, and leveling is how you make an agreement the units can actually sign.