Skill Hub — SAP AMS / Operations

Operational Knowledge Capture

Turn firefighting into reusable knowledge: capture what was done, why it worked, and when it applies.

What this skill is for

This skill helps you document operational knowledge in a form that the next person — or an AI agent — can actually use. It captures not just the solution but the context: what was happening, what almost went wrong, why the fix worked, and when the same fix applies again. The output is an Operational Knowledge Capture Note that reduces repeat incidents and onboarding time.

When to use this skill

An incident was resolved after significant troubleshooting and the method should be reusable.
A workaround was discovered for a known system limitation and other teams need to know it.
A complex configuration or custom code behavior was decoded and the explanation should survive the person who found it.
A new team member is joining and needs to understand how the landscape actually works, not just how it was designed.
An AI agent or automation tool needs structured operational knowledge to handle routine incidents.
A runbook or procedure was updated during an emergency and the update needs to be formalized.

Real work situations

Example 1: The "magic" transaction sequence for stuck IDocs

A consultant discovers that IDocs in status 64 can be cleared with a specific sequence of BD87, WE19, and a custom program — but only when the error is a specific partner profile mismatch. The knowledge capture records the exact sequence, the error pattern that justifies it, the cases where it does not apply (status 51 with syntax errors), and the verification step. Six months later, a new consultant uses the note to resolve the same issue in 10 minutes instead of 2 hours.

Example 2: The weekend restart procedure that always misses one step

After every planned restart, the qRFC queues fail to process because one RFC destination is not verified before queue release. The knowledge capture updates the runbook with the missing step, explains why the destination matters (it handles CRM replication), and adds a verification command. The next restart follows the updated runbook and avoids the queue buildup.

Example 3: The customer-specific pricing condition that breaks every quarter

A pricing condition for a specific customer group is maintained manually and expires every quarter because the validity period is not extended. The knowledge capture documents the condition type, the customer group, the transaction to extend it, the business owner who must approve the extension, and the report that detects the upcoming expiration. The next quarter, the report triggers a proactive ticket instead of a reactive emergency.

Example 4: The MDG change request activation that fails for one specific entity type

A data steward finds that MDG change request activation fails for supplier entities when a specific industry sector is selected, due to a missing mapping in the CVI synchronization. The knowledge capture records the entity type, the industry sector, the error message, the workaround (manual CVI sync after activation), and the long-term fix (update the mapping table). Future stewards avoid the failure and know when the workaround is still needed.

Inputs required

The incident ticket or triage record with full symptom, resolution, and timeline.
The exact transactions, programs, commands, or configuration paths used to resolve the issue.
The system landscape where the resolution was applied: client, system, module.
The business context: which process, which user group, which time window.
What was tried that did not work — the failed attempts are as valuable as the success.
The stakeholder who owns the process or data and can verify the knowledge is correct.
Any related documentation, runbooks, or wiki pages that should be updated or linked.

Questions to ask

What was the exact symptom, and what was the last successful state before the failure?
What specific steps were taken to resolve the issue, in what order, and in which system?
Why did those steps work? What was the underlying mechanism or system behavior?
What was tried that did not work, and why did it fail?
Under what conditions does this knowledge apply, and when does it not apply?
What would have happened if the resolution had not been applied, or had been applied incorrectly?
Who owns the process or system where this knowledge applies, and who can verify it is still valid?
How will someone know this knowledge exists when they encounter the same symptom?
When should this knowledge be reviewed or retired?

Working method

Capture immediately after resolution. Do not wait. Memory decays fast. Schedule 15 minutes after every non-trivial incident to document.
Record the situation. What was happening? Which system, which process, which users, which time window? Include urgency and business impact.
Record what was done. Step by step. Include transaction codes, program names, table names, configuration paths, and exact values. Assume the reader has moderate SAP knowledge but no context about this specific landscape.
Record why it worked. Explain the system behavior, data flow, or configuration logic that made the fix effective. This is the difference between a runbook and a cheat sheet.
Record what almost went wrong. Document failed attempts, wrong paths, assumptions that were false, and near misses. This prevents the next person from repeating the same dead ends.
Define preconditions. When does this knowledge apply? Which system version, which client, which module, which data state? Be explicit about exclusions.
Define limitations. What does this procedure not cover? What are the edge cases where it fails or needs escalation?
Define verification. How does the next person confirm the procedure is still valid? Which transaction, which report, which check?
Name an owner. Who maintains this knowledge? Who can answer questions if the note is unclear?
Set a review date. Operational knowledge rots. Systems change. Set a review date based on system stability: 3 months for volatile areas, 6 months for stable ones.
Make it discoverable. Store the note where people look for help: ticket system, wiki, knowledge base, or runbook repository. Tag it with symptom keywords, error messages, and transaction codes.
Link related knowledge. Connect to other capture notes, runbooks, Atlas pages, or ticket histories that cover adjacent topics.

Decision rules

