Lesson 6 of 6
Working with the process owner
10 min
The relationship between a key user and their process owner decides how fast a project can move. Key users see the detail; process owners have the authority. When decisions flow quickly between them, workshops close, gaps get resolved and sign-off is credible. When they do not, the project waits or, worse, makes decisions nobody owns.
Which decisions belong to the process owner
| Decision | Owner | Key user's part |
|---|---|---|
| Adopt a standard process that changes how people work | Process owner | Explain the change and its impact on the team |
| Accept or reject a gap and its cost | Process owner (with design authority) | Describe need, impact, priority |
| Set approval thresholds, tolerances, credit policy | Process owner | Provide data on volumes and exceptions |
| Accept a known defect or workaround for go-live | Process owner | State the defect, workaround and risk precisely |
| Sign off UAT and readiness for the process | Process owner | Provide the evidence-backed status |
| Choose field labels, layouts and personal settings | Key user (within design) | Decide and record |
- Does the decision change what the business does, what it risks or what it spends?Yes → process owner · No → continue
- Does it affect another process or another department?Yes → process owners of both, through the design authority · No → continue
- Is it within the agreed design and only affects how the team uses the system?Yes → key user decides and records it · No → process owner
An escalation template
Process owners are busy. A good escalation lets them decide in five minutes. Contoso uses a one-page template; Maria sends it by email and records it in the backlog tool so the decision is traceable.
Making it work day to day
Agree a regular slot with the process owner, for example 30 minutes weekly during Explore and Realize, so decisions do not wait for chance meetings. Bring decisions, not status: the status is in the plan. Record each decision where the project can find it, with the date and the person who made it. When a decision changes, record the change too. Months later, during testing or after go-live, "who decided this and why?" is one of the most frequent questions on any SAP project, and the record answers it. Good records also protect the process owner: when auditors ask why a tolerance or approval threshold was set at a particular value, the decision log shows the reasoning and the date, rather than relying on memory.
What would you do?
In a Realize sprint review, the consultant tells Maria that the standard invoice cannot show the fleet contract ID without the custom field already agreed, but adding a second custom field for the fleet depot code would take two days. The depot code was never in the requirements. Customers have started asking for it. What should Maria do?
- Decisions that change what the business does, risks or spends belong to the process owner.
- Cross-process decisions go through the design authority with both owners.
- Escalate with one page: decision needed, context, options, recommendation, consequence of no decision.
- Hold a regular decision slot and record every decision with date and owner.
Check your understanding · not graded
Lesson check
1. Who decides whether to accept a known defect with a workaround for go-live?
2. What should the first line of an escalation contain?
3. A process owner agrees to a change in a corridor. What should the key user do?
4. Which decision can a key user usually take alone?