Improvement opportunities examples
Summarize
Summary of Improvement Opportunities Examples
This guide outlines practical use cases for identifying improvement opportunities within ServiceNow records, focusing on patterns in assignment group changes, SLA breaches, and task creation delays. These examples help analysts detect inefficiencies and bottlenecks by defining specific finding rules using field conditions and process timings.
Show less
Use Case 1: Record Bouncing Between Groups
These examples help identify records that move between assignment groups, which can indicate process inefficiencies:
- Use Case 1a: Detects incidents that return to the initial assignment group after reassignment. Analysts configure finding rules by specifying the initial group in the start and end conditions, tracking the duration of the bounce.
- Use Case 1b: Identifies all bouncing records moving between any groups but with the same initial assignment group. It uses broader conditions for assignment groups with constraints ensuring the same group reappears, also tracking duration.
Use Case 2: SLA Breach During New State
This use case detects records in the 'New' state during an SLA breach event. The finding rule links the state condition with a contextual SLA breach condition (based on the 'Made SLA' activity definition). It tracks transitions from 'New' to 'Work in Progress' states with SLA breach context, allowing you to pinpoint records affected by SLA violations during initial processing.
Use Case 3: Delayed Task Creation After Work in Progress
This scenario highlights records where task creation is delayed beyond six hours after the parent record enters the 'Work in Progress' state. The finding rule tracks the time between the parent incident state change and the start of associated incident tasks, helping identify delays that impact resolution times.
Practical Application for ServiceNow Customers
By configuring these finding rules with precise start and end conditions, field value checks, and duration tracking, ServiceNow customers can:
- Quickly identify inefficiencies like record bouncing or delayed task initiation.
- Monitor SLA breaches in specific states to improve service quality.
- Gain actionable insights to optimize assignment processes and task workflows.
These examples serve as templates that you can adapt to your environment, enabling targeted analysis and continuous improvement within your incident and task management processes.
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.
- 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
- 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
- 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.
- 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
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