Beställ rätt IT rätt

2014-03-26 Artikelbanken Kravhantering Läst 8459 gånger

Vissa källor säger att 61 procent av IT-projekten misslyckas eller försenas. Oavsett exaktheten i siffran är det ett alarmerande faktum. Alla skyller på alla, verksamheten på IT och vice versa. IT önskar tydligare beställning och engagemang från beställarhåll. Verksamheten förstår inte å sin sida varför IT-leverantören alltid måste tänka infrastruktur och dra ut på projekten så länge. Sanningen ligger förstås någonstans mittemellan. Samtidigt ser vi att fler och fler verksamheter köper tjänster i molnet eller väljer offshoring och därmed hoppas kunna ”köpa sig fri” från skenande IT-kostnader. Riskfritt eller? Såklart inte.

Att veta målbild och varför en IT-investering ska göras är fundamentala frågor inför en beställning. Genom att prioritera relevant förberedelsearbete så kommer kostnaderna i slutänden sannolikt inte att öka okontrollerat under mottagningsfasen enligt nedanstående figur.

Den här artikeln visar på en övergripande nivå och genom praktiska exempel hur du förflyttar fokus till förberedelserna och därmed inte bara kontrollerar kostnaderna och styr hela processen utan även att du grundar för IT-kvalitet.

En bra grund borgar för kvalitet

För varje IT-lösning finns ett bakomliggande rationaliseringsbehov. Idag när IT i princip är en del av kärnverksamheten och datorer i olika format finns i var mans hand, har man nästan glömt bort varför IT behövs. Det är på något sätt så grundläggande och självklart.

Nu vet vi ju att det inte enbart handlar om rationalisering idag utan lika mycket om lösningens funktion, effektivitet, stabilitet, design, mobilitet, säkerhet och användbarhet för att bara nämna några fler grundläggande behov.

Vilka är förväntningarna?

Det är ingen som helst tvekan att det är användarna och verksamheten själva som bäst vet vilka problem IT-stödet ska lösa, det vill säga vad som är rätt IT, men behovet och förväntningarna behöver ändå formuleras.

Tänk dig att du och familjen ska bjuda svärföräldrarna på middag. Du och respektive börjar genast fundera på vad ni ska bjuda på och är det första gången ni träffas kanske det är lite extra förväntningar. Du funderar vidare, har svärföräldrarna några speciella preferenser eller är det rentav någon av dem som är allergisk och så vidare. Behovsbilden klarnar och så småningom växer middagsplanen fram, ni letar fram ett recept och snart har ni inköpslistan klar; en del finns säkert redan i kyl och frys att använda.

Omsätter man det till att beställa IT-stöd så hittar du snabbt motsvarande frågeställningar som behöver besvaras för att kunna definiera behovet:

  • Varför behövs IT-stödet
  • Var i arbetsflödet ligger den eventuella flaskhalsen
  • Vilka arbetsuppgifter behöver förenklas
  • Vilka funktioner behövs
  • Vem är det som drar nytta av lösningen
  • Omfattas känslig information
  • Är IT-stödet beroende av annan information än sin egen
  • Ska IT-stödet producera digital information till andra system
  • Vad är ambitionsnivån

Fokuserar man på ovanstående frågeställningar så kommer eventuellt även insikten att det inte ens är IT-stödet som är boven i dramat. Kanske rentav en annan förändring i organisation eller rutiner ger minst lika bra effekt? Statistiken visar att ”feltänk” som hittas i detta läge kostar väldigt lite att åtgärda.

Är det en större investering kommer självklart fördjupade analyser att behövas som handlar om fördjupad modellering kring begrepp och intressenter, målformuleringar, behovsanalys och nyttokalkyl för att nämna några aktiviteter inom verksamhetsanalys.

Tänk leverans och test tidigt

Familjemiddagen närmar sig och du börjar planera för middagen. Går det att förbereda några moment innan söndagen så det inte blir så stressigt i slutänden? Dela upp handlingen och kanske är det så att du till och med vill provlaga maten för att provsmaka och vara säker på resultatet?

