Business Process Monitoring for SAP (Configure)

⚙️ Configure Business-Process Monitoring for SAP

Configure GermainUX to measure the execution, duration, completion, abandonment, and efficiency of SAP business processes.

Business processes are constructed from events collected through RUM JS, the GermainUX Engine, synthetic scenarios, or custom integrations. GermainUX can analyze only the workflow steps represented by the available telemetry.

📋 Prerequisites

Before configuring a business process:

Prerequisite

Deploy RUM JS and/or the GermainUX Engine.

Confirm that the required SAP events appear in GermainUX.

Identify the process start and completion conditions.

Identify required, optional, repeated, and alternative steps.

Select a reliable process-correlation method.

Define the expected process and step durations.

Establish privacy requirements for business identifiers.

📡 Event sources

Source

Example process evidence

RUM JS

Pages, application views, clicks, form submissions, errors, and browser requests

Engine

HTTP checks, API events, log events, file events, database results, and integration activity

Custom event

Store-specific or SAP-specific business milestone

Synthetic scenario

Controlled execution and validation of a predefined process

SAP Commerce Cloud storefront

Product, search, cart, checkout, and order-related frontend events

GermainUX does not automatically observe undocumented SAP internals. Backend process steps require an accessible and configured source.

🔍 Select the process

Start with a process that has clear business value and observable steps.

💡 SAP business-process examples

Potential processes include:

Example

Purchase requisition creation

Purchase-order approval

Invoice approval

Sales-order entry

Material lookup

Inventory transfer

Expense submission

Employee self-service

Vendor onboarding

Customer maintenance

Service-request handling

🛒 SAP Commerce Cloud examples

For SAP Commerce Cloud, formerly SAP Hybris, potential processes include:

Example

Product discovery

Search to product

Product to cart

Cart to checkout

Checkout to order

Customer registration

Login and password recovery

Return request

The exact process must reflect the application’s actual event flow.

🔧 Define the business process

Go to:

Germain Workspace > Analytics > Business Processes

Create or select the SAP business process.

Configure:

Field

Name

Description

Application

Environment

Start condition

Completion condition

Failure conditions

Abandonment timeout

Correlation

Expected duration

Steps

Relevant dimensions

Use a clear name such as:

SAP Purchase Requisition
SAP Invoice Approval
SAP Sales Order Entry
SAP Commerce Checkout

✅ Define the start and completion

▶️ Start condition

The start condition identifies when a process instance begins.

Examples include:

Example start

User opens the creation page

User selects a Fiori application

User clicks Create

Relevant API request begins

A configured log event appears

Customer starts checkout

Avoid starting the process on a generic login or page view unless it reliably represents process intent.

🏁 Completion condition

The completion condition identifies successful business completion.

Examples include:

Example completion

Confirmation page appears

Success event is created

Approved API response is received

Expected log event appears

Document status reaches the required state

Order-completion event is collected

A successful click or HTTP status does not necessarily prove that the business process completed. Use the strongest available business-success evidence.

📝 Configure the process steps

Define every observable step required for analysis.

Example:

Order

Step

1

Open Purchase Requisition Application

2

Enter Requisition Details

3

Add Line Item

4

Validate Requisition

5

Submit Requisition

6

Requisition Confirmation

For each step, configure:

Attribute

Step name

Entry condition

Completion condition

Expected duration

Warning duration

Critical duration

Required or optional status

Use business-oriented names rather than raw URLs, element IDs, or API paths.

🔍 Configure correlation

Correlation determines which events belong to the same process instance.

Potential identifiers include:

Identifier

User session

RUM session identifier

Request or correlation identifier

Transaction identifier

Approved business-document identifier

Synthetic execution identifier

Application, environment, user, and timestamp

Session-based correlation

Use session correlation when the complete process occurs within one browser session.

This is suitable for processes derived primarily from RUM events.

Identifier-based correlation

Use an approved transaction or document identifier when the process:

When to use

Continues across multiple sessions

Includes several users

Moves between browser and backend systems

Remains active for hours or days

Includes an approval workflow

Do not collect sensitive identifiers unless necessary and approved. Mask or hash them when the original value is not required.

Time-based correlation

Time proximity can support analysis but is not reliable proof that two events belong to the same process.

Use time-based correlation only when stronger identifiers are unavailable, and document its limitations.

🔁 Configure alternative paths

SAP processes frequently contain valid variations.

Configure:

Alternative path

Optional steps

Role-dependent steps

Conditional approval

Rework loops

Rejection paths

Cancellation

Save and resume

Multi-user handoffs

Accelerated paths

Do not classify every deviation from one ideal sequence as a failure.

Example:

Submit
  ├─ Approved
  ├─ Additional Approval Required
  ├─ Returned for Correction
  └─ Rejected

Each outcome can have a different completion or failure meaning.

⌛ Configure abandonment

A process is abandoned when it starts but does not reach an accepted completion condition within the configured period.

Define abandonment according to the process.

Examples:

Example

Browser workflow: no further activity for 30 minutes

Checkout: no purchase completion within the attribution window

Approval: no approved, rejected, or cancelled state within the expected period

Long-running workflow: no state change within the configured SLA

Do not mark an event sequence as abandoned merely because GermainUX lost monitoring coverage or could not correlate later events.

Keep these outcomes separate:

