Dette innlegget er for dem som bestiller strategien, godkjenner den eller senere skal gjennomføre den: sekretærer og kasserere (skarbnik) i kommuner, styreledere og styremedlemmer i kommunale selskaper, administrerende direktører og økonomidirektører i selskaper, samt IT-ledere som ønsker at dokumentet endelig skal hjelpe dem i budsjettsamtalen. Jeg har skrevet separat om vanlige feil i kommunale strategier i innlegget IT-strategi i 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 sjekket 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.
- Det er ingen penger. Manglende kobling til budsjettet gjør at strategien og den økonomiske planen lever hver sin liv.
- Den endrer ikke måten man kjøper inn på. Nye systemer kjøpes fortsatt inn som før, ut fra leverandørenes tilbud og ikke ut fra egne standarder.
- Den har ingen eier. Dokumentet ble vedtatt ved vedtak eller styrebeslutning, og der endte dets liv.
- Den er skrevet på IT-språk. Styret og rådet finner ikke svar på sine spørsmål: hvor mye, hvorfor, hva skjer hvis vi ikke gjør noe.
Syv elementer i en strategi som faktisk blir brukt
- Dagens situasjon. Et register over systemer med eier, avtale, lisens, kostnad og sluttdato for support, et kart over prosesser og integrasjoner, og et risikoregister. Uten dette blir alle de neste punktene gjetning. Dette er oppgaven til en kartlegging.
- Målarkitektur. Et enkelt bilde av hvordan registre, prosesser, integrasjoner og tilganger 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 bør arve disse dataene.
- Standarder. Noen få prinsipper som gjelder ved alle innkjøp: hvordan tildeler vi rettigheter, hvordan bør grensesnittet for ansatte se ut, hvordan dokumenterer vi krav, hvilke rettigheter til data vi må ha, hvilket språk (standard) vi bruker til å beskrive prosesser, og hvordan vi sikrer en exit fra samarbeidet.
- Veikart delt i lovpålagt og investering. Skill mellom det vi må gjøre fordi loven eller en avtale krever det (i offentlige etater for eksempel et EZD-system for elektronisk dokument- og saksbehandling, KSeF – det polske e-fakturasystemet, e-Doręczenia – den polske e-leveringstjenesten), og det vi gjør fordi det lønner seg. Med rekkefølge og begrunnelse. Et eksempel: en faktura hentet fra KSeF kan lagres i saksmappen, men bør ifølge loven først få faglig godkjenning, formell og regnskapsmessig verifisering, og deretter automatisk overføres til økonomi- og regnskapssystemet.
- Budsjett delt i investering og drift. Driftskostnadene øker med hvert nytt system og bør synliggjøres før beslutningen om innkjøp tas. Mer om dette i innlegget om total eierskapskostnad (TCO). Husk at implementering som regel er en engangsinvestering (CAPEX), men sett fra et budsjett-, drifts- og sikkerhetsperspektiv innebærer det blant annet service og oppdateringer (OPEX) som gjentar seg år etter år.
- Innkjøpsprinsipper for systemer. Når det er behov for kartlegging eller analyse før innkjøp, hvem som skal vurdere tilbudet, og hvilke klausuler som må inn i avtalen. Noen av disse har jeg beskrevet i innlegget om tender-spesifikasjon (SWZ) uten vendor lock-in.
- Eier og gjennomgangsrytme. En konkret person på ledelsesnivå bør gjennomgå strategien og eierskapskostnadene minst én gang i året, i forbindelse med budsjettet, etter et klart og forutsigbart prinsipp for hvor ofte gjennomgangen skjer.
Den enkleste testen på en strategi: kan kassereren eller økonomidirektøren, når de utarbeider neste års budsjett, hente poster og begrunnelser direkte fra den? Hvis ikke, lever strategien og budsjettet hver sin liv, og det er det som akkurat nå haster mest, som avgjør IT-utgiftene.
Eksempel fra praksis
Vannverksselskapet Wodociągi Miejskie, som tilhører en middels stor kommune, utarbeidet en innkjøpsplan for IT for det kommende året. Opprinnelig ba IT-avdelingen om samtidig utskifting av kontordatamaskiner, kjøp av et nytt overvåkingssystem og modernisering av nettverksinfrastrukturen. Styret ba imidlertid om at man viste hvilke utgifter som var mest presserende sett fra et perspektiv om kontinuitet i vannforsyningen.
Selskapet startet med en kartlegging: de satte opp utstyr, programvare, nettverksforbindelser og serviceavtaler, og koblet dem deretter til konkrete prosesser – fra kundeservice til styring av renseanlegg. Det viste seg at deler av utstyret som formidlet kommunikasjonen med anleggene, nærmet seg slutten av supportperioden, og at dokumentasjonen av forbindelsene ikke dekket alle lokasjoner. Samtidig kunne de fleste kontordatamaskinene fortsatt fungere uten vesentlig innvirkning på kjernetjenestene.
På denne bakgrunn ble rekkefølgen på innkjøpene endret. Først ble det planlagt å rydde opp i og sikre forbindelsene til de teknologiske anleggene, samt bytte ut utstyr som ved svikt kunne vanskeliggjøre overvåkingen av vannforsyningen. Deretter ble det planlagt supplering av sikkerhetskopiering og overvåking. Utskifting av deler av kontordatamaskinene ble utsatt til et senere trinn.
Overfor styret begrunnet ikke lenger IT-avdelingen budsjettet med en generell påstand om at «utstyret er gammelt». De viste i stedet sammenhengen: konkret infrastrukturkomponent → prosessen den betjener → konsekvens ved svikt → foreslått innkjøp. Dermed kunne styret godkjenne utgiftene i etapper og forklare tilsynsrådet hvorfor infrastruktur knyttet til tjenestekontinuitet fikk prioritet fremfor kontorutstyret som var mest synlig for de ansatte.
Når man trenger en uavhengig rådgiver
Det er mulig å skrive strategien selv, forutsatt at noen i organisasjonen har tid til det og ser helheten. Ekstern støtte er nyttig når dagens situasjon ikke er dokumentert, når strategien skal danne grunnlag for å 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 noen trengs for å oversette den ene siden til den andre.
Jeg utarbeider digitaliseringsstrategi og målarkitektur på grunnlag av en kartlegging: med veikart, standarder, innkjøpsprinsipper og et budsjett som lar seg forsvare.