Skill Hub — SAP AMS / Operations

Incident Triage

Classify incidents fast, contain business impact, and route to the right owner without wasting time on premature diagnosis.

What this skill is for

This skill helps you decide what an incident is, who should handle it, and what to do in the first 15 minutes. It stops you from debugging a sales order block when the real problem is a failed IDoc that never created the customer. It stops you from assigning a master data issue to the ABAP team when the data steward is the actual owner.

When to use this skill

A ticket arrives with a vague subject like "system not working" and no error message.
Multiple users report the same symptom through different channels (ticket, chat, email).
An interface failure is blocking downstream processes and business users are escalating.
A background job failed and you need to decide if this is a one-off or a systemic issue.
A production change went live and unexpected errors are appearing in multiple areas.

Real work situations

Example 1: Sales orders stuck in delivery block

A business user reports that 40 sales orders created this morning are blocked for delivery. The first instinct is to check delivery block reasons in VBAK/VBAP. Triage reveals that all 40 orders share the same newly created ship-to party. The ship-to party was replicated from MDG with an incomplete address. The right owner is the BP/MDG data steward, not the SD functional team.

Example 2: IDoc status 51 after a weekend transport

On Monday morning, 200 IDocs are in status 51 in WE02. The ticket says "interface broken." Triage shows the error segment contains a new mandatory field that was added in Saturday's transport. The segment version changed but the sender system was not updated. The owner is the integration team, and the immediate containment is to roll back the segment change or coordinate a sender update.

Example 3: Background job cancellation with no obvious error

A periodic billing job cancelled overnight. The ticket says "billing did not run." Triage checks SM37, finds the job log points to a table space issue, and confirms with the Basis team that a database maintenance window ran longer than expected. The owner is Basis, the containment is a job reschedule, and the follow-up is to adjust maintenance windows or job timing.

Example 4: Multiple users locked out after password policy change

Helpdesk reports 15 users cannot log in. Triage checks SU01 and finds a password policy change was applied to the wrong user group. The owner is security administration, the containment is an emergency policy revert for the affected group, and the correction is a review of policy assignment rules.

Inputs required

The original ticket or alert with timestamp, reporter, and initial description.
System landscape map or at least a list of systems in the scope (DEV, QAS, PRD, MDG, PI/PO/CPI).
Interface ownership matrix or a list of known interfaces and their owners.
Monitoring tool access: SM37, SM58, SMQ1/SMQ2, WE02/WE05, SLG1, ST22, DBACOCKPIT.
Contact list for functional teams, Basis, security, data stewards, and integration.
Recent change log: transports, configuration changes, master data loads, password policy updates.

Questions to ask

What exactly stopped working, and what was the last successful execution or transaction?
How many users, records, orders, or IDocs are affected? Is the number growing?
Did anything change in the system in the last 24–48 hours: transport, config, data load, patch?
Is this a known error message or a new one? Search the ticket history for the same message.
Which business process is blocked, and what is the financial or operational cost per hour?
Does the symptom match a single system, a single interface, or a single data object, or is it scattered?
Who owns the failing component: functional, Basis, integration, security, or data stewardship?

Working method

Read the ticket once. Do not start debugging. Extract: reporter, timestamp, system, transaction, error text, number of affected items, business process.
Classify by business impact.
- Critical: revenue-impacting process stopped for multiple users.
- High: single user or small group blocked on a time-sensitive process.
- Medium: workaround exists, no immediate business deadline.
- Low: cosmetic, reporting lag, or single non-urgent request.
Classify by technical domain. Map the symptom to one of: master data, configuration, custom code, integration, infrastructure, security, user error, or unknown.
Check for recent changes. Look at transport logs, change documents, transport of copies, and scheduled jobs in the last 48 hours. Correlation is not causation, but it is the fastest filter.
Contain the impact.
- If data is being created incorrectly, stop the creation process.
- If an interface is failing, pause or queue the messages.
- If a job is failing, disable the schedule until the cause is known.
- If users are locked out, apply an emergency workaround and document it.
Route to the right owner. Use the interface ownership matrix and team contact list. Do not assign to "AMS team" as a whole. Assign to a named functional area with a specific question.
Document the triage decision. Record classification, containment action, owner assignment, and what you checked. This becomes the input for root cause analysis if needed.
Set expectations. Tell the reporter: what you found, what you did, who is working on it, and when they will hear next.

Decision rules

