En IT-køreplan, på engelsk et IT roadmap, oversætter strategien til en rækkefølge. I en virksomhed med flere afdelinger, selskaber eller programmer er rækkefølgen den egentlige beslutning, for de fleste initiativer er gode, og det er afhængighederne mellem dem, der afgør, hvad der kan lade sig gøre. Planen skal vise, hvad der kommer først, hvad der venter på hvad, og hvem der må vente. Den laves af IT sammen med forretningslederne, ejes af CIO’en eller IT-chefen, og den skal godkendes af den ledergruppe, der skal bære konsekvenserne. En tidslinje uden afhængigheder er en ønskeliste med datoer.
Hvorfor rækkefølgen er det svære
Hver forretningsenhed kan med rette sige, at netop dens projekt haster. Salget vil have nyt kundesystem, økonomien vil have nyt ERP, og produktionen vil have bedre data fra fabrikken. Lægges projekterne på en tavle ved siden af hinanden, ser de ud til at kunne køre samtidig. De støder sammen af tre grunde.
For det første deler de ofte nøglepersoner, både i IT og i forretningen. Den ene dygtige procesejer i økonomien kan ikke sidde i to projekter. For det andet deler de data og integrationer, så et kundesystem kan afhænge af de stamdata, ERP-programmet skal rydde op i. For det tredje er der grænser for, hvor mange ændringer en afdeling kan tage imod på én gang, uanset hvor mange konsulenter der hyres.
En virksomhed uden flere parter kan klare sig med en enkel plan over tre år. Her skal planen bære en afvejning mellem enheder.
Sådan bygger I planen
Arbejdet kan deles i fire trin.
- Saml initiativerne. Tag dem fra strategien, de kørende programmer og de udløb, der kommer af sig selv, som kontrakter, systemer uden support og krav fra myndigheder eller kunder.
- Tegn afhængighederne. For hvert initiativ skrives, hvad det skal have fra andre, og hvad andre venter på. Spørg også, hvilke personer og afdelinger det trækker på.
- Find de faste punkter. Nogle datoer kan ikke flyttes, fx regnskabsår, højsæson, en kontrakt, der udløber, eller en overgang aftalt med en anden part. De lægges ind først.
- Afgør rækkefølgen. Resten fordeles mellem punkterne, indtil planen kan bære den kapacitet, I faktisk har. Det, der ikke kan være der, skrives ud som udskudt, med en begrundelse.
Det sidste trin er ledelsesarbejde. Hvis IT lægger rækkefølgen alene, vil den blive en teknisk ordning, som forretningslederne bagefter skændes om. Hvis forretningslederne deltager, kan de se konsekvensen af deres eget ønske, og det gør forhandlingen mere saglig.
Et tænkt eksempel
Tænk jer en virksomhed med tre selskaber, som vil have fælles ERP, nyt kundesystem og fælles ledelsesrapportering. Hver for sig haster de. Afhængighederne viser, at den fælles rapportering kræver ens kontoplaner og stamdata, som kommer med ERP-programmet, og at kundesystemet skal bruge samme kundedata. Salgsdirektøren må derfor vente, eller også bygges en midlertidig løsning, som senere skal fjernes. Den beslutning er en direktionssag. Den fremkommer kun, fordi afhængighederne står på papir.
Hvad planen skal vise
En køreplan skal kunne læses på en side, og detaljerne hører til i programmerne. Vis disse ting:
- spor pr. område, fx forretningsområde, data og platform, så det fælles arbejde ses,
- de faste punkter og de store beslutninger, der skal træffes undervejs,
- de vigtigste afhængigheder mellem sporene,
- tydelig forskel mellem det, der er besluttet, og det, der er retning.
Præcisionen bør falde med afstanden. Det næste år kan stå med kvartaler. Året efter kan stå som halvår, og det sidste år er en retning. Ledelsen vil gerne have datoer så langt ud som muligt, men datoer, ingen tror på, koster troværdighed, når de flyttes.
Hvordan planen lever
Planen revideres mindst to gange om året og i øvrigt, når der sker noget stort. Det hører naturligt hjemme i porteføljerådet, som også skal håndtere, hvordan for mange samtidige IT-projekter tynder kapaciteten ud. Når et projekt flyttes, skal rådet se, hvilke andre der flytter med. Det er netop den oplysning, der forsvinder, hvis planen er en tegning, som ligger i en præsentation.
Hvad gør I nu? Tag de fem største initiativer, og tegn afhængighederne mellem dem på et møde med IT og de berørte forretningsledere. Arbejdet tager en formiddag og viser som regel, hvor den første afgørelse skal træffes.
Det skal I lade være med
- At lægge alle projekter parallelt for at gøre alle tilfredse · nøglepersonerne afslører planen inden for få måneder.
- At love præcise datoer tre år frem · retningen holder, datoerne gør ikke.
- At glemme de ting, der kommer af sig selv · kontrakter og systemer uden support kræver plads i planen.
Det skal I kræve af dem, der leder IT
- ☐ En køreplan på én side med afhængighederne tegnet ind.
- ☐ En liste over det, der er udskudt, og begrundelsen.
- ☐ Oversigt over de nøglepersoner, flere initiativer deler.
- ☐ Besked om konsekvenser for andre initiativer, når et enkelt flyttes.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Prioriteringsmodel til IT-projekter · Hvad står der i en IT-strategi?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
