Digitale en AI-transformatie benutten tijdens de integratie | Postmerger interimmanagement

digitale en AI transformatie integratie systemen samenvoegen

Belangrijkste punten

  • Een post-merger integratie biedt mogelijkheden om technologie en processen fundamenteel te verbeteren, niet alleen systemen samen te voegen.
  • Digitale en AI-transformatie is cruciaal, maar organisaties moeten verder kijken dan enkel systeemintegratie.
  • Begin met het bepalen van de waardecreatie voor de toekomst, niet met technische oplossingen voor bestaande systemen.
  • AI kan tijdens integratie waarde toevoegen door repetitieve taken te automatiseren en processen te optimaliseren.
  • Een goede digitale roadmap maakt afhankelijkheden zichtbaar en helpt beslissingen te prioriteren voor een succesvolle integratie.

Digitale en AI-transformatie tijdens een post-merger integration: van technisch samenvoegen naar echte waardecreatie

Een fusie of overname creëert bijna altijd een uniek moment om opnieuw te kijken naar technologie, processen, data en de manier waarop mensen werken. Twee organisaties brengen immers ieder hun eigen ERP-systemen, CRM-platformen, data-architectuur, applicaties, workflows en digitale gewoonten mee. Op papier lijkt dat vooral een integratievraagstuk: dubbele systemen consolideren, data migreren en ervoor zorgen dat de nieuwe organisatie technisch als één geheel kan functioneren. In werkelijkheid ligt er een veel grotere kans. Juist tijdens een post-merger integration ontstaat de mogelijkheid om niet alleen systemen samen te voegen, maar ook fundamenteel te verbeteren hoe de nieuwe onderneming haar werk organiseert en waarde creëert.

Dat is tegelijkertijd precies waarom digitale en AI-transformatie tijdens een integratie zo lastig is. De organisatie is al zwaar belast met nieuwe structuren, veranderende verantwoordelijkheden, klantvraagstukken, synergieprogramma’s en dagelijkse operationele druk. Daardoor ontstaat al snel de neiging om technologische keuzes zo pragmatisch mogelijk te maken: kies één systeem, migreer de data en ga door. Dat kan op korte termijn verstandig lijken, maar het risico is dat twee oude werkwijzen technisch worden samengebracht zonder dat de nieuwe organisatie er werkelijk beter van wordt. De kernvraag zou daarom niet alleen moeten zijn welke systemen we behouden, maar vooral: hoe willen we dat de gecombineerde onderneming straks werkt, en welke digitale en AI-capabilities hebben we daarvoor nodig?

De systeemintegratie is niet hetzelfde als digitale transformatie

Na een overname ligt de focus begrijpelijkerwijs vaak op continuïteit. Klanten moeten bediend blijven worden, medewerkers moeten toegang houden tot de juiste systemen en Finance moet kunnen consolideren. IT-teams krijgen daarom snel een lange lijst met technische afhankelijkheden, migraties en integraties op hun bord. Het gevolg is dat het gesprek gemakkelijk wordt gedomineerd door architectuur, applicatielandschappen en deadlines. Welke ERP-oplossing wordt leidend? Welk CRM-platform blijft bestaan? Welke systemen moeten op Day 1 met elkaar kunnen communiceren en welke legacy-applicaties kunnen later worden uitgefaseerd?

Dat zijn noodzakelijke vragen, maar ze zijn niet voldoende. Wanneer technologie uitsluitend wordt benaderd als een consolidatieopgave, bestaat het risico dat de nieuwe onderneming haar oude complexiteit simpelweg meeneemt naar de toekomst. Een inefficiënt proces blijft inefficiënt wanneer het wordt gemigreerd naar een moderner platform. Dubbele controles blijven bestaan wanneer ze alleen technisch worden geautomatiseerd. Een nieuwe digitale architectuur creëert pas echte waarde wanneer ook processen, verantwoordelijkheden en werkwijzen worden herzien. Daarom moet digitale transformatie tijdens post-merger integration altijd verder kijken dan de techniek alleen.

