Outlier Detection for Oracle Siebel CRM (Configuration)

⚙️ Configure Outlier and Anomaly Detection for Oracle Siebel CRM

GermainUX detects unusual behavior in Oracle Siebel CRM that may be hidden within large volumes of normal user, application, component, error, and business-process data.

It can help identify:

• A new error among recurring errors

• An abnormal increase in Object Manager response time

• A component using an unusual percentage of its task capacity

• A sudden increase in crashes

• A workflow becoming slower than its historical baseline

• An unexpected decline in user activity

• A Siebel server behaving differently from comparable servers

• A record or process that stops progressing

• An issue affecting one team, region, browser, server, or application version

🔍 Outlier, anomaly, and SLA violation

These terms describe different conditions.

A condition can satisfy more than one definition. For example, a response-time spike can be both statistically anomalous and above its SLA.

🛠 Detection mechanisms

No single method detects every type of unusual Siebel behavior. Combine the mechanisms appropriate to the monitored data.

See Outlier and Anomaly Detection.

📋 Prerequisites

Before enabling anomaly detection:

• Deploy and connect the GermainUX Engine.

• Configure the required Siebel data sources.

• Confirm that the selected KPIs receive consistent data.

• Verify application, environment, server, and component dimensions.

• Collect sufficient representative historical data.

• Identify normal business periods and maintenance windows.

• Configure error and crash categorization where applicable.

• Define who will investigate and respond to detected anomalies.

• Confirm that detected conditions can be validated against raw instances.

An unreliable or incomplete source KPI will produce unreliable anomaly results.

🎯 Select Siebel KPIs to analyze

Begin with KPIs tied to meaningful operational or user outcomes.

👥 User-experience KPIs

Examples include:

• Siebel user-click duration

• Page, screen, or view performance

• Network-request duration

• Browser errors

• User-facing application errors

• Session duration

• Business-process duration

• Process-step duration

• Workflow overrun

• Abandonment or timeout

🖥️ Application and component KPIs

Examples include:

• Component availability

• Component run state

• Running tasks

• Task-utilization percentage

• Tasks per process

• Active MTS processes

• MTS-process utilization

• Server Manager response

• HTTP and SISNAPI availability

• Object Manager errors

• Log-error volume

• Crash volume

🏭 Infrastructure and database KPIs

Examples include:

• CPU

• Memory

• Disk

• Network

• Database response time

• Connection or session volume

• SQL duration

• Query volume

• Integration response time

Avoid enabling anomaly detection indiscriminately on every available KPI. Start with KPIs for which an unexpected change would require investigation or action.

📊 Establish a baseline

Smart Insights requires representative historical behavior.

The baseline should include:

• Normal business days

• Busy and quiet periods

• Weekday and weekend differences

• Regular batch or maintenance activity

• Seasonal patterns

• Expected regional differences

• Normal application releases when appropriate

• Representative user and transaction volume

Do not establish a baseline using only:

• An outage

• A load test

• A migration period

• An unusual business event

• An incomplete deployment

• A period with missing data

Wait until monitoring is stable before treating statistical results as operational alerts.

🔁 Use business-period comparisons

Siebel activity often follows predictable time patterns.

Compare current behavior with the appropriate historical period, such as:

• Same time on previous business days

• Same weekday in previous weeks

• Current business hour versus equivalent business hours

• Month-end versus prior month-end periods

• Peak contact-center hours versus previous peak periods

Comparing Monday morning with Sunday night can produce an apparent anomaly that is simply normal business behavior.

🏷️ Select dimensions

Dimensions help determine whether an anomaly affects the entire environment or one segment.

Useful Siebel dimensions include:

• Application

• Environment

• Enterprise

• Server

• Component

• Object Manager

• Screen

• View

• Applet

• User

• Team

• Role

• Department

• Region

• Browser

• Application version

• Business process

• Process step

• Error category

• Integration endpoint

Avoid dimensions with excessive cardinality unless the analysis requires instance-level detail. Extremely granular segmentation can create insufficient data per segment and unstable results.

🔧 Configure Smart Insights

Configure Smart Insights for the selected KPI and measure.

For each configuration:

1. Select the KPI.

2. Select the measure to analyze.

3. Define the application and environment scope.

4. Add the dimensions required for segmentation.

5. Select the relevant business-period comparison.

6. Exclude planned maintenance and nonrepresentative periods.

7. Allow sufficient time to establish a baseline.

8. Review detected increases, decreases, spikes, and deviations.

9. Validate results against individual facts.

10. Configure alerts only after the detection quality is acceptable.

Useful measures include:

• Count

• Average

• Median

• Percentile

• Maximum

• Error rate

• Availability percentage

• Unique users

• Completion rate

• Overrun

• Task-utilization percentage

Use percentiles instead of averages when a small group of slow transactions would otherwise be hidden.

📁 Configure categorization

Categorization is appropriate for high-volume events with repeated signatures, including:

• Object Manager errors

• JavaScript exceptions

• User-facing errors

