Skill Hub — Work Documentation and Handover

Process Documentation Working Skill

Document how a business process actually works, who owns each step, what systems are involved, and where it breaks.

What this skill is for

Most business processes exist partially in people's heads, partially in system configurations, and partially in outdated wiki pages. This skill produces a Process Document: a structured description of how a process actually operates, not how it is supposed to operate. The document captures the sequence of steps, the systems and transactions used, the owners and approvers, the data inputs and outputs, and the known failure points. The output is designed to help new team members, auditors, and AI agents understand the process without relying on tribal knowledge. It is also the foundation for process improvement, automation, and training.

When to use this skill

A process exists only in the heads of a few people and the team needs to capture it before they leave or go on vacation.
An audit or compliance review requires documented process evidence showing who does what and where.
A process is being considered for automation or improvement and the team needs a baseline of current state.
A new team member needs to understand a process quickly without shadowing someone for two weeks.
A process is generating repeated errors or incidents and the team needs to map the breakpoints to fix them.
An AI agent needs to understand a process to suggest improvements or generate automation logic.

Real work situations

SAP order-to-cash: shadowing the process to find gaps

A new SAP functional consultant needs to understand how the order-to-cash process works in a specific S/4HANA system. The process is not standard: custom credit checks, a modified delivery block logic, and a manual step where a sales admin updates a Z-table. The existing documentation is a three-year-old PowerPoint that does not mention the Z-table. The consultant uses this skill to document the actual process: sales order creation in VA01, credit check via custom transaction ZCREDIT, delivery block removal in VL02N, manual Z-table update by the sales admin, and goods issue in VL02N. Without this documentation, the consultant misses the Z-table step and creates orders that fail downstream.

Master data governance: mapping the vendor creation process

The vendor master data creation process involves three departments: procurement requests the vendor, finance validates the tax number, and master data maintains the record in SAP. The process breaks when finance takes five days to validate and procurement creates duplicate records because they do not know the vendor is already in process. The team documents the actual process: request form in the portal, validation queue in a shared mailbox, manual entry in SAP via FK01, and notification to procurement. The documentation reveals the bottleneck and the duplication trigger. The team then redesigns the process with a status tracker.

Integration operations: documenting the IDoc error handling flow

An integration team handles failed IDocs between SAP and a warehouse system. The process is reactive: a monitoring alert fires, an operator checks SM58, opens the IDoc in WE02, checks the mapping in SAP PI, and either reprocesses or forwards to the functional team. The process is not documented. When the senior operator is on vacation, a junior operator reprocesses an IDoc with a mapping error, causing duplicate warehouse movements. The team uses this skill to document the actual flow with decision points: if status is 51, check WE02 first; if error is mapping, forward to PI team; if error is data, forward to functional team; never reprocess without checking the error category.

Inputs required

Subject matter expert or process owner who can walk through the actual steps.
System documentation showing transactions, tables, programs, and configurations involved.
Sample documents or screenshots showing the process in action (optional but helpful).
Incident or ticket history showing where the process breaks.
Organizational chart or role definitions showing who owns each step.
Existing process documentation, even if outdated, to understand what has changed.
Data flow diagrams or integration maps if the process crosses systems.

Questions to ask

What triggers the process? What is the first event or input?
What is the sequence of steps? What happens first, second, third?
Who performs each step? What is their role, and what system access do they need?
What systems, transactions, or programs are used at each step?
What data enters the process, what data is transformed, and what data leaves the process?
Where does the process break? What are the top three failure points?
What are the workarounds? When the process breaks, what do people actually do?
What are the breakpoints between manual and automated steps?
What are the compliance, audit, or SLA requirements that constrain the process?

Working method

Identify the process scope. Define the start and end of the process. Name the process and the version of the system it runs on. State what is in scope and what is out of scope.
Interview the process owner. Ask the person who performs the process to walk through it step by step. Do not accept summary descriptions. Ask for transaction codes, screen names, and field names.
Shadow the process if possible. Watch the process owner perform the steps. Record the actual sequence, not the theoretical one. Note deviations, workarounds, and shortcuts.
Map the steps. Create a numbered list of steps. For each step: name the action, identify the actor, list the system or transaction, describe the input, describe the output, and note the decision logic.
Identify breakpoints. Mark where the process fails, where manual intervention is required, where data quality issues arise, and where handoffs between teams occur.
Document workarounds. For each known failure point, document the workaround that people actually use. Include when the workaround is valid and when it is dangerous.
Validate with the process owner. Walk through the document with the person who performs the process. Correct errors, add missing steps, and clarify ambiguous descriptions.
Validate with a new person. Ask someone who does not know the process to follow the document. If they cannot, the document is incomplete.
Write the Process Document. Use the template below. Include process summary, step list, system map, owner matrix, breakpoint analysis, and known workarounds.
Publish and maintain. Store the document in the agreed location. Set a review date. Update the document when the process changes, not when someone complains that it is wrong.

