Lesson 1 of 5
A troubleshooting method
9 min
Listen to this lesson
Most SAP problems are solved by people who follow a method, not by people who know the most transaction codes. Under time pressure, during a test cycle or a cutover weekend, the temptation is to jump to the first plausible cause and start changing things. This lesson gives you a four-step loop that keeps you honest: observe, hypothesize, test, confirm.
- ObserveCollect facts: exact symptom, system and client, user, time, transaction or app, what changed recently, how often it happens
- HypothesizeList possible causes and rank them by likelihood and by how cheap they are to check
- TestCheck the most likely or cheapest hypothesis with a tool: dump, log, lock list, trace, comparison with a working case
- ConfirmFix, then reproduce the original scenario and show the symptom is gone; record cause and evidence
Observe: describe and isolate
SAP's own training on troubleshooting starts the same way: determine where, when and in what context the error occurs, because a vague report is not enough. "Billing does not work" is a complaint. "Since Tuesday's transport import, creating an invoice in CMQ client 100 for sales area 1710 / 10 / 00 ends with a runtime error for every user, while sales area 1710 / 10 / 00 orders created before Tuesday bill correctly" is a problem statement. Isolation is half the diagnosis: if it fails for one user but not another, or on one front end but not the other, you have already narrowed the field.
| Question | Why it matters |
|---|---|
| Which system, client and front end? | Client 100 in CMQ is not client 100 in CMD; SAP GUI and Fiori take different paths |
| Which user, and does it fail for others? | User-specific failures point to authorizations, personalization or user data |
| When did it start, and what changed then? | Transports, refreshes, SAP Notes and job changes are the usual suspects |
| Always, sometimes, or once? | Intermittent failures suggest load, locks, timing or data-dependent logic |
| Is there a working comparison case? | Comparing a good and a bad case is the fastest way to find the difference |
Observation questions to answer before forming a hypothesis.
Hypothesize and test
Write hypotheses down, even informally, and attach a check to each one. Start with checks that are cheap and decisive: looking at ST22 for a dump takes one minute; tracing a whole process takes an hour. SAP's procedure also recommends searching SAP Notes with keywords from the log or dump, and comparing an error-free process with the failing one. A hypothesis that the checks do not support is crossed out, not kept "just in case".
Confirm and record
A problem is solved when you can reproduce the original scenario and the symptom is gone, not when the error message changes. Record the root cause, the evidence and the fix. In a test program, that record is the defect's resolution note; in operations it feeds the problem management process. If you cannot solve it, escalate with the evidence you collected: SAP Support incidents move much faster with dumps, log extracts and traces attached.
- Can you reproduce the problem on demand?Yes → trace and compare while reproducing · No → collect data at each occurrence (time, user, dump, log) until a pattern appears
- Does it fail for everyone?Yes → suspect code, configuration or environment · No → compare the failing and working users or data
- Did it start after a known change?Yes → test that change first · No → check for gradual causes such as data growth or full logs
What would you do?
A tester reports "VA01 is broken in CMQ" at 09:15 and Kenji is ready to debug the sales order code. What should Sam suggest first?
- Observe, hypothesize, test, confirm: and write each step down.
- Isolate: system, client, front end, user, time, frequency and what changed.
- Check cheap, decisive hypotheses first; compare working and failing cases.
- Confirm by reproducing the original scenario; record root cause and evidence.
Check your understanding · not graded
Lesson check
1. What is the first step of the troubleshooting loop?
2. Which observation suggests an authorization or user-data cause?
3. When is a problem confirmed as solved?
4. What makes an SAP Support incident move faster?