Improvement opportunities examples

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Improvement Opportunities Examples

    This document outlines practical use cases for defining improvement opportunities within ServiceNow by leveraging finding rules and conditions. These examples help organizations identify inefficiencies and bottlenecks in incident management processes, such as record reassignment patterns, SLA breaches, and delays in task creation. By configuring specific start and end conditions, ServiceNow customers can pinpoint areas requiring operational improvements and take targeted actions.

    Show full answer Show less

    Use Case Examples and Configuration Guidance

    • Use Case 1a: Record Bouncing Between Groups
      Enables detection of records that are reassigned from an initial group (e.g., Service Desk) to another group and then resolved again by the initial group.
      • Start condition: Incident assigned to the initial group (e.g., Service Desk), matching the first occurrence.
      • End condition: Incident reassigned back to the initial group, matching the last occurrence.
      • Duration tracking is enabled to measure the time between these assignments.
    • Use Case 1b: Detect All Bouncing Records Between Groups
      Identifies all records bouncing between groups without specifying the initial group, capturing all occurrences where assignment groups change.
      • Start condition: Incident assigned to any group, first occurrence.
      • End condition: Incident assigned to any group, all occurrences.
      • Relation constraint ensures the same assignment group is considered.
      • Duration tracking enabled.
    • Use Case 2: SLA Breach Occurrences
      Highlights records that were in the "New" state at the time an SLA breach occurred.
      • Start condition: Incident state is "New" at first occurrence.
      • Contextual condition: SLA breach detected when “Made SLA” field is false (requires “Made SLA” as an activity definition).
      • End condition: Incident state changes to "Work in Progress" with SLA made true.
      • Duration tracking enabled to measure time between these states.
    • Use Case 3: Delay Over Six Hours Between Parent State and Task Creation
      Detects cases where it took longer than six hours to create underlying tasks after the parent incident entered "Work in Progress."
      • Start condition: Parent incident state changes to "Work in Progress" (first occurrence).
      • End condition: Incident task creation event, with a minimum duration constraint of six hours.
      • Duration tracking enabled to measure the delay.

    Practical Benefits for ServiceNow Customers

    • Identify inefficient workflows and record reassignment patterns that delay resolution.
    • Monitor SLA breaches in relation to incident states to prioritize corrective actions.
    • Detect delays in task initiation that impact overall resolution times.
    • Leverage configurable finding rules to tailor detection based on organizational processes.
    • Use duration tracking to quantify delays and support continuous improvement initiatives.

    The finding definitions use cases are described below.

    Use case 1a: Record bouncing between groups. Analysts often want to identify records that go from a particular group (for example service desk), then reassign to another group, and eventually resolved by the initial group again.record bouncing between groups

    In case the initial group is known, use the following finding rule: Message and category.
    • Start condition table config: incident
    • Start condition
      • Name: group name, for example, Service Desk
      • Condition type: Field/value condition
      • Field = Assignment Group
      • Predicate = Is
      • Field value = Service Desk
      • Occurrence(s) to match: first only
    Relation: eventually followed by
    • End condition table config: incident
    • End condition
      • Name: group name, for example Service Desk
      • Condition type: Field/value condition
      • Field=Assignment group
      • Predicate= Is
      • Field value = Service Desk
      • Occurrence(s) to match: last only
      • Track duration: true

    Use case 1b: In case all bouncing records between groups with similar initial group must be identified, use the Message and category finding rule.

    • Start condition table config: incident
    • Start condition
      • Name: Assignment group is anything
      • Condition type: Field/value condition
      • Field = Assignment group
      • Predicate = Is anything
      • Occurrence(s) to match: first only
    Relation: eventually followed by
    • End condition table config: incident
    • End condition
      • Name: Assignment group is anything
      • Condition type: Field/value condition
      • Field=Assignment group
      • Predicate=Is anything
      • Occurrence(s) to match: all
      • Track duration: true
      • Relation constraint: Has the same assignment group

    Use case 2: SLA breach. Show all records that were in the state New, while the SLA breach happened.SLA breach flow

    After you give the finding definition a message and category, specify the finding rule as follows.
    • Start condition table config: incident
    • Start condition
      • Name=state
      • Condition type: Field/value condition
      • Field=State
      • Predicate=Is
      • Field value=New
      • Occurrence(s) to match=first only
    • Contextual condition:
      • Name=SLA breach
      • Finding Def= Add the finding def message
      • Condition type= Contextual field/value condition
      • Field=Made SLA (make sure you have Made SLA defined as activity definition in your project)
      • Predicate=is not
      • Field value=true
    • Relation: directly followed by
    • End condition table config: incident
    • End condition
      • Name: State
      • Condition type: Field/value condition
      • Field=State
      • Predicate=is
      • Field value=Work in progress
      • Occurrence(s) to match=first only
    • Contextual condition:
      • Name=SLA breach
      • Condition type= Contextual field/value condition
      • Field=Made SLA (make sure you have Made SLA defined as activity definition in your project)
      • Predicate=is
      • Field value=true
    • Track duration: true
    SLA breach

    Use case 3: Longer than six hours between parent state Work in Progress and task creation. The resolution time or records often depends on the completion of one or more tasks. To improve the solution time of the main record, it’s therefore important to start the tasks as quickly as possible after the main records reached the Work in Progress state. In this example, the user wants to find all records where it took longer than six hours to create the underlying tasks after the main record went into Work in Progress. After giving the Finding definition a message and category, specify the finding rule as follows.

    • Start condition table config: Parent, for example incident
    • Start condition
      • Name: First occurrence of Work in Progress
      • Condition type: Field/value condition
      • Field=State
      • Predicate=Is
      • Field value=Work in progress
      • Occurrence(s) to match: first, only
        • Relation: eventually followed by
        • End condition table config: incident task
        • End condition
          • Name=incident task start
          • Condition type=Process start
            • Constraint: Minimum duration is 6 hours
            • Track duration: true finding definition occurrence
    finding rule specification