Begin niet bij systemen, maar bij de toekomstige organisatie

Een goede digitale integratiestrategie begint bij de vraag hoe de nieuwe organisatie in de toekomst waarde wil creëren. Welke klantinteracties moeten eenvoudiger en sneller worden? Welke processen vragen om meer standaardisatie? Waar wil de organisatie schaalvoordelen realiseren? Welke taken kunnen worden geautomatiseerd en waar blijft menselijke expertise essentieel? Pas wanneer dat beeld helder is, kunnen verstandige keuzes worden gemaakt over systemen, data en technologie.

Dat klinkt logisch, maar in de praktijk wordt de volgorde vaak omgedraaid. Een organisatie kiest eerst welk systeem technisch het meest voor de hand ligt en past vervolgens haar processen aan de beperkingen van dat systeem aan. Daarmee wordt de kans gemist om de integratie als katalysator te gebruiken voor echte verbetering. Juist tijdens een fusie of overname bestaat er meer legitimiteit dan normaal om bestaande werkwijzen ter discussie te stellen. Dat moment moet worden benut om een Target Digital Operating Model te ontwerpen waarin strategie, processen, data, technologie en organisatie elkaar versterken.

Twee legacy-landschappen samenvoegen vraagt om scherpe keuzes

Bij vrijwel iedere overname ontstaat een omvangrijk legacy-vraagstuk. Beide ondernemingen hebben door de jaren heen applicaties, interfaces, rapportagetools, lokale oplossingen en tijdelijke workarounds ontwikkeld. Vaak bestaan er meerdere systemen voor vergelijkbare functionaliteit en zijn sommige applicaties sterk verweven met processen die in de nieuwe organisatie toch moeten veranderen. Het simpelweg kiezen van de “beste” applicatie is daarom zelden voldoende.

Een goede application rationalization kijkt niet alleen naar functionaliteit en technische kwaliteit, maar ook naar strategische waarde, totale kosten, schaalbaarheid, data, gebruikerservaring en afhankelijkheden. Welke systemen vormen een toekomstbestendig platform? Welke legacy-oplossingen moeten zo snel mogelijk worden uitgefaseerd? Welke applicaties kunnen tijdelijk naast elkaar blijven bestaan omdat migratie op korte termijn te veel risico oplevert? Door dergelijke keuzes te koppelen aan een duidelijke roadmap ontstaat rust en richting. Niet alles hoeft tegelijk, maar de organisatie weet wel welk technologisch landschap zij uiteindelijk wil bereiken.

Vereenvoudig processen voordat je ze automatiseert

Een van de grootste kansen binnen een integratie ligt in het combineren van procesharmonisatie en digitalisering. Twee organisaties hebben vaak verschillende werkwijzen voor order-to-cash, procure-to-pay, customer service, finance of HR. De verleiding is groot om deze processen eerst technisch samen te brengen en daarna verder te optimaliseren. Maar juist dan dreigt automatisering bestaande complexiteit te cementeren.

De betere volgorde is meestal om eerst te bepalen welke processtappen werkelijk nodig zijn. Waar bestaan dubbele controles? Welke overdrachten kunnen verdwijnen? Welke goedkeuringen kunnen worden vereenvoudigd? Waar wordt dezelfde data meerdere keren ingevoerd? Pas daarna ontstaat een goede basis voor automatisering. AI, workflowsoftware en robotic process automation leveren de meeste waarde wanneer ze worden toegepast op een proces dat inhoudelijk al logisch is. Anders ontstaat vooral een sneller en technologisch geavanceerder slecht proces.

AI kan juist tijdens een integratie veel directe waarde creëren

AI-transformatie binnen post-merger integration wordt soms gezien als iets voor later, wanneer de technische basis eenmaal op orde is. Dat is begrijpelijk, maar niet altijd verstandig. Juist tijdens een integratie ontstaat namelijk veel repetitief en kennisintensief werk waarvoor AI snel waarde kan toevoegen. Denk aan het analyseren en vergelijken van contracten, het harmoniseren van productinformatie, het ondersteunen van data mapping, het samenvatten van beleid en procedures of het helpen van medewerkers bij het vinden van informatie in twee samengevoegde kennisomgevingen.

