Name process, system, data and KPI ownership separately
“Owner” is not one concept. Name the process owner, stage owners, decision owners, system owners, data owners and KPI owners separately—so the exception always has a name.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Context
A commercial transformation assigned “the business” as owner of the customer lifecycle and “IT” as owner of the CRM. When a customer was created twice, the sales team, the finance team, the CRM administrators and master data each pointed to another. Every one of them owned something; nobody owned the exception.
02Decision drivers
- D01
Exceptions need a named owner
- D02
Business decisions must not be made by system administrators
- D03
Data quality must be fixed at the source
- D04
KPIs need someone to act, not only someone to compute
03Options considered
One “business owner” per process
Small, single-function processes
Cost: Hides decision, data and system ownership; exceptions bounceA full RACI per activity
Audits
Cost: Unreadable; rarely used to resolve anythingNamed ownership types per process, decision, system, data concept and KPI
Cross-functional processes on shared platforms
Cost: An ownership model to maintain04Decision
For every value stream, name a process owner accountable for the end-to-end outcome; a stage owner per stage; a decision owner per decision (with separate approvers where needed); a system owner per platform, responsible for configuration and releases but not for business rules; a data owner per concept, responsible for quality at the source; and a KPI owner who acts on each measure, separate from the definition owner where that differs. Record them in one ownership model, and route exceptions by type to the named owner.
05Consequences
- Exceptions reach a named person on the first attempt.
- System owners stop deciding business questions by implementing them.
- Data quality has an owner who can fix it.
- The ownership model becomes an artefact that changes with the organization.
06Revisit when
The process lives entirely inside one function and one system.
The organization adopts a product-team model that merges several ownership types by design.
07Where this decision is applied
Cases that take this decision, and why it matters there.
- Operating-model case / 03Moving from CRM tool to commercial operating platformA CRM that exists but does not run the business: management routines moved into it, parallel tools retired, data quality owned, lifecycle definitions governed—and a plan for after go-live.
- Operating-model case / 04Designing customer ownership in a multi-subsidiary organizationOne customer relationship across several legal entities, subsidiaries and sales teams: who owns the relationship, each local transaction and the global account data—and who resolves the conflicts.
- Adoption case / 05Replacing mandatory fields with data people useA CRM full of complete but meaningless data: each field audited for who enters it, who uses it and which decision it feeds—then removed, derived, prefilled, made conditional or kept, with value returned to the person entering it.
- Adoption case / 06Keeping adoption owned after the project team leavesA rollout that ended at go-live: responsibilities handed from project roles to named operating owners, a friction register feeding one governed backlog, a release cadence, and adoption signals reviewed on a schedule—so the design keeps improving.