De gouden regels van goed contracteren
Ooit vertelde iemand mij dat je het beste op je trouwdag al de voorwaarden voor je echtscheiding kunt vastleggen. Het idee achter deze gedachte is dat je juist op dit moment, wanneer je nog op een roze wolk zit, komt tot de meest schappelijke voorwaarden.
Vertaald naar onze wereld van software implementaties betekent dit dat een goed contract al begint bij de offerteaanvraag. Want wat is het geval? Tijdens de selectiefase krijgt u verschillende offertes toegestuurd, met ieder een eigen structuur die totaal onvergelijkbaar zijn. Wij sturen daarom bij een offerteaanvraag een hoofdstukindeling mee. Leveranciers vragen wij hun oplossing, aanpak en kosten – zoveel mogelijk gespecificeerd – te beschrijven, zodat klanten appels met appels kunnen vergelijken. Dit ondersteunt een goed selectieproces.
Als er een voorkeur voor een leverancier bepaald is, dan moet er een goed contract opgesteld worden. Wat zijn enkele noodzakelijke onderdelen van een goed contract? De volgende elementen geven al veel duidelijkheid en zorgen voor een soepele(re) samenwerking:
- Afspraken over werkverdeling
- Geen verborgen kosten
- Een duidelijke scope
Afspraken over werkverdeling
Een RACI-diagram is hier een goed hulpmiddel voor. De afkorting staat voor ‘Responsible, Accountable, Consulted, Informed’. Bij elke deliverable leg je vast wie waarvoor verantwoordelijk is en wanneer. Discussies over meerwerk zijn hierdoor verleden tijd.
Geen verborgen kosten.
Open calculaties zijn een middel om onverwachte kosten te voorkomen. Na livegang kunnen de kosten voor conversies, rapportages, autorisaties, interfaces met andere bedrijfsapplicaties en ondersteuning flink oplopen. Een praktijkvoorbeeld hiervan kwamen wij tegen bij een door ons begeleide klant. Hij kreeg plotseling te maken met 20 % extra implementatiekosten. Na aanvraag van een specifieke prijsopgave bleken dit kosten te zijn van bovengenoemde activiteiten. De leverancier voelde hierbij ook wel nattigheid, zodat deze zijn uurtarief direct aanpaste zodat de totale aanneemsom gelijk kon blijven.
Een duidelijke scope
Je kan tijdens het project nog zo goed samenwerken, maar als je geen goede afspraken gemaakt hebt wanneer het project afgerond is, dan kun je aan het eind nog heftige onenigheid krijgen. Een goede scope-definitie in het contract is een voorwaarde voor een goede afronding. Wat wordt wel opgeleverd en ook wat wordt niet opgeleverd. Deze is gelinkt aan de blauwdruk. Samen met de klant stellen we de blauwdruk op in de selectiefase. De blauwdruk is een leidend document voor de implementatie. Hierin is de gewenste procesondersteuning vastgelegd.
Het doel van een goede contractering is zeker niet om de leverancier het vel over de neus te trekken. Dit leidt slechts tot revanchegevoelens die je als klant altijd terug krijgt in het project. Een software implementatie zoals bijvoorbeeld een ERP-systeem markeert de start van een langdurige, jarenlange samenwerking. Een contract moet dus fair zijn. De leverancier moet geen onmogelijke voorwaarden opgelegd krijgen die deze in de praktijk niet kan waarmaken (of die een doel op zichzelf worden). Ondertussen moet u als klant voldoende waarborgen krijgen voor een goed projectresultaat, met een goede prijs voor het best passende product.
Dit is waarschijnlijk wel de allerbelangrijkste gouden regel wat betreft contracteren: een contract moet de basis zijn voor een goede implementatie en niet voor een goede rechtszaak!
Wat is jouw ervaring met contractering? Wanneer je graag begeleid wordt door een expert
neem dan gerust contact met ons op. Ruud Haring staat je graag te woord.
