Skill Hub — SAP AMS / Operations

Root Cause Analysis

Separate symptoms from causes, trace defects to their entry point, and produce a correction and prevention plan.

What this skill is for

This skill helps you find why a defect happened, not just what went wrong. It produces a clear chain from observed symptom to underlying cause to entry point in the lifecycle. The output is a Root Cause Analysis Note that tells a correction team what to fix and a prevention team what to control.

When to use this skill

An incident has been triaged and the same symptom has occurred at least twice.
A high-impact incident blocked a critical business process for more than four hours.
A change went live and caused unexpected failures in a different module or system.
A data quality report shows a spike in defects and the source is unknown.
A background job or interface has been failing intermittently and the failure pattern is unclear.

Real work situations

Example 1: Duplicate customer master records blocking invoicing

The symptom is duplicate customers in the system. The immediate cause is a failed merge. The root cause is that the customer creation process allows manual entry in both SAP and a downstream CRM without a uniqueness check against the central MDG system. The entry point is the CRM create API that bypasses MDG validation. The correction is a data merge and deduplication run. The prevention is enforcing MDG as the single point of entry for customer creation.

Example 2: Sales order incompletion procedure causing nightly batch failures

The symptom is batch job cancellation every night at 02:00. The immediate cause is a missing required field in 3% of orders. The root cause is a recent incompletion procedure change that added a mandatory field for a specific sales document type, but existing open orders were not updated. The entry point is the transport that changed the incompletion procedure without a data migration. The correction is a mass update of the affected field. The prevention is a change process that requires data impact assessment for incompletion procedure changes.

Example 3: qRFC queue buildup after a system restart

The symptom is SMQ1 showing thousands of queued messages. The immediate cause is a backlog after a system restart. The root cause is that the restart procedure does not include a step to verify RFC destination availability before releasing queues, and one destination was down for maintenance. The entry point is the restart runbook. The correction is manual queue release after destination verification. The prevention is updating the runbook and adding an automated destination health check before queue release.

Example 4: Billing documents created with wrong tax code

The symptom is incorrect tax codes on invoices. The immediate cause is a condition record with an expired validity period. The root cause is that tax condition records are maintained manually by a regional team with no review process, and the expired record was not flagged. The entry point is the manual maintenance process without validation. The correction is a reversal and re-billing with the correct condition. The prevention is a periodic review report for expiring condition records.

Inputs required

The triage record or incident ticket with full symptom description, timestamps, and affected scope.
System logs: SM21, SLG1, ST22, SM37, SM58, SMQ1/SMQ2, WE02/WE05.
Change history: transport logs, change documents (SCU3), configuration changes in the relevant time window.
Master data samples: affected records with before/after comparison if available.
Process documentation or runbooks for the affected area.
Stakeholder access: functional consultant, data steward, Basis, integration team, business user who reported the issue.
Ticket history for the last 30–90 days to check for recurrence.

Questions to ask

What exactly was observed, and what is the earliest point in time this symptom could have started?
What changed in the system, process, data, or organization just before the first occurrence?
Where did the defect enter the lifecycle: user entry, interface, batch load, system replication, or configuration change?
Which validation or control should have caught this, and why did it not?
Is the defect isolated to a specific data object, user, time window, or document type?
What business process is affected, and what is the quantified impact (orders blocked, invoices delayed, revenue at risk)?
Has this exact symptom or a closely related one occurred before? When and how was it resolved?
Who owns the process or data object where the defect entered, and who owns the process that should prevent it?

Working method

Confirm the symptom. Reproduce or verify the reported defect with your own eyes. Do not rely on second-hand descriptions. Document the exact error text, transaction, and record IDs.
Define the defect boundary. Determine: affected system, module, document type, time window, number of records, and whether the defect is ongoing or historical.
Build a timeline. List events in chronological order: first failure, last success, any changes, any maintenance windows, any data loads. Use system logs and change documents.
Identify the immediate cause. What directly produced the symptom? A missing field? A failed validation? A timeout? A wrong condition record? State it in one sentence.
Trace to the root cause. Ask "why" up to five times or until you reach a process, configuration, or governance gap that explains the immediate cause. The root cause is the thing that, if fixed, prevents recurrence.
Identify the entry point. Where in the lifecycle did the defect first enter? User entry, interface, batch, replication, manual config, or code change?
Classify the defect type. Use one of: data, configuration, custom code, process, integration, infrastructure, user error, or unknown. If unknown, state what is missing to determine it.
Quantify business impact. Count affected records, estimate cost, identify downstream processes that are blocked or delayed.
Design the correction. How will affected records or systems be fixed? Manual, mass update, reprocessing, reversal, or configuration rollback?
Design the prevention control. What validation, workflow, monitoring, or process change will stop this from recurring? The prevention must address the root cause, not the symptom.
Assign owners and deadlines. Name a person or team for correction and a person or team for prevention. Set realistic deadlines.
Document in a Root Cause Analysis Note. Use the template below or the Artifact Templates page.

Decision rules

