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

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

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:

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:

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:

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:

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:

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 Opportunities:**
- **Role and Responsibility Changes:**
- **Exception Handling:**
- **Delta from As-Is (key changes):**
  1.
  2.

[Attach to-be swim-lane diagram]

## Process KPIs

| Process | KPI Name | Type | Unit | Baseline | Target | Measurement Method | Frequency |
|---------|---------|:----:|------|:--------:|:------:|-------------------|-----------|
| | | Lead/Lag | | | | | |

## Open Items

| Item | Design Decision Required | Owner | Due Date | Risk if Unresolved |
|------|------------------------|-------|----------|--------------------|

Verification

This skill is complete ONLY when ALL of the following are true:

• Process inventory is complete with every in-scope process and sub-process listed
• Every process has a named process owner — no TBD entries
• As-is documentation covers all eight components per process (swim-lane, systems, data, integration, pain points, workarounds, volume, exceptions)
• As-is is validated by the process owner as accurate
• SAP Best Practice Scope Item has been reviewed for every process before to-be design begins
• Every process variant has a documented business justification and is approved by process owner and sponsor
• To-be design covers all components per process including transaction mapping, configuration requirements, and exception handling
• Every to-be design is reviewed and approved by the process owner
• Every process has at least one leading and one lagging KPI with baseline value, target value, and measurement method
• No KPI has a TBD baseline — baseline values sourced from as-is or current measurement
• Process design document is signed off before configuration begins in Realize

Evidence required: Signed process design document per process area with as-is diagrams, Best Practice comparison, to-be diagrams, variant decisions, and KPI table fully populated.

If any verification item is not met, the skill is NOT complete. Do not claim completion.

Next Skill

After completing this skill, invoke:

• fit-gap-analysis — When to-be processes are designed and the team moves to classifying each requirement against SAP standard capability

Conditions for handoff: Process design documents are signed off for all in-scope processes. The to-be design defines the business requirements that will be classified as Fit, Gap-Config, Gap-Dev, Gap-Process, or Partial in the fit-gap matrix.

Cross-References

• project-kickoff — The project scope defined in kickoff determines which process areas are in scope for design
• fit-gap-analysis — To-be process requirements are the input to fit-gap classification; process design and fit-gap run in sequence
• estimation — Process complexity and variant count from process design feed into the effort estimate for configuration and development
• change-management — Role and responsibility changes identified in to-be design drive the stakeholder impact analysis and training needs
• sap-process-modeler agent — Dispatch for large-scale process mapping engagements spanning 10+ end-to-end processes across multiple modules