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.
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.