Lesson 5 of 5
Roles in change approval
8 min
A change process is only as good as the people in it and the separation between them. The same person should not ask for a change, build it, test it, approve it and import it. Splitting those duties is what makes approval meaningful.
| Role | Responsibility | Contoso example |
|---|---|---|
| Requester | Describes the need and the business reason; confirms the result | A pricing analyst asking for a new fleet discount |
| Business process owner | Approves the business impact and accepts the tested result | Maria for order to cash; Dan for finance |
| Change manager | Runs the process, checks the evidence, chairs the CAB, approves low-risk changes | Contoso's IT change manager |
| Change advisory board (CAB) | Reviews higher-risk changes and releases; business and IT represented | Weekly CAB with Maria, Dan, IT leads |
| Developer or consultant (implementer) | Builds the change in DEV; unit tests; documents | Order-to-cash consultant |
| Tester | Executes functional and regression tests in QAS; records evidence | Priya's test team |
| Release manager | Plans releases, sequences transports, coordinates import windows | IT release manager |
| Basis / transport administrator | Imports approved transports into production | Basis team on the import window |
| Emergency approver | Approves emergency changes quickly; ensures retrospective review | Duty manager with the process owner |
Typical roles in SAP change approval. Small teams combine roles, but never the incompatible ones.
Separation of duties
The most important separation is between the people who build a change and the people who move it into production. Developers should not have authorization to import transports into production or to change configuration there. SAP supports this with client settings that lock production against direct changes, authorizations for the transport management system, and, in SAP Cloud ALM, transport restrictions and personas such as developer, tester, change manager and deployment manager.
The CAB in practice
A useful CAB is short and evidence-based. Each change is presented with its risk rating, test evidence and rollback approach; the business owner says whether the timing works; the board approves, defers or rejects. A CAB that approves everything without reading the evidence adds delay without adding control, and a CAB that debates design is doing the work of an earlier gate.
Roles during a project and after go-live
During Contoso's implementation, the program controls change: Grace's PMO runs the release plan, Priya's team owns test evidence, and the design authority approves scope changes. At go-live, those duties pass to the run organization. The handover should be explicit: who becomes change manager, who sits on the CAB, who the emergency approvers are for each process area, and which change policy applies from the first day of hypercare. A common gap is the first few weeks after go-live, when project consultants still have broad access and fixes flow quickly. Hypercare needs speed, but it still needs the same separation of build, approve and deploy, with every fix recorded so it can be added to the regression pack.
What would you do?
Contoso's small support team proposes that the order-to-cash consultant should both build changes and import them into production during evenings, to save waiting for Basis. What should the change manager decide?
- Roles: requester, business process owner, change manager, CAB, implementer, tester, release manager, Basis, emergency approver.
- Separate build from deploy and approve; developers should not import to production.
- Route approvals by business impact and technical risk according to the change policy.
- A good CAB reviews evidence, timing and rollback briefly and decides.
Check your understanding · not graded
Lesson check
1. Who should accept the tested business result of a pricing change?
2. Which duties must be separated most strictly?
3. What should a CAB review for each change?
4. How is an imported SAP transport usually reversed?