Daarnaast ontstaan kansen om nieuwe processen vanaf het begin slimmer te ontwerpen. Een gecombineerde Customer Service-organisatie kan bijvoorbeeld meteen werken met AI-ondersteunde kennisontsluiting. Finance kan automatische classificatie en analyse gebruiken en Procurement kan contractinformatie sneller vergelijken. Het belangrijkste is dat AI-use-cases niet worden gekozen omdat de technologie interessant is, maar omdat ze aantoonbaar bijdragen aan integratiedoelstellingen zoals lagere kosten, snellere harmonisatie, betere klantbeleving of hogere medewerkerproductiviteit.

Van losse AI-ideeën naar een gezamenlijk use-case portfolio

In een fusieorganisatie ontstaan vaak snel veel digitale ideeën. Beide ondernemingen hebben al eigen pilots, leveranciersrelaties en innovatieagenda’s. Wanneer al deze initiatieven zonder centrale prioritering doorgaan, kan de gecombineerde onderneming eindigen met een nog complexer technologielandschap dan waarmee zij begon. Daarom is een gezamenlijk AI use-case portfolio essentieel.

De waarde zit niet in zoveel mogelijk use-cases starten, maar in het selecteren van een beperkt aantal toepassingen met een duidelijke businessimpact. Een goede beoordeling kijkt naar potentiële waarde, implementatiecomplexiteit, databeschikbaarheid, risico’s, procesimpact en schaalbaarheid. Sommige use-cases kunnen snel een zichtbaar resultaat geven, terwijl andere strategischer zijn en meer voorbereiding vragen. Door die balans bewust te ontwerpen, ontstaat een roadmap waarin AI geen verzameling experimenten is, maar onderdeel wordt van de bredere transformatie van de nieuwe onderneming.

Data is de verbindende laag van de nieuwe organisatie

Een fusie legt vaak genadeloos bloot hoe verschillend organisaties naar hun eigen werkelijkheid kijken. Dezelfde klant kan in twee systemen anders zijn geregistreerd, productcodes verschillen, definities van omzet of marge zijn niet identiek en historische data heeft verschillende kwaliteitsniveaus. Zonder harmonisatie ontstaat geen gemeenschappelijke basis voor rapportage, automatisering of AI.

Daarom moet een data strategy binnen post-merger integration verder gaan dan technische migratie. Er moet worden bepaald welke definities leidend worden, wie eigenaar is van kritieke data, welke kwaliteit nodig is en hoe data toegankelijk wordt gemaakt voor processen en besluitvorming. Zeker bij AI is dat cruciaal. Een slim model kan alleen betrouwbare ondersteuning bieden wanneer de informatie waarop het is gebaseerd voldoende consistent, actueel en begrijpelijk is. Data governance wordt daarmee geen administratieve bijzaak, maar een directe voorwaarde voor digitale waardecreatie.

De organisatie moet mee veranderen met de technologie

Digitale integratie heeft vrijwel altijd gevolgen voor functies en verantwoordelijkheden. Wanneer processen worden geautomatiseerd, verandert het werk van medewerkers. Wanneer data beter beschikbaar komt, kunnen beslissingen lager in de organisatie worden genomen. Wanneer AI kennis ontsluit, verschuift de rol van experts mogelijk van informatie leveren naar beoordelen, coachen en uitzonderingen behandelen. Als die organisatorische consequenties niet bewust worden meegenomen, ontstaat een nieuwe technologielaag bovenop oude structuren.

Dat is een van de belangrijkste oorzaken waarom digitale transformaties minder opleveren dan verwacht. De technologie is geïmplementeerd, maar medewerkers blijven dezelfde controles uitvoeren, managers blijven dezelfde goedkeuringen vragen en teams blijven werken volgens oude verantwoordelijkheden. Een goede digitale roadmap moet daarom altijd verbonden zijn met het Target Operating Model, rollen, governance en capability building. De echte productiviteitswinst ontstaat pas wanneer technologie aanleiding geeft om werk daadwerkelijk anders te organiseren.

