Vorige maand tekenden we bij een grote onderwijsinstelling het contract voor een Dynamics-implementatie. Niet na twee weken onderhandelen, maar na maanden waarin we elke acceptatiestap, elke betaalmijlpaal en elk exitscenario hebben vastgelegd voordat er ook maar één omgeving was ingericht. Saai? Misschien. Maar het is precies het werk dat bepaalt of zo'n traject over twee jaar een succes is of een hoofdpijndossier.
Ik begeleid op dit moment een CRM-implementatie op het Dynamics-platform en zie dagelijks waar het knelt. Zelden in de techniek. Vrijwel altijd in de besturing eromheen.
De cijfers die niemand in de demo laat zien
Leveranciers laten je graag zien wat Dynamics allemaal kan. Wat ze niet laten zien:
- Het aantal koppelingen met bestaande systemen dat je moet ontwerpen, bouwen en testen voordat het platform iets nuttigs doet. Bij ons zijn dat er meer dan tien.
- De discussie over welk systeem de bron is van welke data. Wie is eigenaar van de productcatalogus? Waar leeft het klantrecord? Die vragen kosten weken, geen dagen.
- De beheercapaciteit na livegang. Wij vroegen anderhalve fte en kregen er één toegekend. Dat verschil staat nu als risico in ons register, met naam, eigenaar en maatregel.
Een Dynamics-project is voor tachtig procent een organisatieproject en voor twintig procent een IT-project. Wie het andersom bestuurt, komt zichzelf tegen.
Betalen op acceptatie, niet op de kalender
De belangrijkste afspraak in ons contract is niet de prijs. Het is het betaalritme. We betalen een deel bij de start en de rest pas wanneer een fase formeel is geaccepteerd. Geen acceptatie, geen factuur.
Dat klinkt hard, maar het werkt voor beide kanten. De leverancier weet precies wat "af" betekent, want de acceptatiecriteria zijn een bijlage bij het contract. Wij weten dat de prikkel om kwaliteit te leveren tot de laatste dag intact blijft. En de stuurgroep weet dat er nooit meer geld de deur uit is dan er waarde is binnengekomen.
Drie dingen die je hiervoor nodig hebt:
- Acceptatiecriteria per fase, vastgelegd vóór ondertekening. Achteraf onderhandelen over wat "werkend" betekent is de duurste vergadering die er bestaat.
- Een acceptatieproces met een eigenaar. Iemand moet bevoegd zijn om te tekenen, en iemand moet de hertest bewaken.
- Een exitplan, ook als je niet van plan bent te vertrekken. Juist dan onderhandel je er ontspannen over.
Change-control is geen bureaucratie, het is geheugen
Elke implementatie van anderhalf jaar of langer krijgt te maken met wijzigingen. Nieuwe wensen, gewijzigde prioriteiten, een reorganisatie tussendoor. Het verschil tussen beheerste en onbeheerste projecten is niet dat de eerste geen wijzigingen kennen. Het is dat ze een proces hebben om erover te besluiten.
Wij hanteren een beslismandaat op drie niveaus: het projectteam beslist binnen de fase, de stuurgroep beslist over scope en budget, en alles wat een harde eis uit het programma van eisen raakt, gaat via formele change-control. Elke wijziging krijgt een ticket, een afweging en een besluit. Over een jaar weet niemand meer waarom iets is aangepast. Het register wel.
Van CRM naar ERP: dezelfde wet, zwaardere gevolgen
Alles wat hierboven staat geldt voor CRM. Voor ERP geldt het in het kwadraat. Een CRM dat hapert is vervelend voor je klantprocessen. Een ERP dat hapert raakt je facturatie, je voorraad en je jaarrekening.
Daarom is de volgorde bij een ERP-traject wat ons betreft altijd dezelfde:
- Eerst de processen en de proceseigenaren scherp, dan pas het systeem.
- Eerst het integratielandschap in kaart, met per koppeling een ontwerp en een bronbesluit, dan pas bouwen.
- Eerst de acceptatie- en betaalstructuur in het contract, dan pas tekenen.
Het platform doet er minder toe dan de meeste selectietrajecten suggereren. De besturing eromheen bepaalt de uitkomst.
Geen papierwerk, maar stuurwerk
Ik hoor soms dat PRINCE2 en stuurgroepen ouderwets klinken. Tot de eerste keer dat een leverancier een deadline mist en je zonder discussie kunt terugvallen op een afspraak die zwart op wit staat. Dan is dat "papierwerk" ineens het enige dat telt.
Goede projectgovernance merk je niet aan dikke documenten. Je merkt het aan korte vergaderingen, snelle besluiten en het ontbreken van verrassingen.
← Terug naar alle artikelen