SAP Signavio in S/4HANA Migration: Process Intelligence Before Go-Live

Most S/4HANA migration programmes underinvest in process intelligence and pay for it during user acceptance testing and hypercare. Business users discover that a process that worked for fifteen years now behaves differently — not because the system was configured wrong, but because nobody captured what the process actually was, as opposed to what the process documentation said it was. SAP Signavio closes this gap, but only if deployed at the right points in the migration programme.

What Signavio actually is

SAP Signavio is a process management suite with three distinct capability areas that are separately licensed and separately useful:

Signavio Process Manager — a collaborative BPMN modelling tool. Teams draw process models, link them to system documentation, and maintain a version-controlled process repository. This is the “design” half of the suite.

Signavio Process Intelligence (formerly Signavio Process Mining) — mines transactional data from SAP and other source systems to reconstruct the actual process execution flows from event logs. This is the “discover” and “analyse” half. It ingests data from SAP tables (CDHDR/CDPOS for change documents, VBFA for sales document flow, EKBE for purchasing history, BKPF/ACDOCA for FI postings) and reconstructs the real process variants, cycle times, and bottlenecks.

Signavio Process Collaboration Hub — the publishing and governance layer that makes process documentation accessible to business users outside the modelling tool.

For migration programmes, Process Intelligence is the high-value component. You can operate it without Process Manager if budget is constrained.

The process mining data model

Signavio Process Intelligence works from an event log: a minimum of case ID, activity name, and timestamp. For S/4HANA source systems, the extraction connectors pull from:

• Order-to-Cash: VBFA (document flow), VBAK/VBAP (orders), VBRK/VBRP (billing), FI clearing documents
• Procure-to-Pay: EKKO/EKPO (purchase orders), EKBE (purchase order history), MIGO-related material document tables, RBKP/RSEG (invoice receipt)
• Record-to-Report: BKPF (accounting document header), ACDOCA (universal journal), CDHDR (change documents)

The mining engine then produces a process map showing every real variant — the paths actually executed by the system — with frequency counts, cycle times, and conformance scores against the designed process model. A typical Order-to-Cash process in an ECC system running for 10+ years will surface 30–100 variants; most organisations thought they had 3–5.

Where Signavio fits in the migration toolchain

The standard SAP migration toolchain involves RSAM (Readiness Assessment for SAP S/4HANA), SAP Transformation Navigator, and — where customisation is heavy — automated ABAP code remediation tooling. Each of these is technically oriented: they answer “what code needs to change?” Signavio answers the complementary question: “what do the processes actually look like and what should change in the business?”

flowchart LR
    subgraph "Discover"
        PM["Process Mining\n(Signavio Process Intelligence)"]
        RSAM["RSAM\n(Simplification list check)"]
        CC["Custom Code Scan\n(ATC / s4ready.ai)"]
    end
    subgraph "Design"
        PROC["Target Process Models\n(Signavio Process Manager)"]
        GAP["Gap Analysis\n& Fit-to-Standard"]
        CONF["Configuration\nDecisions"]
    end
    subgraph "Deploy"
        IMPL["S/4HANA Implementation\n(config + remediation)"]
        UAT["UAT Test Cases\n(from process variants)"]
        CUTOVER["Cutover & Go-Live"]
    end
    subgraph "Operate"
        MON["Continuous Monitoring\n(post-migration mining)"]
        CONFORM["Conformance Checking\nvs target model"]
    end

    PM --> GAP
    RSAM --> GAP
    CC --> CONF
    GAP --> PROC
    PROC --> IMPL
    PROC --> UAT
    IMPL --> CUTOVER
    CUTOVER --> MON
    MON --> CONFORM

    style PM fill:#4a90d9,color:#fff
    style RSAM fill:#6dbf6d,color:#fff
    style CC fill:#6dbf6d,color:#fff

RSAM tells you which tables and function modules are deprecated and must change. Signavio tells you which process paths are actually used and how frequently. Both inputs are necessary for scope control.

The scope creep problem — and how process intelligence addresses it

Scope creep in S/4HANA migrations most commonly occurs in two forms:

Form 1: Over-customisation. Stakeholders request that legacy custom process variants be preserved in S/4HANA because “the business depends on them.” Without process mining data, you have no basis to challenge this. With Signavio data, you can show that a claimed-critical variant represents 0.3% of annual transactions, has a 4x longer cycle time than the standard path, and was last used 18 months ago.

Form 2: Undiscovered dependency. A process in scope turns out to have an undocumented dependency on a custom table or a Z-program that also feeds a downstream process. Signavio’s process maps surface these dependencies through the data: if your procurement process frequently triggers a variant that includes a non-standard posting step, that step will appear in the event log even if no documentation exists for it.

Both of these fail modes are recoverable before go-live if the data is available early enough. They are expensive surprises if they surface during UAT.

What to capture before go-live

At minimum, extract and baseline these process areas in Signavio before starting S/4HANA configuration:

Order-to-Cash: document all variants with frequency and cycle time. Identify which variants involve manual interventions (billing blocks, credit holds, manual pricing conditions). These are the variants most likely to be disrupted by the migration.

Procure-to-Pay: identify three-way match exceptions. What percentage of invoices hit the GR/IR tolerance? What are the most common reasons for purchase order amendment? These drive configuration decisions for tolerance groups and release strategies in S/4HANA.

Month-end close: map the actual sequence of posting and reversal activities. Finance teams often have month-end scripts that depend on ECC-specific timing behaviours that change in S/4HANA’s universal journal model.

Custom program usage: combine SAP system log data (SM20 / ST05 usage statistics) with Signavio to identify which Z-transactions are called within process flows. This directly inputs the custom code remediation prioritisation: if a Z-program appears in a high-frequency variant, it is a higher priority than one that appears in a variant last executed two years ago.

Post-migration conformance monitoring

One of the underused capabilities of Signavio Process Intelligence is running it against the S/4HANA system after go-live. Point the mining connector at the new system, import the target process models, and run conformance checking: every transaction in the live system is compared against the defined process model and deviations are flagged automatically.

This gives hypercare teams objective data within days: not “the system feels wrong” but “17% of Order-to-Cash transactions are following variant C, which bypasses the credit check step, and here are the specific sales order numbers.” That is actionable immediately.

The operational setup cost for post-go-live monitoring is low if the extraction and model configuration was done pre-migration. Doing the work once, with dual use in both phases, is the correct investment model.

---

SAP, S/4HANA, Signavio, and related marks are trademarks of SAP SE.