Governance moet innovatie versnellen, niet verstikken

Tijdens een integratie is er vaak behoefte aan strakke governance. Investeringen moeten worden gecoördineerd, risico’s beheerst en dubbele initiatieven voorkomen. Tegelijkertijd kan te veel centrale controle juist de innovatie vertragen. Businessteams moeten ruimte houden om te experimenteren en nieuwe technologie toe te passen op concrete problemen.

Een volwassen digital governance model zoekt daarom bewust naar balans. Duidelijke standaarden zijn nodig voor architectuur, cybersecurity, privacy en verantwoord AI-gebruik, maar binnen die kaders moet snelheid mogelijk blijven. Dat vraagt om heldere decision rights: welke technologiekeuzes worden centraal gemaakt, waar mogen businessunits zelf experimenteren en wanneer moet een pilot naar enterprise-schaal worden gebracht? Door dat vroeg te regelen, voorkom je dat de nieuwe organisatie óf in technologische anarchie belandt óf zoveel goedkeuringslagen bouwt dat innovatie tot stilstand komt.

Een digitale roadmap moet keuzes en afhankelijkheden zichtbaar maken

Een goede digitale en AI-roadmap voor post-merger integration is geen lange lijst met IT-projecten. Ze laat zien hoe verschillende initiatieven samen bijdragen aan de toekomstige organisatie. Sommige legacy-systemen moeten verdwijnen voordat processen kunnen worden gestandaardiseerd. Sommige AI-use-cases vragen eerst om betere data. Andere automatiseringen kunnen juist snel worden ingezet en direct capaciteit vrijmaken voor het integratieprogramma.

Door die afhankelijkheden expliciet te maken, wordt het mogelijk om verstandig te faseren. Wat moet op Day 1 gereed zijn? Welke verbeteringen willen we binnen de eerste 100 dagen realiseren? Welke platformkeuzes zijn bepalend voor de komende drie jaar? Zo ontstaat een roadmap die zowel urgentie als langetermijnrichting bevat. Niet alles tegelijk, maar wel alles vanuit één samenhangend ontwerp.

Waarom een externe adviseur hier juist waarde kan toevoegen

Digitale en AI-integratie raakt vrijwel iedere functie. IT kijkt naar architectuur en veiligheid, Operations naar continuïteit, Finance naar businesscases, HR naar vaardigheden en de business naar snelheid en klantwaarde. Al die perspectieven zijn terecht, maar zonder onafhankelijke regie kunnen ze gemakkelijk in verschillende richtingen trekken. Een externe adviseur kan helpen om keuzes terug te brengen naar de gezamenlijke waarde voor de nieuwe onderneming.

De kracht zit daarbij niet in het voorschrijven van technologie, maar in het verbinden van strategie, proces, data en organisatie. Welke investeringen hebben werkelijk prioriteit? Welke legacy-systemen houden we te lang in leven? Welke AI-pilots verdienen schaal en welke moeten we stoppen? Welke processen moeten eerst worden vereenvoudigd voordat we automatiseren? Door die vragen onafhankelijk te structureren, ontstaat een digitale transformatie die niet wordt gedreven door leveranciers of bestaande systemen, maar door de doelstellingen van de nieuwe organisatie.

Van roadmap naar daadwerkelijke uitvoering

Daar ligt voor mij ook de kracht van de combinatie van extern advies en interim-management. Als adviseur kun je helpen om het toekomstbeeld te ontwerpen, de technology baseline te analyseren, use-cases te prioriteren en een geïntegreerde roadmap te ontwikkelen. Maar daarna begint het lastigste gedeelte: de uitvoering.

