Fra den første kortlægning til overtagelsen af systemet. Én rådgiver på ledelsens side gennem hele kursen.

1. Kortlægning af IT-systemer og processer

   Hvad har vi egentlig?

   Udgangspunktet for enhver implementeringsbeslutning. Før I vælger system, leverandør eller retning, får I et klart og struktureret overblik over, hvad I allerede har.

   • Et register over applikationer med ejer, kontrakt, licens, omkostning og ophør af support.
   • Et kort over understøttede og ikke-understøttede processer, et kort over integrationer og over de steder, hvor data tastes ind manuelt igen.
   • Et risikoregister, herunder single points of failure og afhængighed af én leverandør (lock-in).
   • Kategorisering af systemerne i A/B/C/D og en opsummering på én side til ledelsen.

   2–6 uger, under tærskelværdien for offentligt udbud.

   Hele omfanget af IT-kortlægningen

2. Behovsanalyse og workshops

   Hvad har vi reelt brug for?

   Interne workshops, hvor vi finder ud af, hvad organisationen reelt har brug for. Ofte får jeg det frem med enkle spørgsmål: Hvad er definitionen på succes? Hvornår vil projektet blive vurderet som en succes? Virksomheder og offentlige myndigheder springer meget ofte dette over, enten fordi de tror, at de allerede ved det hele, eller fordi de simpelthen ikke har tid til dybere spørgsmål. Det er en af de hyppigste årsager til problemer i projekter.

   • Workshops med ledelsen og de medarbejdere, der arbejder i processen til daglig: mål, forventninger, begrænsninger.
   • En definition af succes og de kriterier, der viser jer, at projektet er lykkedes.
   • En beskrivelse af, hvad der ikke fungerer i dag, og af, hvordan fremtiden skal se ud.
   • Input til kravene eller til en markedsafdækning – eller en beslutning om, at der ikke er brug for et nyt system.

   Spørgsmålene, jeg starter med

3. Digital strategi og målarkitektur

   Hvor skal vi hen, og i hvilken rækkefølge?

   En strategi, der ikke ender i en skuffe, fordi den bygger på det, organisationen faktisk har, og siger, hvad der skal gøres i det næste budget.

   • En målarkitektur opbygget i lag: registre, processer, integrationer og adgang.
   • Standarder, som organisationen tager i brug: en rettighedsmodel, en grænsefladestandard, regler for dokumentation af krav.
   • En køreplan, der skelner mellem lovkrav og investeringer.
   • Indkøbsregler for systemanskaffelser og et budget fordelt på investering og drift.

4. Krav og projektforberedelse

   Hvordan beskriver vi behovene, så leverandøren forstår dem?

   Krav formuleret i jeres processers sprog, før I sender opgaven i udbud eller beder om tilbud. De gør tilbuddene sammenlignelige og gør det muligt senere at holde leverandøren op på det aftalte.

   • Interviews, proceskort, datamodel, integrationer og testscenarier.
   • Først og fremmest et svar på, hvad succeskriteriet for implementeringen er: hvorfor vi gør det, og hvilke resultater vi forventer.
   • Når ledelsen har en idé, men ikke tid til at skrive den ud: et koncept eller en prototype efter én samtale, på ca. 2 dage.

5. Tilbudsvurdering og leverandørdialog

   Hvordan sammenligner vi tilbud fra forskellige leverandører på en god måde?

   En uafhængig vurdering ved siden af jeres egen IT-afdelings anbefaling, ikke i stedet for den. Ledelsen får en sammenligning, som den kan basere sin beslutning på og forsvare over for kommunalbestyrelsen, ejeren eller koncernens hovedkontor.

   • Spørgsmål til leverandørerne og demonstrationer baseret på jeres egne scenarier.
   • En sammenligningsmatrix: tilbud bragt ned på et fælles omfang, samlede omkostninger over flere år, vilkår for drift og for udtræden af kontrakten.
   • I datterselskaber en sammenligning efter koncernens indkøbsretningslinjer, om nødvendigt på engelsk.
   • Deltagelse i møder med leverandører som kundens repræsentant.

6. Implementering, forandring og overtagelse

   Hvordan kommer projektet i mål, får vi folk med og holder leverandøren op på aftalen?

   Et stort IT-projekt er også en forandring af den måde, folk arbejder på. Ofte det første af sin art i jeres organisation, men ikke i min praksis. Jeg repræsenterer ledelsen i implementeringsteamet og guider forandringen, så medarbejderne rent faktisk tager det nye system til sig. Ledelsen skal kun ind over igen, når der skal træffes en beslutning.

   • Opfølgning på omfang, tidsplan og beslutninger om ændringer, med en log over ændringer og beslutninger.
   • Forandringsledelse: kommunikationsplan, uddannelse, forandringsambassadører i afdelingerne, samtaler med dem, der endnu ikke er overbevist.
   • Korte opsummeringer til ledelsen og til kommunikationen med IT, kommunalbestyrelsen eller koncernens hovedkontor.
   • Overtagelse ud fra aftalte testscenarier og kriterier, kontrolleret datamigrering.
   • En driftsaftale, der ikke gør jer mere afhængige af én leverandør end nødvendigt.

   Sådan ser det ud ved en ERP-implementering

7. Fast rådgiver for ledelsen

   Vi har ingen IT-direktør. Hvem holder øje med helheden?

   En rolle, der internationalt kaldes „fractional CIO“ (deltids-CIO), med én forskel: Jeg overtager hverken IT-afdelingen eller dens budget. Jeg omsætter ledelsens intentioner til krav, vurderer IT-afdelingens anbefalinger og varetager kundens interesser over for leverandørerne.

   • Et månedligt møde med kommunaldirektøren eller den administrerende direktør og IT-chefen, en månedlig rapport om drift og risici.
   • En kvartalsvis gennemgang af risici og kritiske kontrakter, en udtalelse før større indkøb.
   • De første 90 dage: en indledende vurdering og eventuelle akutte „røde flag“, etablering af registrene og en gennemgang af kontrakterne, en rapport til ledelsen med en køreplan for 12–24 måneder.

Hvor lang tid hver etape tager, afhænger af organisationen og projektet: hvor godt forberedt organisationen er, organisationskulturen og det mandat, ledelsen giver. Derfor fastlægger vi omfang og tidsplan efter den første samtale. Kun IT-kortlægningen har fast pris og tidsplan.