> ## Documentation Index
> Fetch the complete documentation index at: https://docs.germainux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Business Process Monitoring for Oracle Siebel CRM (Configure)

> GermainUX monitors Oracle Siebel CRM business processes and identifies where workflows become slow, inefficient, repetitive, or incomplete.

Components
[`GermainUX RUM JS`](https://docs.germainux.com/main/germain-ux-rum-js)
`GermainUX Engine Feature availability: GermainUX 2017.2 or later`
[`Engine`](https://docs.germainux.com/main/germain-ux-engine)
[`JS Profiler`](https://docs.germainux.com/main/germain-ux-js-profiler)
[`Mobile App`](https://docs.germainux.com/main/germain-ux-mobile-app)
[`RPA Bot Recorder`](https://docs.germainux.com/main/germain-ux-rpa-bot-recorder)
[`RUM JS`](https://docs.germainux.com/main/germain-ux-rum-js)

Availability
2014.1 or later

> [card] [Prerequisites](#prerequisites)
>
> Docs to read first

> [card] [Choose the process type](#choose-the-process-type)
>
> Models of business processes

> [card] [Validate the process](#validate-the-process)
>
> Test with real executions

> [card] [Troubleshooting](#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:

* [RUM JS Deployment for Oracle Siebel CRM](https://docs.germainux.com/main/deploy-rum-js-siebel-openui.md)
* [Engine Deployment for Oracle Siebel CRM](https://docs.germainux.com/main/engine-deployment-for-oracle-siebel-crm.md)

## 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:

**1. Open the Service Request screen**

**2. Create a new Service Request**

**3. Enter customer and issue details**

**4. Assign the Service Request**

**5. Resolve the issue**

**6. 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](https://docs.germainux.com/main/business-process-workflow-monitoring.md).

## 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:

```text theme={null}
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

> [accordion] 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:

```text theme={null}
Overrun = Actual duration - Expected duration
```

For example:

```text theme={null}
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:

**1. Create the process definition**

**2. Select the process type**

**3. Associate it with the Siebel application**

**4. Define the start condition**

**5. Add the process steps**

**6. Define matching conditions for each step**

**7. Configure correlation**

**8. Define completion and failure conditions**

**9. Set expected process and step durations**

**10. Set the timeout**

**11. Add permitted dimensions**

**12. Save and enable the process**

Detailed configuration guidance is available in [Business Process and Workflow Mining](https://docs.germainux.com/main/business-process-workflow-monitoring.md).

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

> [accordion] Show all 9
>
> * Overrun
> * Lost productivity
> * Process outcome

See [KPIs for Oracle Siebel CRM](https://docs.germainux.com/main/oracle-siebel-crm-monitoring-kpis.md).

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.

## Related documentation

* [Business Process and Workflow Mining](https://docs.germainux.com/main/business-process-workflow-monitoring.md)
* [Oracle Siebel CRM Monitoring Configuration](https://docs.germainux.com/main/oracle-siebel-crm-monitoring-configuration.md)
* [User Monitoring and Session Replay for Oracle Siebel CRM](https://docs.germainux.com/main/siebel-user-monitoring-and-replay-configuration.md)
* [Error Monitoring for Oracle Siebel CRM](https://docs.germainux.com/main/siebel-error-monitoring-configuration.md)
* [KPIs for Oracle Siebel CRM](https://docs.germainux.com/main/oracle-siebel-crm-monitoring-kpis.md)

## Get Help

> [card] [Contact GermainUX Support](https://docs.germainux.com/main/support.md)
>
> 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.

> [card] 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.