Skill Hub — Business Analysis

Process Analysis Working Skill

Map how work actually happens, where it breaks, and who owns each step — so improvements fix reality, not documentation.

What this skill is for

Process documentation in most organizations describes an ideal state that no one follows. This skill documents the real process: the workarounds, the manual fixes, the system hops, the approval delays, and the exception paths. The output is a Process Analysis Note that shows what to fix, what to automate, and what to leave alone. It prevents the common failure where a redesign optimizes a process that does not exist.

When to use this skill

A project needs a baseline "as-is" process before designing the "to-be" state.
An incident recurs and the post-mortem shows the process has undocumented exception paths.
An automation opportunity is identified but no one knows the full sequence of manual steps.
A team is being handed over to another team and operational knowledge is scattered.
A compliance audit asks for process documentation and the existing diagrams are three years old.
An integration failure spans multiple process steps and each team only knows their own piece.

Real work situations

Order-to-cash: orders block at credit check

A sales team reports that orders block unpredictably at credit check. The documented process says credit limit is checked at order creation. The real process shows: some customers have special agreements bypassing credit check, the credit controller updates limits weekly in a spreadsheet before entering them in SAP, and rush orders are created by a different team using a different transaction. Without mapping the real process, any credit management redesign breaks these workarounds and increases blocks.

Purchase-to-pay: invoices sit unposted

Accounts payable says invoices take weeks to post. The documented process says: receive invoice, match to PO, post. The real process shows: invoices arrive by email to a shared mailbox, a clerk prints and stamps them, another clerk enters header data, a third checks GR status in a separate system, discrepancies are escalated via instant message to a buyer who may be on vacation, and only then is the invoice posted. The bottleneck is not the posting transaction — it is the handoff between clerk and buyer.

Master data change: updates take three days

A business unit complains that customer master data changes take three days to propagate. The documented process says: request, approve, update, replicate. The real process shows: requests are sent by email to a data steward who works part-time, approval requires a signature from a manager who is rarely at their desk, updates are batched and run overnight, replication to CRM is manual because the interface broke six months ago and no one fixed it. The fix is not faster replication — it is fixing the broken interface and redesigning the approval handoff.

Inputs required

System transaction logs or audit trails showing actual user activity.
User interviews with people who perform each step, not just managers who oversee them.
Existing process documentation (to be verified, not trusted).
Incident tickets showing where the process breaks and how it is recovered.
Screen recordings or live walkthroughs of the actual execution.
IDoc, API, or integration flow logs if the process spans systems.
Stakeholder Analysis to know who to interview.

Questions to ask

What is the first screen, transaction, or document used to start this process?
What data is entered manually and what is populated automatically?
Where does the process wait for someone else, and how long does that wait typically last?
Which step has no clear owner, or has an owner who is unaware they own it?
What is the longest wait time, and what causes it?
Where do errors get caught today, and who fixes them?
What do you do when the system does not let you proceed as documented?
Which steps exist only to fix problems created by earlier steps?

Working method

Identify the process trigger and end state. What event starts it? What condition means it is complete? Be specific: "customer sends PO" not "order process starts."
Walk through actual execution with a user. Ask them to show you the real screens, not the training material. Record the sequence.
Record each step with actor, system, input, output, and duration. Use a table. Do not skip "obvious" steps like "save draft" or "check email."
Mark variations and exceptions. Ask: what happens if the customer is new? What happens if the amount is over a threshold? What happens on Friday afternoon?
Identify pain points with evidence. Do not record "slow" — record "takes 20 minutes because the search helps do not filter by date."
Map data flows between systems. Which fields move where? Which system is the source of truth for each field?
Verify ownership of each step. Ask who can change the step, not just who performs it. Check system roles if needed.
Document in a Process Analysis Note. Include trigger, steps, variations, pain points, system touchpoints, data flows, and ownership.

Decision rules

If process documentation contradicts actual execution, trust the execution and flag the documentation as outdated.
If a step has no owner, stop and identify the owner before proposing any change to that step.
If a step exists only to fix errors from an earlier step, the earlier step is the real problem.
If two systems exchange data manually (email, spreadsheet, rekeying), that is an integration gap, not a process step.
If duration data is unavailable, estimate from user memory and flag as unverified.
If a variation happens more than 20 percent of the time, it is not an exception — it is part of the process.
If a pain point has no evidence (no timing, no frequency, no ticket count), treat it as unverified opinion.

Deliverables

Process Analysis Note — Structured document with trigger, steps, variations, pain points, system touchpoints, data flows, and ownership. See template below.
As-Is Process Map — Visual or tabular representation of the process with exception paths.
Pain Point Register — Table of pain points with evidence, frequency, impact, and proposed improvement.
System Touchpoint Matrix — Which systems are involved, what data moves where, and integration gaps.

Templates

Process Analysis Note (compact)

---
artifact: Process Analysis Note
id: PAN-001
date: YYYY-MM-DD
process: Name
scope: As-is | To-be | Gap
---

## Process name and trigger


## Steps


| Step | Actor | System | Action | Input | Output | Duration | Issues |
|------|-------|--------|--------|-------|--------|----------|--------|
| 1 | Clerk | SAP | Create sales order | Customer PO | Order | 5 min | Manual entry |

## Variations


## Pain points


## System touchpoints


## Data flows


## Ownership


## Improvement opportunities


## Related processes

Quality checklist

Every step has an identified actor and system.
Process trigger and end state are explicitly defined.
Variations and exceptions are documented, not ignored.
Pain points have evidence: timing, frequency, ticket count, or user quote.
Data flows between systems are mapped with field-level detail where possible.
Ownership is verified, not assumed from job titles.
Duration is either measured or estimated with a confidence flag.

Common mistakes

Documenting the ideal process instead of the real one. Consequence: improvements fail because they ignore actual workarounds that users depend on.
Skipping exception paths. Consequence: automation or redesign breaks on edge cases that happen weekly.
Not mapping data flows. Consequence: system changes break downstream processes because field mappings were assumed.
Assuming documented process is current. Consequence: decisions are based on fiction. The redesign optimizes a process abandoned two years ago.
Interviewing only managers. Consequence: missing the workarounds, keyboard shortcuts, and manual fixes that operators use daily.

Agent instructions

AI agents should use this skill to document real processes before making any recommendation about change, automation, or integration.

Always start with a real transaction or incident, not a diagram or document. Ask users to show you the actual screens they use.
Record exceptions and workarounds as primary process steps, not footnotes. If a workaround happens daily, it is the process.
Map data flows explicitly — which fields move between which systems, and which system is the source of truth.
Verify ownership by asking who can change the step, not just who performs it. Check system roles if available.
Produce a Process Analysis Note. If documentation contradicts reality, document reality and flag the documentation gap.
Link to Atlas diagnostics when process gaps relate to SAP. For example, O2C process blocks should reference SAP Sales Order Block Diagnosis.
Do not optimize a process you have not observed. If you only have documentation, state that the analysis is unverified.

Related skills

Related Atlas pages

Order-to-Cash — Process context for O2C analysis.
SAP Process Audit — Diagnostic patterns for SAP process review.
SAP Sales Order Block Diagnosis — Specific O2C block analysis.

Verification status and limitations

This skill is a public working interpretation of process analysis practices. It is not official BPMN, Six Sigma, or SAP documentation. It focuses on operational reality in enterprise systems and may not cover highly regulated or safety-critical process domains.

Known limitations: the skill assumes access to users who can demonstrate the process. In remote or outsourced environments, screen recordings or transaction logs may substitute but with reduced accuracy. The skill does not cover process simulation or statistical process control.