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 ni väljer system, leverantör eller riktning får ni en tydlig och strukturerad bild av vad ni 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 Fullständig beskrivning av steget

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.

   Fullständig beskrivning av steget

4. Krav och projektförberedelse

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

   Krav skrivna på era processers språk, innan ni 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.

   Fullständig beskrivning av steget

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 er 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 era 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.

   Fullständig beskrivning av steget

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 er organisation, men inte i min praktik. Jag företräder ledningen i införandeteamet 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: kartläggning av organisationskulturen och användarna, anpassningsstrategi, kommunikationsplan, utbildning, förändringsambassadörer på förvaltningar och avdelningar, samtal med dem som ännu inte är övertygade, mätetal för införande, användning och effekt. Mer om förändringsledning.
   • 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 er till en leverantör mer än nödvändigt.

   Så ser det ut vid ett ERP-införande Fullständig beskrivning av steget

7. Samordning och fast ordning i projekten

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

   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:n 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.

   När projekten är flera och IT-avdelningen knappt hinner med driften av systemen saknas någon som till vardags håller koll på helheten. I rollen som fast samordnare på beställarens sida för jag register över projekt, åtgärder, risker, beslut och dokument, samlar in statusrapporter, påminner om tidsfrister och eskalerar när ett ärende står still. Jag tar inte över genomförandet och fattar inga beslut åt er: varje åtgärd har en ägare på er sida.

   • En enda aktuell lista över projekt, åtgärder, risker, beslut och dokument med ägare, tidsfrist och status.
   • Veckostatus och ett statusmöte med anteckning och åtgärdslista, en månadsrapport till kommundirektören, VD:n eller ledningen.
   • Påminnelser, kontroll av att dokumentationen är komplett, tidig varning om risker och förberedd eskalering.
   • Samordning av information med leverantörerna: statusrapporter, utfästelser och tidsfrister.

   Vi väljer en rytm efter antalet projekt och efter hur mycket tid er IT-avdelning har:

   • Grundläggande, en gång i månaden: uppdatering av registren, upp till två statusmöten och en månadsrapport.
   • Regelbunden, varje vecka: statusrapporter, statusmöte, register, uppföljning och en månadsrapport till ledningen.
   • Intensiv, en eller två gånger i veckan: en större projektportfölj, beroenden mellan projekten och åtgärdsplaner för projekt som är hotade.
   • Tillfällig, flera gånger i veckan: under några månader, när organisationen har en lucka i projektstyrningen och portföljen snabbt behöver ordnas upp. Därefter går ni tillbaka till en lättare rytm.

   Fullständig beskrivning av steget

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. Jag tar fram en offert för varje steg, även IT-inventeringen, efter ett 30 minuter långt samtal.