Når en koncern køber flere virksomheder om året, kan IT-integrationen ikke opfindes forfra hver gang. Den tredje overtagelse må ikke behandles som den første. Det kræver en fast opskrift, ofte kaldet en playbook: en standardplatform, som nye selskaber flytter ind på, mindstekrav, der gælder alle, en tjekliste, der følger den enkelte integration fra overtagelsesdagen, og et hold, der har kapacitet til den næste. Opskriften starter den dag, handlen er gennemført, og den er et redskab for IT og koncernledelsen. Den har intet med valget af, hvad der skal købes, at gøre.
Hvorfor regelmæssige opkøb er en anden opgave
Efter ét opkøb er integrationen et projekt. Ved mange opkøb bliver den en driftsopgave. Bliver hver overtagelse behandlet for sig, ender koncernen med et lag af særlige løsninger, som ingen længere kan overskue. Integrationerne overlapper også. Holdet er ikke færdigt med forrige selskab, før det næste kommer, og IT-afdelingen kan ende med at bruge det meste af sin kraft på integration og for lidt på resten af porteføljen.
Den, der ejer opskriften, er derfor vigtig. I koncerner med en CIO eller koncern-IT-leder ligger den dér, og ansvaret skal være skrevet ned. Selskaberne skal vide, at opskriften er koncernens og ikke et forslag.
Standardplatformen
Standardplatformen er det, et nyt selskab kommer over på. Den skal være lille nok til at kunne rulles ud gentagne gange og stor nok til, at koncernen får det, den har brug for. Den kan bestå af fælles identitet og adgang, mail og samarbejde, sikkerhedsværktøjer, rapportering af tal og en fælles måde at købe IT på. Kernesystemer hører sjældent med. Koncerner, der køber forskellige forretninger, kan have en anden linje end dem, der køber det samme igen og igen, og her kan valget af model for IT efter opkøbet ligge fast fra starten.
Platformen skal have en ejer, et budget og en version. Når den ændres, skal det stå tydeligt, hvad det betyder for de selskaber, der allerede er på den. En platform, der ikke vedligeholdes, bliver hurtigt selv en af de særlige løsninger, den skulle fjerne.
Mindstekrav
Et nyt selskab behøver ikke stå på standardplatformen fra første dag. Mindstekravene skal alle derimod opfylde inden for en fastsat tid. Et brugbart sæt mindstekrav kan dække:
- sikkerhed, herunder adgangsstyring, backup og hændelsesmelding,
- rapportering af tal til koncernen med faste frister,
- ejerskab af domæner, licenser og administratoradgange,
- en opdateret liste over systemer og leverandører,
- en navngiven IT-ansvarlig i selskabet.
Kravene skal stå skrevet, være få og kunne måles. Sikkerhedsdelen ejes af dem, der leder sikkerheden. Kan et selskab ikke opfylde et krav til tiden, skal der være en undtagelse med slutdato og en ansvarlig.
Tjeklisten
Tjeklisten er den samme hver gang og tilpasses efter selskabet. Den følger faser, I kender fra den enkelte integrationsplan: første dag, de første uger, overblik, beslutning om model, første flytninger og afslutning.
Vis for hvert punkt, hvem der gør det, hvor lang tid det må tage, og hvad der tæller som færdigt. Opgørelsen af licenser og kontrakter, meldingen til medarbejderne og listen over administratorer skal alle have en fast skabelon. Det sparer mest på de små ting, som ellers skulle findes frem hver gang. Dele af listen kan være hentet fra tidligere integrationer, så den bærer koncernens egen viden.
Tjeklisten kræver stadig dømmekraft. En virksomhed med egen IT-afdeling, særlige kundekrav eller et fagsystem, der er grunden til købet, kan kræve afvigelser. Skriv afvigelserne ned, og send erfaringen retur til opskriften.
Hvem er klar til det næste?
Kapaciteten er let at undervurdere. Ét fast integrationshold med få personer, der gør det hver gang, bliver dygtigt. Det kræver, at holdet har sin egen plads i budgettet og ikke lånes fra driften fra sag til sag. I mindre koncerner kan det være en person med en fast rolle og en liste over dem, der trækkes ind.
Hold regnskab med belastningen. Hvor mange integrationer der kan køre samtidig, afhænger af holdet og af selskaberne, så der er ikke noget fast tal. Sig det åbent til koncernledelsen, hvis IT ikke kan tage endnu en uden, at noget andet må vente, og lad porteføljerådet træffe valget. Når en integration er afsluttet, skal den overdrages til almindelig drift og lukkes. Ellers hober de sig op.
Læring fra gang til gang
Afslut hver integration med et kort møde: hvad gik godt, hvad tog længere tid end planlagt, hvad var uventet, og hvad skal ændres i opskriften? Gem svarene ét sted, og giv en person ansvaret for at opdatere opskriften. Hold samtidig øje med de besluttede synergier, for de viser, om opskriften faktisk leverer det, ledelsen forventede.
Se på det hele mindst én gang om året. Passer platformen stadig til det, koncernen køber? Er mindstekravene de rigtige? Har selskaber, der er købt for længst, fået lov til at blive stående på en midlertidig løsning?
Det skal I lade være med
- At lade den lede, der tilfældigvis har tid · integration kræver et fast hold.
- At gøre standardplatformen for stor · så kan den ikke rulles ud gang på gang.
- At lade undtagelser stå uden slutdato · de bliver til nye særlige løsninger.
- At tage nye selskaber ind uden at lukke de forrige · det kræver en beslutning i ledelsen.
Det skal I kræve af den eksterne
- ☐ En skrevet opskrift med platform, mindstekrav og tjekliste.
- ☐ En ejer af opskriften og en plan for at opdatere den.
- ☐ Et overblik over kapacitet og igangværende integrationer.
- ☐ Afvigelser, der er begrundede og skrevet ned.
- ☐ Anbefalinger uden økonomisk interesse i valget af platform.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Absorbere, samle eller lade leve · Fælles eller lokalt IT · Kapitalfond som ny ejer
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