Decision rules

If the process owner describes the ideal process, ask for the actual process. Document what happens, not what should happen.
If a step has no system transaction, document it as a manual step and note the tool or format used.
If a breakpoint is caused by a known system limitation, document the limitation and the workaround. Do not pretend the system works perfectly.
If a process crosses multiple systems, document each system handoff as a separate step with its own owner and validation.
If a process has multiple variants, document the most common variant first and list exceptions separately.
If a step is performed by a different person depending on the day or shift, document the variability and the escalation rule.

Deliverables

Process Document — Structured description of the actual process, including steps, owners, systems, breakpoints, and workarounds. See template below.
Process Owner Matrix — Table showing each step, the responsible role, and the escalation contact.
Breakpoint Analysis — List of known failure points, their frequency, impact, and current workarounds.

Templates

Process Document (compact)

---
artifact: Process Document
id: PROC-<area>-<number>
process_name: <Name of process>
scope_start: <Trigger event>
scope_end: <End state>
system: <Primary system, e.g., S/4HANA>
version: <System version or release&gt
document_date: YYYY-MM-DD
owner: <Process owner name and role&gt
doc_author: <Document author&gt
doc_reviewer: <Document reviewer&gt
doc_status: draft | reviewed | approved
---

## Process Summary
- Trigger: <What starts the process>
- End state: <What successful completion looks like>
- Frequency: <How often the process runs>
- SLA: <Time or quality target>
- Compliance requirement: <Audit or regulatory requirement>

## Process Steps
| Step | Action | Actor | System / Transaction | Input | Output | Decision Rule |
|------|--------|-------|---------------------|-------|--------|---------------|
| 1 | <Action> | <Role> | <T-code or program> | <Data or document> | <Result> | <If X then Y> |
| 2 | <Action> | <Role> | <T-code or program> | <Data or document> | <Result> | <If X then Y> |

## System and Data Flow
- <Describe data movement between systems, tables, and interfaces>

## Owner Matrix
| Step | Primary Owner | Backup Owner | Escalation Contact |
|------|---------------|--------------|---------------------|
| 1 | <Name> | <Name> | <Name> |

## Breakpoints and Workarounds
| Breakpoint | Symptom | Frequency | Workaround | Risk of Workaround |
|------------|---------|-----------|------------|-------------------|
| <Where it breaks> | <What the user sees> | <How often> | <What people do> | <What could go wrong> |

## Related Documents
- <Link to decision log, runbook, or knowledge article>

Quality checklist

The process document describes the actual process, not the ideal process.
Every step has a specific action, actor, system, input, and output.
Decision rules are documented for steps that branch based on conditions.
Known breakpoints and workarounds are documented honestly.
A person who does not know the process can follow the document and perform the steps.
The process owner has reviewed and approved the document.
System transactions, tables, and programs are named explicitly.
The document is stored in a findable location with a review date.

Common mistakes

Documenting the ideal process instead of the actual process. Consequence: new team members follow the document, hit a real-world deviation, and do not know what to do. The document becomes unreliable.
Using generic step descriptions without transaction codes or screen names. Consequence: the reader cannot locate the exact screen or program. "Go to the material screen" is not enough; "MM03, display material, basic data 1 tab" is.
Omitting workarounds. Consequence: when the process breaks, people invent ad-hoc fixes that are not validated, leading to data quality issues or compliance violations.
Documenting a process without validating it with a new person. Consequence: the document contains gaps that the expert forgot to mention. The new person discovers them the hard way.
Writing the document once and never updating it. Consequence: the document becomes outdated within months. People stop trusting it and revert to asking the expert directly.

Weak output vs Strong output

Weak output

A one-page wiki entry: "The order-to-cash process starts with a sales order. The order is checked for credit. Then it is delivered. Then it is billed. Then it is paid. The sales team handles orders. The finance team handles billing. If there are issues, contact the functional lead." No transaction codes, no step numbers, no decision rules, no breakpoints, no workarounds, no system names. The reader learns nothing useful about how to actually perform the process.

Why it fails: The document is so generic that it applies to any company. It does not help a new person perform the process. It does not reveal breakpoints. It cannot be used for automation or improvement.

Strong output

---
artifact: Process Document
id: PROC-O2C-2026-001
process_name: S/4HANA Order-to-Cash with Custom Credit Check
scope_start: Customer purchase order received
scope_end: Payment posted in FI
system: S/4HANA 2023
version: 2023 FPS01
document_date: 2026-06-10
owner: S. Mueller, Sales Process Lead
doc_author: M. Chen
doc_reviewer: S. Mueller
doc_status: approved
---

## Process Summary
- Trigger: Customer purchase order received via EDI or portal
- End state: Payment posted in FI, customer account cleared
- Frequency: 200–400 orders per day
- SLA: Order to delivery within 48 hours; invoice within 24 hours of delivery
- Compliance requirement: All credit checks must be logged in ZCREDIT_LOG for audit

