Lesson 1 of 5
Designing the change process
10 min
SAP Cloud ALM gives you building blocks: requirements, features with statuses, transports, releases, test runs and history. It does not give you a change process. That is your job, and it is the job auditors will ask about. A good process says which kinds of change exist, which path each one follows, who decides at each step and what evidence they decide on.
In SAP Solution Manager ChaRM, the path was built into document types such as normal and urgent changes. Cloud ALM has a single change object, the feature, so the path is defined by your procedure and expressed through feature attributes: priority, tags, release and workstream. That is more flexible, and it means you must write the rules down.
Three change paths
| Path | Used for | How it looks in Cloud ALM | Approval |
|---|---|---|---|
| Normal | Planned enhancements and project scope | Feature with a planned release; full status flow; regression in the release window | Change Manager after test sign-off |
| Standard (pre-approved) | Low-risk, repeatable changes such as adding a new number range interval for a plant | Feature tagged "standard", using a pre-approved test checklist | Pre-approved by the change board; Change Manager confirms the checklist |
| Urgent | Fixes for production incidents that cannot wait for the next release | Feature tagged "urgent", very high priority, emergency release; focused test | Change Manager plus process owner; retrospective review within five working days |
The paths differ in speed and evidence, never in traceability. Every change, even the 2 a.m. fix, is a feature with transports, a test record and an approval in its history. What the urgent path saves is waiting time, not control.
The normal flow, step by step
- RequestRequirement raised and approved by the process owner, for example Dan for finance
- SpecifyFeature created from the requirement, release assigned, In Specification
- BuildIn Implementation: transports created from the feature, changes built in CMD, deployed to CMQ
- TestIn Testing: linked test cases executed by Priya’s team and key users
- ApproveSuccessfully Tested, then Ready for Production set by Luis
- DeployImported to CMP with its release; feature Deployed; requirement completes
Designing the urgent path
Urgent changes are where processes break. Design this path before you need it. At Contoso, a production incident with a business impact can open an urgent feature. Luis assigns it to a standing Emergency release in the deployment plan, so it never waits for a planned go-live date. Kenji builds the fix; Priya's team runs a focused test of the fix and the process around it in CMQ; Luis and the affected process owner approve; Sam imports it. Within five working days, the feature gets a short review: was the urgency real, did the fix hold, does anything need a follow-up normal change?
- Is production stopped or a legal or financial deadline at risk?Yes → urgent path · No → next question
- Is the change on the pre-approved standard list?Yes → standard path with its checklist · No → next question
- Can it wait for the next planned release?Yes → normal path · No → escalate to Luis and the process owner for an urgent decision
The standard change catalog
Standard changes are the quiet win in a change process. They are changes the board has already judged low risk and repeatable, so each instance does not need a fresh debate. Contoso's catalog is short and specific, and each entry names its checklist and the one test that confirms it. Anything not on the list is not standard, however small it looks.
- Adding a number range interval for an existing object in plant 1710 or 1720.
- Adding a new output condition record for an existing output type and customer.
- Extending an existing authorization role with a display-only transaction already used elsewhere.
- Adjusting a background job start time that has no downstream dependency.
Review the catalog every quarter. If a standard change ever causes an incident, it comes off the list until the board has looked at why.
What would you do?
A finance user asks for a new G/L account to be added to a posting rule "urgently, today" because a month-end report looks wrong. Production is running. Which path should Luis choose?
- Cloud ALM provides one change object; your procedure defines the paths.
- Express paths with feature attributes: tags, priority, release, workstream.
- Paths differ in speed and evidence depth, never in traceability.
- Design the urgent path in advance, with a standing emergency release and a retrospective review.
Check your understanding · not graded
Lesson check
1. How are change types such as urgent changes expressed in Cloud ALM?
2. What should an urgent change save compared with a normal change?
3. Why give urgent changes a standing emergency release?