⚙️ 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 |
Lost productivity
Lost productivity can be estimated by comparing actual duration with an approved baseline.
For one process instance:
Across multiple instances:
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.
🔗 Related documentation
ℹ️ Get More Information
GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your SAP environment.
Component: Engine, JS Profiler, Mobile App, RPA Bot Recorder, RUM JS
Feature Availability: 2022.1 or later