Governing operating-model change after go-live
A fictional operating-model case: the transformation ended at go-live; the organization kept changing and the model did not.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Every change is classified by operating-model domain, decided by its owner within a time limit, released as a versioned change, and reviewed for effect; exceptions feed the next review.
Two years after go-live, changes arrive as tickets to the platform team; nobody decides whether they change the operating model—so the configuration drifts.
Who may change which part of the operating model, with which evidence, and how is each change released?
Run the operating model as a product with a versioned design, a change-authority matrix per domain, and a quarterly review that uses exceptions and variation as evidence.
The commercial platform went live and the project team moved on. Since then, requests arrive as tickets: a new field, a new approval, a new report, a local rule. The platform team implements what is asked. Stage definitions have drifted, three approvals overlap and nobody can say what the current operating model is.
02The reality · current state
How the organization operates today.
- Every change is a ticket; nobody asks which layer it changes
- The platform team decides business questions by implementing them
- Stage definitions have drifted from the original design
- Overlapping approvals were added one request at a time
- No version of the operating model is documented
- Exceptions are resolved but never change anything
03Operating model
The design, layer by layer.
- 03Process
Stage definitions versioned with the model
- 04Ownership
A decision owner per domain—process, system, data, KPI, variation—named before any request arrives
- 05Systems
The platform implements approved changes; it does not decide them
- 06Data
A new field needs a data owner and the decision that will use it
- 08Governance
Change authority per domain; time limits; a quarterly model review
- 09Measurement
Each change carries the KPI it should move—and is reviewed against it
04Key dimension · Change authority & versioned evolution
A change lifecycle, and who may approve which change
Every request follows one lifecycle. What differs is who decides, which evidence is required and how long it may take.
- 01RequestAnyone, with a business owner
States the problem, not the solution
- 02ClassifyOperating-model office
Which domain: process, system, data, KPI, variation, exception
- 03DecideThe domain’s decision owner
With the required evidence, within the time limit
- 04ImplementPlatform, process or data team
In a versioned release
- 05ReviewDecision owner
Did the KPI it named move?
| Change | Authority | Evidence | Lead time |
|---|---|---|---|
| New field | Data owner for the concept | Which decision will use it | Per release |
| New or changed approval | Decision owner (with finance above policy) | Risk being controlled; overlap check | Next quarterly review |
| Stage definition | Global process owner | Ageing and conversion data | Next quarterly review |
| Local rule | Global governance | Variation register entry | 4 weeks |
| New report | KPI definition owner | Metric contract and forum | Next monthly forum |
The first question for every ticket is “which layer does this change?”. Most drift came from changes nobody classified.
05Decision rights
Who decides what, with which evidence, within what time.
| Decision | Decides | Approves | Consulted | Evidence | Within |
|---|---|---|---|---|---|
| Classify a change request | Operating-model office | — | Requester | The request’s problem statement | 5 working days |
| Release a new model version | Global governance | — | Domain owners | Approved changes and their impact | Quarterly |
| Roll back a change | Domain decision owner | — | Platform owner | KPI moved the wrong way | Next release |
06Governance
The forums that run and change the model.
| Forum | Decides | Evidence |
|---|---|---|
| Operating-model reviewQuarterly | Model version, core changes, variations to renew or retire | Exception patterns, variation register, change effects |
| Change triageWeekly | Classification and routing to owners | New requests |
07The trade-offs
Credible options, judged against these premises.
Platform team implements requests as they come
Very small organizations
Cost: Configuration drifts; business decisions made by adminsFreeze the model after go-live
Stable markets
Cost: Workarounds grow outside the systemVersioned model with change authority per domain
Organizations that keep changing
Cost: An operating-model office and a review cadence08The second layer
Questions that change the design.
Authority
- Who may change a stage, a rule, a field or a KPI?
- What evidence does each change need?
- Who can say no?
Release
- How is the model versioned?
- How are subsidiaries told what changed?
- How is a change rolled back?
Learning
- Which exceptions changed the model last quarter?
- Which changes moved their KPI?
- When is a variation retired?
09Decisions & outputs
What the work produces.
- 01Change-authority matrix
- 02Change lifecycle
- 03Model versioning
- 04Quarterly review agenda
- 05Exception-to-change loop
- 06Change effect review