Process Design

SAP Process Design

This skill enforces structured, evidence-based business process design for SAP implementations so that no to-be process is designed without documenting the as-is, no custom process is introduced without first validating SAP Best Practice, no process is left without an owner, and no process is complete without measurable KPIs.

Iron Laws

1. NEVER DESIGN TO-BE WITHOUT DOCUMENTING AS-IS. A to-be process designed without understanding the current state is a consultant's assumption dressed as a solution. The as-is documents pain points, workarounds, data flows, and integration touchpoints that the to-be must address. Skipping it produces designs that cannot be adopted.
2. REFERENCE SAP BEST PRACTICE BEFORE PROPOSING CUSTOM. Every to-be process must be compared to the relevant SAP Best Practice Scope Item before any variant or custom design is introduced. If the Best Practice meets the business need, it is the default. Custom design requires explicit justification of why Best Practice is insufficient.
3. NEVER SKIP PROCESS OWNER ASSIGNMENT. A process without an accountable owner has no one to approve the design, resolve disputes in workshops, sign off on UAT, or own adoption post go-live. Every process and sub-process must have a named process owner before the design is baselined.
4. DEFINE MEASURABLE KPIs FOR EVERY PROCESS. A process without KPIs cannot be improved, benchmarked, or measured for the value it delivers. Every process must have at least one leading and one lagging KPI, with a baseline value and a target value agreed with the business before Realize begins.

---

Rationalization Table

| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter | |---|---|---|---| | Skip as-is documentation | "The client wants to move quickly — let's design the future state directly" | Without as-is, the design team misses critical integration points, data flows, exception handling paths, and user workarounds that must be addressed in the to-be. The design goes into UAT with gaps that surface as defects. | Iron Law 1: As-is documentation is not optional. If time is short, document at swim-lane level — but document it. | | Propose custom process before checking Best Practice | "The client's process is unique — SAP standard won't work" | SAP Best Practices cover the majority of standard business scenarios. "Unique" processes are often unique habits, not unique business requirements. Best Practice adoption reduces cost, improves upgradability, and shortens delivery. | Iron Law 2: Show the Best Practice process first. Justify deviation with a named business requirement that Best Practice cannot meet. | | Leave process owner TBD | "We'll assign owners once the design is more stable" | Design stability requires process owner input. A design without an owner cannot be reviewed, approved, or tested by the right person. The owner must co-create the design, not receive it. | Iron Law 3: Process owner is identified in Step 1 — before design begins, not after. | | Define KPIs as generic targets | "We'll improve efficiency and reduce errors" | Generic KPIs cannot be measured, baselined, or targeted. They cannot drive remediation if adoption is poor. Without specific KPIs, the project cannot demonstrate value to the business sponsor. | Iron Law 4: Every KPI has a name, a unit of measure, a baseline value, a target value, and a measurement method. | | Design all variants upfront | "The client has 12 variants of this process — let's document them all" | Documenting all variants before standardizing creates an unmaintainable design with 12 times the testing effort. Use variant analysis to reduce variants to the minimum necessary before designing each one. | Variant analysis step: Consolidate variants before designing. Challenge every variant with "what is the business reason this cannot follow the standard path?" | | Skip integration touchpoints | "This is a pure finance process — no integration needed" | Pure processes are rare. Most SAP processes touch adjacent modules (FI-MM, SD-FI, PP-QM) or external systems. Missing integration touchpoints means the design is incomplete and the fit-gap analysis will be wrong. | Step 2 (as-is): Integration touchpoints are a mandatory component of the as-is documentation. | | Treat process design as a documentation exercise | "We just need the process maps for the design spec" | Process design shapes configuration decisions, gap identification, testing scenarios, and training content. A design produced only for documentation produces designs that are disconnected from what is actually configured. | Process design drives fit-gap, configuration, and test case design. These downstream dependencies must be called out at the start of every design workshop. |

---

Red Flags

Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:

• "Let's design the future state and come back to as-is later..." → As-is must be documented first. Stop.
• "The client's process is too unique for SAP standard..." → Have you shown them the Best Practice? Start there.
• "We'll assign a process owner in the next phase..." → Process owner must be named before design begins. Stop.
• "KPIs can be defined after go-live once we have real data..." → Baseline data comes from the as-is. Define KPIs now.
• "We have 15 process variants — let's document them all..." → Run variant analysis first. Reduce before designing.
• "This process doesn't touch any other modules..." → Verify the integration touchpoints. Assumption of isolation is a risk.
• "The design is done — we just need sign-off..." → Has the process owner been involved throughout, or only at sign-off? Involvement ≠ sign-off.
• "We'll use the same design from the last project..." → Requirements and org context differ. Validate this design against this client's as-is before reusing.

