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.

Three Stages of TOGAF® Risk Management That Must Be Kept Distinct

When applying TOGAF® risk management in practice, it is essential not to confuse the following three stages:

1. Initial Risk Assessment: Assess the risk before mitigation.
2. Risk Mitigation and Residual Risk Assessment: Design the mitigation actions and estimate how far the risk should be reduced.
3. Conduct Residual Risk Assessment: Reassess the risk based on evidence after the mitigation actions have been implemented.

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

Do Not Confuse Effect, Frequency, and Impact

One of the most common worksheet errors is treating Effect and Impact as though they mean the same thing.

• Effect: The severity of the consequence for the enterprise, business operations, or transformation if the risk occurs.
• Frequency: The likelihood or expected frequency of the risk during the transformation.
• Impact: The overall risk rating derived by combining Effect and Frequency in the approved risk matrix.

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.

Which Risks Should an EA Manage During an SAP Implementation?

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:

• Standardizing the ERP template may prevent a plant from maintaining business-critical JIT/JIS processes.
• Delays in the SAP S/4HANA-to-MES interface may cause production confirmations and inventory balances to diverge.
• Planning constraints may not be reproduced correctly when moving from APO to PP/DS, resulting in infeasible production plans.
• Integration failures between SAP EWM and warehouse automation equipment may stop outbound logistics.
• Defects in Business Partner harmonization may create duplicate customer and supplier master records.
• A big-bang cutover may expose multiple plants to production and shipping disruption at the same time.
• An inadequate authorization design may lead to segregation-of-duties violations or financial control deficiencies.

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.

Practical Example: SAP S/4HANA Cutover with JIT/JIS Integration

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.

1. Write the Risk as Cause–Event–Business Consequence

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:

• Cause: Insufficient processing capacity or an interface failure
• Risk event: Delayed or missing JIT/JIS messages
• Business consequence: Failure to generate shipping instructions and a possible OEM production-line stoppage

2. Conduct the Initial Risk Assessment

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:

• OEM delivery terms and contractual consequences of a line stoppage
• Revenue, compensation, and premium-freight exposure for each hour of disruption
• Historical incident and latency data from the existing EDI platform
• Performance test results for the new platform
• Peak message volumes compared with processing capacity
• The length of time for which a manual fallback process can remain viable

3. Design the Mitigation Actions

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.

Estimate the Planned Residual Risk

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.

Conduct the Residual Risk Assessment Using Evidence

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.

Separate Planned and Validated Residual Risk in the Worksheet

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.

Recommended Fields for an EA Risk Management Worksheet

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

Integrating TOGAF® ADM Risk Management with SAP Activate

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.

How to Run the Risk Assessment Meeting

The following sequence enables the team to assess one significant risk in approximately 30 minutes:

1. The Risk Owner explains the cause, risk event, and business consequence.
2. The EA confirms the related Architecture Principle, requirement, and decision.
3. The Business Owner assesses the Effect.
4. The Solution or Technology Lead presents the evidence supporting the Frequency rating.
5. The team derives the Initial Impact from the approved matrix.
6. The Action Owner proposes the mitigation and completion criteria.
7. The team calculates the Planned Residual Risk.
8. The team agrees on the required evidence, due dates, and reassessment date.
9. After implementation, the team validates the evidence and determines the Validated Residual Risk.
10. The appropriate authority decides whether to accept the risk, require additional mitigation, postpone deployment, or change the scope.

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.

Example Residual Risk Decision Rules

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.

Common Failure Modes

1. Initial and Residual Risk Have the Same Values

The team may not be able to explain whether or how the mitigation reduces Effect or Frequency.

2. The Mitigation Says Only “Perform Testing”

Without test conditions, acceptance criteria, an owner, a deadline, and evidence, mitigation completion cannot be governed.

3. Planned Residual Risk Is Reported as an Actual Result

A planned L rating may reach executive reporting even when the mitigation remains incomplete. Planned and Validated Residual Risk must be separated.

4. The EA Makes Every Assessment

The EA provides integration and consistency, but should not unilaterally determine business impact or accept business risk.

5. The Worksheet Is Closed Immediately After Go-Live

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.

Practical Checklist for Enterprise Architects

• The risk is written as cause, event, and business consequence.
• The evidence supporting Effect and Frequency is recorded.
• Impact is derived from the approved risk matrix.
• Every mitigation action has an owner, due date, and completion criterion.
• The team can explain whether each action reduces Effect, Frequency, or both.
• Planned and Validated Residual Risk are recorded separately.
• Test results and other evidence are linked to the assessment.
• The authority responsible for accepting the Residual Risk is identified.
• The risk is traceable to requirements, architecture decisions, and ABBs/SBBs.
• Post-go-live KRIs, triggers, and review dates have been established.

Conclusion

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.

References and Related Resources

TOGAF® and Enterprise Architecture

1. The Open Group — The TOGAF Standard
   The official landing page for the TOGAF Standard, including the Architecture Development Method, architecture governance, and related guidance.
2. The Open Group — TOGAF Series Guides
   The official collection of practical guidance supporting the application of the TOGAF framework.
3. TOGAF Risk Management — Public Reproduction of TOGAF 9.1 Content
   Contains the relevant sections on Initial Risk Assessment, Risk Mitigation and Residual Risk Assessment, Conduct Residual Risk Assessment, and Phase G risk monitoring. This is a third-party reproduction rather than an official The Open Group publication page.
4. The Open Group — Security and Risk Management
   Official information on integrating security and risk management with Enterprise Architecture.
5. The Open Group — Risk Analysis
   Official information on risk analysis using Open FAIR with the TOGAF Standard.
6. The Open Group — How the ArchiMate Language and the TOGAF Standard Complement Each Other
   Explains how TOGAF and ArchiMate support traceability from requirements to implementation, including ADM Phase G.

SAP Activate and SAP Implementation

7. SAP — SAP Activate
   SAP’s official overview of the SAP Activate methodology, Fit-to-Standard, implementation phases, accelerators, quality gates, and supporting tools.
8. SAP Learning — Defining the Purpose of SAP Activate and the Implementation Approach
   An SAP learning resource for Enterprise Architects explaining the phased approach to business transformation.
9. SAP Learning — Analyzing Each Phase of SAP Activate
   Detailed guidance on Prepare, Explore, Realize, Deploy, Fit-to-Standard workshops, and implementation accelerators.
10. SAP Learning — The Three Pillars of SAP Activate
    Explains governance, iterative implementation, testing, quality gates, cutover, and post-go-live support.
11. SAP Learning — Using the SAP Integrated Toolchain Across SAP Activate Phases
    Explains how SAP Cloud ALM, SAP Signavio, and SAP LeanIX support target design, implementation, testing, release, and deployment.
12. SAP Help Portal — How to Approach Fit-to-Standard Analysis
    An official SAP Activate accelerator covering Fit-to-Standard analysis, configuration, integration, and solution design.
13. SAP Help Portal — SAP ERP Transformation with an Integrated Toolchain
    Connects Prepare with transformation planning, Explore with Target Architecture definition, Realize and Deploy with implementation, and Run with monitoring.

---

Disclaimer

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.

---

Back to Top