Dette innlegget er for dem som bestiller, godkjenner eller selv skal gjennomføre strategien: kommunesekretærer og økonomisjefer (skarbnik) i kommuner, styreledere og styremedlemmer i kommunale selskaper, administrerende direktører og finansdirektører i virksomheter, samt IT-ledere som ønsker at dokumentet endelig skal hjelpe dem i budsjettsamtalen. De vanligste feilene i kommunale strategier har jeg skrevet om i et eget innlegg, IT-strategi i kommunesektoren (JST): de vanligste feilene. Her fokuserer jeg på hva selve dokumentet bør inneholde.
Hvorfor strategier havner i skuffen
Ut fra det jeg har sett i offentlige og private organisasjoner, er strategien sjelden faglig dårlig. Den havner i skuffen fordi den ikke lar seg bruke ved den første konkrete beslutningen.
- Den starter med en visjon, ikke med en oversikt. Ingen har kartlagt hvilke systemer, avtaler og avhengigheter som allerede finnes, så planen kolliderer med virkeligheten ved første innkjøp.
- Den beskriver mål, men ikke rekkefølge. Alt er viktig, så ingenting kommer først.
- Den mangler penger. Uten kobling til budsjettet lever strategien og den finansielle planen hver sin side.
- Den endrer ikke måten man kjøper på. Nye systemer anskaffes fortsatt som før, basert på leverandørenes tilbud og ikke egne standarder.
- Den har ingen eier. Dokumentet ble vedtatt gjennom et vedtak eller en styrebeslutning, og der sluttet livet dets.
- Den er skrevet på IT-språk. Styret og rådet finner ikke svar på sine egne spørsmål: hvor mye, hvorfor, og hva som skjer hvis man ikke gjør noe.
Syv elementer i en strategi som faktisk brukes
- Nåsituasjonen. Et register over systemer med eier, avtale, lisens, kostnad og supportslutt, et kart over prosesser og integrasjoner, samt et risikoregister. Uten dette blir alle de neste punktene gjetning. Dette er oppgaven for kartleggingen.
- Målarkitektur. Et enkelt bilde av hvordan registre, prosesser, integrasjoner og tilgang forholder seg til hverandre. Det handler ikke om tekniske skjemaer, men om å svare på hvilke systemer som er sentrale og hvilke som støtter dem, hvor data bør oppstå, og hvilke systemer som skal arve disse dataene.
- Standarder. Noen få regler som gjelder ved alle anskaffelser: hvordan vi tildeler rettigheter, hvordan grensesnittet for ansatte skal se ut, hvordan vi dokumenterer krav, hvilke datarettigheter vi må ha, hvilket språk (standard) vi bruker for å beskrive prosesser, og hvordan vi sikrer en exit fra samarbeidet.
- Veikart med skille mellom lovpålagte tiltak og investeringer. Hold det som må gjøres fordi loven eller en avtale krever det (i det offentlige for eksempel et EZD-system (elektronisk saksbehandlingssystem), KSeF (det polske e-fakturasystemet) eller e-Doręczenia (den polske e-leveringstjenesten)) atskilt fra det som gjøres fordi det lønner seg – med rekkefølge og begrunnelse. Et eksempel: en faktura som er hentet fra KSeF, kan lagres i saksmappen, men bør i henhold til loven først gjennom faglig godkjenning og formell/regnskapsmessig kontroll, før den avsluttes med automatisk registrering i økonomisystemet.
- Budsjett delt i investering og drift. Driftskostnadene øker med hvert nytt system og bør være synlige før innkjøpsbeslutningen tas. Mer om dette i innlegget om total eierkostnad. Husk at selve innføringen som regel er en engangsinvestering (CAPEX), men at kontinuitet og sikkerhet sett fra budsjettets side blant annet krever service og oppdateringer (OPEX), som gjentar seg år etter år.
- Anskaffelsesprinsipper for systemer. Når det er behov for kartlegging eller analyse før innkjøp, hvem som vurderer tilbudet, og hvilke klausuler som må være med i avtalen. Noen av disse har jeg beskrevet i innlegget om SWZ (anbudsspesifikasjon) uten vendor lock-in.
- Eier og gjennomgangsrytme. En konkret person på ledelsessiden bør gjennomgå strategien og eierkostnadene, minst én gang i året i forbindelse med budsjettet, etter et tydelig prinsipp om at gjennomgangen skal være syklisk.
Den enkleste testen på en strategi: kan økonomisjefen (skarbnik) eller finansdirektøren, når neste års budsjett utarbeides, hente poster og begrunnelser direkte fra den? Hvis ikke, lever strategien og budsjettet hver sin side, og det er det som akkurat haster, som avgjør IT-utgiftene.
Eksempel fra praksis
Kommunale Vannverk, et selskap eid av en middels stor kommune, utarbeidet en plan for IT-innkjøp for det kommende året. IT-avdelingen foreslo i første omgang å bytte ut alle kontormaskiner samtidig, kjøpe et nytt overvåkingssystem og modernisere nettverksinfrastrukturen. Styret ba imidlertid om å få vist hvilke utgifter som var mest presserende sett fra vannforsyningens kontinuitet.
Selskapet startet med en kartlegging: de samlet oversikt over utstyr, programvare, nettverksforbindelser og serviceavtaler, og koblet dem deretter til konkrete prosesser – fra kundebehandling til styring av vannbehandlingsanleggene. Det viste seg at en del av utstyret som formidlet kommunikasjonen med anleggene, nærmet seg slutten av sin supportperiode, og at dokumentasjonen av forbindelsene ikke dekket alle lokasjoner. Samtidig kunne de fleste kontormaskinene fortsette å fungere uten vesentlig innvirkning på de kritiske tjenestene.
På dette grunnlaget ble innkjøpsrekkefølgen endret. Først ble det planlagt å rydde opp og sikre forbindelsene til de tekniske anleggene, samt bytte ut utstyr der et driftsstopp kunne vanskeliggjøre overvåkingen av vannforsyningen. Deretter ble det planlagt å styrke sikkerhetskopiering og overvåking. Utskiftingen av en del av kontormaskinene ble skjøvet til et senere trinn.
Overfor styret begrunnet ikke IT-avdelingen lenger budsjettet med en generell påstand om at «utstyret er gammelt». De viste i stedet sammenhengen: konkret infrastrukturkomponent → prosess den understøtter → konsekvens ved driftsstans → foreslått innkjøp. Dermed kunne styret godkjenne utgiftene trinnvis og forklare tilsynsrådet hvorfor infrastruktur knyttet til tjenestekontinuitet fikk prioritet foran kontorutstyret som var mest synlig for de ansatte.
Når er en uavhengig rådgiver nødvendig
Strategien kan skrives med egne krefter dersom noen i organisasjonen har tid til det og ser helheten. Ekstern støtte er nyttig når nåsituasjonen ikke er dokumentert, når strategien skal brukes til å forsvare budsjettet overfor rådet, eieren eller overordnet myndighet, når flere regulatoriske krav kommer samtidig, eller når ledelsen og IT ser ulikt på prioriteringene og det trengs noen som kan oversette det ene perspektivet til det andre.
Jeg utarbeider digitaliseringsstrategi og målarkitektur basert på en kartlegging: med veikart, standarder, anskaffelsesprinsipper og et budsjett som lar seg forsvare.