OLA's and SLA's

[Diane22]

We need to implement three use cases pertaining to agreements.

Case # 1:

RITM has 2 tasks, which run in parallel (no dependencies)

Task # 1 = OLA is set to 3 days

Task # 2 = OLA is set to 2 days

RITM = SLA is set to 3 days to set the user expectation

Case # 2

RITM has 3 tasks, which run sequentially (dependencies)

Task # 1 = OLA is set to 1 day

Task # 2 = OLA is set to 2 days (starts after task # 1 in the conditions)

Task # 3 = OLA is set to 2 days (starts after task # 2 in the conditions)

RITM = SLA is set to 5 days 

Case # 3

RITM has 3 tasks, with a run mix

Task # 1 = OLA is set to 5 days

Task # 2 = OLA is set to 2 days (starts after task # 1 in the conditions)

Task # 3 = OLA is set to 10 days (starts after task # 1 in the conditions)

RITM = SLA to be set to 15 days 

Configuring the OLA is easy enough, and dealing with the sequence also straightforward using the conditions.  What I'm not finding is how to configure the actual SLA which encompasses all tasks and set the user expectation for delivery timeline.  We would be displaying that number in the Delivery Timeline field (which is a text field), but would also want to measure the workflow as a whole, with the related OLA information and the performance of the contributing teams.

There are no pause conditions, and the OLA clock stops once the task is closed complete or incomplete.

The RITM (SLA) clock stops once all tasks are no longer active.  Ad Hoc tasks are not included.

 

[Brian Lancaster]

Unless your are using catalog tasks for approval you cannot put an OLA on an approval. SLA configuration can only be put on tables that are extended from the Task table like incident, sc_request, sc_req_item, incident, problem, etc.

[Brian Lancaster]

I don't think you can put OLA in the SLA Breakdown. SLA Breakdown definitions are for things like assignment group and assigned to on the tables the SLA/OLA is associated with.

[M Talha]

Hi @Brian Lancaster 

You’re correct that SLA Breakdown Definitions are primarily for attributes like assignment groups and do not include OLAs directly. Instead:

1. SLA Breakdown: Tracks details about the SLA but doesn't include OLA information.
2. Linking OLAs: Monitor OLAs separately and report them alongside SLAs.
3. Reporting: Use reporting tools to correlate OLA performance with SLA compliance for improvement insights.

Thank you for the clarification!Mark it helpful if this helps you to understand.

[M Talha]

Hi @Diane22   For this how you can approach the implementation of the three use cases related to agreements, focusing on configuring SLAs and OLAs while ensuring user expectations are properly set.

Case #1: Parallel Tasks with RITM SLA

1. Configure OLAs:

   • For Task #1, set the OLA to 3 days.
   • For Task #2, set the OLA to 2 days.

2. Configure SLA for RITM:

   • Set the SLA for the RITM to 3 days. This aligns with the maximum OLA, ensuring user expectations are met.
   • Use business rules to stop the SLA clock once both tasks are completed (either complete or incomplete).

3. Delivery Timeline Calculation:

   • Set up a script in the Delivery Timeline field to display the SLA duration of 3 days, which represents the user expectation.

Case #2: Sequential Tasks with Dependencies

1. Configure OLAs:

   • Task #1: OLA set to 1 day.
   • Task #2: OLA set to 2 days, dependent on Task #1.
   • Task #3: OLA set to 2 days, dependent on Task #2.

2. Configure SLA for RITM:

   • Set the SLA for the RITM to 5 days. This should encompass the total time expected to complete all tasks sequentially.
   • Implement business rules to calculate the SLA based on the sum of OLAs (1 + 2 + 2 days).

3. Delivery Timeline Calculation:

   • In the Delivery Timeline field, calculate and display the SLA duration of 5 days.

Case #3: Mixed Task Execution

1. Configure OLAs:

   • Task #1: OLA set to 5 days.
   • Task #2: OLA set to 2 days, dependent on Task #1.
   • Task #3: OLA set to 10 days, also dependent on Task #1.

2. Configure SLA for RITM:

   • Set the SLA for the RITM to 15 days. This total should account for the longest path considering the OLAs.
   • For example, the overall timeline can be represented as the maximum OLA from Task #1 (5 days) plus the OLAs for Tasks #2 and #3 when applicable.

3. Delivery Timeline Calculation:

   • In the Delivery Timeline field, show the SLA duration of 15 days.

Additional Considerations

• SLA Stop Conditions: Ensure the SLA clock stops when all tasks are inactive. This can be implemented using business rules that check the state of the related tasks.

• Performance Metrics: Consider creating a dashboard or report that measures the performance of the contributing teams based on OLA and SLA compliance.

• Ad Hoc Tasks: Since these tasks are not included in the SLA calculations, make sure the logic for their exclusion is clearly defined in your business rules.

By following these guidelines, you can effectively configure the SLAs and OLAs for each case, ensuring user expectations are clearly communicated and monitored within ServiceNow. If you need further assistance or specific code examples, feel free to ask!

"If you find this helpful, please mark it as helpful!"

[Diane22]

I believe the actual link to the Request ITEM is established inside the OLA, using this field.  When I do it this way, I get both the SLA and the OLA ...  still testing