Från den första inventeringen till leveransgodkännandet. En rådgivare på ledningens sida längs hela kursen.

1. Inventering av IT-system och processer

   Vad har vi egentligen?

   Utgångspunkten för varje beslut om ett införande. Innan du väljer system, leverantör eller riktning får du en tydlig och strukturerad bild av vad du redan har.

   • Ett applikationsregister med ägare, avtal, licens, kostnad och slutdatum för support.
   • En karta över processer med och utan systemstöd, en karta över integrationer och över var data förs in manuellt en gång till.
   • Ett riskregister, inklusive enskilda felpunkter (single points of failure) och inlåsning hos leverantörer.
   • Kategorisering av systemen i A/B/C/D och en sammanfattning på en sida för ledningen.

   2–6 veckor, under tröskelvärdet för offentlig upphandling.

   Hela omfattningen av IT-inventeringen

2. Behovsanalys och workshoppar

   Vad behöver vi verkligen?

   Interna workshoppar där vi reder ut vad organisationen verkligen behöver. Ofta lockar jag fram det med enkla frågor: vad är definitionen av framgång? När kommer projektet att bedömas som lyckat? Företag och myndigheter hoppar mycket ofta över det här, antingen för att de tror att de redan vet allt eller för att de helt enkelt saknar tid för djupare frågor. Det är en av de vanligaste orsakerna till problem i projekt.

   • Workshoppar med ledningen och de medarbetare som arbetar i processen varje dag: mål, förväntningar, begränsningar.
   • En definition av framgång och de kriterier som visar att projektet har lyckats.
   • En beskrivning av vad som inte fungerar i dag och av hur framtiden ska se ut.
   • Underlag för kravställning eller en marknadsundersökning, eller ett beslut om att inget nytt system behövs.

   Frågorna jag börjar med

3. Digitaliseringsstrategi och målarkitektur

   Vart ska vi, och i vilken ordning?

   En strategi som inte hamnar i en byrålåda, eftersom den bygger på vad organisationen faktiskt har och säger vad som ska göras i nästa budget.

   • En målarkitektur i lager: register, processer, integrationer och åtkomst.
   • Standarder som organisationen antar: en behörighetsmodell, en gränssnittsstandard, regler för hur krav dokumenteras.
   • En färdplan som skiljer regulatoriska skyldigheter från investeringar.
   • Inköpsregler för systemanskaffningar och en budget uppdelad på investering och förvaltning.

4. Krav och projektförberedelse

   Hur beskriver vi behoven så att leverantören förstår dem?

   Krav skrivna på dina processers språk, innan du går ut med en upphandling eller skickar en offertförfrågan. De gör anbuden jämförbara och gör det möjligt att senare hålla leverantören ansvarig.

   • Intervjuer, processkartor, en datamodell, integrationer och testscenarier.
   • Framför allt ett svar på frågan om vad som räknas som framgång för införandet: varför vi gör det här och vilka resultat vi förväntar oss.
   • När ledningen har en idé men inte tid att skriva ner den: ett koncept eller en prototyp efter ett enda samtal, på ungefär 2 dagar.

5. Utvärdering av anbud och samtal med leverantörer

   Hur jämför vi olika leverantörers anbud på ett effektivt sätt?

   En oberoende bedömning vid sidan av din IT-avdelnings rekommendation, inte i stället för den. Ledningen får en jämförelse som den kan grunda sitt beslut på och försvara inför kommunfullmäktige, ägaren eller koncernens huvudkontor.

   • Frågor till leverantörerna och demonstrationer utifrån dina egna scenarier.
   • En jämförelsematris: anbuden omräknade till en gemensam omfattning, totalkostnad över flera år, villkor för förvaltning och för att lämna avtalet.
   • För dotterbolag en jämförelse mot koncernens inköpsriktlinjer, vid behov på engelska.
   • Deltagande i möten med leverantörer som beställarens representant.

6. Införande, förändring och leveransgodkännande

   Hur genomför vi projektet, får med oss medarbetarna och håller leverantören ansvarig?

   Ett stort IT-projekt innebär också en förändring av hur människor arbetar. Ofta det första i sitt slag i din organisation, men inte i min praktik. Jag företräder ledningen i projektgruppen och leder förändringen så att medarbetarna faktiskt tar till sig det nya systemet. Ledningen behöver bara kopplas in igen när ett beslut krävs.

   • Bevakning av omfattning, tidplan och ändringsbeslut, med en logg över ändringar och beslut.
   • Förändringsledning: en kommunikationsplan, utbildning, förändringsambassadörer på förvaltningar och avdelningar, samtal med dem som ännu inte är övertygade.
   • Korta sammanfattningar för ledningen och för kommunikationen med IT, kommunfullmäktige eller koncernens huvudkontor.
   • Leveransgodkännande mot överenskomna testscenarier och kriterier, verifierad datamigrering.
   • Ett förvaltningsavtal som inte låser dig till en leverantör mer än nödvändigt.

   Så ser det ut vid ett ERP-införande

7. En fast rådgivare till ledningen

   Vi har ingen IT-direktör. Vem håller koll på helheten?

   En roll som internationellt kallas deltids-CIO (”fractional CIO”), med en skillnad: jag tar inte över IT-avdelningen eller dess budget. Jag översätter ledningens intentioner till krav, granskar IT-avdelningens rekommendationer och företräder beställarens intressen gentemot leverantörerna.

   • Ett månatligt möte med kommundirektören eller vd och IT-chefen, en månadsrapport om drift och risker.
   • En kvartalsvis genomgång av risker och kritiska avtal, ett yttrande inför varje större inköp.
   • De första 90 dagarna: en inledande bedömning och eventuella akuta ”röda flaggor”, uppstart av registren och en avtalsgenomgång, en rapport till ledningen med en färdplan för 12–24 månader.

Hur lång tid varje steg tar beror på organisationen och projektet: hur förberedd organisationen är, vilken organisationskultur den har och vilket mandat ledningen ger. Därför fastställer vi omfattning och tidplan efter det första samtalet. Endast IT-inventeringen har fast pris och tidplan.