Systemen moeten worden uitgefaseerd, processen moeten veranderen, AI-oplossingen moeten worden opgeschaald en medewerkers moeten anders gaan werken. Tegelijkertijd moet de dagelijkse operatie doorgaan en moeten integratiemijlpalen worden gehaald. Juist daar kan een interim-manager tijdelijk eigenaarschap nemen, afhankelijkheden oplossen en zorgen dat technologie niet als los IT-programma wordt uitgevoerd, maar als onderdeel van de bredere transformatie van de onderneming.

De echte test van digitale integratie

Een succesvolle digitale integratie herken je uiteindelijk niet aan het aantal gemigreerde systemen, afgesloten IT-projecten of AI-pilots. De echte vraag is of de nieuwe onderneming aantoonbaar beter functioneert dan de twee organisaties ervoor.

Zijn processen eenvoudiger geworden? Kunnen medewerkers sneller werken? Is er één betrouwbare databasis? Zijn legacy-kosten daadwerkelijk verdwenen? Kunnen klanten gemakkelijker zaken doen met de organisatie? Worden AI en automatisering zichtbaar gebruikt om kwaliteit, snelheid en productiviteit te verbeteren? En is het technologielandschap eenvoudiger en schaalbaarder geworden?

Als het antwoord daarop ja is, heeft de integratie meer opgeleverd dan technische consolidatie.

Een fusie is namelijk een zeldzaam moment waarop een organisatie niet alleen systemen móét veranderen, maar ook de kans krijgt om fundamenteel opnieuw te bepalen hoe zij wil werken.

De grootste fout is dan om twee oude technologielandschappen zo snel mogelijk aan elkaar te knopen en het daarbij te laten. De grootste kans is om technologie, processen, data en organisatie bewust samen te ontwerpen, zodat de nieuwe onderneming niet alleen geïntegreerd is, maar aantoonbaar slimmer, eenvoudiger en toekomstbestendiger functioneert.

Bij dit eerder op Linkedin gepubliceerde artikel, heb ik op basis van de circa 20 jaar interim-management ervaring bij Post-merger integration en organisatieverandering onderstaand ook een eigen PMI IT Dependency Architectuur geschreven:

PMI IT Dependency Architectuur

Van IT-integratie naar bestuurbare organisatieverandering

Bij een fusie of overname behandel ik IT niet als een afzonderlijke technische workstream. IT vormt samen met processen, data, mensen en besluitvorming het zenuwstelsel van de nieuwe onderneming.

Daarom begin ik niet met de vraag welk ERP-, CRM- of HR-systeem moet blijven. Ik begin met de vraag hoe de nieuwe onderneming moet functioneren, welke waarde de integratie moet realiseren en welke afhankelijkheden eerst opgelost moeten worden om daar te komen.

Mijn PMI IT Dependency Architecture bestaat uit zeven samenhangende lagen.

1. Business value & synergy

De bovenste laag bepaalt waarom we überhaupt iets veranderen.

Hier staan de integratiedoelstellingen: omzetgroei, kostenreductie, schaalvoordeel, betere klantbediening, hogere productiviteit, risicoreductie en eventueel carve-out- of TSA-doelstellingen.

Iedere belangrijke IT-investering moet aan minimaal één van deze doelen bijdragen.

De kernvraag is:

Welke waarde kan de nieuwe onderneming pas realiseren wanneer deze IT-afhankelijkheid is opgelost?

Daarmee voorkom ik dat een integratie verandert in een verzameling IT-projecten zonder duidelijke relatie met de oorspronkelijke deal rationale.


2. Target Operating Model

Onder de waardepropositie ligt het toekomstige operating model.

Hier bepalen we hoe de gecombineerde onderneming straks werkt. Welke activiteiten worden centraal georganiseerd? Wat blijft lokaal? Welke capabilities worden samengevoegd? Waar kiezen we bewust voor best-of-both en waar voor één groepsstandaard?

Dit bepaalt vervolgens welke technologie nodig is.

De afhankelijkheid loopt dus bewust:

Deal rationale → synergie → operating model → proces → data → applicatie → infrastructuur.

Niet andersom.

