Business Process Monitoring for Oracle Siebel CRM (Configure)

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

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:

See:

• RUM JS Deployment for Oracle Siebel CRM

• Engine Deployment for Oracle Siebel CRM

🔍 Select a process to monitor

Begin with workflows that are critical, frequent, slow, error-prone, or costly.

Common Siebel examples include:

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.

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.

☝️ Identify the source events

Each process step must be driven by data that GermainUX collects.

Possible source events include:

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.

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:

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

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

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.

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:

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:

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

• Oracle Siebel CRM Monitoring Configuration

• User Monitoring and Session Replay for Oracle Siebel CRM

• Error Monitoring for Oracle Siebel CRM

• KPIs for Oracle Siebel CRM

ℹ️ Get More Information

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

Contact GermainUX Support.