SLA på en post-it lapp?
Det händer om och om igen att jag träffar på en IT-leverantör som frustrerat och skamset erkänner – “Vi bör ha men… Vi har inte SLAs med våra kunder.” Därefter följs en längre beskrivning över långa dokument, komplexa upptidsberäkningar samt en kundrelation som kännetecknas av Service Level disAgreement.
Detta är förstås inte syftet med ett SLA. Och nog behöver det inte bli så svårt. I sin enklaste form är SLA en överenskommen leverans mellan kund och leverantör.
Tre bokstäver, 1-2-3…
“Detta vill jag ha” säger kunden.
“Detta kan vi fixa såhär bra” säger leverantören.
“Då kör vi” säger båda och skakar hand.
Magiskt – ett SLA!
Denna magi är egentligen hela grunden för en IT-leverans mellan två parter – vad, vilken nivå, är vi överens? Och idén representeras effektivt av SLAs tre bokstäver:
Service – vad ska levereras?
Level – till vilken nivå?
Agreement – visst är vi två parter överens?
Bokstäverna skapar grund för kunden att veta vad de ska få. Bokstäverna skapar grund för leverantören att veta hur de kan lyckas med leverans. Och inte skulle vi köpa eller leverera IT utan denna grund?
Service Level DISagreement?
Detaljer kan dock försvåra. IT-leveranser är komplexa och när vi strävar efter en ”hundraprocentig” SLA kan det driva tid. Veckor läggs på arkitektur, dagar på övervakningsmetoder, och otroligt nog kan vi lägga tiotals timmar på antal tillåtna ringsignaler i Service Desk… Parallellt växer frustration hos både kund och leverantör och kalendertid tickar på. Ofta uppstår då genvägar och antaganden från både parter, och en leverans som vi INTE är överens om initieras.
Varför inte istället erkänna att en lyckad IT-leverans samt SLA egentligen är någonting som sker i etapper med regelbunden förbättring? Som en agil process bör vi från start erkänna att vi inte kan till 100% definiera vad (S) eller vilken nivå (L). Istället kommer vi överens (A) om en första SLA-version SAMT en aktiv dialog för ytterligare versioner över tid.
Hur att börja?
Sagt på ett annat sätt, varför inte börja som vi gör med våra bästa affärsidéer? Varför inte börja med en post-it lapp? På lappen definiera de mest kritiska S och L och sedan skriv under med A (två stycken). En vecka senare, lägg post-it lappen mitt på en A4-sida. Utveckla S och L som en mindmap på sidan och igen skriv under med era A. En månad senare, lägg A4-sidan mitt på ett blädderblock, utveckla vidare och skriv under.
Tänk då att en enkel post-it lapp kan vara ett fungerande SLA?! En gul 7x12cm papperslapp som hjälper oss att slippa frustrationer och skam. Med dess hjälp har ni inte bara fått fram ett dokument, men tre versioner av ert SLA på en månad. Och ännu viktigare – en fungerande process för leverans och dialog mellan kund och leverantör. Inte illa.
PS – SLAs är viktiga och ska inte uppfattas på annat vis. De komplexa bitar som tillgänglighet, incidenthantering, förändringshantering, m.m. kan och skall definieras. Gärna i post-it-andan (så småningom i dokument och tabell) där detaljer växer fram över tid. Och alltid med dialog och överenskommelse mellan kund och leverantör.
Verktyg, stöd och kunskap i IT Service Management
Onbird har samlat ett antal verktyg, skrifter och kurserbjudanden på vår ITIL-sida.
CIO-utmaningar 2024
SLA på en post-it lapp? av Jeffrey Schmitz | jan 24, 2018 | ITIL/ITSM I takt med att den digitala transformationen accelererar, blir IT alltmer kritiskt för företagens framgång. Trots detta finner sig CIO:er och IT-avdelningar ofta på efterkälken när det gäller deras deltagande…
Scrum Master vs Projektledare
Tillagd: Hur kan rollerna Scrum Master och Projektledare fungera tillsammans på bästa sätt. Vilka är de potentiella konflikterna och hur kan de lösas?
Jo, så är det - ITIL är fortfarande oerhört relevant
Rykten kring ITILs död är överdrivna. Värdet av ITIL and ITSM är fortfarande stort, kanske större. Här kommer fem snabba skäl...