Een veelgemaakte fout is eerst het systeem te kiezen en vervolgens de organisatie rond die keuze te ontwerpen.


3. End-to-end processen

De derde laag bevat de processen waarmee de organisatie daadwerkelijk waarde creëert.

Ik kijk daarbij niet primair naar afdelingen, maar naar end-to-end ketens zoals:

  • lead-to-order;
  • order-to-cash;
  • procure-to-pay;
  • plan-to-produce;
  • hire-to-retire;
  • record-to-report;
  • service-to-resolution.

Per proces bepaal ik wat van beide ondernemingen behouden blijft, wat verdwijnt en wat opnieuw moet worden ontworpen.

Mijn uitgangspunt is daarbij eenvoudig:

Eerst vereenvoudigen, daarna harmoniseren en pas daarna automatiseren.

Anders automatiseer je vooral de historische complexiteit van twee ondernemingen.


4. Data & information

Data vormt de verbindende laag tussen de oude en nieuwe organisatie.

Daarom kijk ik vóór een migratie naar definities, eigenaarschap en kwaliteit. Wat bedoelen beide ondernemingen bijvoorbeeld precies met klant, omzet, marge, product, leverancier of medewerker?

Wanneer die definities verschillen, bestaat er technisch misschien één systeem terwijl bestuurlijk nog steeds twee ondernemingen bestaan.

Deze laag omvat daarom onder meer:

masterdata → datadefinities → data ownership → datakwaliteit → migratie → rapportage → KPI’s → AI readiness.

Voor AI is deze laag cruciaal.

Geen betrouwbare data betekent geen betrouwbare AI.


5. Applications & digital capabilities

Pas daarna komt het applicatielandschap.

ERP, CRM, HRIS, Finance, procurement, planning, data platforms, workflowtools, collaboration, customer portals en specialistische applicaties worden niet afzonderlijk beoordeeld.

Per applicatie bepaal ik de relatie met processen, data, gebruikers en andere systemen.

Daaruit volgen vier mogelijke beslissingen:

RETAIN – behouden omdat het systeem strategisch en schaalbaar is.

MIGRATE – gebruikers, processen of data naar het gekozen doelplatform brengen.

TRANSFORM – niet simpelweg migreren, maar proces en technologie opnieuw ontwerpen.

RETIRE – uitfaseren zodra de relevante afhankelijkheden zijn opgelost.

Daarmee ontstaat geen simpele applicatielijst, maar een dependency map.


6. Technology, security & continuity

Onder de applicaties ligt de technische fundering.

Hier kijk ik naar cloud, infrastructuur, identity & access management, cybersecurity, netwerken, interfaces, API’s, integratieplatformen, back-up, disaster recovery en business continuity.

Deze laag bepaalt vaak wat technisch mogelijk is op Day 1.

Daarom maak ik expliciet onderscheid tussen:

Day 1 critical dependencies
Wat moet absoluut functioneren om de onderneming veilig te laten draaien?

Day 100 dependencies
Welke verbindingen moeten snel verdwijnen of structureel worden ingericht?

Transformation dependencies
Welke keuzes bepalen het landschap voor de komende twee tot drie jaar?

Niet alles hoeft op Day 1 geïntegreerd te zijn.

Het moet op Day 1 vooral duidelijk zijn wat nog níét geïntegreerd is, welk risico daaraan verbonden is en wanneer dat risico verdwijnt.


7. People, governance & capability

De onderste én tegelijkertijd verbindende laag bestaat uit mensen en governance.

Systemen veranderen niets zelfstandig.

Daarom koppel ik iedere belangrijke technologische verandering aan rollen, verantwoordelijkheden, kennis, besluitvorming en capabilities.

Wie is eigenaar van het nieuwe proces? Wie bezit de data? Wie beslist over uitzonderingen? Welke kennis zit bij enkele kritieke medewerkers? Welke capabilities moeten intern blijven en welke kunnen extern worden georganiseerd?

Dit is ook de laag waar ik als interim-manager extra nadruk op leg.

