Lesson 2 of 6
Modelling and the Collaboration Hub
10 min
Listen to this lesson
A process owner does not need to draw BPMN, but must own what the drawings say. In SAP Signavio, models are built in Process Manager, approved through Process Governance and published in the Process Collaboration Hub, where the business reads them. This lesson covers what a good model contains, how it is published, and how it stays true.
From hierarchy to model
Course sap-pow-201 introduced the process hierarchy: end-to-end process, process area, process, process step. In Process Manager this becomes a structure of linked diagrams. Higher levels are value chains or overview diagrams; lower levels are BPMN diagrams with lanes for roles, tasks, events and gateways. Objects such as roles ("Accounts payable clerk"), IT systems ("SAP S/4HANA, CMP") and documents ("Supplier invoice") come from a shared dictionary, so the same role means the same thing in every diagram and can be searched across the model.
| Level | Contoso example | Owner's concern |
|---|---|---|
| End-to-end process | Procure to pay | Scope and handoffs across departments |
| Process area | Invoice to payment | Which teams are involved |
| Process | Process supplier invoice | Who does what, in which system, with which controls |
| Process step (BPMN detail) | Verify invoice against PO 4500002246 and GR 5000001876; post in Supplier Invoices app | Exceptions, approvals and evidence |
Contoso's procure-to-pay hierarchy, as modeled in Process Manager.
Starting from SAP content
Few owners start from a blank page. SAP Signavio Process Explorer offers SAP best-practice content and value accelerators that can be taken into Process Manager as a starting point, and SAP Signavio Process Navigator shows SAP Best Practices processes for fit-to-standard. Contoso's team started from SAP's procure-to-pay content and adapted it: the approval thresholds (purchase requisitions over $10,000 need release; purchase orders over $25,000 need approval in the flexible workflow) and the Lakeside Components EDI flow were added as Contoso specifics.
Decide the modeling conventions once and publish them: naming (verb plus object, such as "Post supplier invoice"), which BPMN elements are allowed at each level, how controls are marked, and how SAP apps and transactions are referenced on tasks. Conventions make models comparable across owners, and they let testers and auditors read any process without asking the modeler what a symbol means.
Publishing with approval
SAP describes approval workflows as the way decision makers review the quality and factual correctness of a diagram before it is published. Editing and submitting for approval needs a modeler license and access rights, and an approval workflow must be set up in Process Governance. Without a workflow, whoever can publish decides what the business reads. For a process that carries controls, like Dan's, that is not acceptable.
What a good model contains
| Element | Why the owner cares | Example in "Process supplier invoice" |
|---|---|---|
| Lanes for roles | Who is accountable for each task | AP clerk, buyer, approver, process owner |
| Systems on tasks | Where the work happens; what to test | SAP S/4HANA CMP, supplier EDI via Integration Suite |
| Controls marked | What auditors and testers will check | Three-way match; approval for invoices over the threshold |
| Exception paths | Where cases get stuck in reality | Price difference block; missing goods receipt |
| Links to KPIs and documents | How performance is measured | Invoices paid after due date; automation rate |
Elements that make a model useful to owners, testers and auditors, not only to modelers.
Exception paths are the part most often missing. A model that shows only the happy path is easy to approve and useless for testing and training, because the real work is in the exceptions. Process mining (lessons 3 and 4) tells the owner which exceptions are frequent enough to model; the rest can be described in one line.
Living documentation
- Change together. When a configuration change alters a process, the model change is part of the same change request; the release is not complete until the published model matches.
- Review on a rhythm. Owners review their models at least yearly and after each release that touched the process.
- Use the comments. The Collaboration Hub lets readers comment; an unanswered comment is a signal that the model and reality differ.
- Link to evidence. Test scenarios and controls reference the model version they were built from.
What would you do?
After a release, the supplier invoice process gains an extra approval step for invoices over a threshold. The configuration is in production, but the published model still shows the old flow. Ana, the AP clerk, follows the model in training new colleagues. Who should act, and how?
- Models follow the process hierarchy, with shared dictionary objects.
- Start from SAP content (Process Explorer, Process Navigator) and add your specifics.
- Publish through an approval workflow in Process Governance, with the owner as approver.
- Keep models current: change them with configuration, review on a rhythm, answer comments.
Check your understanding · not graded
Lesson check
1. What does the dictionary in Process Manager provide?
2. What must exist before a model can be submitted for approval?
3. When should a model change be made after a configuration change?
4. Where can SAP Best Practices processes be viewed for fit-to-standard?