Bedrijven die nieuwe erp-systemen of andere grote zakelijke applicaties implementeren weten dat ze grote risico’s lopen. Zij zullen proberen die risico’s zo veel mogelijk te vermijden en beheersbaar te maken. De beste manier is ervoor te zorgen dat het project door ervaren professionals wordt uitgevoerd. Daarmee ben je er echter nog niet.
Het grote risico van grotere zakelijke systeemimplementaties komt voort uit de veranderlijke aard van de te automatiseren organisatie, in combinatie met het feit dat de technische oplossing die voor de organisatie opgezet wordt juist een statisch karakter heeft. Als je een project start, definieer je wat je wilt hebben. Dat laat je maken en voorbereiden, maar tegen de tijd dat je het wilt gaan gebruiken, wil je inmiddels iets anders dan wat je vooraf gezegd had.
Meestal worden in de praktijk veranderingen in de organisatie ‘geabsorbeerd' in het lopende project. Het project wordt dan aangepast aan de veranderde realiteit. Echter, de uitwerking van organisatieveranderingen op een lopend project is vaak onvoorspelbaar. Een strategische wijziging van een bedrijf hoeft niet per definitie grote gevolgen voor een project te hebben. Sommige kleine organisatorische veranderingen kunnen soms juist wel dramatische gevolgen hebben.
Projectcontracten met uitgebreide functionele specificaties, hoe goed bedoeld ook, leiden vaak tot een totaalmislukking. Bij iedere organisatorische verandering moet immers het contract weer uit de kast gehaald worden, met alle onderhandelingsrisico's van dien. Zolang de verhoudingen niet opnieuw vastgelegd zijn, is het project slecht bestuurbaar, en dat kan een aantal keren achter elkaar gebeuren. Alleen al het stilleggen van dit soort projecten is een enorm risico, omdat het moeilijk is alle deelnemers aan het project opnieuw te enthousiastmeren. Ervaren projectmanagers zullen dergelijke contracten dan ook willen voorkomen.
Als er geen functionaliteit in een contract mag staan, wat mag er dan wel in staan? Grotere implementaties van zakelijke informatiesystemen worden met behulp van projectmanagementmethodes aangestuurd. Het bekendste voorbeeld daarvan is Prince II. Daarbij gaat het om de verdeling van verantwoordelijkheden en de wijze waarop het project beheerd wordt. Dit behelst planningstechnieken, voortgangsrapportage en rapportagelijnen in het project: wie doet wat wanneer, wat gebeurt er bij onverwachte situaties? De methode voorziet in identificatie van onverwachte ontwikkelingen, van een afwegingsmethode hoe er mee om te gaan tot en met een beslisstructuur. Juist dit laatste onderdeel draagt bij tot risicobeheersing. De noodzaak van de organisatorische wijziging kan daardoor op evenwichtige wijze worden afgewogen tegen projectrisico en -kosten.
Contracten zouden de projectmanagementstructuur moeten volgen en versterken. De inhoud daarvan zal afhangen van de kenmerken van het project en ook van de betrokken partijen. Ook de verhoudingen tussen de partijen kunnen daarbij een rol spelen. Een pasklaar model is er niet. In ieder geval moet niet alleen de projectopzet professioneel en kundig aangepakt worden, ook het opstellen van het contract vereist diepgaand begrip van de dynamiek en de aanpak van het betrokken project. Door contracten nauw bij de projectstructuur aan te laten sluiten kan het projectmanagement worden versterkt in plaats van doorkruist.
Frank van 't Geloof
Advocaat
Adriaanse de Meijer Advocaten
Frank van 't Geloof, auteur van dit artikel, is twintig jaar lang projectmanager geweest van grote erp-implementaties. Sinds december 2009 is hij als advocaat verbonden aan Adriaanse de Meijer Advocaten.
Typische advocaten-denkstijl: Als het maar in een contract staat is het risico belegd.
Onzin natuurlijk.
Ervaring leert dat beide partijen fouten maken in dergelijke grote trajecten. Om elkaar dan voor de rechtbank ter verantwoording te roepen is onzinnig. Dergelijke zaken duren vervolgens jaren en de enige die er wijzer / rijker van worden zijn…
http://www.enotes.com/shakespeare-quotes/lets-kill-all-lawyers
De PrinceII structuur zorgt ervoor (als je het goed doet) dat alle partijen weet wat er van hem verwacht wordt.
Om vervolgens tegenslagen aan te kunnen, en die zijn er altijd, heb je vertrouwen en doorzettingsvermogen nodig. Begin alleen aan dit soort trajecten met een partner. Niet met een leverancier. Partners kweek je niet met boeteclausules en rechtzaken.
… en verwacht niet dat je vooraf precies het eindresultaat kunt beschrijven: de omgeving waarin je opereert verandert continu. Je kunt wel in een document proberen te beschrijven wat er over 2 jaar klaar moet zijn maar misschien heb je dat dan niet meer nodig. Blijf vooral flexibel en hou rekening met voortschrijdend inzicht.
Hugo heeft met zijn verwijzing naar PRINCE2 een punt, maar welk punt?
ERP projecten mislukken omdat doel en middel worden verward. Het gaat niet om functionele specificaties, het gaat om de verbetering van een proces (business case) en de specs zijn hieraan ondergeschikt. Maar IT of ERP projecten denken dat het IT / ERP systeem implementeren het doel is.
En daarmee krijgt Marcel vanuit de logica ook gelijk want door een onduidelijk doel gaan we dus harde maar onwerkbare contractuele afspraken maken zonder flexibiliteit.
Dit wordt versterkt door een project manager van de leverancier. Het middel van de klant (ERP systeem) is het doel van de leverancier. Een project manager van de leverancier zal daarom vrijwel altijd falen. Hugo zei het als: “als je het goed doet” want de enige manier om doel en middel scherp te houden is door de leiding (Executive) en project manager van de klant te laten komen.
Een PM van de leverancier is in PRINCE2 termen daarom vrijwel altijd een teammanager (op work package niveau).