---

Hard Gates

DO NOT produce a to-be process design until ALL of the following exist:

1. As-is process documented at swim-lane level with pain points, workarounds, and integration touchpoints identified
2. SAP Best Practice Scope Item reviewed and compared against the business requirement
3. Process owner named and confirmed as available for design workshops
4. Variant analysis complete — number of process variants agreed and justified
5. KPI baseline values sourced from the as-is or current measurement — not estimated
6. Design reviewed with the process owner before it is baselined

---

Checklist

Step 1: Identify Processes, Owners, and Scope

Before any mapping or design begins, establish the process inventory:

• Process list: Enumerate all business processes in scope for design (e.g. Procure-to-Pay, Order-to-Cash, Record-to-Report)
• Sub-process breakdown: Decompose each process into sub-processes (e.g. Purchase Requisition, Purchase Order, Goods Receipt, Invoice Verification)
• Process owner assignment: Name the accountable business owner for each process and sub-process
• Org units involved: Which departments, plants, company codes, or sales organizations execute each process?
• SAP module mapping: Map each process to the primary SAP module(s) involved

Evidence: Process inventory table with process, sub-process, process owner (named), org unit, and SAP module for every in-scope process. Gate: Every process has a named process owner before Step 2 begins. "TBD" is not a process owner.

Step 2: Document the As-Is Process

For every process, document the current state before designing the future state:

As-Is Documentation Components:

| Component | What to Capture | |-----------|----------------| | Swim-lane diagram | Process steps, decision points, actors (roles/systems), and flow by lane | | System landscape | Which systems are currently used (legacy ERP, spreadsheets, email, paper) | | Data inputs and outputs | What data enters and leaves each step? What documents are created? | | Integration touchpoints | Which adjacent processes or systems does this process touch? | | Pain points | What is slow, error-prone, manual, or inconsistent in the current process? | | Workarounds | What informal fixes have users invented to compensate for system or process limitations? | | Volume and frequency | How often does this process run? What transaction volumes are typical? | | Exceptions | What are the most common non-standard paths? How are exceptions handled? |

Conduct as-is workshops with the process owner and key users. Do not reconstruct the as-is from documentation alone — people know what the documentation does not say.

Evidence: Swim-lane diagram and as-is summary per process with all eight components documented. Gate: As-is is validated by the process owner as an accurate representation of current state before to-be design begins.

Step 3: Compare Against SAP Best Practice

For every process, identify and review the corresponding SAP Best Practice Scope Item:

• Locate the Scope Item: Use SAP Best Practices Explorer to find the relevant Scope Item(s)
• Review the standard flow: Walk the Best Practice process against the business requirement
• Gap identification: Note where the Best Practice flow differs from the business requirement
• Coverage assessment: Is the gap a process habit (accept Best Practice) or a genuine business requirement (design variant)?

Best Practice Adoption Decision:

| Scenario | Decision | |---------|---------| | Best Practice fully meets the requirement | Adopt Best Practice as the to-be — no variant needed | | Best Practice meets the requirement with configuration | Adopt Best Practice — configure the variant | | Best Practice does not meet a genuine business requirement | Design a process variant — document the business justification | | Client wants to keep current process regardless of Best Practice | Escalate — current-process-as-default is a risk to timeline and clean core |

Evidence: Best Practice comparison table per process with Scope Item ID, comparison result, and adoption decision. Gate: No process variant is designed without a documented business justification for deviation from Best Practice.

Step 4: Conduct Variant Analysis

Before designing multiple process variants, challenge and reduce them:

• Identify all variants: List every known variant of the process (regional, org unit, product type, customer type)
• Challenge each variant: "What is the business reason this cannot follow the standard path?"
• Consolidate where possible: Variants that differ only by habit or preference should be consolidated to the standard path
• Approve remaining variants: Process owner and project sponsor confirm which variants will be designed and supported
• Estimate variant cost: Each additional variant multiplies configuration, testing, and training effort — quantify this

Variant Decision Matrix:

| Variant | Business Justification | Can Consolidate? | Decision | Additional Effort | |--------|----------------------|:----------------:|---------|:----------------:| | [Variant Name] | [Reason] | Y/N | Keep / Consolidate | [days] |