Een consultant kan de gewenste architectuur tekenen. De integratie slaagt pas wanneer iemand verantwoordelijkheid neemt voor de afhankelijkheden tussen workstreams en ervoor zorgt dat beslissingen daadwerkelijk worden uitgevoerd.


De Dependency Spine

Dwars door deze zeven lagen loopt wat ik de Dependency Spine zou noemen:

Deal rationale
↓
Synergie & waarde
↓
Target Operating Model
↓
End-to-end processen
↓
Data
↓
Applicaties
↓
Technologie
↓
Mensen & capabilities
↓
Migratie en uitvoering
↓
Meetbaar resultaat

Iedere belangrijke integratiebeslissing moet langs deze keten kunnen worden teruggeleid.

Wanneer iemand bijvoorbeeld zegt:

“We migreren het CRM naar systeem A.”

dan is dat voor mij geen besluit maar het begin van de analyse.

Ik wil weten:

Welke commerciële capability ondersteunt dit?

Welk toekomstig proces wordt leidend?

Welke klantdefinitie gebruiken we?

Welke interfaces zijn afhankelijk?

Welke rapportages veranderen?

Welke medewerkers moeten anders werken?

Welke legacyapplicatie kan daarna daadwerkelijk uit?

Welke synergie komt daardoor vrij?

Pas wanneer die keten duidelijk is, bestaat er een bestuurbare integratiebeslissing.

De horizontale PMI-afhankelijkheden

Naast de verticale architectuur gebruik ik een tweede dimensie. Iedere IT-beslissing toets ik aan zes horizontale afhankelijkheden:

Customer
Wat merkt de klant en welk continuïteitsrisico ontstaat?

Operations
Welke processen kunnen wel of niet functioneren?

Finance & synergy
Welke kosten, baten en synergieën hangen ervan af?

People
Welke rollen, kennis en capaciteit zijn noodzakelijk?

Risk & compliance
Welke juridische, cyber-, privacy- of controlrisico’s ontstaan?

Timing
Welke andere integratiemijlpaal kan pas plaatsvinden nadat deze dependency is opgelost?

Zo ontstaat feitelijk een matrix.

Een ERP-migratie is dan niet meer alleen een IT-project. De migratie heeft afhankelijkheden met Finance, Operations, Procurement, HR, klanten, data en de synergiecase.

Dat is precies waar integraties in de praktijk vastlopen: niet binnen de workstreams, maar tussen de workstreams.

De PMI Dependency Matrix

Ik zou iedere materiële dependency daarom vastleggen in één bestuurbaar format:

DependencyBusiness impactOwnerDepends onBlocksDay 1/100/LaterRiskValue/Synergy
Customer master harmonisatieHoogCDO/CommercialData definitionsCRM migrationDay 100HoogCross-selling
ERP keuzeHoogCFO/CIOTOM + Finance processFinance migrationDay 100HoogCost synergy
IAM integratieKritiekCIO/CISOEmployee masterSystem accessDay 1KritiekContinuity
Contract AI use caseMiddenLegal/ProcurementContract dataProcurement automationLaterMiddenProductivity
Legacy ERP retirementHoogCIO/CFOData + process migrationLicense exitLaterMiddenCost synergy

De architectuur wordt daardoor geen statische PowerPoint.

Het wordt een managementinstrument voor de integratie.

AI als versneller binnen de architectuur

AI plaats ik bewust niet als achtste losse laag.

AI loopt horizontaal door de architectuur.

Het kan tijdens een integratie bijvoorbeeld helpen bij contractanalyse, data mapping, kennisontsluiting, procesanalyse, productharmonisatie en het vergelijken van policies. Later kan AI onderdeel worden van het nieuwe operating model.

Maar ook hier geldt dezelfde dependency-logica.

AI use case
→ businessprobleem
→ proces
→ beschikbare data
→ governance
→ technologie
→ capability
→ meetbare waarde.

Als die keten niet klopt, start ik de use case niet.

