Your change system knows that a change happened. Figaf knows what changed
The gap this closes
The Change Management System (ChaRM or Cloud ALM) decides whether a change may go to production, and it does that job well. However, it lacks transparency about what impact and configuration the change has. This means that you need to perform validation in secondary systems and have more manual processes.
Figaf supplies the transport engine and the content-level detail. The Change Management System keeps the authority and the audit record.
Two objects, two jobs
| The Change Document | The Figaf Ticket | The Transport | |
|---|---|---|---|
| Is | the authorization | the container of what changes | the act of moving it |
| Holds | justification, approval, release window | selected objects, test evidence, documentation | source, target, result |
| Is owned by | release management | the integration team | the integration team |
One change document ↔ one Figaf ticket ↔ two transports (Dev→QA and Dev→Prod)
What stays exactly as it is today
- The release calendar, the change document types, and the approval procedure. Untouched.
- The Change Management System as the system of record and the gate.
- The transport number your auditor follows.
Figaf sits underneath this. It executes the steps the Change Management System cannot perform itself.
What the process looks like
How to read it. The left-hand box is your process today, unchanged. The right-hand box is new capability. This is a proposed solution.
How much has to be built
Three levels. They are a menu, not a sequence you have to complete.
| Level | What it is | Build cost | Where the gate lives |
|---|---|---|---|
| 0: Reference only | The Change Management System number is a mandatory field on the Figaf ticket. Approvals happen in the Change Management System as they do today; a person releases in Figaf. Nothing built. | None, works in week one | In the Change Management System, procedurally |
| 1: One-way | Figaf posts ready / imported / failed into the ServiceNow record; your existing ServiceNow ↔ Change Management System link carries it onward. Release still triggered by a person. | Days, ServiceNow-side configuration | In the Change Management System via ServiceNow |
| 2: Two-way, Change Management native | A PPF action plus custom ABAP calls the Figaf API to release the import; Figaf writes status back to the change document. | Weeks of ABAP on your side | In the Change Management System, technically enforced |
Our recommendation: start at Level 0
Run at Level 0 while you are evaluating Figaf. Nothing is built, and the audit chain closes from day one. Because it closes as soon as both systems record each other’s number.
Then add depth only when something specific has made the case for it:
- Move to Level 1 when people forget to update the ticket, or you find yourself asking “where is that change now?” That is a visibility problem, and an outbound event is exactly what fixes it.
- Move to Level 2 when procedure alone stops holding. Someone releases without authorization, or an auditor asks for technical enforcement rather than recorded evidence.
Two release cycles at Level 0 will tell you which of those you actually have. Most organisations ask for enforcement and then discover that visibility was the real pain. Level 2 buys enforcement, not evidence. It is worth deciding early which of the two you are audited on.
One timing note, as information rather than pressure: Solution Manager 7.2 mainstream maintenance ends 31 December 2027, and SAP’s stated direction is Cloud ALM. Weeks of ABAP spent on a Level 2 Change Management System integration is investment in a platform with a published end date.
What you get that you cannot get otherwise
To be straight about the alternative: SAP can move the content: Content Agent Service packages it into an MTAR, and Cloud Transport Management has been integrated with the Change Management System since SolMan 7.2 SPS10. Anyone who says “SAP already does this” is right about the moving. What that path does not give you:
- Content-level visibility: which iFlow, which mapping step, which parameter, version against version. Your approver sees the change, not just its number.
- Test evidence attached to the transport: “was this tested?” is answered by the record, not by someone’s memory.
- Documentation as a by-product: generated from the change rather than written up afterwards.
- Per-environment configuration handled: the same iFlow needs different endpoints and credentials per stage. This is the step that most often breaks a manual move.
- Enforced separation of duties: the developer who built the change cannot be the one who moves it to production. On cloud integration you very likely do not have this control today.
- Rollback: the previous version is a known, re-transportable state.
- A complete audit trail: requested, approved, moved, by whom, when, and what the system looked like before and after.
Points 1-7 are the box being opened. The transport itself was never the hard part.
