Stakeholder Operating Model
1. What Is a Stakeholder Operating Model?
A Stakeholder Operating Model defines exactly who does what, when, with which approval, within which SLA, and what action is required after a system notification.
It bridges the gap between a process flowchart (what happens) and day-to-day operational reality (who actually does it, by when, and what triggers action).
Core Question: For every step in a business process — who is responsible, who must approve, how long do they have, what does the system tell them, and what must they do next?
2. Why It Matters
Most process documentation describes what happens in a cycle. A Stakeholder Operating Model answers the harder questions:
| Without SOM | With SOM |
|---|---|
| "Credit check happens" | Finance / Credit Controller reviews within 1 business day |
| "Delivery is created" | Customer Service creates outbound delivery upon notification |
| "Invoice is sent" | Billing Accountant creates invoice the same day as PGI |
| Escalation undefined | If no action in SLA window, supervisor is notified automatically |
3. Core Elements of the Model
Each step in a business process should be documented with these six elements:
3.1 Responsible Role
The specific job title or team that must perform the action. Never a department alone — always a named role.
3.2 Approval Required
Whether the step requires another party's explicit approval before proceeding. If yes, document who approves, in what sequence, and what rejection means.
3.3 SLA / Timeline
The maximum time allowed to complete the step after it is triggered. Can be:
- Same-day — action must happen same business day
- Fixed window — e.g. 1 business day, 2 hours
- Event-based — e.g. by agreed delivery date
- To be confirmed — management has not yet approved the exact SLA
3.4 System Notification
The system message, workflow task, or email that signals the responsible role that action is needed. Without a clear notification rule, steps are missed.
3.5 Required Action
The exact action the notified person must take. Vague steps like "review" are insufficient — specify create, approve, reject, release, post, or follow up.
3.6 Escalation Rule
What happens if the SLA expires without action? Define:
- Who is notified (supervisor, manager)
- At what interval (e.g. after 4 hours, after 1 day)
- Whether the task auto-escalates in the system
4. Standard Model Format
| Process Step | Department | Responsible Role | Approval Needed | SLA / Timeline | System Notification | Required Action | Escalation |
|---|---|---|---|---|---|---|---|
| Step name | Owning dept | Specific role | Yes / No (+ who) | Duration | Message/task sent | Action verb + object | Notify whom if expired |
5. Approval Sequences
When a step requires approval, the SOM must document:
- Who initiates — the role that creates or submits
- First approver — role, SLA, and rejection action
- Second approver (if sequential) — same detail
- Post-approval action — what happens immediately after full approval
- Rejection path — where the document goes if rejected and what the initiator must do
Example — Quotation Approval: Salesman creates → Financial Director approves first → Sales Director approves second → Salesman can create sales order with reference. If rejected at any step → quotation returned to salesman for revision.
6. Notification Rules
Notifications should be:
- Specific — sent to the named role, not a generic inbox
- Actionable — include a link or transaction code where action is needed
- Time-stamped — so SLA tracking can begin
- Escalated — if no action is taken within the SLA window
7. SLA Classification
| SLA Type | Meaning | When to Use |
|---|---|---|
| Confirmed | Management has approved the exact timing | Mature, signed-off processes |
| To be confirmed | Timing agreed in principle, not formally set | During implementation / Fit-Gap |
| Event-based | Triggered by business event (e.g. payment terms) | Collection, delivery |
| Continuous | No fixed SLA — ongoing monitoring | Credit management, AR aging |
8. Relationship to Other BPM Concepts
| Concept | Purpose | Relationship |
|---|---|---|
| Process Map / BPMN | Shows what steps happen and in what order | SOM answers who and when for each step |
| RACI Matrix | Documents responsibility at a high level | SOM adds SLA, notification, and escalation detail |
| Fit-Gap Analysis | Compares standard vs. company-specific process | Company SOM is the output of Fit-Gap decisions |
| Value Chain View | Shows end-to-end business value | SOM is the operational layer inside each step |
9. Company-Specific vs. Generic Model
| Generic (Standard Best Practice) | Company-Specific |
|---|---|
| Describes typical industry roles | Names actual company roles and departments |
| Uses range SLAs (e.g. 1–2 days) | Uses agreed internal SLAs |
| Applies to any ERP implementation | Reflects actual Fit-Gap decisions |
| Found in Standard Business Cycles | Found in Company Fit-Gap Case Studies |
See the O2C Stakeholder Operating Model under Standard Business Cycles for the generic best-practice O2C model. See the SD Stakeholder Operating Model under Company Fit-Gap → 05 - Sales & Distribution for the company-specific version.