Daarmee voorkom je dat een integratie tientallen interessante AI-pilots creëert terwijl de fundamentele organisatiecomplexiteit blijft bestaan.

Mijn drie PMI-filters

Uiteindelijk toets ik iedere belangrijke digitale integratiebeslissing aan drie eenvoudige vragen.

1. Continuity

Moet dit nu om de onderneming veilig te laten functioneren?

Dit zijn de Day 1- en business-continuityvraagstukken.

2. Simplification

Kunnen we door deze verandering structureel complexiteit verwijderen?

Hier zitten application rationalization, procesharmonisatie, data en legacy retirement.

3. Value creation

Maakt deze keuze de nieuwe onderneming aantoonbaar beter dan beide ondernemingen vóór de transactie?

Hier komen digitalisering, AI, automatisering, nieuwe capabilities en synergie samen.

Een initiatief dat geen duidelijke bijdrage levert aan continuity, simplification of value creation krijgt geen automatische plek op de roadmap.

Van dependency architecture naar executieroadmap

De laatste stap is cruciaal.

Ik vertaal de architectuur niet naar één groot IT-programma, maar naar een gefaseerde executieroadmap:

Day 0 — Understand
Baseline, critical dependencies, TSA’s, risico’s, systemen, data, capabilities en beslisrechten begrijpen.

Day 1 — Protect
Continuïteit, toegang, security, financiële consolidatie, klantbediening en wettelijke verplichtingen veiligstellen.

Day 1–100 — Simplify
Processen harmoniseren, quick wins realiseren, data-eigenaarschap bepalen, dubbele initiatieven stoppen en target platforms kiezen.

Month 3–12 — Integrate
Migreren, applicaties consolideren, data harmoniseren, operating model implementeren en legacy uitfaseren.

Month 6–24 — Transform
Automatisering, AI, analytics en nieuwe digitale capabilities opschalen.

Exit — Prove value
Legacy-kosten daadwerkelijk verwijderen, synergie aantonen, capabilities overdragen en zorgen dat de nieuwe organisatie zelfstandig verder kan.

Daarmee wordt digitale integratie geen IT-migratie met een einddatum.

Het wordt een gecontroleerde beweging van twee bestaande organisaties naar één aantoonbaar betere onderneming.

De essentie van mijn aanpak

Na ruim twintig jaar interim-management en post-merger integratie is voor mij de belangrijkste les dat complexe integraties zelden vastlopen omdat één team zijn eigen project niet begrijpt.

Ze lopen vast op afhankelijkheden.

Finance wacht op IT. IT wacht op een procesbesluit. Operations wacht op data. HR wacht op de organisatiestructuur. De business wacht ondertussen op iedereen.

Daarom probeer ik niet alle complexiteit centraal te beheersen. Ik maak de kritieke afhankelijkheden zichtbaar, geef ze een eigenaar en zorg dat besluiten in de juiste volgorde worden genomen.

Mijn PMI IT Dependency Architecture gaat daarom uiteindelijk niet over technologie. Het gaat over het bestuurbaar maken van afhankelijkheden, zodat technologie, processen, data en mensen in dezelfde richting veranderen en de waarde uit de deal daadwerkelijk gerealiseerd kan worden.

Gerelateerde pagina’s

 

Meer lezen over AI governance en verantwoord gebruik

Meer lezen over interim CIO of programmamanager inhuren

Meer lezen over postmerger integratie, AI en bedrijfsprocessen automatiseren

 

Interimmanager inhuren voor post-merger integratie en organisatieverandering

   

Wie ik ben:

Ik ben een hands-on interim-manager die strategie, mensen en operatie bij elkaar brengt. Geen theoretische rapporten, maar goed samenhangende plannen, 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

 

Klik hier om naar de dienstverlening te gaan voor complexe organisatieverandering, post-merger integratie trajecten, overname, of interim-management en advies in maatwerktrajecten.

 

Drs. ing. Robrecht Heukers LSSBB

06 – 44 99 04 98

robrecht.heukers@postmerger.nl