Fra den første kartleggingen til overtakelsen av systemet. Én rådgiver på ledelsens side gjennom hele kursen.

1. Kartlegging av IT-systemer og prosesser

   Hva har vi egentlig?

   Utgangspunktet for enhver beslutning om innføring. Før dere velger system, leverandør eller retning, får dere et klart og strukturert bilde av hva dere allerede har.

   • Et register over applikasjoner med eier, kontrakt, lisens, kostnad og slutt på support.
   • Et kart over støttede og ikke-støttede prosesser, et kart over integrasjoner og over steder der data tastes inn manuelt på nytt.
   • Et risikoregister, inkludert single points of failure og avhengighet av én leverandør (lock-in).
   • Kategorisering av systemene i A/B/C/D og et sammendrag på én side til ledelsen.

   2–6 uker, under terskelverdien for offentlige anskaffelser.

   Hele omfanget av IT-kartleggingen

2. Behovsanalyse og workshoper

   Hva trenger vi virkelig?

   Interne workshoper der vi finner ut hva organisasjonen virkelig trenger. Ofte får jeg det fram med enkle spørsmål: Hva er definisjonen på suksess? Når vil prosjektet bli vurdert som vellykket? Bedrifter og offentlige etater hopper svært ofte over dette, enten fordi de tror de allerede vet alt, eller fordi de rett og slett ikke har tid til dypere spørsmål. Det er en av de vanligste årsakene til problemer i prosjekter.

   • Workshoper med ledelsen og de medarbeiderne som jobber i prosessen til daglig: mål, forventninger, begrensninger.
   • En definisjon av suksess og kriteriene som viser dere at prosjektet har lyktes.
   • En beskrivelse av hva som ikke fungerer i dag, og av hvordan fremtiden skal se ut.
   • Innspill til kravene eller til en markedsundersøkelse – eller en beslutning om at det ikke trengs et nytt system.

   Spørsmålene jeg starter med

3. Digital strategi og målarkitektur

   Hvor skal vi, og i hvilken rekkefølge?

   En strategi som ikke havner i en skuff, fordi den bygger på det organisasjonen faktisk har, og sier hva som skal gjøres i neste budsjett.

   • En målarkitektur bygd opp i lag: registre, prosesser, integrasjoner og tilgang.
   • Standarder som organisasjonen tar i bruk: en tilgangsmodell, en grensesnittstandard, regler for dokumentasjon av krav.
   • Et veikart som skiller mellom lovpålagte krav og investeringer.
   • Innkjøpsregler for systemanskaffelser og et budsjett fordelt på investering og drift.

4. Krav og prosjektforberedelse

   Hvordan beskriver vi behovene slik at leverandøren forstår dem?

   Krav skrevet på språket til prosessene deres, før dere lyser ut en konkurranse eller ber om tilbud. De gjør tilbudene sammenlignbare og gjør det mulig å holde leverandøren ansvarlig senere.

   • Intervjuer, prosesskart, datamodell, integrasjoner og testscenarier.
   • Først og fremst et svar på spørsmålet om hva som er suksesskriteriet for innføringen: hvorfor vi gjør dette, og hvilke resultater vi forventer.
   • Når ledelsen har en idé, men ikke tid til å skrive den ut: et konsept eller en prototyp etter én samtale, på ca. 2 dager.

5. Tilbudsevaluering og leverandørdialog

   Hvordan sammenligner vi tilbud fra ulike leverandører på en god måte?

   En uavhengig vurdering ved siden av anbefalingen fra deres egen IT-avdeling, ikke i stedet for den. Ledelsen får en sammenligning den kan bygge beslutningen på og forsvare overfor kommunestyret, eieren eller konsernets hovedkontor.

   • Spørsmål til leverandørene og demonstrasjoner basert på deres egne scenarier.
   • En sammenligningsmatrise: tilbud brakt ned til et felles omfang, totalkostnad over flere år, vilkår for drift og for å gå ut av avtalen.
   • I datterselskaper en sammenligning etter konsernets innkjøpsretningslinjer, ved behov på engelsk.
   • Deltakelse i møter med leverandører som kundens representant.

6. Innføring, endring og overtakelse

   Hvordan får vi prosjektet i mål, folk med oss og leverandøren til å levere det som er avtalt?

   Et stort IT-prosjekt er også en endring i måten folk jobber på. Ofte det første av sitt slag i organisasjonen deres, men ikke i min praksis. Jeg representerer ledelsen i prosjektteamet og veileder endringen slik at folk faktisk tar i bruk det nye systemet. Ledelsen trenger bare å komme inn igjen når det må tas en beslutning.

   • Oppfølging av omfang, tidsplan og beslutninger om endringer, med en logg over endringer og beslutninger.
   • Endringsledelse: kommunikasjonsplan, opplæring, endringsambassadører i avdelingene, samtaler med dem som ennå ikke er overbevist.
   • Korte sammendrag for ledelsen og for kommunikasjonen med IT, kommunestyret eller konsernets hovedkontor.
   • Overtakelse etter avtalte testscenarier og kriterier, kontrollert datamigrering.
   • En driftsavtale som ikke gjør dere mer avhengige av én leverandør enn nødvendig.

   Slik ser det ut ved en ERP-innføring

7. Fast rådgiver for ledelsen

   Vi har ingen IT-direktør. Hvem holder oversikten over helheten?

   En rolle som internasjonalt kalles «fractional CIO» (deltids-CIO), med én forskjell: Jeg overtar verken IT-avdelingen eller budsjettet dens. Jeg omsetter ledelsens intensjoner til krav, vurderer anbefalingene fra IT og ivaretar kundens interesser overfor leverandørene.

   • Et månedlig møte med kommunedirektøren eller administrerende direktør og IT-sjefen, en månedlig rapport om drift og risiko.
   • En kvartalsvis gjennomgang av risikoer og kritiske kontrakter, en vurdering før større innkjøp.
   • De første 90 dagene: en innledende vurdering og eventuelle akutte «røde flagg», etablering av registrene og en gjennomgang av kontraktene, en rapport til ledelsen med et veikart for 12–24 måneder.

Hvor lang tid hver etappe tar, avhenger av organisasjonen og prosjektet: hvor godt forberedt organisasjonen er, organisasjonskulturen og mandatet ledelsen gir. Derfor fastsetter vi omfang og tidsplan etter den første samtalen. Bare IT-kartleggingen har fast pris og tidsplan.