How to set up SLA/OLA in big organization?

[Jakub K_]

Hey Everyone,

Before asking question, let me set the scene:

• 3000+ active support groups for Incident Management
• Multiple departments, supported by hundreds of IT teams in different regions, time zones and working schedules

Our Goal: Set up Incident Management SLAs supported by OLAs for the entire company in a way it is easy to configure/maintain and will not impact the platform performance. How we can achieve that?

Suggested SLA/OLA design:

There are two challenges:

1. Ensure, that OLAs store the information about Assignment_Groups, so we can easily track which group had trouble to achieve OLA for breached SLA incidents.
   We want to address that by appending task_sla record for SLAs/OLAs to new table (let's call it u_task_sla_history) so we can also note the reference to Support Group and Assignee for each record.
2. Implement easy to manage and maintain set of SLA/OLA definitions, having in mind each Support Group may use different Work Schedule, Time Zone and holiday calendar.
   We have trouble to understand best approach for doing this.

[scott barnard1]

You can create a standard set of SLA and OLA is you have a very standard organisation.

From experience most large organisations are not actually large organisations but groups of smaller ones that are affiliated.

My current org is only about 2200 fulfiller across 30+ countries service 150k ish end users so not your scale. However a single set of "standard" SLA's OLA's has been tried and found not workable.

Previously I worked for a large US outfit that had many thousands of support groups supporting multiple accounts across the world. Again it didn't work as each account had a master service agreement and local SLA's and each functional capability had OLA's and even regional variants.

So the concept is sound and having a template is great

However if two entities agree that the measure of their performance is X and you only deal with Y you are backing yourself into a corner.

Just my 2 cents

[User661539]

Hi Jakub,

You have very well described the challenge we also have in our organisation.We have multiple assignment groups per country and Supporting services with OLAs also have challenges to understand the best approach for this. Our Challenge is as you say 

1.  to capture the Assignment group (or in our case also Supporting service name) for each started OLA  and (
2.  Keep the set of OLAs  as generic  as possible and optimize  the numbers still able to differentiate OLAs for the priorities, type ( response, resolution,..) and also the schedule to use.

If we could store assignment group and Service name per task OLA it should reduce the numbers drastically. Have you done any progress in the area and implemented any additional table to capture the information or received any other recommendations? 

[Daniel97]

Hi Jakub,

I also feel this same pain.

Assuming:

- Incident only

- 3.000 support groups

- 4 priority levels

- Timezone only set by solution group (not by Requesting User or Reported CI)

- Schedule only set by solution group (not by Requesting User or Reported CI)

- Incident response time set by leaving a single status that once past never returns

- OLA response time set by the moment you have Assignee (person) <> empty, and that manually you cannot force this situation

I understand that your scenario could be addressed, in a fashion that is not optimal but would work, by the minimum of:

- 4 SLA Response Rules, per Priority

- 4 SLA Resolution Rules, per Priority

- 12.000 OLA Response Rules, per Priority & per group

- 12.000 OLA Resolution Rules, per Priority & per group

So.. 24.008 rules. And some Business Rule to automate your u_task_sla_history records.

And this, I understand, is real the pain here (it is already painfull suposing my simplified assumptions are in place, and could be worst if a more complex environment): How to manage those +24K rules efficiently and always correctly? Specially if you have 3000 "live" groups ecosystem, the chance of having 5 new groups IN, and 5 terminated groups OUT every single day, having to keep consistent SLA module & it´s rules is uber-challenging.

My solution would start by customizing a new SLA/OLA base-parameter table, such as u_slm_base_definitions, and by creating a relation to it from the Groups form. Once a Group is saved with a link to the "SLM Base Definition", a Business Rule would "automatically" drop (or deactivate) any previious contract_sla *OLA entry* for that particular group and add the brand new set of OLAs (8 rules for the example above per group). 

The main objective of this solution is to avoid the manual administrative effort (and QA compliancy effort) to keep the contract_sla table sharp & up-to-date.

Any thoughts?

And how about rules that are not Priority-Driven such as, Service Requests that could be Catalog Item-Driven? If you had only 100 Catalog Items, in order to have OLAs (resolution and response) for every single possible scenario (considering a mandatory business requirement that no IN or SR EVER goes without both OLA´s, and that free transfer of SR´s among any solution group is completely allowed), so there would be 2 x 100 x 3000 = 600.000 OLA rules? Terrifying!!

Cordial