Evidence: Variant decision matrix with business justification and consolidation decision for every variant. Gate: No variant proceeds to design without explicit process owner and sponsor approval.

Step 5: Design the To-Be Process

Design the future-state process for each approved process and variant:

To-Be Design Components:

| Component | What to Produce | |-----------|----------------| | Swim-lane diagram | To-be flow with SAP roles, system steps, and integration points | | SAP transaction mapping | Which SAP transactions or Fiori apps support each process step | | Configuration requirements | What configuration settings, org structure, or master data are required | | Automation opportunities | Where can workflow, automation (BTP/RPA), or output management reduce manual steps | | Delta from as-is | What changes from current state — steps added, removed, or changed | | Exception handling | How are exceptions managed in the new process | | Role and responsibility changes | Which roles change as a result of the new process (input to change management) |

Design workshops must include the process owner. The functional consultant facilitates — the process owner co-designs.

Evidence: To-be swim-lane diagram and process design document per process with all components populated. Gate: To-be design reviewed and approved by the process owner before it is submitted for configuration.

Step 6: Define Process KPIs

For every process, define measurable performance indicators:

KPI Design Principles:

• Every process must have at least one leading KPI (predictive — warns before performance drops) and one lagging KPI (outcome — measures result)
• KPI must be measurable in SAP or via a connected analytics tool — not estimated manually
• Baseline value must come from the as-is or current measurement, not from assumption
• Target value must be agreed with the process owner and business sponsor

KPI Categories for SAP Processes:

| Category | Example KPIs | |---------|-------------| | Efficiency | Cycle time, touchless rate, manual steps per transaction | | Quality | Error rate, exception rate, first-pass yield | | Compliance | On-time completion rate, policy adherence rate | | Volume | Transaction volume, throughput rate | | Cost | Cost per transaction, processing cost |

Evidence: KPI table per process with KPI name, category, unit of measure, baseline value, target value, measurement method, and measurement frequency. Gate: No KPI is accepted without a baseline value and a named measurement method. "TBD" baseline is not acceptable.

Step 7: Baseline the Process Design Document

Compile all outputs into the process design document and obtain sign-off:

• Compile as-is, Best Practice comparison, variant analysis, to-be design, and KPIs into one document per process or process area
• Review with the process owner and resolve any outstanding design questions
• Obtain formal sign-off from the process owner before the document is handed to configuration
• Flag any open items that will require further decision — assign an owner and due date per item

Evidence: Signed process design document per process area with no unresolved design decisions and all open items assigned. Gate: No configuration begins in Realize on a process that does not have a signed process design document.

---

Deliverable Template

# SAP Process Design Document

## Header
- **Process Area:**
- **SAP Module(s):**
- **Process Owner:** [Name, Role, Org Unit]
- **Design Version:**
- **Prepared By:**
- **Process Owner Sign-Off:** [Name, Date]

## Process Inventory

| Process | Sub-Process | Process Owner | Org Unit | SAP Module | Variants |
|---------|------------|--------------|---------|-----------|:--------:|
| | | | | | |

## As-Is Process Summary

### [Process Name]
- **Systems Used:**
- **Key Pain Points:**
  1.
  2.
- **Workarounds Identified:**
  1.
  2.
- **Integration Touchpoints:**
- **Transaction Volumes:**
- **Exception Rate:**

[Attach swim-lane diagram]

## SAP Best Practice Comparison

| Process | Best Practice Scope Item | Coverage Assessment | Adoption Decision | Justification if Variant |
|---------|------------------------|:------------------:|:-----------------:|------------------------|
| | | Full / Partial / None | Adopt / Configure / Variant | |

## Variant Analysis

| Variant | Business Justification | Consolidate? | Decision | Additional Effort (d) | Approved By |
|--------|----------------------|:-----------:|---------|:--------------------:|------------|
| | | Y/N | Keep / Consolidate | | |

## To-Be Process Design

### [Process Name] — [Variant if applicable]
- **SAP Transactions / Fiori Apps:**
- **Configuration Requirements:**
- **Automation Opp

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [vigneshbarani24](https://github.com/vigneshbarani24)
- **Source:** [vigneshbarani24/sap-superpowers](https://github.com/vigneshbarani24/sap-superpowers)
- **License:** MIT
- **Homepage:** https://sap-superpowers.vercel.app/

Install and usage instructions live in the source repository linked above.