Business Process Monitoring for Oracle Siebel CRM (Configure)

ComponentsGermainUX RUM JSGermainUX Engine Feature availability: GermainUX 2017.2 or laterEngineJS ProfilerMobile AppRPA Bot RecorderRUM JS

Availability2014.1 or later

Prerequisites

Docs to read first

Choose the process type

Models of business processes

Validate the process

Test with real executions

Troubleshooting

Fix process monitoring gaps

Configure Business-Process Monitoring for Oracle Siebel CRM GermainUX monitors complete Oracle Siebel CRM business processes and automatically identifies where workflows become slow, inefficient, repetitive, or incomplete.

Business-process monitoring overview

Instead of measuring only individual clicks or transactions, business-process monitoring connects multiple user and system activities into one end-to-end process. GermainUX can then determine:

	Capability	Details
1	How long the complete process takes	How long the complete process takes
2	How long each step takes	How long each step takes
3	Where users wait or repeat work	Where users wait or repeat work
4	Where processes are abandoned	Where processes are abandoned
5	Which users, teams, roles, or applications are affected	Which users, teams, roles, or applications are affected
6	Why a step or workflow is inefficient	Why a step or workflow is inefficient
7	How much productivity is lost	How much productivity is lost
8	Whether technical problems contributed to the delay	Whether technical problems contributed to the delay

For example, GermainUX can identify users who require eight minutes to create an order when the expected duration is two minutes, isolate the steps responsible for the six-minute overrun, and correlate them with the corresponding sessions, errors, requests, and technical events.

Prerequisites

Before configuring a Siebel business process:

Prerequisite	Notes
Deploy RUM JS when the process includes browser and user activity.	Deploy RUM JS when the process includes browser and user activity.
Deploy the GermainUX Engine when the process includes server-side, log, database, or integration events.	Deploy the GermainUX Engine when the process includes server-side, log, database, or integration events.
Confirm that the required source KPIs receive data.	Confirm that the required source KPIs receive data.
Identify the application and environment.	Identify the application and environment.
Select a process with a clear business purpose.	Select a process with a clear business purpose.
Document its expected start, steps, completion, and duration.	Document its expected start, steps, completion, and duration.
Determine how different process instances will be correlated.	Determine how different process instances will be correlated.
Identify the process owner and expected SLA.	Identify the process owner and expected SLA.

See:

Select a process to monitor

Begin with workflows that are critical, frequent, slow, error-prone, or costly. Common Siebel examples include:

Process	Process
Lead to Opportunity	Opportunity to Quote
Quote to Order	Service Request open to close
Customer or account creation	Customer onboarding
Case escalation	Approval processing
Order submission	Product or asset registration
Contact-center call handling	Field-service dispatch and completion

Avoid beginning with a large process that contains many unrelated outcomes. Start with one clearly defined workflow, validate it, and expand it progressively.

Define the monitoring objective

Before configuring the process, document the question it must answer.

Objective	Example
Performance	How long does it take to create a Service Request?
Efficiency	Which step causes most of the workflow overrun?
Adoption	Are users following the expected Siebel workflow?
Productivity	How much employee time is lost to slow or repeated steps?
Completion	What percentage of started processes are completed?
Quality	Which errors or validation messages prevent completion?
Segmentation	Which teams, roles, regions, or versions perform differently?
Technical correlation	Are browser, server, integration, or database problems causing delays?

The monitoring objective determines which steps, measures, dimensions, and success criteria should be configured.

Choose the process type

GermainUX supports different business-process models.

1 Sequential business process

Use a sequential process when the workflow has known steps that are expected to occur in a defined order. Example:

Open the Service Request screen

Create a new Service Request

Enter customer and issue details

Assign the Service Request

Resolve the issue

Close the Service Request

The process completes when its final step occurs. Sequential processes are appropriate when:

The expected path is known.
Step order matters.
The process is normally completed by one user or session.
Deviations and drop-offs should be measured against a defined workflow.

Collaborative business process

Use a collaborative process when:

Steps are not known or fixed in advance.
Activities may occur in different orders.
Multiple users or sessions contribute to the same process.
Users can return to an earlier step.
The process can contain a variable number of activities.
Steps should be discovered from captured activity.

For example, a complex Opportunity may be updated by sales, legal, finance, and management across multiple sessions before reaching its final state. See Business Process and Workflow Mining.

Identify the source events

Each process step must be driven by data that GermainUX collects. Possible source events include:

Event	Event
Siebel user clicks	Screens and views
Applets	Button or command activity
Field or record changes	Browser events
User-facing errors	Validation messages
Network requests	Siebel log events
Server transactions	Workflow events
Integration events	Database events
Custom events created through an API or rule

