Alle indlægJournal · indlæg 02 / 02
Uden jargon

Beskedent interiør fra et gammelt kontor med træpaneler og sagsmapper på et bord ved vinduet.
Illustrationsfoto
Kort svar: En IT-strategi virker, når den tager udgangspunkt i, hvad organisationen faktisk har, og fortæller, hvad der skal gøres i det kommende budget. Den bør indeholde en beskrivelse af den nuværende situation (systemer, kontrakter, omkostninger, risici), en målarkitektur, nogle få standarder, der gælder for ethvert indkøb, en køreplan opdelt i lovpligtige forpligtelser og investeringer, et budget opdelt i investering og drift, indkøbsregler samt en ejer og en fast rytme for gennemgange. Et dokument uden disse elementer bliver som regel til en hensigtserklæring om retning, som ingen vender tilbage til.

Dette indlæg er til dem, der bestiller strategien, godkender den, eller senere skal udføre den: sekretærer og kæmnere i offentlige myndigheder, direktører og bestyrelsesmedlemmer i kommunale selskaber, direktører og økonomidirektører i virksomheder samt IT-chefer, der gerne vil have, at dokumentet endelig hjælper dem i budgetsamtalen. Jeg har skrevet særskilt om typiske fejl i myndigheders strategier i indlægget IT-strategi i JST: de mest almindelige fejl. Her fokuserer jeg på, hvad selve dokumentet bør indeholde.

Hvorfor strategier ender i skuffen

Ud fra det, jeg har set i offentlige og private organisationer, er en strategi sjældent indholdsmæssigt dårlig. Den ender i skuffen, fordi den ikke kan bruges ved den første konkrete beslutning.

  • Den starter med en vision og ikke med en opgørelse. Ingen har undersøgt, hvilke systemer, kontrakter og afhængigheder der allerede findes, så planen kolliderer med virkeligheden ved det første indkøb.
  • Den beskriver mål, men ikke rækkefølge. Alt er vigtigt, så intet er det første.
  • Der er ingen penge. Manglende sammenhæng med budgettet gør, at strategien og den finansielle plan lever hver for sig.
  • Den ændrer ikke måden, man køber ind på. Nye systemer bliver stadig købt som før, ud fra leverandørers tilbud og ikke ud fra egne standarder.
  • Der er ingen ejer. Dokumentet blev vedtaget ved en beslutning eller en bestyrelsesafgørelse, og dermed sluttede dets liv.
  • Den er skrevet i IT-sprog. Bestyrelsen og rådet finder ikke svar på deres spørgsmål i den: hvor meget, hvorfor, og hvad der sker, hvis vi ikke gør noget.

Syv elementer i en strategi, der bliver brugt

  1. Nuværende situation. Et register over systemer med ejer, kontrakt, licens, omkostning og udløb af support, et kort over processer og integrationer samt et risikoregister. Uden det er hvert efterfølgende punkt gætværk. Det er en opgave for inventarisering.
  2. Målarkitektur. Et enkelt billede af, hvordan registre, processer, integrationer og adgang forholder sig til hinanden. Det handler ikke om tekniske diagrammer, men om at svare på, hvilke systemer der er centrale, og hvilke der understøtter dem, hvor data bør opstå, og hvilke systemer der bør arve disse data.
  3. Standarder. Nogle få regler, der gælder ved ethvert indkøb: hvordan vi tildeler rettigheder, hvordan grænsefladen for medarbejderne skal se ud, hvordan vi dokumenterer krav, hvilke datarettigheder vi skal have, hvilket sprog (standard) vi bruger til at beskrive processer, og hvordan vi sikrer en exit fra samarbejdet.
  4. Køreplan opdelt i forpligtelse og investering. Adskilt det, vi skal gøre, fordi loven eller en kontrakt kræver det (i offentlige myndigheder for eksempel et EZD-system (elektronisk dokument- og sagsstyringssystem, EZD RP), det polske nationale e-fakturasystem (KSeF) eller e-Delivery (e-Doręczenia)), fra det, vi gør, fordi det kan betale sig. Med rækkefølge og begrundelse. For eksempel: en faktura, der er hentet fra KSeF, kan gemmes i sagsakterne, men ifølge loven skal den have en indholdsmæssig godkendelse, en formel og regnskabsmæssig kontrol og afslutte sit forløb med en automatisk registrering i det finansielle/regnskabsmæssige system.
  5. Budget opdelt i investering og drift. Driftsomkostningerne vokser med hvert nyt system og bør være synlige, før beslutningen om indkøb træffes. Mere om det i indlægget om den samlede ejeromkostning (TCO). Husk, at implementeringen som regel er en engangsinvestering (CAPEX), men set fra et budget-, drifts- og sikkerhedsperspektiv er service og opdateringer (OPEX) noget, der gentages år efter år.
  6. Indkøbsregler for systemer. Hvornår der er brug for en inventarisering eller en analyse forud for et indkøb, hvem der vurderer tilbuddet, og hvilke klausuler der skal indgå i kontrakten. En del af dette har jeg beskrevet i indlægget om SWZ (udbudsspecifikation efter polsk udbudsret) uden vendor lock-in.
  7. Ejer og gennemgangsrytme. En konkret person på ledelsesniveau bør gennemgå strategien og ejeromkostningerne mindst én gang om året i forbindelse med budgettet, efter en klar og fast tilbagevendende plan for disse gennemgange.