På samma sätt fungerar det med IT-lösningar. Redan när du bestämmer varför du behöver en IT-lösning och vad lösningen ska fylla för syfte så har du det bästa tillfället att även tänka på:

  • Hur kan du säkerställa resultatet
  • Vilket resultat motsvarar dina acceptanskriterier
  • Hur kan du paketera leveransen
  • Vem är det som bäst avgör resultatet

Att så tidigt som möjligt kunna utvärdera resultatet gör att du minimerar risken för felaktiga beslut och investeringar. Att definiera hur kraven ska testas kommer bland annat att utgöra embryot till senare testplan vad gäller till exempel krav på testmiljö, testdata och testfall. Det är bra att ställa sig frågan var information finns för att kunna säkerställa kravet, till exempel en specifik dialog eller rentav på en rapport av något slag? I middagsexemplet ställde vi oss frågan huruvida det var aktuellt att provlaga maten innan middagen. Motsvarande frågeställning kan vara relevant även för en IT-investering, många IT-tjänster erbjuder prova-på-möjlighet och en del IT-stöd kan utvärderas genom ett så kallat proof-of-concept då man lånar in lösningen och utvärderar den i sin miljö.

Acceptanskriterierna anger vilket resultat som krävs för att kravet ska vara godkänt, till exempel att maten ska vara glutenfri och välkryddad. Kriterierna ska vara tydliga och mätbara men med krav så tidigt i processen (högnivåkrav) kan det vara svårt. Men oavsett är det fördelaktigt att tänka på acceptanskriterierna redan nu. Definierade acceptanskriterier kommer att underlätta vid förberedelserna av testerna.

Att tidigt tänka på hur och att leveransen ska delas upp i mindre delleveranser/paket kommer att underlätta för både IT-leverantör och beställare. Allt för många projekt har motstridiga krav rörande detta; mottagande projekt jobbar och planerar för en agil leverans medan leverantören planerar för en fullständig leverans eller tvärtom. Att tidigt kravställa leveranstakt och arbetssätt bidrar till ett lyckat överlämnade.

Självklart är det slutanvändarna som på ett eller annat sätt ska vara involverade i valideringen men säkerligen har slutanvändarna olika arbetsuppgifter och specialisering. Det är därför bra att det framgår vilken yrkesroll som är mottagare/användare och som slutligen ska ge sitt godkännande. Kommer slutanvändarna att vara tillgängliga för acceptans och inte minst för att förbereda testarbetet? Många gånger finns viljan men tyvärr inte tiden.

Genom att tidigt ställa sig ovanstående enkla frågor så har man kommit en bra bit på väg i att bygga in kvalitet.

Dags att skrota redan nu?

Förr eller senare kommer ditt behov av IT-stödet att förändras eller helt enkelt att upphöra. Du behöver lägga ned, byta ut eller uppgradera det. Men måste du verkligen tänka på det redan nu?

Låt oss kika på ett exempel kring IT-stöd som tillhandahålls som en tjänst i molnet. Som beställare och användare bekymrar man sig då föga var informationen, eller Datat, lagras eller hur?! Men den dagen då tjänsten föråldrats eller dina behov förändrats och det är dags att uppgradera till ny tjänst eller annat IT-stöd in house, hur kommer man då åt Datat? Genom att tidigt fokusera på systemets livslängd kommer du att definiera behov som gör ditt val av IT-stöd mera genomtänkt.

Rent generellt kan det också vara svårare att få support när man vill byta leverantör av tjänst eller system om det inte finns med som krav från början.

Handskakning med leverantören

Även om denna artikel inte går så djupt kring själva avtalet med leverantören så kan nedanstående aspekter vara fördelaktiga att planera för och ligga steget före din IT-leverantör:

  • Hur ser ansvarsfördelning mellan beställare/mottagare ut?
  • Säkerställ att leverantören har tillgänglig kompetens att diskutera dina funktionella och affärsmässiga behov och inte enbart hårda fakta om systemet
  • Säkerställ att leverantören gör systemtest och samverkar i systemintegration samt är delaktigt i din acceptanstest
  • Kan ni komma överens om att regelbunden uppföljning sker?
  • Ingår kravspecificering, kvalitetssäkring och ändringshantering i avtalet?
  • Säkerställ att dokumentation av genomförd kvalitetssäkring medföljer IT-leveransen
  • Hur fungerar support under utveckling och efter leverans?
  • Transparens vad gäller felrapportering?