If the resolution took more than 30 minutes to find, it must be captured.
If the same symptom has occurred twice, capture it and link both tickets to the note.
If the fix involves a workaround for a known system limitation, capture it and flag it as temporary.
If the fix requires access to a restricted system or elevated authorization, document the approval process.
If the knowledge applies to only one client or system, state that explicitly. Do not generalize without verification.
If a runbook already exists for this topic, update the runbook rather than creating a separate note.
If the root cause is a bug or defect that will be fixed in a patch, set the review date to the patch release date and plan to retire the note.
If the knowledge involves a custom program or enhancement, include the program name and version.

Deliverables

Operational Knowledge Capture Note — The primary artifact. See the template below or the Artifact Templates page.
Updated Runbook or Wiki Page — If the knowledge fits an existing procedure, update it rather than creating a new document.
Knowledge Link in Ticket System — A comment or link in the resolved ticket pointing to the capture note for future reference.
Stakeholder Notification — A brief message to the business owner or data steward informing them that operational knowledge about their process has been documented.

Templates

Operational Knowledge Capture Note (compact)

---
artifact: Operational Knowledge Capture Note
id: OKC-001
date: YYYY-MM-DD
author: Name
topic: Incident | Procedure | Workaround | Decision
---

## Situation


## Symptom


## What was done


## Why it worked


## What was tried and failed


## What almost went wrong


## Preconditions


## Limitations


## Verification


## Owner


## Review date


## Related knowledge

Quality checklist

The note was written within 24 hours of incident resolution.
The symptom is described with exact error text, transaction, and at least one example record ID.
The resolution steps are numbered and include exact transaction codes or program names.
The causal explanation (why it worked) is present and distinct from the step description.
At least one failed attempt or wrong path is documented.
Preconditions and limitations are stated explicitly.
A verification method is defined so the next person can confirm the note is still valid.
An owner is named and a review date is set.
The note is stored in a discoverable location with relevant tags or keywords.
Related knowledge is linked: other notes, runbooks, tickets, or Atlas pages.

Common mistakes

Mistake: Documenting only the solution, not the context. Consequence: The next person applies the fix to the wrong situation because they do not know the preconditions.
Mistake: Writing knowledge in private notes or local files. Consequence: When the author leaves, the knowledge leaves with them.
Mistake: Not documenting failed attempts. Consequence: The next person repeats the same two hours of dead ends.
Mistake: Generalizing from one incident without verification. Consequence: The note claims to apply to all clients but only works in one, causing confusion and wrong fixes.
Mistake: Never reviewing or retiring old knowledge. Consequence: A procedure that worked in ECC 6.0 is applied to S/4HANA and fails because the transaction no longer exists.

Agent instructions

When using this skill, an AI agent must:

Capture immediately. Do not wait for a formal request. After resolving or assisting with a non-trivial incident, produce a capture note.
Ask for exact steps. If the user describes a resolution vaguely, ask for transaction codes, program names, table names, and exact values.
Demand the "why." If the user only says "we ran program X and it worked," ask why program X fixed the issue. The causal explanation is mandatory.
Document failures. Ask what was tried that did not work. Include at least one failed attempt in the note.
Be explicit about scope. State exactly which system, client, module, and version the knowledge applies to. Do not generalize.
Produce an Operational Knowledge Capture Note. Use the template above. Fill every field. If data is missing, state what is missing.
Link to related knowledge. Reference other capture notes, runbooks, Atlas pages, or ticket histories. Build a network, not isolated documents.
Set a review date. Propose a review date based on system volatility. Flag notes that may become obsolete due to planned upgrades or patches.
Make it discoverable. Suggest tags, keywords, and storage location. Include the exact error message text so search engines and ticket systems can match it.
Avoid generic language. Do not write "run the standard procedure." Write "Run program Z_CUSTOMER_FIX in client 100 with parameter P_DATE = today."

Related skills

Incident Triage — Use to classify and contain the incident before knowledge capture.
Root Cause Analysis — Use when the incident needs deep analysis before knowledge can be captured.
Recurring Ticket Pattern Analysis — Use when the same symptom appears repeatedly and needs systemic documentation.
Stakeholder Analysis — Use to identify who owns the knowledge and who needs to know it.

Related Atlas pages

Operational Memory for SAP AMS — How operational knowledge fits into the AMS operating model.
SAP AMS Operating Model — The broader context for knowledge capture in AMS.
AI-Ready Process Documentation — How to structure knowledge so AI agents can use it.
AI Agent for SAP Support — How AI agents consume operational knowledge.

Verification status and limitations

This skill is a public working interpretation of knowledge management practice. It is not official SAP or ITIL documentation. The effectiveness of knowledge capture depends heavily on organizational culture: if there is no shared repository or no time allocated for documentation, the skill cannot overcome those barriers. The skill assumes the user has access to a ticket system, wiki, or knowledge base. Some operational knowledge involves proprietary or client-specific procedures that cannot be shared in public repositories.