If the symptom cannot be reproduced, stop the analysis and gather more data before building theories.
If the timeline shows a change within 24 hours of first failure, treat the change as the primary suspect until disproven.
If the defect affects fewer than 10 records and the rule is clear, correct through the governed manual process.
If the defect affects more than 100 records, prepare a mass correction with validation, approval, and a rollback plan.
If the root cause is a missing validation, fix the validation before correcting existing records.
If the root cause is a process gap, produce a process change proposal, not just a one-time fix.
If the defect has occurred before and was "fixed," the previous fix was not a root cause fix. Escalate to find the deeper cause.
If the entry point is an interface, check the source system validation before blaming SAP configuration.
If the root cause is unknown after 4 hours of analysis, document what is known, what was ruled out, and what data is missing.

Deliverables

Root Cause Analysis Note — The primary artifact. Contains symptom, timeline, root cause, entry point, impact, correction, and prevention. Use the Artifact Templates page for the full format.
Remediation Backlog Item — If correction requires significant work, create a tracked backlog item with scope, method, and validation. See Artifact Templates.
Prevention Control Proposal — A short proposal for the validation, monitoring, or process change that prevents recurrence.

Templates

Root Cause Analysis Note (compact)

---
artifact: Root Cause Analysis Note
id: RCA-001
date: YYYY-MM-DD
author: Name
status: draft | reviewed | closed
---

## Symptom


## Defect classification


## Affected scope


## Timeline


## Immediate cause


## Root cause


## Entry point


## Business impact


## Correction approach


## Prevention control


## Correction owner


## Prevention owner


## Deadlines


## Verification


## Related incidents

Quality checklist

The symptom is described with exact error text, transaction code, and at least one example record ID.
A timeline exists with at least three data points: last known success, first failure, and any relevant change or event.
The root cause is distinct from the symptom and the immediate cause.
The entry point is identified: where the defect first entered the lifecycle.
Business impact is quantified or at least estimated with a clear method.
The correction approach addresses affected records or systems, not just the root cause.
The prevention control addresses the root cause, not the symptom.
Both correction and prevention have named owners and deadlines.
Ticket history for the last 30 days was checked for recurrence.

Common mistakes

Mistake: Treating the symptom as the root cause. Consequence: You correct the blocked orders but the missing validation that allowed bad data remains, so the defect recurs.
Mistake: Stopping at the immediate cause. Consequence: You fix the failed IDoc but the sender system keeps sending invalid data because the root cause is an upstream schema mismatch.
Mistake: Not checking for recurrence. Consequence: You treat a systemic issue as a one-off and miss the opportunity to justify a permanent fix.
Mistake: Proposing prevention that is too expensive or complex to implement. Consequence: The prevention is never approved, and the defect recurs because no simpler control was proposed.
Mistake: Failing to name owners and deadlines. Consequence: The RCA sits in a document repository and nothing changes.

Agent instructions

When using this skill, an AI agent must:

Never accept the user's first description as the root cause. Ask "why" repeatedly until a process, configuration, or governance gap is identified.
Build a timeline before proposing theories. Use timestamps from logs, change documents, and tickets. Do not guess at chronology.
Separate three layers: symptom (what was seen), immediate cause (what directly failed), and root cause (why the failure was possible). Label each layer explicitly.
Check for recurrence. Ask the user for ticket history or similar incidents in the last 30–90 days. If recurrence exists, flag it and reference the Recurring Ticket Pattern Analysis skill.
Quantify impact. Ask for numbers: records affected, orders blocked, hours lost, revenue at risk. If numbers are unavailable, state the estimation method.
Produce a Root Cause Analysis Note. Use the template above. Fill every field. If data is missing, state what is missing and who can provide it.
Link to Atlas diagnostics for technical depth. If the root cause involves IDocs, RFCs, background jobs, or master data, reference the relevant Atlas page for detailed technical steps — but do not replace the RCA with a technical procedure.
Avoid generic prevention. "Better training" is not a prevention control. "Mandatory field validation in MDG workflow step 3" is.

Related skills

Incident Triage — Use before RCA to classify and contain the incident.
Recurring Ticket Pattern Analysis — Use when the same symptom appears multiple times.
Change Impact Analysis — Use when the root cause traces back to a recent change.
Data Quality Root Cause — Use when the defect is a data quality failure.

Related Atlas pages

SAP IDoc Status Diagnostics — Technical depth on IDoc failures.
SAP qRFC/tRFC Diagnostics — Queue and RFC failure patterns.
SAP Background Job Diagnostics — Job failure analysis.
SAP Master Data Duplicate Diagnostics — When duplicates are the symptom.
SAP Incompletion Procedure Diagnostics — When missing fields cause blocks.

Verification status and limitations

This skill is a public working interpretation of root cause analysis practice. It is not official SAP, ITIL, or Six Sigma documentation. The "5 Whys" method is a simplification; complex failures may require fault tree analysis or Ishikawa diagrams. The skill focuses on operational incidents rather than strategic or organizational failures. Some root causes may require access to proprietary system logs or vendor documentation that is not available in all landscapes.