Att ta fram en ny IT-tjänst som ska generera ett specifikt värde i verksamheten kan vara väldigt komplext. Ofta är det flera olika organisationer som deltar i arbetet där var och en har sitt eget perspektiv på vad som är viktigt.
Ett exempel är om det ska utvecklas en ny applikation och projektet koncentrerar all sin kraft på funktionaliteten i applikationen. När applikationen är klar så upptäcks det att den inte passar in i den övriga IT-infrastrukturen, de verktyg vi använder för alla andra applikationer fungerar inte och driftavdelningens medarbetare har inte den kompetens som krävs för att hantera driften.
I detta exempel skapas en stor kostnad som inte fanns med i kalkylen från början och i värsta fall så blir den totala kostnaden så stor att projektet inte borde ha genomförts över huvud taget om alla kostnader varit kända.
Genom att skapa en process som reglerar aktiviteterna underlättas utmaningen med att få in alla aspekter av en ny IT-tjänst genom hela dess livscykel. Dessutom skapas en förutsättning att kontinuerligt förbättra kvaliteten på nya tjänster och effektivisera arbetet med att ta fram dessa.
Syfte
Syftet med tjänstedesign är att säkerställa att alla olika aspekter av designarbetet beaktas så att mål och syfte uppnås för den nya IT-tjänsten.
Syftet uppnås genom att:
- Tillhandahålla enhetliga aktiviteter vid design av nya och förändrade tjänster
- Producera kompletta designpaket
- Säkerställa att tillräcklig design utförs före överlämning till change management-processen
- Säkerställa att alla nya IT-tjänster ligger i linje med policydokument och strategier
Mäta och förbättra kvaliteten och effektiviteten i designaktiviteter
Omfattning
I en liten IT-organisation utan egen utveckling kan processen i sin enklaste form bestå av en checklista som beskriver vilka olika områden som måste beaktas vid framtagning av en ny IT-tjänst.
För större organisationer med egen utveckling och en hög frekvens av nya IT-tjänster så behöver tjänstedesign vara en uttalad process som på ett tydligt sätt har sammanfogats med de processer som används för kravhantering i utvecklingsmodellen.
Omfattningen på tjänstedesign skiljer sig alltså väldigt mycket mellan olika IT-organisationer beroende på storlek och antalet egenutvecklade applikationer. Varje IT-organisation måste därför besluta om vilken ambition och omfattning som processen ska ha.
Som utgångspunkt omfattar tjänstedesign de aktiviteter som krävs för att säkerställa kvaliteten och funktionaliteten i nya eller förändrade IT-tjänster.
Det blir inte effektivt att hantera samtliga förändringar genom tjänstedesign. Därför måste en trigger sättas i change management-processen som talar om när en förändring ska hanteras av tjänstedesign. Nivån på denna trigger är givetvis olika för varje organisation, men nya tjänster, förändringar med hög risk eller förändringar som påverkar flera olika tjänster kan vara en bra utgångspunkt. För att underlätta är det bra om triggern för tjänstedesign är densamma som triggern för vilka förändringar som ska hanteras av CAB i change management-processen.
Oavsett storlek på organisation så ingår det i tjänstedesign att:
- Utveckla och förvalta policy och metod för designarbetet
- Effektivisera tjänstedesign
- Producera kompletta designpaket till CCB
Värde för verksamheten
Tjänstedesign säkerställer att IT-organisationen beaktar alla olika aspekter av en ny tjänst och därmed minskar risken för oförutsedda kostnader för verksamheten.
Genom tjänstedesign uppnås dessutom:
- Önskat värde hos verksamheten till acceptabla risker och kostnader
- Minskning av oplanerat arbete under överlämningsfasen
- Enhetlig design av samtliga tjänster vilket underlättar driftsättning
Designaspekter
Det är viktigt att försöka ha en övergripande syn vid design av tjänster. Oavsett uppgift så har människor med olika bakgrund olika syn på vad som behöver göras och vad som är viktigt. Det är lätt att fastna i sitt eget specialområde, sin egen aspekt, och i värsta fall designa lösningar som inte fungerar ihop med resterande IT-miljö. För att underlätta det övergripande perspektivet, används fem olika aspekter på designarbetet:
Design av tjänsten – Denna aspekt omfattar dels kraven på vilket värde tjänsten ska uppfylla, dels hur tjänstens arkitektur byggs upp. Här omfattas kopplingar och beroenden till befintliga tjänster, ramar som finns i policyer och styrande dokument. Utöver det ska alla krav på funktionsförmåga och värde inhämtas och dokumenteras.
Information och verktyg – Befintliga informationssystem och verktyg ska analyseras för att se om de kan hantera kraven från den nya tjänsten. Det som ska analyseras är tjänsteportföljens uppbyggnad med bland annat metoden för kostnadsberäkning och tjänstestruktur och de verktyg som används för kunskapshantering och mätning av tjänsten.
Arkitektur – Både den tekniska och den organisatoriska arkitekturen ska analyseras för att se om de klarar av kraven från den nya tjänsten. I den tekniska arkitekturen ingår dels infrastrukturplattformen men även de verktyg som används för till exempel övervakning och driftsättningar. Den organisatoriska arkitekturen omfattar funktioner och roller samt de metoder som används.
Processer och funktioner – En ny tjänst innebär ny information och nya rutiner för befintliga processer. Funktioner behöver analyseras för att identifiera eventuella behov av ny kompetens som krävs för att hantera den nya tjänsten.
Mätning och rapporter – Befintliga verktyg och rapportstrukturer behöver analyseras för att se om den nya tjänsten går att mäta och följa upp eller om nya verktyg behövs.
Designpaket
Ett designpaket bör skapas under tjänstedesign för varje ny eller förändrad tjänst. Designpaketet innehåller all information som behövs för att bygga, testa och etablera tjänsten i IT-miljön. Oftast består ett designpaket endast av dokument, men kan i vissa fall även innehålla enklare former av applikationer och system för att påvisa koncept och funktionalitet inför ett beslut att utveckla en fullskalig tjänst.
Ett designpaket bör minst innehålla:
- Kontaktuppgifter
- Verksamhetskrav
- Tjänstens tänkta värde i verksamheten
- Tjänstedesign
- Funktionella krav
- Icke funktionella krav
- Servicenivåer
- Operativa krav i IT-drift
- Design och arkitektur för tjänsten
- Organisatorisk analys
- Tjänsten
- Plan för överlämning
- Plan för IT-drift
- Acceptanskriterier
Aktiviteter
Planera design – varje nytt designprojekt bör planeras i detalj. Särskilt viktigt är det i större projekt där utvecklingsavdelningens kravställningsmodell eventuellt ska samordnas med externa leverantörer och den egna driftorganisationen. Allt eftersom arbetssättet mognar inom IT-organisationen, blir aktiviteten lättare eftersom målet är att det ska finnas rutiner och mallar som gör det lätt för projektledaren att utföra jobbet.
Genomföra design – Detta steg utförs som en aktivitet vid mindre designuppdrag eller som ett projekt enligt IT-organisationens projektmodell. En av de viktigaste aktiviteterna är att tidigt boka och schemalägga egna och verksamhetens resurser för att minimera onödiga väntetider. Resultatet av denna aktivitet är ett tjänstepaket som beskriver alla aspekter av designen.
Kontrollera design – Alla utvecklingsprojekt eller aktiviteter avslutas med en genomgång av designen för att säkerställa att det efterfrågade värdet Uppnåtts, att samtliga aspekter beaktats samt att tillämpliga regelverk och policyer följts. Allt som medvetet avviker ska dokumenteras som en del av designpaketet.
Lämna över designpaket – När allt finns dokumenterat i tjänstepaketet, kan det skickas tillbaka till change management-processen. Nästa steg är att ta beslut om den färdiga designen i change control board (CCB). Resurser som medverkat i designen bör närvara på beslutsmötet för att redogöra för designen och svara på frågor.
Dokumentation
All information om nya eller förändrade tjänster ska finnas i tjänstepaketet vid större förändringar. Informationen sparas som en del av tjänstedokumentationen för spårbarhet. Mindre förändringar dokumenteras direkt i förändringsärendet eller med dokument kopplade till ärendet.
Följande dokumentation ska finnas inom ramen för tjänstedesign:
- Designpolicy
- Mall för designpaket
- Rutin för planering av design
Rutin för test av design
Relationer till övriga processer och funktioner
Tjänstedesign har kopplingar till många andra processer. Här listas de vanligaste:
Trigger
Tjänstedesign triggas genom att något av de beslutade kriterierna uppfylls i change management-processen. Exempel på dessa kriterier är:
- En helt ny tjänst
- Större förändring av en befintlig tjänst
- Förändring som omfattar flera tjänster
- En förändring med hög risk för störningar i verksamheten
Input
Följande Input behövs för tjänstedesign:
- Förändringsärende (RFC)
- Information om verksamheten som ska använda tjänsten
- Dokumentation över arkitektur (information, applikation, teknik, tjänster)
- Tjänstedokumentation om befintliga tjänster
- IT-strategi
- Policydokument och övriga styrande dokument
- Tjänstestruktur
Output
Följande output genereras av tjänstedesign:
- Designpaket
- Reviderad arkitektur
- Reviderade mätsystem och metoder
- Reviderade processer
- Uppdaterad tjänsteportfölj
- Uppdaterad tjänstekatalog
- Beslutsunderlag för en ny eller förändrad tjänst
Mätning
Så här kan tjänstedesign mätas:
- Antal förändringar som måste tas tillbaka till tjänstedesign för att göras om
- Antalet gånger som designprojekt avstannar på grund av resursbrist
- Antalet incidenter som kan härledas till dålig design
Utmaningar
Följande moment behöver särskild uppmärksamhet vid införande av processen:
- Att hålla en hög kvalitativ nivå på innehållet i designpaketen, även för mindre förändringar
- Att få fram gemensamma metoder och mallar för design som accepteras av alla inblandade parter
- Att införliva och nyttja de metoder och mallar som redan finns i organisationen för till exempel utveckling och förvaltning
- Att sätta en lagom ambitionsnivå från början, ett komplext och omfattande regelverk med styrda rutiner kan göra att organisationen undviker processen
