This infographic maps the TOGAF risk management process for SAP S/4HANA manufacturing implementations.
In manufacturing SAP programs, risk management can easily become little more than a project issue log. However, the risks that an Enterprise Architect (EA) must manage extend beyond schedule delays and resource shortages. They include the possibility that the Target Architecture will fail to deliver the intended business outcomes, the business risks introduced by architectural decisions, and the risks that remain after mitigation.
This article translates the TOGAF® concepts of Initial Risk Assessment, Risk Mitigation and Residual Risk Assessment, and Conduct Residual Risk Assessment into a practical management approach that EAs can apply immediately during an SAP S/4HANA implementation in a manufacturing enterprise.
The working example concerns an automotive component manufacturer implementing SAP S/4HANA together with a new EDI platform for JIT/JIS messages. It is an original scenario developed for this article and does not reproduce an example provided by The Open Group.
When applying TOGAF® risk management in practice, it is essential not to confuse the following three stages:
TOGAF® describes the initial assessment as follows:
“Combine effect and frequency to come up with a preliminary risk assessment.”
In other words, the Effect—the severity of the consequences if the risk materializes—is combined with the Frequency—the likelihood or expected occurrence of the event—to determine the Preliminary Impact.
The purpose of mitigation is not simply to list actions. It is to:
“reduce the risk to an acceptable level.”
The risk that remains after mitigation is the Residual Risk:
“risk that remains is called the ‘residual risk’.”
In the risk worksheet, the left-hand section therefore records the pre-mitigation assessment, the center records the mitigation, and the right-hand section records the post-mitigation assessment.
| Risk ID | Risk | Preliminary Effect | Preliminary Frequency | Preliminary Impact | Mitigation | Residual Effect | Residual Frequency | Residual Impact |
| Unique identifier | Cause, event, and consequence | Pre-mitigation severity | Pre-mitigation likelihood | Pre-mitigation rating | Specific actions | Post-mitigation severity | Post-mitigation likelihood | Post-mitigation rating |
One of the most common worksheet errors is treating Effect and Impact as though they mean the same thing.
For example, if the Effect is Critical and the Frequency is Likely, the TOGAF-style matrix used in this article produces an Impact rating of High (H).
The Impact field should therefore contain the overall rating—E, H, M, or L—not a description such as “production stoppage.” The business consequence belongs in the Risk field or in a separate Business Consequence field.
The project management issue log and the architecture risk register should not be treated as the same artifact.
An item such as “the development task is two weeks late” is primarily a project issue or delivery risk. An EA should focus on risks that connect architectural decisions to business outcomes, such as:
The EA should classify each risk by the relevant Business, Data, Application, or Technology Architecture domain and maintain traceability to the associated architecture decision, requirement, building block, and transition initiative.
Assume that an automotive component manufacturer is replacing its legacy ERP system with SAP S/4HANA. At the same time, the company will begin receiving JIT/JIS delivery instructions from automotive OEMs through a new EDI platform.
A weak risk statement would be:
The EDI integration may fail.
This does not provide enough information to evaluate the Effect or define an effective mitigation.
A usable risk statement would be:
Insufficient processing capacity or an interface failure in the new EDI platform may delay or lose JIT/JIS messages from OEM customers, preventing SAP from generating shipping instructions and potentially causing an OEM production-line stoppage.
This statement identifies:
The Initial Risk Assessment is completed before taking the proposed mitigation into account.
An OEM line stoppage could lead to delivery failure, premium freight, contractual compensation, and deterioration in the customer relationship. The Effect is therefore assessed as Critical.
Because the new EDI platform has no proven production history and may need to process simultaneous message peaks from several OEMs, the Frequency is assessed as Likely.
Applying the risk matrix gives:
Critical × Likely = H
| Risk ID | Risk | Effect | Frequency | Impact |
| R-EDI-001 | Delayed or missing JIT/JIS messages prevent shipping-instruction generation and cause an OEM line stoppage | Critical | Likely | H |
The assessment team should not select Critical or Likely solely on intuition. It should review evidence such as:
The Mitigation field should not contain a vague statement such as “perform sufficient testing.” Each action must have a responsible owner and a verifiable completion criterion.
| Action ID | Mitigation | Owner | Completion Criterion |
| M-01 | Conduct a performance test at 200% of the expected production peak | Integration Lead | Zero message errors and 95% processed within 60 seconds |
| M-02 | Run the legacy and new EDI platforms in parallel for ten business days | Cutover Lead | Zero differences in message counts and content |
| M-03 | Automatically detect processing delays exceeding five minutes | Operations Lead | Monitoring and notification tests passed |
| M-04 | Implement message replay and reprocessing | Development Lead | All failure-scenario reprocessing tests passed |
| M-05 | Establish a rollback procedure to the legacy EDI platform | Cutover Lead | Rollback test completed within 30 minutes |
| M-06 | Perform the cutover by OEM and plant rather than as a big bang | Deployment Lead | Go/No-Go criteria approved for every wave |
| M-07 | Obtain cutover approval from business, shipping, and IT owners | Business Owner | All designated approvers have signed off |
The EA must confirm that each action addresses a cause or consequence of the risk. Monitoring alone may not reduce the probability of an interface failure. Performance testing and phased deployment primarily reduce Frequency, while message replay and rollback primarily reduce Effect. This relationship should be explicit.
Once the mitigation has been designed, the team estimates the risk level expected if every mitigation action operates as intended.
Message replay and rollback within 30 minutes should prevent a technical incident from escalating into an OEM production-line stoppage. The planned Effect can therefore be reduced from Critical to Marginal.
Performance testing, parallel operations, and a phased cutover should reduce the probability of a production incident. The planned Frequency can therefore be reduced from Likely to Seldom.
Marginal × Seldom = L
| Initial Risk | Planned Residual Risk |
| Critical × Likely = H | Marginal × Seldom = L |
This is not yet the validated Residual Risk. It is a forecast based on the assumption that the mitigation actions will be completed and will operate effectively.
Before the production go-live decision, the EA, Risk Owner, Business Owner, SAP Solution Architect, Integration Lead, and Operations Lead should review the evidence that the mitigation actions have been completed and are effective.
| Validation Item | Actual Result | Assessment |
| Performance test at 200% of expected peak | 95% of messages processed within 42 seconds | Passed |
| Ten-business-day parallel run | Zero receiving differences | Passed |
| Incident detection | Alert generated within three minutes | Passed |
| Message reprocessing | Successful in every failure scenario | Passed |
| Rollback to legacy EDI | Service restored within 27 minutes | Passed |
Based on this evidence, the team can validate the Residual Effect as Marginal, the Residual Frequency as Seldom, and the Residual Impact as L.
The planned rating must not be copied into the validated rating if the evidence is incomplete. If, for example, the rollback test fails, Frequency may decline, but the Effect remains Critical.
| Assessment Point | Effect | Frequency | Impact |
| Initial | Critical | Likely | H |
| Planned Residual | Marginal | Seldom | L |
| Validated Residual | Critical | Seldom | M |
In this situation, the organization must implement additional mitigation, postpone the cutover, reduce the scope of the deployment wave, or obtain acceptance from an appropriately authorized governance body.
The basic TOGAF® sample worksheet contains one set of Residual Risk columns. In an SAP implementation, it is advisable to extend the worksheet to distinguish the planned rating from the validated rating.
| Assessment Type | Effect | Frequency | Impact | Assessment Date | Evidence |
| Initial Risk | Critical | Likely | H | October 15, 2026 | Design review and historical incident data |
| Planned Residual Risk | Marginal | Seldom | L | November 10, 2026 | Mitigation Plan |
| Validated Residual Risk | Marginal | Seldom | L | January 15, 2027 | Performance, rollback, and parallel-run results |
This extension makes differences between the expected and actual effectiveness of mitigation visible. For example, management can see immediately when a risk expected to fall to L remains at M.
To use the worksheet as a governance artifact, add the following fields to the basic TOGAF® structure.
| Field | Purpose | Example |
| Risk Owner | Accountability for the risk and its acceptance | Supply Chain Director |
| Action Owner | Responsibility for implementing mitigation | Integration Lead |
| Architecture Domain | Related architecture area | Application / Technology |
| Related Requirement | Traceability to an architecture or business requirement | REQ-EDI-023 |
| Architecture Decision | Traceability to the relevant decision | ADR-017 Phased Cutover Strategy |
| Related ABB/SBB | Affected architecture or solution building block | Integration Service / EDI Gateway |
| KRI / Trigger | Indicator that initiates reassessment | Messages delayed by more than five minutes |
| Target Residual Level | Required post-mitigation rating | L |
| Evidence | Proof supporting the assessment | Performance Test Report |
| Acceptance Authority | Person or body authorized to accept the risk | CIO / SCM Executive |
| Review Date | Date of the next assessment | February 15, 2027 |
| Status | Current governance state | Mitigating / Validated / Accepted |
TOGAF® and SAP Activate should not be operated as two disconnected methodologies. Architecture risk management should be embedded in the existing SAP implementation governance model.
| SAP Activate / TOGAF Timing | EA Activity | Primary Deliverable |
| Prepare / ADM Phase A | Confirm risk appetite, assessment scales, and approval authority | Risk Management Approach |
| Explore / ADM Phases B–D | Identify risks from Fit-to-Standard and the Target Architecture | Initial Risk Register |
| Realize / ADM Phases E–F | Design mitigation, deployment waves, and completion criteria | Mitigation Plan and Planned Residual Risk |
| Deploy / ADM Phase G | Validate evidence and reassess Residual Risk | Validated Residual Risk and Go/No-Go decision |
| Run / Architecture Change Management | Monitor KRIs and reassess risks when changes occur | Updated Risk Register |
During Explore and Fit-to-Standard, not every gap should automatically be recorded as an architecture risk. A gap becomes a relevant risk when leaving it unresolved—or resolving it through a particular design decision—creates uncertainty about achieving the Target Architecture or the intended business outcome.
The following sequence enables the team to assess one significant risk in approximately 30 minutes:
The EA should not determine every rating alone. The Business Owner should assess the business Effect, the technology and operations leads should substantiate Frequency, and the authorized governance body should decide whether to accept the Residual Risk. The EA ensures consistency, cross-domain integration, and traceability to the architecture.
The organization’s own risk appetite takes precedence. However, the following rules illustrate how the ratings can drive decisions.
| Residual Impact | Example Governance Decision |
| E | Do not authorize go-live; escalate immediately to executive management |
| H | Require additional mitigation; executive approval required for exceptional acceptance |
| M | Require an acceptance decision by the steering committee or accountable business executive |
| L | Allow the Risk Owner to accept the risk, subject to continued KRI monitoring |
A Low rating does not mean that the risk has disappeared. When a Residual Risk is accepted, its status should normally be Accepted / Monitoring, not automatically Closed. It should continue to be monitored during ADM Phase G and production operations.
The team may not be able to explain whether or how the mitigation reduces Effect or Frequency.
Without test conditions, acceptance criteria, an owner, a deadline, and evidence, mitigation completion cannot be governed.
A planned L rating may reach executive reporting even when the mitigation remains incomplete. Planned and Validated Residual Risk must be separated.
The EA provides integration and consistency, but should not unilaterally determine business impact or accept business risk.
Peak-volume periods, additional plant deployments, SAP upgrades, and changes to OEM messaging specifications may alter Frequency. The KRI and reassessment conditions must remain active.
A TOGAF® risk management worksheet is not simply a list of SAP implementation risks. It is a governance artifact that enables the EA to manage a connected sequence of decisions:
Initial assessment → Mitigation design → Planned Residual Risk → Mitigation execution → Validated Residual Risk → Acceptance → Continuous monitoring
In a manufacturing SAP implementation, ERP disruption can immediately affect production, logistics, customer deliveries, financial closing, and regulatory compliance. The EA must therefore track not only the initial level of risk, but also whether the mitigation addresses the architectural cause, whether the Residual Risk is supported by evidence, and who has formally accepted the remaining exposure.
By separating Planned Residual Risk from Validated Residual Risk and adding Owner, Evidence, Acceptance Authority, and KRI fields, organizations can connect TOGAF® risk management directly to SAP solution reviews, test completion decisions, Go/No-Go governance, and ADM Phase G Implementation Governance.
TOGAF® is a registered trademark of The Open Group. This article is an independent practical interpretation of how TOGAF risk management techniques can be applied to an SAP implementation in a manufacturing enterprise. It is not an official implementation guide issued or endorsed by The Open Group or SAP. The SAP scenario, risk assessments, mitigation actions, and worksheet examples were developed specifically for this article.
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Net present value (NPV) is the go-to metric for evaluating major IT investments. This guide…
Many Architecture Repositories get built, then quietly abandoned. This article explains the eight components defined…
A practical guide to accelerating EA with generative AI: core principles, a 12-week TOGAF ADM…
Forecast and call-off integration, provisional pricing, chargeable subcontracting, kanban, and acceptance matching. This article maps…
ERP implementation in global manufacturing requires critical decisions about ERP scope, surrounding applications, global standardization,…
Measure SAP S/4HANA ROI over just three years and you will mostly see cost. This…