En IT-afdeling kan organiseres efter teknik, efter proces, efter forretningsenhed eller efter produkt. Ingen af de fire er rigtig i sig selv. Hver model løser ét problem og flytter et andet derhen, hvor lederne skal bruge tid på det. Det første spørgsmål er derfor, hvilket problem I vil løse. Det andet er, hvilken ledelsesopgave I er villige til at tage på jer bagefter. Læseren her har egne IT-folk og egen IT-leder, og flere selskaber eller et stort program har ændret kravene til afdelingen.
Hvorfor spørgsmålet kommer nu
Organiseringen bliver sjældent valgt. Den vokser frem, mens afdelingen får flere folk, og den holder, indtil noget ændrer sig. Det kan være et nyt selskab i koncernen, et ERP-program over flere år eller en driftsopgave, der flytter til en leverandør. Så begynder det at knirke. De samme personer sidder i programmet og tager telefonen om driften, afdelingerne ved ikke, hvem de skal ringe til, og IT-lederen bruger dagen på at flytte folk mellem opgaver.
Skriv problemet ned i én sætning, før I tegner noget nyt. “Programmet får ikke de folk, det er lovet” peger på en anden løsning end “salg og produktion oplever to forskellige IT-afdelinger”. Uden den sætning bliver et nyt diagram til en flytning af kasser.
Efter teknik
Her samles folk efter fag, med servere og netværk i én gruppe, applikationer i en anden og brugersupport i en tredje. Modellen giver faglig dybde. Specialister lærer af hinanden, dækker for hinanden og har en leder, der forstår deres arbejde.
Prisen ligger i koordineringen. En ændring for en afdeling i forretningen skal gennem flere grupper, og ingen af dem ejer resultatet. Lederne bruger tid på overdragelser, og den, der har et problem, oplever at blive sendt rundt. Modellen passer, når meget af driften ligger i egne hænder. Den kræver faste processer på tværs, for ellers lander ansvaret for helheden hos IT-lederen personligt.
Efter proces: plan, byg og drift
Her deles afdelingen efter, hvor en opgave er i sit liv. Plan ejer arkitektur og prioritering, byg gennemfører projekter, og drift holder systemerne kørende. Styrken er, at programmerne får folk, der ikke samtidig skal holde driften i gang.
Svagheden ligger i overgangen fra byg til drift. Dem, der bygger, går videre, og dem, der skal leve med resultatet, var ikke med, da valgene blev truffet. Ledelsen skal derfor have faste krav til, hvornår noget er klar til overdragelse, og en person, der afgør uenigheder. Plan-delen skal også have reel vægt. Består den af et par folk uden mandat, ender prioriteringen hos dem, der råber højest.
Modellen er værd at overveje, når store programmer kører ved siden af en tung drift.
Efter forretningsenhed
Her får hver division eller hvert selskab sine egne IT-folk, ofte med en leder tæt på den lokale ledelse. Det giver nærhed og hurtige svar. Forretningen oplever, at IT kender dens hverdag.
Regningen kommer som dobbeltarbejde. Grupperne løser samme opgave på hver sin måde, aftaler og systemer glider fra hinanden, og fælles løsninger bliver svære at løfte. Koncernledelsen må tage stilling til, hvad der skal være ens, og hvem der må sige nej til en enhed. Det spørgsmål er emnet i fælles eller lokalt IT. IT-lederen styrer her gennem aftaler og fælles regler, for folkene refererer til en anden. Det er en større ledelsesopgave, end diagrammet viser. Har I én central arbejdsgiver for IT-folk, der arbejder fast i selskaberne, så få det med i overblikket. Sælges en enhed, eller flyttes opgaven til en leverandør, kan det selskab, hvor folkene faktisk arbejder, ifølge EU-Domstolen også anses for overdrager (C-242/09, Albron). Det er et spørgsmål til advokat.
Efter produkt
Ordet kommer fra softwarehuse, og teams omkring et produkt hører hjemme dér. I en virksomhed, der bruger IT, betyder det noget mere jordnært. En varig gruppe har ansvaret for en samlet IT-ydelse, fx vejen fra ordre til levering eller medarbejdernes arbejdsplads, fra ønske over ændring til drift. Gruppen har en ejer, der prioriterer sammen med forretningen.
Det samler ansvaret og fjerner mange overdragelser. Til gengæld skal der være folk nok til at bemande hver gruppe med de nødvendige fag, ellers deler I de samme specialister alligevel. Forretningen skal også stille en ejer med tid til opgaven. Uden den ejer har den gamle arbejdsdeling bare fået en ny overskrift. Modellen virker bedst på områder med mange ændringer og dårligere på stabil infrastruktur.
Samlet ser de fire modeller sådan ud:
- Efter teknik · Styrke: Faglig dybde · Prisen: Koordinering, ingen ejer resultatet · Passer, når: Meget af driften ligger i egne hænder
- Efter proces · Styrke: Programmerne får deres egne folk · Prisen: Overgangen fra byg til drift · Passer, når: Store programmer kører ved siden af en tung drift
- Efter forretningsenhed · Styrke: Nærhed og hurtige svar · Prisen: Dobbeltarbejde · Passer, når: Koncernen kan sige, hvad der skal være ens
- Efter produkt · Styrke: Samlet ansvar, få overdragelser · Prisen: Kræver folk nok og en ejer i forretningen · Passer, når: Områder med mange ændringer
De tre spørgsmål, der afgør det
Få afdelinger bruger én model rent. Infrastrukturen kan stå efter teknik, mens forretningssystemerne står efter ydelse, og programmerne har deres egen gruppe. Det er fint, så længe I kan forklare, hvorfor hver del står, som den gør. Prøv diagrammet på tre spørgsmål:
- Hvem ejer resultatet, når en ændring går på tværs af grupperne?
- Hvem afgør det, når programmet og driften vil have den samme person?
- Hvem aftaler med forretningen, hvad der kommer først?
Kan I svare med ét navn hver gang, kan diagrammet bruges. Tre svar med “det aftaler vi” betyder, at spørgsmålet er flyttet ud i hverdagen. Organisationen er desuden en enkelt del af helheden. Processer, sourcing og styring hører med, som beskrevet i IT operating model.
Hvad I gør nu
Bed IT-lederen og to ledere fra forretningen om hver at formulere problemet. Tegn derefter to modeller, og skriv for hver, hvilken ledelsesopgave der bliver større. Vælg den, hvor I kan bemande den opgave i dag. Rækkefølgen for selve ændringen står i omlægning af IT-afdelingen.
Skal en ekstern CIO med på opgaven, indledes forløbet hos Nielco IT med en gennemgang. Bagefter løber samarbejdet fast hver måned, og timerammen ligger aftalt fra begyndelsen. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At kopiere et diagram fra en anden virksomhed · det løste deres problem, og I kender ikke regningen.
- At omorganisere for at løse et personproblem · en leder, der ikke slår til, bliver ikke stærkere i en ny kasse.
- At skifte model lige før en go-live · vent, til programmet kan tåle det, eller hold programmets folk uden for ændringen.
Det skal I kræve af dem, der leder IT
- ☐ Problemet formuleret i én sætning, før der tegnes noget.
- ☐ To modeller med den ledelsesopgave, hver model skaber.
- ☐ Ét navn på ejerskab, på prioritering og på aftaler med forretningen.
- ☐ En plan for, hvordan driften holdes stabil imens.
Kilder
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ledergruppen i IT · Central, decentral eller føderal IT
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