## Process Steps
| Step | Action | Actor | System / Transaction | Input | Output | Decision Rule |
|------|--------|-------|---------------------|-------|--------|---------------|
| 1 | Create sales order | Sales Admin | VA01 | Purchase order | Sales order number | If customer is new, trigger credit check step 2a |
| 2 | Run custom credit check | Sales Admin | ZCREDIT | Customer number, order value | Credit status: green / yellow / red | If red, block order and notify finance (step 2b) |
| 3 | Remove delivery block | Warehouse Planner | VL02N | Sales order, stock availability | Delivery document | If stock is insufficient, create backorder (step 3a) |
| 4 | Perform goods issue | Warehouse Clerk | VL02N | Delivery document, pick list | Goods issue document, inventory update | If batch determination fails, use manual batch (step 4a) |
| 5 | Create invoice | Billing Clerk | VF01 | Delivery document, pricing data | Invoice document | If pricing is incomplete, trigger incompletion log (step 5a) |
| 6 | Post payment | Finance Clerk | F-28 | Bank statement, invoice | Payment document, cleared item | If payment is partial, create dunning note (step 6a) |

## System and Data Flow
- Purchase order arrives via EDI -> IDoc processed in WE02 -> Sales order created in VA01 -> Credit check writes to ZCREDIT_LOG -> Delivery created in VL02N -> Goods issue updates MARD -> Invoice created in VF01 -> Accounting document in BKPF -> Payment posted in F-28.

## Breakpoints and Workarounds
| Breakpoint | Symptom | Frequency | Workaround | Risk of Workaround |
|------------|---------|-----------|------------|-------------------|
| ZCREDIT times out for high-volume customers | Credit status remains blank | 2–3 times per week | Sales admin runs ZCREDIT manually after 5 minutes | Order may ship without credit check; audit log missing |
| Batch determination fails for new materials | "No batch found" error | Daily for new SKUs | Warehouse clerk manually selects batch in MSC1N | Wrong batch selected; expiry risk if not verified |
| Pricing incomplete for promotional materials | Incompletion log blocks billing | Weekly during promotions | Billing clerk manually updates pricing in VK11 | Incorrect pricing posted; margin impact |

## Related Documents
- Decision Log: DS-O2C-2026-001 (custom credit check rationale)
- Runbook: RB-ZCREDIT-001 (manual credit check procedure)
- Knowledge Article: KA-001 (batch determination troubleshooting)

Agent instructions

AI Prompt Pattern

Role: Process documentation writer for an SAP enterprise environment.

Context: You have interviewed a process owner and observed a business process. You need to produce a Process Document that a new person can follow without additional explanation.

Task: Create a structured Process Document using the template below. Include actual steps, systems, owners, breakpoints, and workarounds. Document the actual process, not the ideal one.

Output format: Structured Process Document in Markdown with tables for steps, owners, breakpoints, and system flow.

Never document the ideal process if the actual process differs. The value of process documentation is in capturing reality, not theory.
Always include transaction codes, program names, and table names. "Go to the material screen" is not enough. Use exact names: MM03, basic data 1.
Always document workarounds and breakpoints. If people use a workaround, document it with its conditions and risks. Do not hide it.
Validate the document with the process owner and a new person. If the new person cannot follow it, the document is incomplete.
Do not invent steps, owners, or systems. If you are unsure, state "Unknown" and flag for review.
Link to Atlas diagnostics when the process touches SAP areas with documented failure modes. For example, order-to-cash processes should reference SAP Incompletion Procedure Diagnostics.
Update the document when the process changes. A process document that is outdated is worse than no document because it creates false confidence.

Related skills

Runbook Writing Working Skill — Use to produce the step-by-step operational procedures for specific breakpoints in the process.
Knowledge Article Writing Working Skill — Use to document known workarounds and troubleshooting steps as self-service articles.
Process Analysis Working Skill — Use to analyze and redesign the process before documenting it.
Handover Note Writing Working Skill — Use to package process documentation into a handover package.

Related Atlas pages

Order-to-Cash — Conceptual context for O2C process documentation.
SAP Incompletion Procedure Diagnostics — Diagnostic context for incompletion breakpoints in sales processes.
AI-Ready Process Documentation — Guidance on structuring process documentation for AI consumption.

Verification status and limitations

This skill is a public working interpretation of process documentation practices. It is not official BPMN, SAP, or ITIL documentation. It focuses on capturing actual processes in enterprise and SAP environments where tribal knowledge is common and process drift is frequent.

Known limitations: the skill does not cover BPMN modeling, flowchart creation, or formal process mining. It produces text-based process documents suitable for wikis and knowledge bases. It assumes access to a process owner who can describe the actual process. It does not replace formal process audit or process redesign activities; it documents the current state as input for those activities.