Select events that reliably represent the business action. Avoid using a generic page load when a more specific action, record change, or success message is available.

Define the process

Document the complete process before configuring it.

Definition	Purpose
Process name	Identifies the monitored workflow
Application	Associates the process with Siebel CRM
Environment	Separates Production, UAT, QA, and other environments
Start condition	Creates a new process instance
Steps	Identify the milestones being measured
Completion condition	Marks the process as successfully completed
Failure condition	Identifies an explicit failure
Correlation identifier	Associates events with the correct process instance
Expected duration	Defines the normal end-to-end completion time
Step thresholds	Define the expected duration of each step
Timeout	Closes an instance when no completion event arrives
Dimensions	Allow analysis by user, team, role, region, version, or other context

Use a business-readable name such as:

Siebel Service Request - Open to Close

Define the start condition

The start condition must uniquely identify the beginning of a new process instance. Possible start conditions include:

Opening a specific Siebel view
Clicking New
Creating a record
Selecting a workflow action
Receiving a server-side creation event
Detecting a specific log or integration event

Avoid a start condition that occurs repeatedly during the same process unless a reliable correlation identifier prevents duplicate process instances.

Define process steps

Create steps for meaningful business milestones rather than every individual click. For example:

Step	Representative condition
Start Service Request	User selects New Service Request
Identify Customer	Customer or account is associated
Enter Issue Details	Required issue fields are completed
Assign Request	Owner or group is assigned
Resolve Request	Status changes to Resolved
Close Request	Status changes to Closed

Each step should have:

A clear business name
A reliable matching condition
An expected order when applicable
An expected duration
Sufficient context to associate it with the correct process instance

Too many low-value steps can make the process difficult to analyze. Too few steps can hide the source of inefficiency.

Define completion and failure

A completion condition should prove that the business outcome occurred. Good completion conditions include:

Record status changes to the final state
Order is submitted successfully
Confirmation message appears
Workflow completion event is generated
Required server-side transaction completes
Expected record is created or updated

Do not treat navigation to the final screen as completion unless it reliably proves that the transaction succeeded. Configure explicit failure conditions where possible, such as:

Error message appears
Integration request fails
Workflow enters a failure status
Required record is not created
Server-side exception occurs

Correlate events

GermainUX must associate each event with the correct business-process instance. Possible correlation identifiers include:

Siebel record ID
Service Request number
Order number
Opportunity ID
Account ID
Workflow instance ID

Show all 9

User-session ID
Transaction or correlation ID
A combination of user, application, and time

Use a stable business identifier when a process:

Spans multiple sessions
Is completed by multiple users
Runs for an extended period
Includes browser and server-side events
Can have multiple concurrent instances for the same user

Session correlation alone may be sufficient for a short process completed by one user in one session.

Configure expected duration and overrun

Define the expected duration for the complete workflow and, where useful, for each step. GermainUX can then measure:

Overrun = Actual duration - Expected duration

For example:

Actual duration:   8 minutes
Expected duration: 2 minutes
Overrun:           6 minutes

At scale, the accumulated overrun represents lost productivity or avoidable customer effort. Base the expected duration on:

Historical performance
Business targets
Operational SLAs
Observed performance of proficient users
Process-owner expectations
Controlled test results

Do not set the expected duration from one unusually fast instance. Establish a representative baseline across users and normal operating conditions.

Configure timeout and abandonment

Set a timeout for processes that start but do not produce a completion event. A timed-out process can represent:

User abandonment
Session termination
Incomplete work
A workflow failure
A missing event
An incorrect process definition
A long-running process that legitimately continues later

Choose the timeout according to the process. A short interactive workflow may require minutes, while a collaborative process may remain open for days or weeks. Before classifying every timeout as abandonment, verify that the completion condition and correlation logic work correctly.

Configure dimensions

Add dimensions that help explain differences in process performance. Useful dimensions include:

Dimension	Dimension
User	Team
Role	Department
Region	Siebel application
Environment	Screen or view
Object Manager	Browser
Device	Application version
Process outcome	Customer or product segment, when permitted
New versus experienced user

Collect only dimensions that are operationally useful and permitted by the organization’s privacy requirements.

Configure the process in GermainUX

Use the standard GermainUX business-process configuration to:

Create the process definition

Select the process type

Associate it with the Siebel application

Define the start condition

Add the process steps

Define matching conditions for each step

Configure correlation

Define completion and failure conditions

Set expected process and step durations

Set the timeout

Add permitted dimensions

Save and enable the process

