SLA vs OLA

[rhofing]

I am building a small service catalog that will have SLA`s.   I want to better understand SLA's and OLA's.

If I am understanding the difference between the two, the OLA will be attached to individual catalalog tasks. Task 1 has an OLA of 1 day, task 2 has an OLA of 8 hours, etc.

The SLA =, if I am understaing this correctly, applies to the catalog request as a whole (ie one SLA can have one or more OLA's). What I want to undertsand better is the relationship between OLA and SLA.  

So, if the SLA is 5 days, then the total of any OLA's defined have to add up to 5 days?   Is this correct?   If so, is there a check done when defining the SLA's and OLA's to make sure they add up correctly?   For example, if I define an SLA of 3 days, but my OLA's add up to 5 days, will this be flagged?

Thank you!

Ric

[rhofing]

Thank you Chuck, and to everyone else for their comments. I appreciate the help!

Ric

[Chuck Tomasi]

Anytime

[Daniel97]

Hi Chuck

I understand the SN system´s point of view. It is just a tag, to qualify rules under the Service Now SLA module.

But from a functional/commercial stand point, I would usually associate SLA as a agreement to the end customer, and OLA/UC with back-end service providers (internal or external).

For instance, if I have made a statement that my organization will fix some Priority 2 Incident in 8 hours, I could, behind the scenes, have OLA & UC´s with my service lines where they agreed to solve Priority 2 in 4 hours, therefore if one service line fails to solve within it´s OLA, there still time for the 2nd tier to deal with it, and also to meet SLA requirements.

Since under this view OLA/UC rules would reffer specifically to each assignment group name, when this incident changes from 1st group to 2nd, SLAs would still be running and 1st OLA would stop/pause and 2nd OLA would start fresh, right?

In your understanding, is this view somehow violating product base-concepts or industry best practices?

Cordial

Daniel

[Chuck Tomasi]

My definition is based off ITIL's defs. This isn't a hard and fast rule that is going to break your organization if you choose to use them differently. Just be sure that everyone in your organization (and all those involved with your SLA definitions) agree how they are used and what those definitions mean.

[odijk]

Technically, there is no difference between SLAs and OLAs. It is just a marker on the SLA Definition record.

SLA definitions are triggered for records in the table that they are connected to, when the start condition applies and the stop condition does not apply.

Other than that their definitions are stored in the SLA Definition table and that they work in the exact same way, they do not cooperate. They are NOT set up in a way that the SLA that is defined on a Requested Item is automatically the sum of the OLAs that run on the Catalog Tasks for instance. If you want to enforce this, then you must manually make sure (in the SLA/OLA definitions) that the sum of the OLA times is equal to the SLA time. so:

So, if the SLA is 5 days, then the total of any OLA's defined have to add up to 5 days?   Is this correct?   No

If so, is there a check done when defining the SLA's and OLA's to make sure they add up correctly?   No

For example, if I define an SLA of 3 days, but my OLA's add up to 5 days, will this be flagged? No

Of course it all is possible, but you will have to write all the code yourself. (not recommended, considering the quite nifty method that ServiceNow uses to calculate durations with different time zones and schedules).

From a functional point of view:

An SLA is a contract between the IT Organization and the End User

An OLA is a contract between IT departments

An UC is a contract between the IT organization and suppliers.

Even tough you would WANT these contracts to be in line, this is rarely the case. When setting up SLAs, OLAs and UCs, it is recommended to make sure the content of the contracts is reflected in ServiceNow. After you have done that you can create some reports to see where there is a gap between the UCs, OLAs and SLAs. Those reports can be used to adjust the contracts (and that can be used to adjust the SLAs, OLAs and UCs.)

I ´m sure it is not the answer you were looking for, but I hope it helps.