Voorbeeld uit de praktijk: Agility in een traditionele ERP omgeving

Bij het invoeren van Agile vindt er eigenlijk altijd een verschuiving plaats op de balans tussen enerzijds stabiliteit en beheersbaarheid en anderzijds snelle verandering en innovatie. Agile ontwikkelaars zoeken het liefst de kant van maximale vrijheid om snel nieuwe dingen uit te proberen. Beheerders  zoeken juist de 'rust' van stabiliteit en betrouwbaarheid; zij worden immers als eerste geconfronteerd met de gevolgen van buggy software. Zover niets nieuws.

Van ERP omgevingen wordt vaak gezegd dat deze niet zo geschikt zijn voor de Agile manier van werken, gezien de eisen die gesteld worden aan de betrouwbaarheid van financiële en logistieke administratieve processen en rapportages. De praktijk is echter wel dat de starheid van ERP systemen vaak een rem zet op snelle veranderingen die in de business plaatsvinden. En IT afdelingen worstelen met de forse budgetten voor ERP systemen, waardoor er minder geld beschikbaar is voor nieuwe IT innovaties.  Alle reden om te kijken of er toch ervaringen vanuit Agile kunnen worden toegepast binnen een (dogmatische) ERP omgeving. Hieronder mijn ervaringen.

Boskalis:

Bij Boskalis - een wereldspeler in de offshore en baggerwereld - ging men in 2014 op zoek naar een vernieuwing van het ERP applicatielandschap, dat door overnames was gegroeid tot een mooi verzameling applicaties van bijna alle grote ERP leveranciers, Omdat men tegelijkertijd alle administratieve bedrijfsprocessen tegen het licht wilde houden werd een project opgetuigd dat de vrijheid had om in nieuwe kaders en oplossingen te denken. En zo groeiden er al snel twee subculturen binnen de teams die zich met ERP bezig hielden: Het serviceteam, waar men volgens ITIL-achtige processen incidenten en wijzigingen doorvoerde. En het projectteam waar men Scrum had geadopteerd als methode om het nieuwe ERP systeem in te richten en te beheren. Zo konden we mooi zien welke verschillen er waren tussen de zeg maar klassieke manier van ERP beheer en de agile manier van werken.

Voordat we ingaan op deze verschillen en de lessen die we geleerd hebben eerst wat meer over de agile manier van werken die we binnen het vernieuwingsprogramma hebben gebruikt.

Agile project aanpak:

Bij de start van het ERP programma was al duidelijk dat men een andere, modernere aanpak wilde hanteren om de creativiteit te stimuleren en de betrokkenheid van de eindgebruikers te vergroten. Scrum werd als basis gekozen voor de aanpak. Rollen als product-owner en scrum-master werden geïntroduceerd, net zoals de daily-standup en alle andere werkvormen die bij scrum gebruikelijk zijn.

Maar al snel bleek dat de ERP implementatie, gevolgd door een wereldwijde uitrol, een (te) grote verandering was waar de scrum aanpak volstrekt onvoldoende structuur en houvast voor bood. Toen is een aanpak bedacht die het midden hield tussen een gefaseerde Prince2-achtige aanpak en de Scrum methode die zorgt voor de iteraties binnen elke fase. Door dit goed te dimensioneren konden we het beste uit twee werelden combineren, mede door slimme gebruik te maken van technieken zoals prototyping, inzet van best-practice oplossingen, proof of concepts en pilots. De gefaseerde aanpak zorgde ervoor dat we een meerjarenplanning in grote brokken konden splitsen en beheersen. De scrum aanpak is onovertroffen als het gaat om creëren van eigenaarschap bij gebruikers, creëren van energie binnen het team en natuurlijk het snel kunnen inspelen op nieuwe inzichten. Achteraf bezien lijkt onze aanpak wel enigszins op de Prince2Agile aanpak die gedurende ons project werd vrijgegeven door Axelos.

Tijdens de uitrol fase bleek onze agile aanpak niet meer te werken. Na de eerste paar implementaties hadden we een kernel (standaard processen en de daarbij passende systeeminrichting) ontwikkeld en een uitgewerkt implementatiedraaiboek waarmee we site voor site konden uitrollen. De wijzigingen binnen elke uitrol waren beperkt, zodat we ons grotendeels konden houden aan het standaard draaiboek. Hoewel de scrum-fanatici ons zullen tegenspreken, was onze ervaring dat de scrumaanpak, met zijn relatief korte iteraties, daar gewoon niet zo lekker bij past. Een standaard vooraf uitgewerkt plan werkt in zo'n situatie veel beter. Een uitrol had overigens een doorlooptijd van ergens tussen de 2 en 4 maanden.

Confrontatie Agile aanpak en beheerorganisatie:

De grootste uitdagingen kwamen toen het beheer van het nieuwe ERP platform werd overgedragen aan het serviceteam dat voorheen ook het beheer van legacy ERP systemen uitvoerde. De personen in het serviceteam waren tijdens de looptijd van het project niet meegenomen in de agile manier van werken, waarbij de gebruikers veel zeggenschap en eigenaarschap hebben over de keuze van de oplossing en waarbij de oplossing iteratief tot stand komt. Daarbij was inmiddels een groot deel van het functioneel applicatie beheer uitbesteed aan een leverancier in India, die sterk vasthield aan een ITIL/waterval gebaseerde manier van werken. In deze fase werden de cultuurverschillen tussen de traditionele manier van werken en de agile manier van werken duidelijk zichtbaar, wat een vruchtbare samenwerking in de weg stond. 

Verschillen en lessons-learned:

Er waren duidelijke verschillen tussen de traditionele manier van werken binnen het IT service team en de nieuwe Agile manier van werken. Hieronder heb ik de belangrijkste voor- en nadelen van onze agile manier van werken beschreven.