Til økonomisk tilsyn

Den enkleste test af en strategi: kan kæmneren eller økonomidirektøren, når budgettet for det kommende år udarbejdes, direkte tage poster og deres begrundelse fra den? Hvis ikke, lever strategien og budgettet hver for sig, og det er det, der lige nu er presserende, der bestemmer IT-udgifterne.

Eksempel fra praksis

Selskabet Wodociągi Miejskie (det kommunale vandforsyningsselskab), som tilhører en mellemstor kommune, udarbejdede en IT-indkøbsplan for det kommende år. Oprindeligt anmodede IT-afdelingen om samtidig udskiftning af kontorcomputere, indkøb af et nyt overvågningssystem og modernisering af netværksinfrastrukturen. Ledelsen bad dog om at få vist, hvilke udgifter der var mest presserende i forhold til den fortsatte vandforsyning.

Selskabet begyndte med en inventarisering: det opgjorde udstyr, software, netværksforbindelser og serviceaftaler og knyttede dem derefter til konkrete processer — fra kundeservice til styring af renseanlæggenes drift. Det viste sig, at nogle af de enheder, der formidlede kommunikationen med anlæggene, var tæt på slutningen af deres supportperiode, og at dokumentationen af forbindelserne ikke dækkede alle lokationer. Samtidig kunne størstedelen af kontorcomputerne fortsat fungere uden væsentlig indvirkning på de kritiske ydelser.

På denne baggrund blev rækkefølgen af indkøb ændret. Først blev det planlagt at bringe orden i og sikre forbindelserne til de tekniske anlæg samt udskifte de enheder, hvis nedbrud kunne vanskeliggøre overvågningen af vandforsyningen. Dernæst blev det planlagt at supplere backup og overvågning. Udskiftningen af en del af kontorcomputerne blev udskudt til en senere fase.

Over for ledelsen begrundede IT-afdelingen ikke længere budgettet med den generelle udtalelse om, at "udstyret er gammelt". Den viste sammenhængen: konkret infrastrukturkomponent → understøttet proces → konsekvens ved nedbrud → foreslået indkøb. Dermed kunne ledelsen godkende udgifterne i etaper og forklare bestyrelsen, hvorfor infrastruktur relateret til driftskontinuitet fik forrang frem for det kontorudstyr, der var mest synligt for medarbejderne.

Hvornår er der brug for en uafhængig rådgiver

Det er muligt at skrive strategien selv, hvis der i organisationen findes en person, der har tid til det og kan se helheden. Ekstern støtte er nyttig, når den nuværende situation ikke er beskrevet, når strategien skal bruges som grundlag for at forsvare budgettet over for rådet, ejeren eller en overordnet myndighed, når flere lovkrav er på vej samtidig, eller når ledelsen og IT ser forskelligt på prioriteterne, og der er brug for nogen, der kan oversætte det ene perspektiv til det andet.

Jeg udarbejder digitaliseringsstrategien og målarkitekturen på grundlag af en inventarisering: med køreplan, standarder, indkøbsregler og et budget, der kan forsvares.

Hvor mange år bør en IT-strategi dække?
Retningens tidshorisont kan være lang, men køreplanen bør være kort nok til, at den kan kobles til budgettet. Det vigtigste er, at den fortæller, hvad der skal gøres i det kommende år og i hvilken rækkefølge, og at den bliver gennemgået regelmæssigt.
Hvem bør skrive strategien: IT eller ledelsen?
Begge verdener, men med en klar arbejdsdeling. Ledelsen fastlægger mål og prioriteter, IT bidrager med viden om systemer og begrænsninger. Et dokument, der udelukkende er skrevet af IT-afdelingen, er som regel teknisk korrekt, men besvarer ikke ledelsens spørgsmål.
Skal strategien pege på konkrete systemer?
Den bør ikke lægge sig fast på bestemte produkter. Den bør fastsætte krav, standarder og rækkefølge. Valget af et konkret system er en separat beslutning, der træffes på baggrund af en sammenligning af tilbud.
Har en lille organisation brug for en IT-strategi?
Den har brug for en kortere version: en liste over systemer, rækkefølgen af de nærmeste skridt, nogle få indkøbsregler og et budget. Nogle få sider, som ledelsen vender tilbage til ved hver beslutning, er mere værd end et omfangsrigt dokument uden ejer.
Hvor skal man starte, hvis strategien allerede findes, men ligger i skuffen?
Fra at kontrollere, om beskrivelsen af den nuværende situation er ajourført, og fra at udpege en ejer. Ofte er det nok at supplere køreplanen med en opdeling i forpligtelse og investering og koble den til det kommende budget.
Vil I have en strategi, der fra det første budget fortæller, hvad der skal gøres, og i hvilken rækkefølge? Se, hvordan jeg starter med en inventarisering →

Lad os tale om jeres situation – konkret, ikke i generelle vendinger.