IT en data integreren: eerst de bedrijfsvoering, daarna de techniek
IT- en data-integratie behoren in mijn ervaring tot de meest onderschatte onderdelen van een post-merger integratie. Op papier lijkt de vraag vaak eenvoudig: welk systeem houden we en welk systeem verdwijnt? In de praktijk blijkt al snel dat zo’n beslissing gevolgen heeft voor vrijwel de hele organisatie. Finance, Sales, Operations, HR, Customer Service en managementrapportage zijn allemaal afhankelijk van systemen, data en onderlinge koppelingen.
Daarom behandel ik IT-integratie nooit als een op zichzelf staand technisch migratieproject. Voor mij begint de discussie niet met de vraag welk ERP-, CRM- of HR-systeem technisch het beste is, maar met de vraag hoe de nieuwe organisatie na de integratie moet functioneren.
Welke processen willen we gezamenlijk uitvoeren? Welke informatie hebben medewerkers nodig? Welke managementinformatie moet beschikbaar zijn? Welke organisatieonderdelen worden daadwerkelijk geïntegreerd en welke blijven voorlopig zelfstandig? Pas wanneer daar duidelijkheid over bestaat, kan een verstandige keuze worden gemaakt voor systemen, applicaties, data en interfaces.
In integraties zie ik regelmatig dat deze volgorde wordt omgedraaid. Er wordt bijvoorbeeld vroeg besloten dat iedereen naar het systeem van de grootste organisatie moet migreren. Vervolgens blijkt tijdens de implementatie dat processen van de overgenomen onderneming niet goed in dat systeem passen, dat belangrijke functionaliteit ontbreekt of dat klanten juist afhankelijk zijn van een werkwijze die door de migratie verloren dreigt te gaan.
Mijn uitgangspunt is daarom: niet het bestaande IT-landschap bepaalt de toekomstige organisatie; de toekomstige bedrijfsvoering bepaalt welk IT-landschap nodig is.
Niet automatisch kiezen voor het systeem van de grootste organisatie
Een veelgemaakte aanname is dat de grootste onderneming automatisch ook het beste systeemlandschap heeft. Dat hoeft helemaal niet zo te zijn.
Ik ben situaties tegengekomen waarin een kleinere organisatie veel verder was met automatisering of veel eenvoudiger processen had ingericht. Andersom kan een grotere organisatie juist beschikken over sterkere governance, security, schaalbaarheid of rapportagevoorzieningen.
Daarom vergelijk ik niet alleen applicaties, maar vooral wat beide organisaties ermee kunnen.
Bijvoorbeeld:
- hoe snel kan een order worden verwerkt;
- hoeveel handmatige stappen zijn nodig;
- waar wordt informatie dubbel ingevoerd;
- hoe betrouwbaar zijn rapportages;
- hoe makkelijk kunnen medewerkers informatie terugvinden;
- welke integraties met klanten en leveranciers bestaan al;
- welke applicaties ondersteunen unieke commerciële proposities;
- welke technische schuld zit onder de oppervlakte;
- welke oplossing is schaalbaar voor de toekomstige organisatie.
De uitkomst kan zijn dat één systeem duidelijk de beste keuze is. Maar het kan ook betekenen dat delen van beide landschappen worden behouden of dat juist een nieuwe oplossing nodig is.
Eerst begrijpen wat er achter een systeem zit
Een IT-migratie lijkt soms een kwestie van data overzetten en gebruikers toegang geven tot een nieuwe applicatie. In werkelijkheid zit achter ieder systeem een complete werkwijze.
Een CRM bevat bijvoorbeeld niet alleen klantgegevens. Het kan ook verkoopfasen, prijsafspraken, autorisaties, contractinformatie, forecastlogica en commerciële KPI’s bevatten.
Een ERP-systeem bevat niet alleen financiële transacties, maar bijvoorbeeld ook productstructuren, kostprijzen, voorraadlogica, inkoopvoorwaarden en facturatieregels.
Wanneer twee organisaties dergelijke systemen samenvoegen, moet dus eerst duidelijk zijn welke onderliggende processen en definities de nieuwe standaard worden.
Dat is precies waar IT-integratie een organisatievraagstuk wordt.
Mijn Business-to-Technology Integration Framework
Bij IT- en data-integratie na een overname begin ik niet met de vraag:
Welk systeem houden we?
Ik begin met:
Hoe moet de gecombineerde onderneming straks werken — en welke technologie en data zijn daarvoor werkelijk nodig?
Dat onderscheid is belangrijk.
Een technisch aantrekkelijke consolidatie kan operationeel de verkeerde keuze zijn wanneer processen nog niet zijn geharmoniseerd, verantwoordelijkheden onduidelijk zijn of belangrijke klantfunctionaliteit verloren gaat.
Daarom ontwerp ik IT- en data-integratie in een vaste volgorde.
Ik noem dit mijn Postmerger Business-to-Technology Integration Framework.
| Laag | Centrale vraag | Wat moet helder zijn? | Typisch risico wanneer je te vroeg naar techniek gaat |
|---|---|---|---|
| 1. Businessdoel | Welke waarde moet de integratie realiseren? | Synergie, groei, eenvoud, schaal, control, klantwaarde | IT-project zonder aantoonbare businesscase |
| 2. Operating model | Hoe moet de nieuwe organisatie functioneren? | Centraal/decentraal, verantwoordelijkheden, governance | Systeemkeuze dicteert organisatieontwerp |
| 3. Processen | Welke processen worden gezamenlijk uitgevoerd? | Processtandaard, uitzonderingen, ownership, overdrachten | Oude verschillen worden technisch ingebouwd |
| 4. Data | Welke informatie en definities worden leidend? | Masterdata, definities, bronnen, ownership, kwaliteit | Eén database, maar nog steeds meerdere waarheden |
| 5. Applicaties | Welke functionaliteit is echt nodig? | ERP, CRM, HR, planning, rapportage, specialistische tools | Grootste of oudste systeem wordt automatisch gekozen |
| 6. Interfaces | Hoe stroomt informatie tussen systemen? | Kritieke koppelingen, handmatige stappen, batchprocessen | Individuele systemen werken, keten faalt |
| 7. Security & toegang | Wie mag wat zien en doen? | Identity, autorisaties, privacy, cyberrisico’s | Te veel of juist te weinig toegang |
| 8. Migratie | Hoe gaan we veilig naar de doelomgeving? | Fasering, testing, cutover, fallback, validatie | Technische migratie veroorzaakt operationele verstoring |
| 9. Decommissioning | Wanneer kan de oude omgeving echt uit? | Dataretentie, rapportages, contracten, afhankelijkheden | Dubbele kosten blijven structureel bestaan |
| 10. Waarderealisatie | Heeft de integratie de organisatie daadwerkelijk verbeterd? | Kosten, snelheid, datakwaliteit, gebruikerservaring, bestuurbaarheid | Veel technische output, weinig operationele waarde |
De volgorde is bewust.
Eerst bepaal ik hoe de organisatie moet werken. Daarna wat processen en data nodig hebben. Pas daarna komt de systeemkeuze.
Mijn belangrijkste ontwerpregel: kies functionaliteit vóór merk of platform
Bij integraties ontstaat snel de vraag:
SAP of Dynamics? Salesforce of het bestaande CRM? Systeem A of systeem B?
Ik probeer die discussie eerst een niveau hoger te brengen.
Ik vergelijk niet alleen applicaties.
Ik vergelijk vooral wat de organisatie ermee kan.
Bijvoorbeeld:
| Criterium | Vraag |
|---|---|
| Procesfit | Ondersteunt het systeem het toekomstige proces zonder veel workarounds? |
| Klantimpact | Ondersteunt het klantbediening, service en commerciële propositie? |
| Schaalbaarheid | Kan het toekomstige volume en complexiteit aan? |
| Data | Ondersteunt het de gewenste definities en rapportages? |
| Integratievermogen | Kan het goed samenwerken met andere kritieke applicaties? |
| Security | Voldoet het aan vereiste control en cybersecurity? |
| Gebruiksgemak | Kunnen medewerkers er effectief mee werken? |
| Automatisering | Hoeveel handmatig werk kan verdwijnen? |
| Technische schuld | Welke verborgen complexiteit nemen we mee? |
| Totale kosten | Licenties, beheer, migratie, interfaces en change |
| Transitierisico | Hoe moeilijk is migratie zonder verstoring? |
| Toekomstfit | Past het ook bij de organisatie die we over drie tot vijf jaar willen zijn? |
Daarmee voorkom je dat:
de grootste onderneming automatisch de standaard wordt.
De juiste oplossing kan systeem A zijn.
Systeem B.
Een combinatie van beide.
Of een nieuw platform C.
Mijn Application Decision Matrix
Voor ieder belangrijk systeem beoordeel ik vier mogelijke routes.
1. Behouden
Een bestaand systeem blijft leidend.
Logisch wanneer het:
- goed aansluit op het toekomstige operating model;
- technisch gezond is;
- schaalbaar is;
- voldoende functionaliteit biedt;
- en migratie vanuit de andere omgeving verantwoord is.
2. Consolideren
Twee of meer applicaties worden teruggebracht naar één bestaande oplossing.
Vooral aantrekkelijk bij:
- sterke functionele overlap;
- hoge dubbele kosten;
- gedeelde processen;
- uniforme data;
- duidelijke schaalvoordelen.
3. Koppelen
Beide systemen blijven voorlopig bestaan, maar data en processen worden verbonden.
Dit kan verstandig zijn wanneer:
- organisaties deels zelfstandig blijven;
- volledige migratie weinig extra waarde creëert;
- transitiecomplexiteit hoog is;
- snelheid belangrijker is dan volledige standaardisatie.
4. Vervangen
Beide bestaande oplossingen verdwijnen en er komt een nieuw platform.
Dit is de zwaarste keuze.
Ik vind die vooral logisch wanneer:
- beide omgevingen fundamentele beperkingen hebben;
- de toekomstige organisatie wezenlijk anders werkt;
- technische schuld groot is;
- of een nieuw platform aantoonbaar meer waarde biedt.
De praktische applicatiematrix
Een portfolio kan er bijvoorbeeld zo uitzien:
| Systeem | Procesfit | Datakwaliteit | Schaalbaarheid | Dubbele kosten | Migratierisico | Strategische waarde | Voorkeursroute |
|---|---|---|---|---|---|---|---|
| ERP A | Hoog | Hoog | Hoog | Hoog | Hoog | Hoog | Behouden / consolideren |
| ERP B | Middel | Middel | Laag | Hoog | Middel | Laag | Uitfaseren |
| CRM A | Hoog | Hoog | Hoog | Middel | Middel | Zeer hoog | Behouden |
| Specialistische operations-app | Zeer hoog | Hoog | Middel | Laag | Zeer hoog | Zeer hoog | Voorlopig zelfstandig |
| Reportingtool | Middel | Laag | Middel | Middel | Laag | Middel | Vervangen / consolideren |
De bedoeling is niet om scores mechanisch op te tellen.
Het gesprek is belangrijker:
welke capability verliezen we wanneer we dit systeem uitzetten, en welke complexiteit houden we in stand als we het behouden?
Data vóór migratie: mijn Data Readiness Check
Een technische migratie lost geen semantisch probleem op.
Wanneer twee organisaties verschillende definities hanteren, creëert het samenvoegen van databases niet automatisch één waarheid.
Daarom beoordeel ik vóór een datamigratie minimaal:
| Onderdeel | Centrale vraag |
|---|---|
| Definitie | Betekent “klant”, “omzet”, “marge”, “order” of “actief” in beide organisaties hetzelfde? |
| Golden source | Welke bron wordt straks leidend? |
| Ownership | Wie is verantwoordelijk voor kwaliteit en definitie? |
| Duplicaten | Welke records vertegenwoordigen feitelijk dezelfde entiteit? |
| Historie | Welke historische data moet echt mee? |
| Kwaliteit | Welke data is incompleet, fout of verouderd? |
| Mapping | Hoe worden oude waarden naar nieuwe structuren vertaald? |
| Validatie | Hoe bewijzen we dat gegevens na migratie kloppen? |
| Rapportage | Leveren oude en nieuwe omgeving vóór cutover dezelfde kernuitkomsten? |
| Retentie | Welke data moet juridisch of operationeel beschikbaar blijven? |
Mijn regel is:
Data die vóór migratie semantisch onduidelijk is, blijft na migratie technisch netjes maar inhoudelijk onbetrouwbaar.
Interfaces zijn vaak belangrijker dan de systemen zelf
Bij IT-integraties gaat veel aandacht naar grote applicaties.
Maar de operatie loopt vaak juist vast op de verbindingen ertussen.
Daarom maak ik naast een applicatielandschap altijd een interface- en dependency map.
Per kritieke koppeling wil ik weten:
| Vraag | Waarom dit belangrijk is |
|---|---|
| Welke informatie stroomt er? | Begrijpen wat bedrijfskritisch is |
| Hoe vaak? | Real-time, batch, handmatig |
| Wie is bron en wie ontvanger? | Ownership |
| Wat gebeurt er bij uitval? | Continuïteitsrisico |
| Bestaat een handmatige fallback? | Herstelvermogen |
| Wie bewaakt de koppeling? | Operationeel eigenaarschap |
| Welke downstream-processen zijn afhankelijk? | Impact bepalen |
| Wanneer kan de koppeling verdwijnen? | Decommissioning |
Ook Excel, CSV-imports, handmatige exports en lokale databases neem ik hierin mee.
Niet omdat iedere spreadsheet moet verdwijnen.
Maar omdat juist zulke hulpmiddelen vaak zichtbaar maken waar de formele IT-architectuur de dagelijkse bedrijfsvoering onvoldoende ondersteunt.
Mijn migratiebeslisregel: snelheid versus bedrijfsrisico
Systemen snel uitfaseren kan aantrekkelijk zijn omdat dubbele licentie- en beheerkosten verdwijnen.
Maar snelheid is niet altijd waarde.
Daarom beoordeel ik migraties langs vijf factoren:
| Factor | Vraag |
|---|---|
| Business criticality | Wat gebeurt er met klanten of operatie bij problemen? |
| Reversibiliteit | Kunnen we veilig terug als de migratie mislukt? |
| Datacomplexiteit | Hoe moeilijk zijn mapping en validatie? |
| Afhankelijkheden | Welke processen, systemen of rollen moeten eerst klaar zijn? |
| Dubbele kosten | Wat kost wachten werkelijk per maand? |
Daaruit kunnen verschillende keuzes volgen.
Hoog bedrijfsrisico + lage kosten van wachten
Gefaseerd migreren.
Laag bedrijfsrisico + hoge dubbele kosten
Versnellen.
Hoog bedrijfsrisico + hoge dubbele kosten
Managementbesluit nodig over expliciete trade-off.
Lage waarde van integratie + hoge migratiecomplexiteit
Niet automatisch migreren.
Tijdelijk dubbel draaien kan een bewuste architectuurkeuze zijn
Ik zie parallelle systemen niet automatisch als mislukte integratie.
Soms is het rationeel om gedurende een periode twee omgevingen te behouden.
Maar dan wil ik vier dingen expliciet maken:
- Waarom accepteren we tijdelijk dubbele complexiteit?
- Wie is eigenaar van de tijdelijke situatie?
- Wat moet gebeuren voordat één omgeving kan verdwijnen?
- Wat is het uiterste beslis- of exitmoment?
Daarmee wordt “tijdelijk” een bestuurde overgang in plaats van uitgestelde besluitvorming.
Mijn IT Integration Dependency Chain
Veel IT-besluiten zijn downstream van businessbesluiten.
Daarom gebruik ik waar mogelijk deze volgorde:
Deal rationale
↓
Target Operating Model
↓
Processen
↓
Procesownership en rollen
↓
Data & definities
↓
Applicatiekeuze
↓
Interfaces & architectuur
↓
Security & autorisaties
↓
Migratie
↓
Decommissioning
↓
Waarderealisatie
Niet ieder programma loopt volledig lineair.
Maar de afhankelijkheden zijn reëel.
Een autorisatiemodel kan bijvoorbeeld pas duurzaam worden ingericht wanneer rollen duidelijk zijn.
Een ERP-configuratie kan pas goed worden ontworpen wanneer processen zijn gekozen.
Een gezamenlijk dashboard heeft pas betekenis wanneer KPI-definities gelijk zijn.
Dat is waarom ik IT-integratie als bedrijfsintegratie beschouw.
Mijn IT Integration Health Check
Naast projectstatus kijk ik naar een aantal signalen die aangeven of de integratie werkelijk gezond is.
| Dimensie | Groen | Oranje | Rood |
|---|---|---|---|
| Business alignment | IT-keuzes volgen operating model | Enkele aannames open | IT bepaalt feitelijk businessontwerp |
| Procesharmonisatie | Kernprocessen helder | Belangrijke verschillen bestaan | Geen gezamenlijke procesrichting |
| Data | Definities en ownership helder | Kwaliteitsissues beheersbaar | Discussie over basisdata blijft bestaan |
| Interfaces | Kritieke koppelingen bekend | Enkele workarounds | Veel onbekende handmatige afhankelijkheden |
| Security | Identity/rechten gecontroleerd | Tijdelijke uitzonderingen | Ongecontroleerde toegang/legacy accounts |
| Migratie | Getest en beheersbaar | Belangrijke risico’s open | Cutover bedreigt operatie |
| Continuïteit | Fall-back en BCP helder | Gedeeltelijk getest | Geen realistisch herstelplan |
| Adoptie | Gebruikers kunnen effectief werken | Training/support nodig | Techniek live, operatie functioneert slecht |
| Legacy-afbouw | Exitplan uitvoerbaar | Enkele blokkades | Oude omgeving blijft zonder einddatum |
| Businesswaarde | Kosten/kwaliteit/snelheid verbeteren | Effect nog niet bewezen | Technische oplevering zonder aantoonbare waarde |
Het doel van deze health check is niet een groen dashboard.
Het doel is tijdig zichtbaar maken waar een technisch probleem eigenlijk een business-, proces- of governanceprobleem is.
Wanneer is IT-integratie werkelijk succesvol?
Ik beschouw IT-integratie niet als succesvol wanneer:
- één ERP live staat;
- data technisch is gemigreerd;
- applicaties zijn gekoppeld;
- of een legacy-systeem wordt uitgezet.
Voor mij moet uiteindelijk aan vijf voorwaarden worden voldaan.
1. De business kan functioneren
Medewerkers kunnen hun werk doen zonder onnodige workarounds.
2. Klanten ondervinden geen ongecontroleerde hinder
Integratie verbetert of beschermt klantbediening.
3. Management kan op betrouwbare informatie sturen
Data en KPI’s hebben heldere definities en ownership.
4. De technologie ondersteunt het gekozen operating model
Niet andersom.
5. De beoogde waarde wordt daadwerkelijk gerealiseerd
Dubbele kosten verdwijnen, processen worden eenvoudiger, informatie verbetert of risico neemt aantoonbaar af.
Pas dan is de technische migratie ook een geslaagde bedrijfsintegratie.
Mijn belangrijkste praktijkregel
Als ik één principe uit dit framework zou moeten kiezen, is het:
Migreer geen systeem voordat je begrijpt welke bedrijfsvoering, processen, data en verantwoordelijkheden dat systeem straks moet ondersteunen.
Dat kan betekenen dat een migratie later plaatsvindt dan technisch mogelijk is.
Het kan ook betekenen dat juist sneller geconsolideerd wordt omdat processen, data en afhankelijkheden al helder zijn.
En soms betekent het dat een systeem voorlopig helemaal niet geïntegreerd hoeft te worden.
Het doel is voor mij niet het kleinste mogelijke applicatielandschap.
Het doel is een IT- en datalandschap dat de gecombineerde onderneming eenvoudiger, betrouwbaarder en beter bestuurbaar maakt.
Datamigratie is zelden alleen ‘data verplaatsen’
Een van de meest praktische problemen die ik tijdens integraties tegenkom, is dat dezelfde gegevens in beide organisaties iets anders betekenen.
Een klant kan bijvoorbeeld in het ene systeem één juridische entiteit zijn en in het andere systeem uit meerdere vestigingen bestaan. Productcodes kunnen verschillen. Omzet kan anders worden geclassificeerd. Een actieve klant kan volgens de ene organisatie iemand zijn die de afgelopen twaalf maanden heeft gekocht, terwijl de andere organisatie hiervoor zes maanden gebruikt.
Als deze definities niet eerst worden geharmoniseerd, krijg je na de technische migratie misschien één database, maar nog steeds geen betrouwbare informatie.
Daarom besteed ik veel aandacht aan vragen als:
wat is onze definitie van een klant;
welke bron is leidend;
welke records zijn dubbel;
welke historische data moeten werkelijk worden meegenomen;
welke gegevens zijn verouderd;
wie wordt eigenaar van de data;
welke validaties voeren we vóór en na migratie uit;
welke rapportages moeten voor en na de overgang hetzelfde resultaat geven.
Dat klinkt misschien operationeel, maar juist dit soort details bepaalt uiteindelijk of managementinformatie na een fusie betrouwbaar is.
Eén rapportage betekent nog niet één waarheid
Een herkenbare situatie tijdens integraties is dat beide organisaties kort na de overname één gezamenlijke managementrapportage moeten produceren.
Dat lijkt een quick win. In werkelijkheid kunnen de cijfers uit beide organisaties volledig verschillende definities bevatten.
Omzet, marge, order intake, churn, bezetting, servicelevels of projectresultaten kunnen allemaal anders worden berekend.
Ik kijk daarom niet alleen naar het samenvoegen van dashboards. Eerst moet duidelijk zijn welke KPI-definities voor de nieuwe organisatie gelden, welke databronnen betrouwbaar zijn en wie verantwoordelijk is voor de kwaliteit ervan.
Pas daarna heeft het zin om één dashboard te bouwen.
Anders ontstaat een mooie gezamenlijke rapportage waarin iedereen nog steeds discussieert over welk cijfer klopt.
Tijdelijk twee systemen naast elkaar kan soms verstandiger zijn
Tijdens een integratie bestaat vaak sterke druk om snel systemen uit te faseren. Iedere maand dat twee applicaties naast elkaar bestaan kost immers geld.
Toch vind ik snelheid niet altijd de belangrijkste maatstaf.
Wanneer een systeem direct gekoppeld is aan klantbediening, facturatie, productie of andere kritieke processen, kan een geforceerde migratie veel meer schade veroorzaken dan enkele maanden extra licentiekosten.
In zo’n situatie kies ik liever voor een gecontroleerde overgang.
Dat kan betekenen:
eerst stabiliseren → processen harmoniseren → data opschonen → migreren → oude omgeving uitfaseren.
Tijdelijke complexiteit kan dan bewust worden geaccepteerd om het bedrijfsrisico te beperken.
Het belangrijke verschil is dat het een bewuste tijdelijke situatie moet zijn, inclusief eigenaar, einddatum en migratieplan. Anders wordt ’tijdelijk’ al snel permanent.
Interfaces zijn vaak belangrijker dan applicaties
Bij een integratie gaat veel aandacht naar de grote systemen: ERP, CRM, HR en finance. Mijn ervaring is dat problemen juist vaak ontstaan in de verbindingen ertussen.
Een order kan bijvoorbeeld probleemloos in CRM worden aangemaakt, maar vastlopen omdat de productcode niet bekend is in ERP. Een medewerker kan in het HR-systeem staan maar nog geen rechten hebben in operationele applicaties. Een wijziging in klantgegevens kan in het ene systeem worden verwerkt terwijl gekoppelde systemen oude informatie blijven gebruiken.
Daarom wil ik tijdens een integratie ook begrijpen:
welke systemen informatie met elkaar uitwisselen;
welke koppelingen bedrijfskritisch zijn;
waar handmatige tussenstappen bestaan;
welke Excel-bestanden feitelijk als interface functioneren;
welke batchprocessen of imports nog draaien;
wat er gebeurt wanneer een koppeling uitvalt;
wie verantwoordelijk is voor herstel.
Het landschap op een architectuurplaat is vrijwel altijd eenvoudiger dan de werkelijkheid in de operatie.
Excel is vaak een belangrijk signaal
In veel organisaties kom je tijdens een integratie Excel-bestanden tegen die veel belangrijker blijken te zijn dan vooraf werd gedacht.
Ze worden bijvoorbeeld gebruikt voor prijsberekeningen, capaciteitsplanning, reconciliatie, projectsturing, klantlijsten of managementrapportages.
Mijn eerste reactie is niet automatisch dat Excel moet verdwijnen. Ik wil eerst begrijpen waarom het bestand bestaat.
Soms is het simpelweg een handige lokale tool. Maar regelmatig maskeert zo’n spreadsheet een ontbrekende systeemfunctie, een slechte koppeling of een proces dat nooit formeel is ingericht.
Juist tijdens een post-merger integratie is dit waardevolle informatie. Het laat zien waar de feitelijke bedrijfsvoering afwijkt van het officiële proces.
Security, toegangsrechten en continuïteit horen vanaf het begin aan tafel
IT-integratie gaat uiteraard ook over security.
Na een overname moeten medewerkers soms snel toegang krijgen tot systemen van de andere organisatie. Tegelijkertijd kunnen oude accounts, leveranciersverbindingen en rechtenstructuren blijven bestaan.
Dat creëert risico’s.
Daarom moeten identity management, autorisaties, security, privacy, back-up, business continuity en leveranciersafspraken onderdeel zijn van het integratieprogramma en niet pas aan het einde als technische checklist verschijnen.
Ook hier is de koppeling met de organisatie belangrijk. Als niet duidelijk is wie na de integratie verantwoordelijk is voor een proces, is meestal ook niet duidelijk wie bepaalde systeemrechten nodig heeft.
IT-besluiten moeten samen met de business worden genomen
Ik zie IT-integraties misgaan wanneer de business zegt: “IT moet dit oplossen”, maar ook wanneer IT zelfstandig probeert te bepalen hoe toekomstige processen eruit moeten zien.
Beide disciplines hebben elkaar nodig.
De business moet duidelijk maken welke processen, klantbediening en managementinformatie nodig zijn. IT moet inzicht geven in technische haalbaarheid, risico, kosten, security, afhankelijkheden en migratiecomplexiteit.
In mijn rol verbind ik die werelden.
Ik zorg dat besluiten niet alleen technisch logisch zijn, maar ook uitvoerbaar zijn in de dagelijkse operatie. Andersom voorkom ik dat de business eisen stelt zonder inzicht in technische consequenties.
Niet ieder systeem hoeft geïntegreerd te worden
Een belangrijke integratiebeslissing is soms juist om iets niet te integreren.
Wanneer een overgenomen onderneming bijvoorbeeld grotendeels zelfstandig blijft opereren, kan volledige systeemharmonisatie meer kosten en risico opleveren dan zij aan synergie creëert.
Dan kan het voldoende zijn om bijvoorbeeld financiële rapportage, identity management, security of bepaalde masterdata te harmoniseren, terwijl operationele systemen voorlopig zelfstandig blijven functioneren.
Ik probeer daarom steeds expliciet te maken:
welke integratie is noodzakelijk om waarde te realiseren, en welke integratie doen we alleen omdat volledige standaardisatie aantrekkelijk klinkt?
Dat onderscheid voorkomt kostbare IT-projecten zonder duidelijke businesscase.
Van technisch migratieplan naar bestuurbaar integratieprogramma
Bij grotere IT- en dataintegraties maak ik afhankelijkheden daarom zichtbaar in één geïntegreerde planning.
Een datamigratie kan bijvoorbeeld pas plaatsvinden nadat processen zijn geharmoniseerd. Een systeem kan pas worden uitgefaseerd nadat rapportages zijn overgezet. Medewerkers kunnen pas naar een nieuwe applicatie wanneer rollen en autorisaties duidelijk zijn. En een juridische entiteit kan soms pas worden opgeheven nadat financiële systemen en contracten zijn aangepast.
Door die afhankelijkheden gezamenlijk te besturen, wordt voorkomen dat ieder team zijn eigen planning optimaliseert terwijl het totale integratieprogramma vertraging oploopt.
Mijn rol is daarbij niet om zelf iedere technische keuze te maken. Ik zorg ervoor dat business, IT, data, leveranciers en management dezelfde prioriteiten hanteren, besluiten tijdig nemen en weten wie waarvoor verantwoordelijk is.
Een succesvolle IT- en data-integratie herken ik uiteindelijk niet aan het aantal uitgefaseerde applicaties. Ik herken haar eraan dat medewerkers hun werk kunnen doen, klanten geen hinder ondervinden, management op betrouwbare informatie kan sturen en de nieuwe organisatie eenvoudiger en beter bestuurbaar is dan vóór de integratie.
Meer lezen over interim-management en organisatieverandering
Interimmanager inhuren voor post-merger integratie en organisatieverandering
✔ De integratie loopt vertraging op
✔ Teams werken langs elkaar heen
✔ Processen sluiten niet meer aan
✔ Er ontbreekt overzicht in data, IT en operatie
✔ Een lijnmanager valt uit en er ontstaat onrust in het team
✔ De verwachte synergie blijft uit
Wie ik ben:
Ik ben een hands-on interim-manager die strategie, mensen en operatie bij elkaar brengt. Geen dikke rapporten, maar uitvoering, grip en resultaat.
✔ 20+ jaar ervaring met complexe integraties
✔ Interim inzetbaar op directieniveau als COO, CIO of programmamanager
✔ Focus op synergie, rust, structuur en meetbaar resultaat
✔ Flexibel inzetbaar, met heldere afspraken en marktconforme tarieven
Meer info over Robrecht Heukers
Van al deze opdrachten zijn referenties beschikbaar:
Telecom: KPN, VodafoneZiggo, Vodafone ● Scheepsbouw: Royal IHC ● Bouw en industrie: ECI Solutions en Arcadis ● Medische sector: Canon Medical ● Woningcorporaties: Thuisvester, WonenBreburg, Portaal en Woonkwartier ● ICT dienstverleners: Getronics, PinkRoccade, MuleSoft ● Banken: ABN Amro, MeesPierson ● Betaaldiensten: Mollie ● Salarisverwerking en ziekteverzuim: VismaRaet en Robidus ● Verzekeraars: AON en Achmea ● Muziekindustrie: BumaStemra
Een complexe organisatieverandering, post-merger integratie of overname bespreken?
Postmerger. BV
Drs. ing. Robrecht Heukers LSSBB
06 – 44 99 04 98
robrecht.heukers@postmerger.nl