If the ticket has no error message and no screenshot, ask for both before assigning to a technical team.
If the symptom matches a recent transport or config change, assign to the team that performed the change first.
If multiple users are affected and the symptom is identical, treat as systemic and escalate to the relevant functional lead.
If the symptom is scattered across modules with no common data object, check infrastructure and integration first.
If an interface is involved, check the IDoc or message status before checking application logic.
If a background job failed, check SM37 for the job log and ST22 for dumps before asking the functional team.
If master data is involved, verify the data object in the source system before assuming SAP is misconfigured.
If containment requires a system change, get approval from the change manager or document it as an emergency change.

Deliverables

Triage Record — A short document with classification, impact, containment, owner, and next steps. Use the template below.
Owner Assignment Note — Who was assigned and why, with the specific question they need to answer.
Containment Log — What was stopped, paused, or worked around, and when it can be reversed.

Templates

Incident Triage Record

---
artifact: Incident Triage Record
id: TRI-001
date: YYYY-MM-DD
reporter: Name / Team
---

## Symptom


## System / Transaction


## Business impact


## Number affected


## Recent changes (last 48h)


## Technical domain


## Containment action


## Owner assigned


## Next update


## Related tickets

Quality checklist

The triage record names the exact system and transaction where the symptom was observed.
Business impact is classified and quantified (users affected, orders blocked, cost per hour).
At least one containment action was taken or a clear reason is given why none was needed.
The owner assignment includes a named team or person, not a generic queue.
Recent changes in the last 48 hours were checked and documented.
The reporter received an update with expected next communication time.
No premature technical diagnosis was made before classification and containment.

Common mistakes

Mistake: Starting to debug before classifying. Consequence: You spend two hours tracing ABAP code when the issue is a missing address in a replicated business partner.
Mistake: Assigning to the wrong team because the symptom looks technical. Consequence: The ticket bounces between teams for days while the business user escalates.
Mistake: Failing to contain impact while investigating. Consequence: More incorrect data is created, more IDocs fail, and the cleanup effort multiplies.
Mistake: Not documenting the triage decision. Consequence: The next shift or the root cause analyst has to start from scratch.
Mistake: Treating every incident as unique. Consequence: You miss patterns that would reveal a systemic failure and a permanent fix.

Agent instructions

When using this skill, an AI agent must:

Gather context first. Ask for the ticket text, system, transaction, error message, number of affected items, and timestamp before proposing any diagnosis.
Separate facts from assumptions. State clearly what is known from the ticket and what is inferred. Label every inference as an assumption.
Do not debug prematurely. The agent's job is classification, containment, and routing — not root cause analysis. If the user asks for a technical fix during triage, redirect to the Root Cause Analysis skill.
Produce a Triage Record. Use the template above. Fill every field that has data. Leave unknown fields blank with a note about what is missing.
Check for patterns. Before declaring an incident unique, ask whether similar tickets exist in the last 30 days. If yes, flag for Recurring Ticket Pattern Analysis.
Link to Atlas diagnostics when relevant. If the symptom involves IDocs, RFCs, background jobs, or master data, reference the relevant Atlas diagnostic page for deeper technical context — but do not perform that diagnosis during triage.
Avoid generic language. Do not write "the system is experiencing issues." Write "40 sales orders are blocked for delivery due to incomplete ship-to party address."

Related skills

Root Cause Analysis — Use after triage when the incident needs permanent resolution.
Recurring Ticket Pattern Analysis — Use when the same symptom appears multiple times.
Operational Knowledge Capture — Use to record the triage method and outcome for future reuse.
Integration Error Handling — Use when triage reveals an interface or IDoc failure.

Related Atlas pages

SAP IDoc Status Diagnostics — Deep dive on IDoc status codes and failure patterns.
SAP Background Job Diagnostics — How to diagnose job failures and cancellations.
SAP Integration Error Handling Diagnostics — Error handling patterns for interfaces.
SAP Business Partner Replication Diagnostics — When BP replication is the suspected cause.
SAP AMS Operating Model — How triage fits into the broader AMS support structure.

Verification status and limitations

This skill is a public working interpretation of SAP AMS operational practice. It is not official SAP or ITIL documentation. The classification criteria (Critical/High/Medium/Low) should be aligned with your organization's specific SLA definitions. The monitoring transactions listed (SM37, WE02, etc.) are common but may vary by SAP release and landscape. Always validate tool availability and naming conventions against your system.