Detailed configuration guidance is available in Business Process and Workflow Mining. Germain Software can also assist with configuring critical or complex Siebel workflows.

Validate the process

Test the definition with representative executions.

Successful execution

Complete the intended workflow and confirm that:

One process instance is created.
The correct start event is used.
Each expected step appears.
Steps occur in the correct order when required.
Step durations are accurate.
The completion condition closes the process.
The process is associated with the correct user and Siebel context.

Slow execution

Introduce a controlled delay and confirm that:

The delayed step reflects the additional time.
The complete process duration increases.
The overrun is calculated correctly.
SLA evaluation produces the expected result.

Abandoned execution

Start the process without completing it and confirm that:

The instance remains open for the configured period.
The timeout closes it as expected.
It is classified correctly as timed out or abandoned.

Failure execution

Trigger a safe, known validation or failure and confirm that:

The correct step or process is marked as failed.
The related error is correlated.
The process does not appear as successfully completed.

Test multiple users and concurrent process instances to validate the correlation logic.

KPIs

Business-process configuration generates or uses KPIs for:

Complete process duration
Process-step duration
Process volume
Completion
Failure
Timeout or abandonment

Show all 9

Overrun
Lost productivity
Process outcome

See KPIs for Oracle Siebel CRM. Configure SLAs for the complete process and the steps that have meaningful operational targets.

Analyze business processes

Use GermainUX to analyze process performance by:

Analysis dimension	Analysis dimension
Complete process	Process step
User	Team or role
Application and environment	Time period
Outcome	Browser or device
Siebel screen or view	Related error
Related technical KPI

Review both aggregate trends and individual process instances. Aggregate analysis identifies where inefficiency occurs at scale, while instance-level data and Session Replay explain why it occurred for a specific user.

Dashboards

Go to: Workspace > Dashboards > All Search for Siebel dashboards, including:

Siebel Business Process
Siebel Biz Ops

The exact dashboard names available depend on the GermainUX version and installed configuration. Use dashboard filters to select the intended process, application, environment, users, teams, and time range.

Troubleshooting

No process instances appear

Verify that:

The process is enabled.
The source KPIs receive data.
The application and environment match.
The start condition matches an actual event.
The matching fields use the correct case and values.
The configured time range includes the test.
The relevant rule is active.

Steps are missing

Check:

Step conditions
Step ordering
Event names and attributes
Application and environment filters
Correlation identifiers
Whether the source event is collected
Whether the user navigated through an alternate path

Duplicate instances appear

Review:

Whether the start event occurs more than once
Correlation logic
Session and record identifiers
Retry or refresh behavior
Whether concurrent instances are expected
Process-reset conditions

Processes never complete

Verify that:

The completion event is collected.
The completion condition matches its actual attributes.
The final event uses the same correlation identifier.
The workflow can finish in a later session.
The timeout is appropriate.
Alternate successful outcomes are included.

Durations are incorrect

Confirm that:

Engine and browser clocks are synchronized.
Events are ordered by their actual timestamps.
Step boundaries represent the intended milestones.
Background time is intentionally included or excluded.
Multiple sessions and users are correlated correctly.
Repeated steps are handled according to the process design.

Get Help

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.

Prerequisites

Choose the process type

Validate the process

Troubleshooting

​Business-process monitoring overview

​Prerequisites

​Select a process to monitor

​Define the monitoring objective

​Choose the process type

​1 Sequential business process

​Collaborative business process

​Identify the source events

​Define the process

​Define the start condition

​Define process steps

​Define completion and failure

​Correlate events

​Configure expected duration and overrun

​Configure timeout and abandonment

​Configure dimensions

​Configure the process in GermainUX

​Validate the process

​Successful execution

​Slow execution

​Abandoned execution

​Failure execution

​KPIs

​Analyze business processes

​Dashboards

​Troubleshooting

​No process instances appear

​Steps are missing

​Duplicate instances appear

​Processes never complete

​Durations are incorrect

​Related documentation

​Get Help

Contact GermainUX Support

Can't find what you need?

Business-process monitoring overview

Prerequisites

Select a process to monitor

Define the monitoring objective

Choose the process type

1 Sequential business process

Collaborative business process

Identify the source events

Define the process

Define the start condition

Define process steps

Define completion and failure

Correlate events

Configure expected duration and overrun

Configure timeout and abandonment

Configure dimensions

Configure the process in GermainUX

Validate the process

Successful execution

Slow execution

Abandoned execution

Failure execution

KPIs

Analyze business processes

Dashboards

Troubleshooting

No process instances appear

Steps are missing

Duplicate instances appear

Processes never complete

Durations are incorrect

Related documentation

Get Help