Outcome

Meaning

Completed

Accepted completion condition occurred

Failed

Configured application or business failure occurred

Abandoned

Process started but did not complete in time

Cancelled

User or system intentionally cancelled it

Pending

Process remains within the allowed period

Unknown

Available telemetry cannot determine the outcome

Monitoring gap

One or more required steps were not observable

⏱️ Configure performance objectives

Define expected durations for:

Scope

Entire process

Individual steps

User activity

System wait

Approval wait

Integration processing

A process can complete successfully and still be inefficient.

Use representative baseline data before setting warning and critical thresholds.

📊 Analyze productivity

GermainUX can analyze productivity using observed process and interaction data.

Potential measures include:

Measure

Meaning

Process duration

Process duration

Step duration

Step duration

Completion rate

Completion rate

Abandonment rate

Abandonment rate

Failure rate

Failure rate

Repeated steps

Repeated steps

Rework

Rework

User wait time

User wait time

Excess duration above baseline

Excess duration above baseline

Number of users affected

Number of users affected

Frequency of inefficient paths

Frequency of inefficient paths

warning Lost productivity

Lost productivity can be estimated by comparing actual duration with an approved baseline.

For one process instance:

image-20260829-141851.png

Across multiple instances:

image-20260829-141903.png

This is an estimate based on the configured baseline and observed events. It should not automatically be treated as employee performance measurement.

👥 Distinguish user time from system time

Where the necessary browser events are available, separate:

Type

User action time

User orientation or decision time

System or network wait time

Idle time

The available breakdown depends on what RUM JS captures and how process steps are defined.

Do not attribute the complete elapsed duration to application slowness or user inefficiency without supporting evidence.

☠️ Configure errors within the process

Associate relevant errors with the affected process and step.

Use these classifications:

Classification

Meaning

User-facing application error

Software failure visible to the user

Silent application error

Software failure not shown to the user

User validation

Expected feedback preventing invalid input or action

Business-process failure

Required business outcome was not achieved

Integration failure

Configured downstream or upstream operation failed

Keep user validation separate from application errors.

🧭 Analyze process segments

Use pivots and filters to compare process performance by:

Dimension

Application

Environment

Process

Step

User role

Department

Business unit

Location

Browser

Device

Release

Completion outcome

Error category

Collect only approved user and business attributes.

🔎 Configure outlier detection

Outlier detection can identify unusual process or step durations after sufficient data has been collected.

Potential use cases include:

Use case

A process takes much longer than its historical baseline.

One step becomes slower after a release.

A user segment follows an unusually repetitive path.

Failure volume increases unexpectedly.

A new process path appears.

Outlier detection operates on collected process data. It does not expose steps that GermainUX cannot observe.

🎯 Configure KPIs

Recommended business-process KPIs include:

KPI

Description

Business Process

Complete process instance

Business Process Step

Individual process step

Process Volume

Number of process instances

Completion Rate

Percentage reaching an accepted completion

Failure Rate

Percentage reaching a configured failure

Abandonment Rate

Percentage starting but not completing in time

Process Duration

Total elapsed process time

Step Duration

Elapsed time for one step

Rework Rate

Percentage containing repeated or corrective steps

Estimated Lost Productivity

Duration above the approved baseline

Affected Users

Distinct users associated with the condition

Custom processes and steps can generate additional KPIs.

🖥️ Configure dashboards

Go to:

Germain Workspace > Dashboards > All

Search for SAP or business-process dashboards, or create a dashboard using the configured process KPIs.

Recommended views include:

View

Process volume

Completion and abandonment

Process-duration trend

Slowest steps

Step drop-off

Repeated steps

Error-affected processes

Estimated lost productivity

Segments with degraded performance

Links to affected sessions and Session Replay

🔔 Configure alerts and reports

Create alerts for actionable conditions such as:

Alert

Process failure-rate increase

Completion-rate degradation

Abandonment-rate increase

Process or step exceeding its SLA

New error affecting a critical step

Unusual increase in rework

Synthetic process failure

Schedule reports for:

Report

Process efficiency

Completion and abandonment

Slowest steps

Process variation

Error impact

Lost-productivity estimates

Changes after a release

✅ Validate the configuration

Test each supported path before production use.

Confirm that:

Validation

The start event creates one process instance.

The completion event closes the correct instance.

Steps appear in the intended order.

Optional steps do not cause false failures.

Repeated steps are represented correctly.

Correlation joins only related events.

Failures use the correct classification.

Abandonment timeout is appropriate.

Monitoring gaps are not classified as abandonment.

Process and step durations are accurate.

Sensitive identifiers are protected.

Synthetic traffic is distinguishable from real-user activity.

Dashboards and alerts use the correct application and environment.

🚫 Important limitations

GermainUX business-process monitoring depends on the available telemetry.

It does not automatically:

Limitation

Discover every SAP workflow

Read undocumented SAP internal states

Correlate events without a shared identifier or validated rule

Determine business success from a browser click alone

Identify ABAP execution paths

Assign all elapsed time to either the user or the system

Measure native SAP GUI activity through RUM JS

Additional SAP events may require custom RUM instrumentation, API access, log parsing, database queries, or another approved integration.

ℹ️ Get More Information

GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your SAP environment.

Contact GermainUX Support.

Feature Availability: 2022.1 or later