Digitaliseringsprojekt i 3 steg: Så här startar du

Det här är det första blogginlägget i en serie om digitaliseringsprojekt som vi valt att kalla för Digitaliseringsprojekt i 3 steg. Vi delar upp digitaliseringsprojekt i tre steg. Hur du kommer igång, hur du får ut mest av varje utvecklingstimme och slutligen hur du får största möjliga värde ur din investering efter lanseringen.

I det här blogginlägget reder vi ut hur du enklast startar ett digitaliseringsprojekt. Det kan vara svårt att veta vart man ska börja och det kan kännas som att det finns många svåra beslut att ta. Vi hoppas kunna leverera några enkla och tydliga riktlinjer som gör att beslutet blir betydligt enklare att ta.

Digitaliseringsprojekt i 3 steg: Det första steget i punktform

• Identifiera alltid på projektets målgrupper och effektmål
• Prioritering är nyckeln till snabbt värdeskapande
• Skapa en gemensam bild och engagera användare tidigt med hjälp av skisser och mockups

Så, vart börjar vi?

Det är dags att investera i ett nytt IT-stöd och då finns det flera olika vägval att ta ställning till. Det vanligaste sättet att starta på är att skriva ner allt som ens befintliga system klarar av och sedan börja utöka kraven med de nya funktionerna som önskas.

Nu ställs krav och önskemål mot kostnad genom att använda en kravspecifikation eller motsvarande dokument och det systemet som har den lägsta kostnaden är det bästa alternativet. Den här metoden fungerar i det läget man bestämt sig för att köpa ett befintligt standardsystem och är helt säker på att kravbilden inte kommer att utvecklas i framtiden. Funderar man däremot på att köpa ett unikt system eller utveckla det på egen hand så bör istället användarnas behov stå i centrum. 

svara på dessa två frågor så minskar risken avsevärt att funktioner som inte behövs köps

Vilka målgrupper finns och vilka effektmål är viktigast att nå?

Dessa två frågor är alltid viktiga att ställa så tidigt som möjligt för att säkerställa att alla som är inblandade i projektet vet till vilka systemet köps eller byggs men ännu viktigare, varför. Om alla som är inblandade i projektet kan svara på dessa två frågor så minskar risken avsevärt att funktioner som inte behövs köps eller att de implementeras på rätt sätt. 

Att identifiera målgrupperna för systemet kan ibland vara enkelt men det är inte alltid så. De direkta målgrupperna kan oftast identifiera genom att fundera på olika interna roller såsom tekniker, administratörer eller tidsregistrerare. Den lite knepigare biten kan vara att identifiera indirekta målgrupper. Det här är användare som påverkas av den förändringen som den nya lösningen innebär men som kanske inte är användare i systemet själva. Ofta handlar det om kunder, leverantörer eller andra samarbetspartners, med andra ord aktörer vars upplevelse av dig är viktig. Om det nya systemet producerar innehåll till dessa grupper bör det vara lika bra men helst bättre än det befintliga.

Att sätta effektmål för projektet handlar om vilka värden som man vill skapa med en ny lösning. Det kan exempelvis  handla om att göra administrationen effektivare, göra kundupplevelsen bättre eller möjliggöra för nya affärsmodeller.

Nu vet vi vad vi vill göra, hur kommer vi vidare?

När målgrupperna är identifierade och målen satt så är det dags att ta nästa steg. Nu börjar arbetet med att prioritera systemets uppgifter för att få så stor effekt som möjligt så snabbt som möjligt, internt sälja in en lösning till de som ska använda systemet och reda ut eventuella tekniska utmaningar.

Då kan man enkelt ändra i lösningen utan att behöva programmera

Börja med att prioritera de viktigaste uppgifterna som systemet ska klara av. Det enklaste sättet att göra detta på är att göra en s.k. backlog. En backlog är en prioriterad lista med alla uppgifter (user stories) som det framtida systemet ska klara av att utföra. Ett bra sätt att börja med är att göra  user stories av följande karaktär:

• En användare ska kunna logga in
• En administratör ska kunna skapa en kund
• En servicetekniker ska kunna registrera tid och material på en order

Att reda ut tekniska utmaningar är metodmässigt enkelt. Gör tester där det behövs för att säkerställa att lösningen går att implementera på det sättet som ni tänkt er. Det kan handla om att kolla så att datakällor är tillgängliga eller att den plattformen som väljs klarar av att hantera de krav som ställs.

Slutligen

Till sist är det dags att sälja in lösningen till användarna. Denna del prioriteras ofta ner i början av projekt då kravställare ofta vill arbeta fram en färdig produkt innan den visas upp för dess användare. Det här sättet är naturligt och klokt ur det perspektivet att det endast ges en chans att göra ett första intryck men det är riskfyllt eftersom det är svårare att ändra i en implementerad lösning än det är att göra rätt från början. Här rekommenderar vi ofta att arbeta med skisser/mockups för lösningens viktigaste delar. Då kan man enkelt ändra i lösningen utan att behöva programmera om densamma och användaren får direkt en känsla att hen fått vara med och påverkat lösningen. Risk förflyttas till projektets början och engagemanget ökar från användarna.

När backlogen är etablerad och förklarad med hjälp av skisser eller mockups är det dags att börja realisera lösningen. Mer om det steget och dess utmaningar kommer vi till i nästa blogginlägg.