• Crashes

• Log messages

• Failed transactions

It helps answer:

• Is this issue new or known?

• How often does this category occur?

• Is its frequency increasing?

• Which users, applications, or components are affected?

• Did the category appear after a release?

Normalize variable values such as record IDs, usernames, timestamps, and transaction identifiers before generating categories.

See:

📖 Configure Document Audit

Use Document Audit when the unusual condition involves a Siebel record or business object rather than a technical metric.

Examples include:

• A Service Request remains in one status for too long.

• An Order changes to an unexpected status.

• A record is updated unusually often.

• Customer data stops synchronizing.

• A process skips a required status.

• A record changes outside the expected workflow.

Document Audit can retain:

• Record identifier

• Changed field

• Previous value

• New value

• Change timestamp

• User or process responsible, when available

• Time spent in a status

Combine the audit data with Smart Insights to detect abnormal volumes, missing changes, or unusual status durations.

🔗 Combine detection methods

🛡️ Configure fixed SLAs

Statistical anomaly detection complements rather than replaces fixed thresholds.

Use fixed SLAs for conditions with a known operational boundary, such as:

• Component unavailable

• HTTP endpoint unavailable

• Task utilization above 95%

• Critical error detected

• Crash detected

• Process duration exceeding a committed target

Use Smart Insights when the expected value changes by business period or when no single static threshold represents normal behavior.

🔔 Configure alerts

Alert only when the detected condition requires action.

An alert should include:

• KPI and measure

• Current value

• Expected or baseline value

• Direction and magnitude of the deviation

• Affected application and environment

• Affected server, component, user group, or workflow

• Number of affected users or instances

• Related errors and KPIs

• Link to the corresponding analysis

• Recommended owner

Consider requiring persistence or multiple observations before alerting on noisy metrics. Do not delay alerts for immediate conditions such as a critical component outage or a new high-impact crash.

Use maintenance periods to suppress expected deviations during planned work.

✅ Validate the configuration

Before relying on anomaly alerts:

1. Review several detected anomalies manually.

2. Confirm that the source data is complete.

3. Compare the detected period with the correct business period.

4. Review the underlying raw instances.

5. Confirm that the dimensions identify the affected segment.

6. Determine whether the change is operationally meaningful.

7. Check for releases, maintenance, holidays, or volume changes.

8. Verify that related KPIs support the finding.

9. Adjust the scope or comparison period if false positives are excessive.

10. Test alert routing.

Do not treat every statistical deviation as a defect. A change can be valid, expected, or beneficial.

⚙️ Investigation workflow

When GermainUX detects unusual Siebel behavior:

1. Detect the condition through Smart Insights, categorization, Error Analysis, Document Audit, or an SLA.

2. Quantify its magnitude, duration, frequency, affected users, and business impact.

3. Segment by application, server, component, user group, process, region, browser, or version.

4. Correlate the anomaly with related KPIs and events.

5. Inspect representative instances in the Analysis Dashboard.

6. Replay or trace an affected user session, workflow, request, or server transaction.

7. Identify the likely technical or process cause.

8. Correct the issue.

9. Verify that the KPI returns to its expected range.

10. Document or automate the response for future occurrences.

💡 Examples

Abnormal Object Manager response time

GermainUX detects that one Object Manager is slower than its historical baseline.

Investigate:

• Server and component

• Task utilization

• Active MTS processes

• Error volume

• Database response

• Integration activity

• Affected screens and users

• Recent releases or configuration changes

New crash spike

GermainUX identifies a new crash category and an abnormal increase in its frequency.

Investigate:

• Stack-trace category

• Affected Object Managers

• First occurrence

• Recent deployment

• Related error codes

• Affected users and sessions

• FDR and core evidence

Workflow slowdown

A Service Request process remains within its fixed SLA but is significantly slower than its historical baseline for one team.

Investigate:

• Slow process steps

• User and team

• Screen and view

• User validations

• Repeated activity

• Related browser and server errors

• Session Replay

🔧 Troubleshooting

Too many anomalies

Review:

• Baseline quality

• Comparison period

• KPI stability

• Maintenance exclusions

• Segmentation cardinality

• Minimum data volume

• Recent releases

• Normal seasonal behavior

No anomalies are detected

Verify:

• The KPI receives data.

• Smart Insights is enabled.

• The correct measure is selected.

• Enough historical data exists.

• The configured application and environment match.

• Filters are not excluding all data.

• The analysis period contains activity.

Expected business peaks generate alerts

Use a business-period comparison that includes the same expected peak and exclude special events that should not become part of the normal baseline.

A detected anomaly has no user impact

Determine whether it still represents a capacity, reliability, compliance, or future-risk issue. If it does not require action, reduce its priority or remove the alert while preserving the insight for analysis.

📚 Related Documentation

• Dashboard and Reports

• AI Insights & Recommendations

• Other Analytics Features

• Other Automation Features

ℹ️ Get Help

The Germain Team can help you set this up. Contact GermainUX Support.