SLM Module Use Cases

[saket-jp]

Hi,

Looking to learn about the purpose and how SLM module should be utilized?  I am looking to hear about practical examples and use cases where SLM was used to drive organizational SLAs across service management processes.

Thanks

Saket

[Tommy SN Sahlin]

Hi saket-jp,

I'm very interested in this topic as well, so am subscribing to your post and hope to also be able to contribute.

cheers  /Tommy

[Daniel97]

Hello All

So far we have used like this:

SLA´s - From organization to end customer. Measured only against Service (Catalogs).

OLA=UC´s (not using UCs tags since from the system perspective they are the same) - From internal service lines to the organization.

Ideally we think of SLA definition value (amount of time) as being at least equal to the OLA, preferably SLA > OLA.

SLA´s do not change when assignment groups change, they keep counting. OLA´s MUST freeze when solution group changes.

This is somehow troublesome to manage if you have too many solution groups, since for this to work, we have yet not found another way then to have rules that reffer specifically to each solution group name.

SLA (OLA/UC) rules (stored under contract_sla table) when triggered, they do start "time counters" (under task_sla table). Those counters we are used to call them TIMMERS. Our SLM reports are not TICKET-based reports, they are TIMMERS-based reports.

A "average/normal" incident, under a "New" status would have FOUR active timmers:

- SLA RESPONSE TIMMER

- SLA RESOLUTION TIMMER

- OLA RESPONSE TIMMER

- OLA RESOLUTION TIMMER

Our SLA´s and OLA´s for incident´s are Priority-driven, based on priorities from 1 to 4.

Service Requests are trickier, they do not relate to Priority. Instead, they relate to the "subject matter". So installing a new ethernet socket in a already cabled room could have a 8 hours target, and a new ethernet point in a non-cabled area could have a 30 days target. So it relates to the service catalog, catalog driven, having rules that reffer specifically to catalog item for SLA´s and catalog item+solution group namelly for OLA´s.

And it gets trickier in some cases (those we expect no to happen, but they insist to occur) where SR´s travel between solution groups. Take a request to set up VPN on a tablet, not a incident but a request, but sometimes, due to - for instance - syncrhonization or security feature policies "Mobile Field Services" solution groups cannot solve it alone, pehaps having to ask (transfering the same SR) to Security or other service line group. Since that secondary service line is not "officially" related to the "Configure VPN on tablet" catalog Item (there is no OLA rule specifficaly to Item+group), in this case this ticket tends to exist without an active OLA timmer. Still looking for solution or workaround to this, since we expect all active tickets to have OLA resolution timmers active at all active times.

Hope this helps, at least to fire up this forum.

[Daniel97]

Hello All

So far we have used like this:

SLA´s - From organization to end customer. Measured only against Service (Catalogs).

OLA=UC´s (not using UCs tags since from the system perspective they are the same) - From internal service lines to the organization.

Ideally we think of SLA definition value (amount of time) as being at least equal to the OLA, preferably SLA > OLA.

SLA´s do not change when assignment groups change, they keep counting. OLA´s MUST freeze when solution group changes.

This is somehow troublesome to manage if you have too many solution groups, since for this to work, we have yet not found another way then to have rules that reffer specifically to each solution group name.

SLA (OLA/UC) rules (stored under contract_sla table) when triggered, they do start "time counters" (under task_sla table). Those counters we are used to call them TIMMERS. Our SLM reports are not TICKET-based reports, they are TIMMERS-based reports.

A "average/normal" incident, under a "New" status would have FOUR active timmers:

- SLA RESPONSE TIMMER

- SLA RESOLUTION TIMMER

- OLA RESPONSE TIMMER

- OLA RESOLUTION TIMMER

Our SLA´s and OLA´s for incident´s are Priority-driven, based on priorities from 1 to 4.

Service Requests are trickier, they do not relate to Priority. Instead, they relate to the "subject matter". So installing a new ethernet socket in a already cabled room could have a 8 hours target, and a new ethernet point in a non-cabled area could have a 30 days target. So it relates to the service catalog, catalog driven, having rules that reffer specifically to catalog item for SLA´s and catalog item+solution group namelly for OLA´s.

And it gets trickier in some cases (those we expect no to happen, but they insist to occur) where SR´s travel between solution groups. Take a request to set up VPN on a tablet, not a incident but a request, but sometimes, due to - for instance - syncrhonization or security feature policies "Mobile Field Services" solution groups cannot solve it alone, pehaps having to ask (transfering the same SR) to Security or other service line group. Since that secondary service line is not "officially" related to the "Configure VPN on tablet" catalog Item (there is no OLA rule specifficaly to Item+group), in this case this ticket tends to exist without an active OLA timmer. Still looking for solution or workaround to this, since we expect all active tickets to have OLA resolution timmers active at all active times.

Hope this helps, at least to fire up this forum.