Digital Transformation Without an Operating Model
An operating model has six moving parts and a transformation programme typically moves one of them. Technology changes while structure, process, data, people, and governance hold their previous shape. The result is a business that looks modernized in procurement records and behaves exactly as it did before.
Six components move together or the change does not hold
Structure determines who reports where and which functions own which outcomes. Process determines the sequence in which work travels. Technology determines what the available tools permit anyone to do.
Data determines what anybody can actually see. People determines which skills exist in the building. Governance determines how decisions get made and how quickly they arrive.
Each of the six constrains the others. A tool permitting a faster sequence delivers nothing where the governance still requires the old approvals. A redesigned process delivers nothing where the data to run it does not exist in usable form.
Programmes fail on this arithmetic rather than on execution quality. Moving one component against five that hold means the five win, because five constraints beat one capability every time.
The system will encode the organization that built it
Conway observed that systems come to mirror the communication structure of the organizations designing them. Teams that do not talk to each other produce components that do not talk to each other.
The observation is uncomfortably reliable in enterprise software. Where finance, operations, and sales each configure their own area with limited contact, the resulting system has three areas that hand off badly. The handoff problem was organizational before it was technical, and the configuration made it permanent.
Fix the communication structure before configuration begins, or accept that the structure is about to be cast into software. Buying a tool does not escape an organizational shape. It records it.
Digitizing a form does not redesign the work
Replacing paper with a screen removes filing and retains everything else. The same fields get completed by the same person, routed to the same approver, for the same reasons nobody has examined.
That substitution is worth doing and should not be described as transformation. It is a media change, and its benefits are real but bounded by the design of the underlying activity.
Redesign asks a different question. Which of these fields does anybody use, which approvals change any outcome, and what would this activity look like if it were designed now rather than inherited. Very few programmes ask it, because asking it reopens decisions people would rather leave settled.
The data model is the constraint nobody budgets for
Every capability a new system promises depends on data arriving in a consistent shape. Reporting, automation, and forecasting all collapse where that shape is inconsistent, and it usually is.
The work of defining entities, agreeing definitions, and cleaning historical records is unglamorous, expensive, and consistently omitted from the business case. It is then discovered mid-programme, at which point it gets compressed rather than resourced.
Budget it explicitly at the start. A programme treating data preparation as a task rather than as a workstream will spend the difference later. It will spend it under time pressure and at a considerably worse rate.
The same customer exists several times under several spellings
Master data problems sound technical and behave commercially. One customer entered five ways produces five partial views, none of which describes the relationship accurately.
Every downstream number inherits that fragmentation. Revenue by account, service performance, and credit exposure all become approximations, and the people using them learn to distrust the reports and reconcile privately in spreadsheets.
Declare a single system of record for each entity and enforce it. That declaration is a governance decision rather than a technical one, and it is the precondition for any claim about a single source of truth being true.
Integration debt grows faster than the system count
Each additional application connected point to point adds more than one obligation. Every new connection must be built, monitored, and updated whenever either end changes.
The maintenance load therefore grows faster than the portfolio does. Organizations reach a point where a substantial share of technical capacity is consumed keeping existing connections functional, which leaves very little for anything new.
Decide the integration approach before the third system arrives rather than after the tenth. The choice is cheap early and expensive to retrofit, and almost nobody makes it at the point where it is cheap.
The seams reveal themselves in the reporting layer
A useful diagnostic requires no assessment methodology at all. Find the reports that need manual work before anyone trusts them.
Every one of those reports marks a seam in the operating model. Somebody is reconciling two systems that disagree, or filling a gap where no system holds the field, or correcting a classification that arrives wrong.
The manual step is not the problem and removing it will not help. It is a symptom describing precisely where the model has a discontinuity, which makes the reconciliation list the best available map of what actually needs fixing.
Nobody owns the flow, only the segments
Systems are owned by function and work travels across functions. Each owner is accountable for their segment and nobody is accountable for the journey a customer order actually takes.
Delay accumulates at the boundaries as a consequence. Each handoff waits for the receiving function's own priorities, and no individual owner has visibility of the total elapsed time or authority to compress it.
Name an owner for the end to end flow with authority across the segments. That role is uncomfortable to create because it cuts across the existing structure, which is exactly the property that makes it effective.
Change saturation limits what can land at once
Organizations have a finite capacity to absorb concurrent change, and it is lower than programme plans assume. Beyond that limit additional initiatives do not proceed more slowly. They stop while continuing to consume attention.
Count what is already in flight before scheduling anything. Most mid-market businesses discover several simultaneous changes competing for the same operational managers, none of which appeared on the same list before somebody assembled it.
Sequencing against that capacity is what allows a programme to finish. Continuity of delivery matters more than the ambition of the plan, because a half installed system is worse than either the old one or the new one.
Naming the models that make this legible
The operating model framework itself does most of the work, by forcing a programme to state what happens to all six components rather than to technology alone.
A capability map contributes the honest inventory. Listing what the business must be able to do, then marking which capabilities are supported, partially supported, or performed heroically by individuals, produces a picture no system diagram contains.
Conway's observation supplies the constraint that the other two miss. Any target design that requires two groups to collaborate closely will produce a system reflecting how closely those groups actually collaborate today.
Adoption is a measurement problem before it is a training problem
Programmes report adoption as logins, completed training modules, and records created. Each of those can be high while the intended change has not occurred anywhere.
The measure worth building is behavioural rather than technical. Whether the decision the system was bought to accelerate is actually arriving faster, and whether the reconciliation somebody used to perform has stopped being necessary.
Consistency in tracking those two questions across the programme reveals problems while they are still cheap. Composure at the point where the numbers disappoint is what separates a correction from a relaunch, and relaunches are how programmes consume two budgets to deliver one outcome.
Conditional rules for the programme
Where the target design depends on data that does not currently exist in consistent form, treat data as the first phase rather than as preparation. Everything downstream inherits its quality.
Where a process is being moved onto a new system without examination, expect the same performance at a higher licence cost. The system is not the variable in that arrangement.
Where several functions are configuring their own areas independently, insert a shared design review before build. The seams created at this stage are the ones that persist for a decade.
Where the organization already has more change in flight than it can absorb, sequencing beats scoping. Adding this programme to a saturated portfolio delays everything including this programme.
Strategic fit decides what should change first
Transformation budgets get allocated to the areas with the loudest complaints, which correlates poorly with where capability actually matters. A distribution business and a professional services business need entirely different things from the same software category.
Strategic fit is the allocation rule. Capabilities close to what the business competes on deserve designed solutions and internal ownership. Capabilities that are necessary and undifferentiated deserve the standard configuration and no further attention.
Operational excellence here is the discipline to underinvest deliberately in the second category. Stakeholder value suffers most where scarce design capacity is spent perfecting something no customer will ever notice.
Structure is what makes the change survivable for people
Every component of the operating model except technology is experienced by staff as their working conditions. Moving technology alone means asking people to deliver a new outcome using the same structure, the same approvals, and the same unreliable data.
That request is answerable through extra effort for a short period, which is why early programme reports look encouraging. The effort is not sustainable, and human capital erodes through exactly the group that carried the programme furthest.
Servant leadership expressed here means moving the other five components so the effort is not required. Trust in the next change depends entirely on whether this one arrived with the structure it needed, and teams keep an accurate record of that.
Watch the full explainer
Related
Further material on management consulting and operational structure from World Consulting Group: [www.worldconsultinggroup.com](https://www.worldconsultinggroup.com)