Ovanstående är generellt aktiviteter som varje IT-leverantör önskar få konkretiserade från sin beställare och kommer att välkomna incitament för att kunna erbjuda en kontrollerad kvalitet i sin leverans.

Att få med dessa aspekter i avtalet är en garanterad framgångsfaktor för din IT-beställning. Allt för ofta bortser man från dessa och senare blir det istället merkostnader.

Leveransgodkännande

Ett leveransgodkännande består av en hel del aktiviteter men börjar med en acceptanstestperiod för att bekräfta att leveransen motsvarar beställningen. Har du valt agil paketering är nedanstående aktiviteter repetitiva för varje delleverans.

Det finns en stor framgångsfaktor för dig här som beställare av IT-lösningar i att tidigt ta i taktpinnen och redan nu planera för startkriterierna för acceptanstesten, något som allt för ofta missas.

  • Är slutanvändare, organisation, och miljö redo för acceptanstest
  • Är testresurserna tillgängliga i rätt tid och omfattning
  • Är slutanvändare utbildade i det nya systemet/funktionerna och eventuellt förändrade rutiner
  • Är verksamhetens acceptanskriterier tydliga, mätbara och kommunicerade inför beslut om införande

Omfattningen av acceptanstesten beror helt och hållet på kvalitén som systemet eller tjänsten har som ingångsvärde även om leverantören förstås ska kvalitetssäkra systemet inför leverans. Målsättningen med en acceptanstest är att känna sig tillräckligt säker att systemet har god kvalitet i förhållande till behov och syfte.

Förbereda mottagningen

Begrepp som att implementera, sätta igång systemet, ”trycka på knappen”, eller införa tjänsten innefattar olika aktiviteter och ambitionsnivå för olika verksamheter. Oavsett ordval så är det en etablering av förändringen som ska göras. Det är många olika viljor och önskemål som ska stöpas ihop till en enhet mot slutet och det är lätt att onödig friktion uppstår på grund av olika målbilder och ambitionsnivåer. Just denna fas utgör det vanligaste problemet för många projekt för att förberedelsearbetet helt enkelt inte är tillräckligt gjort.

Vi går tillbaka till vår middag med svärföräldrarna. Det är nu dags att förbereda detaljer som, hur ska dukningen se ut, hur ska maten serveras och hur ska logistiken fungera kring till exempel fördrinken? Alla dessa aktiviteter är typiska för att slutföra förberedelserna för själva mottagandet av dina gäster.

Att förbereda organisationen på förändringen är något som inte kan hoppas över även om det handlar om en tjänst i molnet eller ett system som sköts av extern part. Någon ska ju i slutänden använda systemet/tjänsten och inloggningsuppgifter kan då behöva administreras, supportfunktionen kan behöva dela upp i first och second line och någon behöver fungera som expertanvändare/Super User.

Användare som varit kritiska till det gamla systemet/tjänsten och inte är tillräckligt förberedda kan helt plötsligt bli motståndare till den nya lösningen. Man vet vad man har…

Blev det som du tänkt dig?

De flesta av oss har varit med och firat projektavslut i någon form. Men, hur många av oss har firat när vi verkligen uppnått syftet med den nya tjänsten eller systemet? Att projektet lyckats och avslutats säger inte med säkerhet något om effekten av förändringen.

Ofta kan resultatet eller effekten visa sig långt efter det att tjänsten/systemet infördes. Du kanske inte ens är med när det är dags. Bra effektmål mäter du till exempel med tidigt införda och effektiva mätetal, intressentuppföljning, intervjuer och diverse statistik.

Sammanfattning

Slutligen så handlar det nu, för verksamheten som beställare, om att styra hela processen och effektivisera varje steg med fokus på förberedelsearbetet. Att ”plocka de lågt hängande frukterna” och använda erfarenheter av åratal av IT-utveckling men att göra detta på ett smart och effektivt sätt.

Verksamhetsstöd med flera roller, alla med kompetens från IT och verksamhet, kommer att vara en förutsättning för företagens verksamhetsutveckling.

Utöver att du reducerar risken för frustration som ofta uppstår under införandet, så finns det också en möjlighet till besparing.

Nästa Steg

 

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln