Inledning

Service Level Management är en av processerna inom Service Design. Det borde räcka för att säga att det är en av de viktigaste processerna, och det är det verkligen. Enligt vår uppfattning är den av avgörande betydelse för två affärsaspekter, nämligen kundnöjdhet och tjänsteleverantörens ekonomiska effektivitet.

När vi läser ITIL kan vi lära oss att målet med SLM är att:

förhandla fram servicenivåavtal (SLA) med kunderna,
designtjänster i enlighet med de överenskomna målen för servicenivån,
säkerställa att alla operativa nivåavtal (OLA) och underliggande kontrakt (UC) är lämpliga,
övervaka och rapportera om servicenivåer.

SLM-processen förknippas ofta bara med den mer formella delen av den, nämligen att säkerställa att alla SLA finns på plats och att servicenivåerna övervakas. Frågan är dock hur man organiserar SLM-processerna på ett meningsfullt sätt så att de ger värde för både kunder och tjänsteleverantörer.

I den här artikeln vill vi dela med oss av EvergoPartners erfarenheter och tankar kring praktiska aspekter av SLM-implementeringen i gränssnittet mot kunden samt inom tjänsteleverantörens organisation.

SLM – SLR och SLA

Av vad vi har sett hittills finns SLM-processen i gränssnittet mot kunden i någon form i nästan alla organisationer. Det är faktiskt svårt att föreställa sig att det inte finns något avtal mellan kund och tjänsteleverantör som definierar servicenivåer, SLA. Frågan är om de servicenivåer som överenskommits i avtalet är optimala för både kunden och tjänsteleverantören. Risken för kunden är att servicenivåerna blir för höga eller för stora och att priset för tjänsten därmed blir för högt. Å andra sidan kan det hända att servicenivåerna är för låga, vilket kan leda till problem när tjänsten väl är i drift. Risken på tjänsteleverantörssidan är att man inte kan uppfylla de servicenivåer som avtalats, åtminstone inte till de priser som avtalats.

Så hur uppnår man en situation där riskerna minimeras och mildras? Här är det SLM-processen som ger en hjälpande hand.

Till att börja med måste vi samla in kundkrav. Detta är startpunkten för processen. Det är verkligen att rekommendera att insamling och hantering av kraven är välstrukturerad. För att fånga upp kraven måste vi lista alla delar som påverkar servicenivåerna och som i slutändan återspeglas i servicenivåavtalet. Dokumentet kallas Service Level Requirements (SLR). Innehållet i SLR kan variera beroende på vilken tjänst som tillhandahålls, men nedan finns en grundläggande lista som kan användas som utgångspunkt.

* Krav på tjänsten

Krav på kapacitet:
- Antal användare,
- Antal samtidiga användare,
- Krav avseende förändringar av kapaciteten

Krav på tillgänglighet
- Standardtider för service
- Kritiska tider för service
- Max. tid då tjänsten kan vara otillgänglig
- Tröskelvärden för tillgänglighet (t.ex. 99,5 %)
- Svarstider från ansökan

Krav för serviceförfrågningar
- Standardkrav för begäran om service
- Förfaranden för begäran om icke-standardiserade tjänster

Krav på hantering av incidenter
- Olika typer av support (via telefon, fjärråtkomst, på plats)
- Supporttider för 1st Line (Service Desk)
- Reaktionstider,
- Lösningstider (beroende på prioritet)
- Förfaranden för eskalering
Rutiner för planerade driftavbrott
Förfaranden för oplanerade avbrott i tjänster
Krav för ändringsbegäran
Säkerhetskrav

I allmänhet ska SLR fyllas i av kunden eftersom den ska återspegla vad kunden behöver från tjänsten för att stödja sina affärsprocesser. Vi måste dock vara medvetna om att det inte är en engångsföreteelse. Enligt oss kräver det faktiskt grundliga och ibland flera diskussioner med kunden så att båda parter har en gemensam förståelse för kraven och deras inverkan på det framtida samarbetet, för att inte tala om priset för tjänsten. Det hjälper till att rationalisera kundernas förväntningar eftersom det händer att de kräver mer än de faktiskt behöver. Å andra sidan hjälper det också till att hitta luckorna, dvs. saker som kunderna inte har tänkt på eller underskattat. En gemensam överenskommelse om SLR utgör grunden för SLA.

Enligt vad vi har observerat finns det en allmän tendens att fokusera på funktionella krav snarare än på servicenivåkrav och i vissa fall till och med bortse från de sistnämnda i den inledande fasen av tjänstedesignen. Istället rekommenderar vi att man fokuserar på servicenivåkraven för att säkerställa att båda parter har en klar uppfattning om detta redan från början.

SLM – OLA och UC

När vi har fått klarhet i kraven på servicenivå måste vi se till att de återspeglas i hela servicekedjan. Eftersom den tjänst som levereras till kunden (Business Facing Service) vanligtvis består av flera underliggande tekniska tjänster (även kallade Supporting Services) måste vi säkerställa att kraven på servicenivå kan uppfyllas även av de tekniska tjänsterna.

Låt oss ta ett enkelt exempel och föreställa oss en Business Facing Service som består av en applikationstjänst som finns i ett centralt datacenter och som är beroende av en WAN-tjänst som gör att kunden kan komma åt tjänsten från en avlägsen plats. SLR för Business Facing Service är 99% för tillgänglighet är 2 timmar för lösning av högprioriterade incidenter och faktiskt är applikationstjänstens tillgänglighet 99% och lösningstiden för högprioriterade incidenter är 2 timmar. Men för WAN-tjänsten är motsvarande parametrar 97% respektive 4 timmar. Vid en första anblick kan vi se att det finns ett gap, men förvånansvärt nog försummas ofta detta uppenbara faktum.

Baserat på vår erfarenhet kan vi säga att det händer ganska ofta att servicenivåer som överenskommits med kunden inte är kompatibla med servicenivåer som överenskommits mellan olika organisationsenheter som hanterar olika tekniska tjänster, om de överhuvudtaget överenskommits. Det skapar en uppenbar risk för tjänsteleverantören att inte kunna tillhandahålla tjänsten på de nivåer som kunden har åtagit sig. Vad värre är, i många fall är risken okänd.

Detta är platsen för ett Operational Level Agreement (OLA). OLA beskriver det ansvar som varje intern supportgrupp har gentemot andra supportgrupper, inklusive processen och tidsramen för leverans av deras tjänster. Målet med OLA är att presentera en tydlig, koncis och mätbar beskrivning av tjänsteleverantörens interna supportrelationer.

Så vad krävs för att komma överens om OLA? Först och främst måste vi känna till alla beroenden mellan Business Facing Service och underliggande tekniska tjänster samt mellan tekniska tjänster. Med andra ord behöver vi dela upp Business Facing Service i tekniska tjänster och relationerna mellan dem. När det är gjort måste vi få till stånd ett avtal mellan de organisationsenheter som ansvarar för att de tekniska tjänsterna ingår i servicekedjan.

I vårt exempel måste det finnas en OLA mellan den enhet som ansvarar för applikationstjänsten och WAN-tjänsten. Om vi vill vara på den säkra sidan och uppfylla kundernas förväntningar på servicenivåer måste WAN-tjänsten uppgraderas. Det kommer troligen att påverka kostnaderna för WAN-tjänsten och priset för Business Facing Service.

Det kan också hända att en eller flera av de tekniska tjänsterna köps från en tredje part eller att support för de tekniska tjänsterna tillhandahålls av den tredje parten, helt eller delvis. Det är här som så kallade Underpinning Contracts (UC) kommer in i bilden. UC är ett avtal mellan tjänsteleverantören och tredje part baserat på vilket den tredje parten tillhandahåller stödtjänster som gör det möjligt för IT-tjänsteleverantören att leverera en tjänst till en kund. På samma sätt som OLA måste UC vara anpassat till SLA.

I vår situation kan det vara så att både applikationstjänsten och WAN-tjänsten kan ha sin UC som måste anpassas till SLA.

Sammanfattning

Det har varit vår (EvergoPartners) observation att många företag inte implementerar SLM från början till slut och täcker hela servicekedjan. Det kan skapa en risk och kan därför inte vara acceptabelt. Från vårt perspektiv är en kritisk förutsättning för en korrekt implementering av SLM att de affärsnära tjänsterna bryts ned till tekniska tjänster och att det finns ett tydligt ägarskap för de tekniska tjänsterna inom IT-tjänsteleverantörens organisation. När det är gjort kan implementeringen av SLM-processen bli en mycket enklare uppgift, men det kräver fortfarande en del arbete som vi mer än gärna delar med oss av till dig.