Angela den Drijver
Als bedrijf ontkom je de komende jaren niet aan grote veranderingen aan je SAP-omgeving. Misschien wil je de stap naar de cloud zetten, je ERP-systeem vernieuwen of al het maatwerk uit SAP vegen. Maar hoe zorg je dat die veranderingen technisch goed uitgevoerd worden, terwijl je de continuïteit van de business waarborgt en andere IT-projecten gewoon blijven draaien? In dit artikel vertel ik je, aan de hand van mijn ervaringen met een bedrijfsovername, hoe je dat slim kunt aanpakken.
Mammoet. Een machtig mooie naam voor een bedrijf dat zich specialiseert in technisch zwaar hijswerk en transport. Een bedrijf van doorzetters. Mouwen opstropen en hard werken. Met die mentaliteit wist Mammoet begin deze eeuw het wrak van de beroemde Koersk-onderzeeër van de bodem van de Barentszzee te lichten. En dankzij die mentaliteit groeide het bedrijf de afgelopen decennia uit tot de wereldwijde marktleider. Mammoet’s ambities zijn onverminderd groot, met de overname van branchegenoot ALE in 2019 als het meest recente succes.
Verandering op grote schaal
Die gebeurtenis heeft een behoorlijke impact op onze organisatie en de SAP-omgeving. ALE was een bedrijf met een omzet van ruim 200 miljoen euro en 2.000 medewerkers. Door de overname zijn we in een klap ongeveer anderhalf keer zo groot geworden. Nu is het zaak om ALE zo snel en zo goed mogelijk een volwaardig onderdeel te maken van Mammoet. Met de overname werd een wereldwijde projectorganisatie in het leven geroepen met regionale projectteams. Deze projectorganisatie, genaamd het integration management office (IMO), moet ervoor zorgen dat ALE en Mammoet één worden en dat daarin alle bedrijfsfacetten worden meegenomen. Dit vraagt om een duidelijke planning, goede communicatie met stakeholders en uiteraard de integratie en migratie van mensen, assets, processen en systemen.
Daar noem ik het al, ook systemen komen aan bod tijdens deze integratie. Het IMO heeft eerder al besloten dat ons huidige SAP-systeem voorlopig het leidende ERP blijft voor Mammoet en dus ook voor ALE. Daarom is het de bedoeling om in de komende tijd zo veel mogelijk ALE-vestigingen wereldwijd, waar mogelijk, te migreren naar ons SAP-systeem. Dit project leid ik samen met een projectleider vanuit de business die het grotere geheel overziet. Waar hij als linking pin verantwoordelijk is voor het afstemmen van de scope en de planning en coördinatie van trainingen, ben ik vanuit de IT-afdeling van Mammoet als Business Application Analist verantwoordelijk voor de technische implementatie. Naast ons tweeën zijn er nog drie collega’s van IT actief in het projectteam en die houden zich bezig met het daadwerkelijke bouwen in het systeem. Samen ondersteunen we de lokale business in het juist opzetten van de ‘financiële kapstok’ waaronder de ALE-vestiging in de toekomst de administratie moet doen, en het migreren van legacy data uit het oude ERP-systeem. Zo werken we aan onze subdoelstelling van het projectteam om ALE op technisch vlak zo goed mogelijk te laten integreren met Mammoet.
Eén SAP-systeem, maar ook uitzonderingen
Laat ik de omvang en schaal van deze verandering – los van de migratie van ALE – even schetsen. Mammoet bestaat uit tientallen bedrijven. Ze dragen allemaal dezelfde naam, maar de bedrijfsactiviteiten worden decentraal georganiseerd. Er zijn wel projecten waar meerdere Mammoet-vestigingen diensten leveren, maar in principe staan vestigingen los van elkaar. IT is een uitzondering op die regel. Onze afdeling is centraal georganiseerd en dienstverlenend voor alle vestigingen wereldwijd. Een groot deel van onze vestigingen werkt met hetzelfde SAP-systeem en we gebruiken veel van de modules binnen SAP. Het voordeel daarvan is dat veel processen naadloos op elkaar aansluiten en niet voor iedere administratie een aparte interface nodig is. Er zijn echter ook uitzonderingen. Bedrijven die we overnemen werken vaak nog niet met SAP, en hebben een compleet eigen ERP-pakket dat losstaat van Mammoet. We onderzoeken in zo’n geval of een migratie naar SAP zin heeft. Dat hangt af van de grootte en activiteiten van het bedrijf, de culturele complexiteit die een migratie met zich mee kan brengen en van lokale wet- en regelgeving die een implementatie mogelijk erg complex maakt.
Maar zo bestaat ook ALE uit tientallen bedrijven. En voor al die vestigingen – verspreid over de hele wereld – moeten we individueel onderzoeken wat de mogelijkheden zijn. Hier is het IMO leidend in. Zij doen vooronderzoek door samen met de lokale managementteams te kijken wat er met een vestiging staat te gebeuren. Wordt een vestiging samengevoegd met een andere Mammoet-vestiging? Of blijft het een onafhankelijke vestiging? Daarna kijken we naar de mogelijkheden om te migreren naar SAP. Wanneer we een besluit nemen, maken we samen met het IMO een planning en gaat ons team van start. Globaal is zo’n migratie op te delen in drie grote stappen:
- Technische implementatie – het bouwen van de kapstok. We zorgen dat de entiteit bestaat in SAP, voldoet aan de richtlijnen van Mammoet en de processen borgt van de vestiging die we migreren.
- Data migratie – het overzetten van masterdata en transactionele data van het legacy-systeem naar SAP. We zorgen ervoor dat data volledig is en dat we weten welke informatie ontbreekt als dat niet het geval is. We verzamelen onder andere data van equipment, boekstanden, personeel en projecten. Daarvoor zijn we grotendeels afhankelijk van de mensen die bij de vestiging werken en de manier waarop ALE de informatie verzamelt. Wij ondersteunen vervolgens in het ‘ombouwen’ van die data naar de Mammoet standaard en zorgen dat de data op de juiste manier in SAP terechtkomt.
- Training en change management – het opstellen van de vereisten voor training en ondersteuning van gebruikers. Dit doen we door een lokaal projectteam aan te stellen en nauw met ze samen te werken om ervoor te zorgen dat alle collega’s van een vestiging weten wat ze moeten doen na de migratie. In principe is het de verantwoordelijkheid van het lokale team om dit te regelen, maar wij zijn hier ondersteunend in op basis van onze ervaring.
In ons team zijn de verantwoordelijkheden opgedeeld tussen IT en de business. Ik ben met mijn IT-collega’s verantwoordelijk voor het technische deel en de businessverantwoordelijke houdt zich bezig met de planning, coördinatie en het managen van stakeholders. Als we een ‘go’ krijgen van het IMO, plannen we kick-off meetings in met mensen van de vestiging. Daarin stellen we een lokaal projectteam aan, met een eigen projectmanager. Zij ondersteunen bij de implementatie, datamigratie en trainingen. Dat team nemen we ook mee in hoe we de technische implementatie uitvoeren en de lokale projectmanager leggen we een aantal vragenlijsten voor. Daarin komen zaken naar voren zoals lokale wet- en regelgeving, vormgeving van de projectadministratie en de planning. Dankzij die vragenlijsten weet ons IT-team precies wat ze moeten inrichten in het systeem. Soms betekent dit dat we ook kleine stukjes maatwerk moeten implementeren.
Tegelijkertijd lopen er meerdere migratietrajecten in verschillende landen naast elkaar. Dit zorgt voor de nodige complexiteit qua planning en technische implementatie. We moeten bijvoorbeeld met het projectteam goed in de gaten houden dat we door de verschillende migratieplanningen niet elkaars werk overschrijven in SAP.
Een bedrijf met global presence, maar ook lokale processen
Om een grote verandering goed te kunnen begeleiden, moet je ook begrijpen hoe groot de impact precies is voor degene die de verandering door maakt. Om beter te leren begrijpen waar ALE qua processen precies vandaan komt, hebben we vlak na de overname een week bij de IT-afdeling in Abu Dhabi meegekeken hoe hun ERP-systeem ingericht was en een mapping gemaakt naar de processen van Mammoet. Daardoor weten we in grote lijnen wat de overeenkomsten en verschillen zijn. Daar hebben we dagelijks profijt van als we met de lokale business over hun processen praten.
We willen niet per regio en vestiging te veel verschillende smaakjes in één ERP-systeem onderhouden. Dat zorgt nog wel eens voor wrijving.
De inrichting van ons SAP-systeem heeft bepaalde richtlijnen die specifiek zijn voor Mammoet. Die komen nooit volledig overeen met die van ALE. Daar komt ook nog eens bovenop dat je altijd wel te maken hebt met lokale afwijkingen van de globale standaard. Maar omdat IT zo centraal georganiseerd is, willen we niet per regio en vestiging te veel verschillende smaakjes in één ERP-systeem onderhouden. Dat zorgt nog wel eens voor wrijving wanneer we een vestiging migreren. Daarom is het belangrijk dat we goed begrijpen hoe processen bij een lokale vestiging lopen, om ze mee te krijgen in de nieuwe manier van werken.
Continuïteit borgen door samenwerking
Naast de verschillende ALE-migraties die we tegelijkertijd uitvoeren, hebben we als IT-afdeling ook veel andere projecten lopen en beheren we het bestaande IT-landschap. Hierbij is het cruciaal dat we de continuïteit van de business borgen. We willen voorkomen dat er iets kapotgaat of dat we ander werk overschrijven, waardoor de business plotseling zijn dagelijkse werkzaamheden niet kan uitvoeren. Door continu kwaliteit te leveren word je als IT-afdeling een betrouwbare business partner.
Daarom volgen we bij dit project een duidelijk change proces. Bij iedere stap monitor ik als gatekeeper de voortgang. Het doel is om iedere technische wijziging goed te testen voordat we die in productie nemen in ons SAP-systeem. We laten ons lokale projectteam alles testen en goedkeuren, zodat we ook samen de verantwoordelijkheid dragen dat we iets goeds neerzetten. We willen daarmee bereiken dat IT een integraal onderdeel wordt van de dagelijkse business. Dat kan door te werken met lokale projectteams en -managers, nauw samen te werken aan de planning en het aanstellen en inzetten van ‘key users’ binnen de hele organisatie.
Daarnaast stemmen we binnen IT veel af tussen de verschillende subafdelingen en projectteams, zodat we continu op de hoogte zijn van de werkzaamheden en planning van diverse IT-projecten. Door dagelijks te overleggen weten we van elkaar wat er speelt, welke afhankelijkheden er zijn en wanneer welke systemen beschikbaar zijn. Binnen mijn projectteam is het mijn verantwoordelijkheid om te zorgen dat onze planning en die van het IMO daarop afgestemd worden.
Je loopt altijd tegen verrassingen aan
Ondanks de nauwe samenwerking en grondig testen, komen we toch wel eens voor verrassingen te staan. Zo hebben we door de uitbraak van het corona-virus onverwacht een nieuwe manier van samenwerken moeten uitvinden, die voornamelijk online plaats vindt in plaats van deels face to face. En tijdens de migratie van ALE UK ontdekten we bijvoorbeeld dat het migreren van equipment en asset masterdata een hele kluif was, omdat er bij Mammoet veel meer (of juist andere) details werden geadministreerd dan bij ALE en dat het veel meer tijd kost om dit uit te zoeken dan gedacht. Dit soort verrassingen kunnen je complete projectplanning in de war schoppen. Het is geen misdaad als je tegen verrassingen aanloopt tijdens de uitvoering van een project. Als je maar zorgt dat alle stakeholders daar goed van op de hoogte zijn, de planning opnieuw wordt afgestemd en iedereen zich bewust is van de consequenties wanneer het project eventueel vertraging oploopt.
Het is geen misdaad als je tegen verrassingen aanloopt tijdens de uitvoering van een project.
Om deze veranderingen goed te visualiseren, werken we met een planning waarin de afhankelijkheden goed worden weergegeven. Duurt het bijvoorbeeld langer voor het lokale projectteam om equipment masterdata te verzamelen? Dan laat de planning zien dat dit bepaalde gevolgen heeft. Niet alleen voor het migreren van de equipmentdata naar SAP, maar bijvoorbeeld ook voor de ingebruikname van planborden en het migreren van financiële assetdata. Door wekelijks, soms zelfs dagelijks op deze planning terug te vallen met het team blijft iedereen goed op de hoogte van eventuele wijzigingen.
Zorg dat je je change proces op orde hebt
Een goed change proces is in mijn ogen een van de belangrijkste dingen bij grote veranderingen. Je project valt of staat bij iets dat goed functioneert en aan alle wensen en eisen van de business voldoet. Hoewel ik het in dit artikel heb gehad over migraties van vestigingen, passen we dit change proces toe bij vrijwel alle wijzigingen in ons SAP-systeem. Grote of kleine wijzigingen – de essentie blijft hetzelfde. Breng in zo simpel mogelijke taal in kaart wat er precies moet gebeuren en werk daarvoor nauw samen met de business. Zorg dat je de risico’s goed in beeld brengt voordat je gaat bouwen. Test uitvoerig en betrek daarbij de business. En neem veranderingen pas in productie als je zeker weet dat ze stabiel zijn. Zo voorkom je problemen in je SAP-systeem waardoor de business zijn werk niet kan doen. Bijkomend voordeel van een goed change proces is dat de mensen aan de businesskant beter begrijpen welk inspanning je levert om iets te wijzigen in SAP. Dat voorkomt een hoop frustratie tijdens het proces!