HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING

Transcriptie

1 HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING versie 2007

2 HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING versie 2007

3 COLOFON Handreiking systeemgerichte contractbeheersing - versie 2007 is een uitgave van Inkoopmanagement GWW (IMG) van Rijkswaterstaat. Deze handreiking wordt gebruikt als syllabus bij de training Systeemgerichte contractbeheersing in de praktijk en als praktische handleiding in de toepassing van systeemgerichte contractbeheersing in projecten. Samenstelling: Paula Kuijpers en Ivo van den Berg Met dank aan: Luc Batterink, Simon Bezuijen, Jan Bijkerk, Ferdinand Bockhoudt, Arjen de Boer, Karel de Jonge, Marcel Krikke, Hans te Pas, Theo Podt, Marcel Polet, Kees Scheurwater, Benno Stoiber, Sam de Visser, Bram van Vliet, Suzan Vos, Wiebe Witteveen Tekst: Direct Dutch Publications B.V. Ontwerp: Gerard Bik BNO Drukwerk: Artoos Nederland, Rijswijk Informatie en aanvraag van exemplaren: Rijkswaterstaat, IMG T.a.v. Kennisveldbeheerder contractmanagement Postbus LA Utrecht Modellen en instrumenten beschikbaar op: Uitgave februari 2007 HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

4 Inleiding De markt tenzij. Dat is het uitgangspunt van Rijkswaterstaat voor het uitvoeren van werkzaamheden. We schakelen de markt in, tenzij blijkt dat dit geen toegevoegde waarde heeft of dat dit niet mogelijk is. Om de expertise van de markt optimaal te benutten, werkt Rijkswaterstaat met innovatieve contractvormen. Kenmerk van innovatieve contractvormen is dat meer afstand wordt genomen van de uitvoering: de opdrachtnemer is verantwoordelijk en bepaalt zelf hoe hij tot het gewenste resultaat komt. Een ander kenmerk van innovatieve contractvormen is dat de opdrachtnemer zelf de kwaliteit van zijn product beheerst. Dit noemen we externe kwaliteitsborging. Als de opdrachtgever gebruikmaakt van het kwaliteitsmanagement van de opdrachtnemer voor de beheersing van een contract, dan spreken we van systeemgerichte contractbeheersing (SCB). Wat systeemgerichte contractbeheersing is en hoe het werkt, kunt u lezen in deze handreiking, die wordt gebruikt in combinatie met de training Systeemgerichte contractbeheersing in de praktijk. Deze handreiking is bedoeld voor RWS ers die in de praktijk met systeemgerichte contractbeheersing te maken krijgen. Beleid, theorie en praktijk komen in deze publicatie uitvoerig aan bod. Toepassing De werkwijze beschreven in deze handreiking is specifiek van toepassing op geïntegreerde contractvormen (D&C en E&C) onder de Uniforme Administratieve Voorwaarden voor geïntegreerde contractvormen (UAV-gc 2005). Systeemgerichte contractbeheersing kan ook worden toegepast op DB(F)M-contracten en E&C-contracten onder UAV Daarbij zijn wel maatwerkuitwerkingen ten aanzien van contractering en contractbeheersing vereist. Deze zijn niet in deze handreiking beschreven. IMG van Rijkswaterstaat kan hierover adviseren. De verdieping De theorie Het inkoopproces Beleid en strategie Inleiding Woordenlijst HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

5 HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

6 Inhoudsopgave HOOFDSTUK 1: INKOOP: BELEID EN STRATEGIE 6 HOOFDSTUK 2: HET INKOOPPROCES EN CONTRACTMANAGEMENT 9 HOOFDSTUK 3: SYSTEEMGERICHTE CONTRACTBEHEERSING: DE THEORIE 13 HOOFDSTUK 4: SYSTEEMGERICHTE CONTRACTBEHEERSING: DE VERDIEPING 22 Contractstructuur en -voorwaarden 22 Eisen aan de opdrachtnemer: IPM en kwaliteitsmanagement 26 Risicomanagement 31 Mix van toetsen 39 Opvolging toetsen 41 Betalingsproces 47 Oplevering 50 VERKLARENDE WOORDENLIJST 52 HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst De verdieping De theorie Het inkoopproces Beleid en strategie Inleiding

7 1 Inkoop: beleid en strategie Rijkswaterstaat streeft sinds 1992 naar vernieuwde werkverhoudingen met marktpartijen. Met de toepassing van het beleid voor innovatief aanbesteden wil Rijkswaterstaat opdrachtnemers eerder betrekken bij de realisatie van projecten. Rijkswaterstaat wil de kennis en ideeën van de markt optimaal benutten en streeft naar creatieve oplossingen. Om optimaal gebruik te maken van de markt, wordt gewerkt met innovatieve contractvormen op basis van functionele specificaties. Het werken met deze contractvormen leidt tot een andere invulling van de rollen van opdrachtgever en opdrachtnemer. De opdrachtnemer heeft een grotere inbreng bij het ontwikkelen en ontwerpen van producten. Wij, als opdrachtgever, voeren regie op afstand. In de corporate inkoopstrategie van Rijkswaterstaat, het document waarin de inkoopaspecten van het ondernemingsplan zijn uitgewerkt, worden voor elk type werkzaamheden innovatieve contractvormen voorgeschreven. Voor aanleg, groot en variabel onderhoud passen we geïntegreerde contractvormen toe (D&C of E&C), contractvormen waarin de opdrachtnemer zowel de ontwerpals de uitvoeringswerkzaamheden op zich neemt. Voor het beheersen van contracten voor aanleg- en groot en variabel onderhoudprojecten maken we gebruik van systeemgerichte contractbeheersing (SCB). Voor vast onderhoud gebruiken we vooralsnog prestatiecontracten. Bij prestatiecontracten baseren we ons in de beheersing op eigen waarnemingen van de geleverde prestatie. Op D&C- en E&C-contractvormen zijn de Uniforme Administratieve Voorwaarden voor geïntegreerde contractvormen (UAV-gc 2005) van toe - passing. Dit zijn vastgestelde juridisch-administratieve voorwaarden van een contract (zie illustratie 1). Werkzaamheden Contractvorm Voorwaarden Contractbeheersing Aanleg D&C UAV-gc 2005 SCB Groot onderhoud D&C of E&C UAV-gc 2005 SCB Variabel onderhoud * E&C UAV-gc 2005 SCB Vast onderhoud Prestatie UAV 1989 Eigen waarneming Illustratie 1: overzicht van werkzaamheden, bijbehorende contractvormen, voorwaarden en wijze van contractbeheersing In het ondernemingsplan wordt één Rijkswaterstaat beschreven met één werkwijze. Het RWS contractenbuffet is een uitwerking van dit principe en bevat instrumenten voor alle GWW-projecten: nat of droog, onderhoud of aanleg. Voor systeemgerichte contractbeheersing zijn binnen het contractenbuffet bijvoorbeeld het model contractbeheersplan, het model toetsplan en het model toetsverslag van toepassing. Medewerkers zijn verplicht deze te gebruiken. Alleen met goede onderbouwing mag hiervan worden afgeweken. * Tot 2008 kunnen ook modelcontracten voor variabel onderhoud worden toegepast onder UAV 1989 met toepassing van eigen waarneming. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

8 HSL: ontstaansgeschiedenis systeem gerichte contractbeheersing Theo Podt Inleiding Voor de realisatie van de HSL-Zuid is systeemgerichte contract - beheersing toegepast. Bij de start van het HSL-project was systeemgerichte contractbeheersing nog geen gemeengoed. Al lopende het project hebben wij het onder de knie gekregen, aldus Theo Podt. De theorie Het inkoopproces Beleid en strategie Foto: Ad Hupkes Podt, sinds 1999 betrokken bij de HSL, vertelt over de implementatie van systeemgerichte contractbeheersing binnen het HSL-project. Systeemgerichte contractbeheersing werd in die tijd EKB genoemd. Het werken met systeemgerichte contractbeheersing werd tijdens een evaluatie bestempeld als een groot experiment in een groot project. Voor ons en voor de opdrachtnemers was systeemgerichte contractbeheersing destijds iets nieuws. Wij leerden door tegelijkertijd te denken én te doen. Het beoordelen van het eindproduct van HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE De verdieping Woordenlijst

9 de aannemer moesten wij zoveel mogelijk loslaten. Het draaide om de kwaliteit van zijn werkprocessen. Dat zat toen nog niet tussen de oren. Maar ook aannemers hadden moeite met systeemgerichte contractbeheersing. Zij waren gewend om te werken met een bestek waarin werkzaamheden gedetailleerd werden voorgekauwd en moesten nog leren om zelf verantwoordelijk te zijn voor aantoonbare kwaliteit. Ze trokken ons tijdens het project soms aan de mouw, wilden ons meer bij de uitvoering betrekken. Wij hielden onze poot stijf. Zij moesten met de oplossing komen, niet wij. Kaart Het projectbureau betaalde de aannemer op basis van de voortgang. Om de aannemer te stimuleren zijn werkzaamheden goed uit te voeren, werd een kaartensystematiek ingevoerd. Voor een vastgestelde afwijking kreeg de aannemer een gele kaart. Had hij deze fout hersteld, dan kwam de kaart te vervallen. Haalde hij voor hetzelfde product of eenheid een tweede gele kaart, dan volgde er, jawel, een rode kaart, inclusief betalingsstop. Pas als de aannemer had laten zien dat hij de fout had hersteld, kwam een gele kaart te vervallen en mocht worden overgegaan tot betaling. Sommige aannemers trokken zich die systematiek erg aan, vertelt Podt. Niet alleen vanwege de financiële consequenties. Ze zagen het ook als een erezaak om geen kaart te halen. Leerpunten Binnen HSL is veel geleerd. Zo is de samenstelling van het toetsteam erg belangrijk, geeft Podt aan. Daar moeten mensen in zitten met verstand van techniek, maar ook mensen met verstand van werkprocessen. Daarnaast heb ik gemerkt dat als je bij systeemgerichte contractbeheersing veel tijd steekt in de voorbereiding van een contract, je dat later in de uitvoering dubbel en dwars terugverdient. Een ander leerpunt: zorg ervoor dat de aannemer ook aandacht heeft voor de nazorg. Bijvoorbeeld aan de hand van een financiële prikkel: voldoe een laatste deel van het bedrag pas helemaal aan het einde van de rit. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

10 2 Het inkoopproces en contract - management Het in het ondernemingsplan geformuleerde streven naar één werkwijze is terug te zien in de standaardisering van de werkprocessen van Rijkswaterstaat (UPP: Uniformering Primaire Processen). Nadere informatie hierover is te vinden op de UPP-intranetsite: Als gevolg van UPP is ook het RWS inkoopproces beschreven. Dit proces, ook wel bekend als de basisstructuur inkoopmanagement van Rijkswaterstaat, bestaat uit vier fasen: opdracht voorbereiden, opdracht verlenen, opdracht beheersen en opdracht afronden. Elke fase bestaat uit een of meer stappen. Opdracht voorbereiden I Specificeren inkoopbehoefte Inleiding Beleid en strategie Opdracht verlenen Opdracht beheersen II III IV Marktbenadering Gunning Voorbereiden contractuitvoering en -beheersing V Ontvangen en vaststellen geleverde prestatie, inclusief wijzigen contract en meer-minderwerk Het inkoopproces VI Factuur verwerken Opdracht afronden VII VIII Evaluatie Afsluiten opdracht De theorie Illustratie 2: de basisstructuur inkoopmanagement van RWS Opdracht voorbereiden (I) In deze fase van het inkoopproces stellen we de inkoopbehoefte vast. Op basis van een afweging van risico s kiezen we onder andere voor de meest geschikte risicoverdeling, marktbenadering, contractomvang, contractvorm, beheersingsvorm, betalingsregeling en gunningcriteria (toepassing EMVI). De gemaakte keuzen worden vastgelegd in een inkoopplan. Op basis van dit inkoopplan worden één of meer contracten opgesteld. Tegelijkertijd met het contract stellen we een contractbeheersplan op. Aan het einde van deze fase maken we een bedrijfseconomische raming. Dit is een aangepaste versie van de raming op basis van kengetallen uit de planfase. Opdracht verlenen (II, III) In deze fase benaderen we de markt en verlenen we de opdracht. Bij de marktbenadering handelen we conform de aanbestedingsregelgeving HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE De verdieping Woordenlijst

11 Algemene Richtlijn Werken (ARW 2005). Afhankelijk van de gekozen aanbestedingsprocedure krijgen marktpartijen inbreng in de inhoud en voorwaarden van de opdracht. Afhankelijk van wijzigingen in de aanbestedingsfase wordt de raming geactualiseerd (marktraming). Nadat de opdracht in de markt is gezet, dienen de marktpartijen hun inschrijvingen in. Op basis van de criteria prijs en kwaliteit (en onderliggende subcriteria) wordt de opdracht gegund. Voor de beoordeling van prijs en kwaliteit wordt de EMVI-systematiek (Economisch Meest Voordelige Inschrijving) gebruikt. Opdracht beheersen (IV, V, VI) In de opdrachtvoorbereidingsfase vormt het contractbeheersplan de aanzet voor de contractbeheersing. Na gunning kan de contractbeheersing verder worden uitgewerkt. Hierin hebben zowel opdrachtgever als opdrachtnemer een rol. Beide partijen brengen op basis van risicomanagement de grootste risico s in kaart en wisselen tijdens een afstemmingsoverleg informatie uit over geïnventariseerde risico s en voorgenomen beheersmaatregelen. Door het gesprek ontstaat bij beide partijen inzicht in mogelijke nieuwe risico s en de wijze waarop deze kunnen worden beheerst. De opdrachtnemer verwerkt deze nieuwe inzichten in zijn risicoregister, projectmanagementplan en onderliggende plannen. De opdrachtgever verwerkt de informatie in het eigen risicodossier en werkt op basis hiervan de contractbeheersstrategie verder uit. Opdrachtgever Actualiseren risicodossier van voor gunning Opdrachtnemer Opstellen risicoregister gunning Afstemmingsoverleg risico s Invullen contract - beheersing Beoordelen Projectmanage - mentplan Opstellen Projectmanage mentplan Illustratie 3: van risicoanalyse naar contractbeheersing Om de contractbeheersstrategie uit te werken, plannen we op basis van de risicoanalyse en de werkwijze van de opdrachtnemer systeem-, proces- en producttoetsen in. Deze toetsen leggen we vast in het toetsplan. Voor het opstellen van een toetsplan wordt het model toetsplan uit het RWS contractenbuffet gebruikt. De opdrachtnemer voert zijn werkzaamheden uit. Daarbij controleert hij zelf op basis van (eventueel geaccepteerde) verificatie- en keuringsplannen of hij aan de eisen in het contract voldoet. Waar nodig, stuurt hij zelf bij. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

12 Rijkswaterstaat ziet toe op levering conform het contract door de geplande mix van systeem-, proces- en producttoetsen uit het toetsplan uit te voeren. Op basis van de bevindingen van deze toetsen stelt de opdrachtgever de geleverde prestatie vast. Als er geen openstaande tekortkomingen zijn, zal een prestatieverklaring (conform de UAV-gc 2005) worden verstrekt. Op basis daarvan kan de opdrachtnemer worden betaald. Eventuele wijzigingen van het contract en de verrekening van meer/minder werk als gevolg van die wijzigingen vinden ook in deze fase van het inkoopproces plaats. Opdracht afronden (VII, VIII) Aan het einde van een project wordt de verzamelde projectinformatie geanalyseerd en verwerkt in een projectrapportage. Evaluaties van het project dienen als input voor mogelijke verbeteringen in een volgend project. Nadat de opdrachtnemer aan al zijn verplichtingen heeft voldaan en de project - administratie is afgerond, wordt het resultaat van de opdracht formeel overgedragen, zoals is vastgelegd in het projectmanagementplan van de opdrachtgever. Hierna wordt de overeenkomst formeel beëindigd. De verdieping Inleiding De theorie Beleid en strategie Woordenlijst Het inkoopproces HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

13 Een open dialoog Suzan Vos, projectmanager Verbreding A4 tussen Leiden en Burgerveen Over de insteek In ons contractbeheersplan is expliciet gekozen voor een risicogestuurde contractbeheersing. Niet dat we in het plan alle risico s hebben uitgekauwd. Integendeel, het plan beschrijft vooral hoe wij als projectorganisatie georganiseerd zijn. Maar gaande de uitvoering van het project zullen wij, als opdrachtgever, de risico s telkens opnieuw analyseren en ons beheersplan zonodig actualiseren. Hierop stemmen we onze toetsingspraktijk af. Welke toetsen we inzetten om te weten te komen of alles gaat zoals het moet gaan, is dus een vraag die we steeds opnieuw stellen. Foto: Hans Sodenkamp, RWS Noord-Holland Over softe factoren Toepassing van systeemgerichte contractbeheersing is een leerproces, zowel voor ons als voor de opdrachtnemer. Het welslagen van een project is geen kwestie van louter de procedure voor systeemgerichte contractbeheersing volgen zoals die op papier staat. Minstens even belangrijk is daadwerkelijk vertrouwen geven aan de opdrachtnemer, een open dialoog voeren over het werk. Ook moeten we consequent zijn in de eisen die we stellen. Mijn intentie is om een sessie te organiseren met betrokkenen op diverse niveaus uit beide projectorganisaties om opvattingen over de vastgestelde risico s te delen. In hoeverre hebben we hetzelfde beeld van de risico s? Wie zou welk risico moeten beheersen? Ik denk dat we zo misverstanden kunnen voorkomen, ook als er in een later stadium druk op de ketel komt te staan. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

14 3 Systeemgerichte contract - beheersing: de theorie Onder contractbeheersing verstaan we het volgende: alle activiteiten die door de opdrachtgever worden uitgevoerd, die er op gericht zijn om zeker te stellen dat de eisen uit de overeenkomst worden bereikt en dat de risico s voor de opdrachtgever op een acceptabel niveau blijven. Hierbij is het primaire doel dat de contractbeheersing efficiënt (op afstand, met zo min mogelijk inspanning) en effectief (gericht op toprisico s van de opdrachtgever) is. Volgens de intern gemaakte afspraken kan bovendien op basis van de resultaten van de contractbeheersing de rechtmatigheid van betaling worden aangetoond. Voor de beheersing van contracten onder de UAV-gc is de methode van systeemgerichte contractbeheersing van toepassing. Deze methode is gebaseerd op de volgende uitgangspunten: Kwaliteitsmanagement door de opdrachtnemer De verantwoordelijkheid voor het voldoen aan eisen uit de overeenkomst ligt bij de opdrachtnemer. De opdrachtnemer beheerst zijn project en kan het voldoen aan de eisen van (deel)producten aantonen met de registraties uit zijn verificatie- en keuringsplan. Het belangrijkste element van de projectbeheersing van de opdrachtnemer is dat hij zelf tijdig afwijkingen signaleert, tijdig passende (correctieve, corrigerende en/of preventieve) maatregelen neemt en dit hele proces regelmatig evalueert. Inleiding Beleid en strategie Het inkoopproces Plan Contract a... a... a... Act Proces Do Product a... a... a... De theorie Check Aantonen a... a... Illustratie 4: schematische weergave van de manier waarop de opdrachtnemer het contract realiseert. In het kader van kwaliteitsmanagement richt de opdrachtnemer zelf zijn processen in en past deze toe. Hij verifieert, controleert en keurt zelf de (deel)producten. Daarmee toont hij aan dat hij aan de eisen van het contract voldoet. Tenslotte is door de Deming-cirkel het principe van continue verbetering weergegeven. De opdrachtnemer moet zelf kunnen bijsturen om afwijkingen te verhelpen. Afwijkingen dient hij te voorkomen door continu de eigen werkwijze te verbeteren. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE De verdieping Woordenlijst

15 Beheersing op afstand De opdrachtgever kiest bewust voor een rol op afstand waarbij er minimale bemoeienis is met de invulling van het projectmanagement en kwaliteitsmanagement van de opdrachtnemer. Beheersing op afstand is een intensief en dynamisch proces. De opdrachtgever richt een mix van toetsen in die risicogestuurd is en gebaseerd is op de eisen van de overeenkomst. Hierbij past de opdrachtgever de Deming-cirkel toe, waarmee hij het proces van toetsen continu optimaliseert. Mogelijke aanleidingen tot optimalisatie zijn wijzigende omstandigheden en risico s, nieuwe inzichten in de voortgang van het werk, bevindingen en tekortkomingen. Mix van toetsen Het naleven van de contractuele verplichting door de opdrachtnemer wordt getoetst door het uitvoeren van een geplande mix van systeem-, proces- en producttoetsen. Deze toetsen leveren een oordeel over het functioneren van het kwaliteitsmanagement, de beheersing van processen en de betrouwbaarheid van de registraties van de opdrachtnemer. De mix van toetsen wordt in de tijd uitgezet in een toetsplan. Eisen aan het toetsplan zijn: de geplande toetsen moeten gebaseerd zijn op een actuele lijst van contract - risico s; de aanvankelijke mix van toetsen bestaat minimaal uit één systeem-, procesen producttoets; per termijn moet een toets worden ingepland op het betalingscriterium (tijdelijk verplichte toets tot 2008, zie toelichting in hoofdstuk 4). Aanvankelijke mix van toetsen Systeemgerichte contractbeheersing is gebaseerd op een mix van systeem- én proces- én producttoetsen. De toetsstrategie biedt de mogelijkheid om op basis van positieve bevindingen in eerdere termijnen tijdelijk het aantal toetsen terug te kunnen laten lopen in volgende termijnen. Het is dus mogelijk dat één type toetsen in een termijn niet voorkomt. In verdere termijnen zal wel een volledige mix worden uitgevoerd. De formulering dat de aanvankelijke mix van toetsen bestaat uit minimaal een systeem-, proces- en producttoets betekent dus niet dat voor elke termijn, betaalpost, werkpakket, object of volledig contract minimaal één systeem-, één proces- en één producttoets moet worden uitgevoerd. Bij de uitvoering van toetsen maakt de opdrachtgever gebruik van het contract en de kwaliteitsdocumenten (het projectmanagementplan en onderliggende plannen, zoals verificatie-, keurings-, testplannen etc.) en de registraties (verificatienota, keuringsrapporten etc.) om te zien of de opdrachtnemer aan zijn eisen voldoet. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

16 Toetssoorten Systeemtoets Een systeemtoets is een toets op het (in Vraagspecificatie deel 2 geëiste) systeem van integraal projectmanagement (IPM), zoals dat door de opdrachtnemer is beschreven in het projectmanagementplan en afgeleide deelplannen, waaronder projectkwaliteitsplan(nen). Het gaat bij deze toets om de risicovolle aspecten van het projectmanagement van de opdrachtnemer. Het gaat hierbij om de inzet van vakkundige medewerkers en benodigde middelen, het bewaken van de planning, het beheersen van risico s, het bewaken van de vereiste procescontroles, de behandeling van geconstateerde afwijkingen en dergelijke. Ook de acties die de opdrachtnemer zelf neemt om zeker te stellen dat hij het projectmanagementplan naleeft, vallen hieronder. Bijvoorbeeld de interne (project)audits, de activiteiten van een kwaliteitsfunctionaris, de sturing door het (project)management etc. De meest geschikte methode om een dergelijke toets uit te voeren, is het houden van interviews met medewerkers die sleutelfuncties vervullen in de projectorganisatie van de opdrachtnemer. Tijdens een gesprek wordt de bewijsdocumentatie (auditvorm) beoordeeld. Procestoets Een procestoets is een toets op het functioneren van de processen die de opdrachtnemer heeft beschreven in het projectmanagementplan en afgeleide deelplannen, zoals projectkwaliteits-, werk-, keurings-, test- of verificatieplannen. Met deze toets wordt vastgesteld of de opdrachtnemer de beheersmaatregelen uitvoert volgens de plannen. De toets is dus gericht op de borging van de kritieke aspecten die binnen het werkproces van invloed zijn op het uiteindelijke resultaat. De vereiste vakdeskundigheid, specifieke richtlijnen of rekenhulpmiddelen, volledige en juiste uitgangspunten, heldere aansturing (wie doet wat en wie beslist waarover), controles en corrigerende maatregelen zijn nadere toetsaspecten in een procestoets. Het houden van (proces)audits en bijwonen en observeren van de processen en/of het opvragen van beoordelingen van controles en kwaliteitsregistraties door de opdrachtnemer, zijn vormen van procestoetsen. Producttoets Een producttoets is een toets waarmee de betrouwbaarheid van de gegevens van de opdrachtnemer wordt geverifieerd. Doorgaans wordt hierbij een keuringsrapport en onderliggende keuringsgegevens bekeken om te beoordelen of het resultaat van de keuring gerechtvaardigd is. Een voorbeeld van een producttoets is het uitvoeren van een meting op een opgeleverd product en het vergelijken van de resultaten van die meting met de registraties van de opdrachtnemer. Risicogestuurd Toetsen worden ingepland op basis van actuele risico s voor de opdrachtgever. Hierbij spelen voornamelijk de risico s een rol die voor Rijkswaterstaat de grootste gevolgen hebben en waarbij de opdrachtnemer invloed heeft op de beheersing. Het risicodossier en toetsplan worden gedurende de looptijd van het contract actueel gehouden, volgens afspraken (over methode en frequentie) in het contractbeheersplan. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst De verdieping De theorie Het inkoopproces Beleid en strategie Inleiding

17 Hoog Toetsfrequentie Systeem Proces Product Illustratie 5: schematische weergave van de theoretisch ideale mix van toetsen over de looptijd van het project Start project Toetstrategie Door een mix van toetsen stelt de opdrachtgever vast of het integraal projectmanagement van de opdrachtnemer functioneert en de gegevens van de opdrachtnemer betrouwbaar zijn. De basis voor de invulling van de mix van toetsen is de toetsstrategie. De opdrachtnemer moet bij de start van het project laten zien dat zijn projectmanagement conform de beschreven plannen verloopt. De opdrachtgever toetst met systeemtoetsen of het projectmanagement van de opdrachtnemer op de risicovolle onderdelen functioneert. Zodra de opdrachtnemer processen uitvoert die voor de opdrachtgever risicovol zijn, worden procestoetsen uitgevoerd. Het is de bedoeling om (als dit het meest efficiënt is) zo veel mogelijk op systeem- en procesniveau te toetsen. De toetsfrequentie kan (na actualisatie van risicodossier en toetsplan) worden afgebouwd als de toetsresultaten veel positieve bevindingen opleveren. Als ze vooral negatieve bevindingen opleveren, moet er tijdig worden bijgestuurd, zodat de strategie zo veel mogelijk kan worden gehandhaafd. Het bijsturen houdt in dat de opdrachtnemer wordt aangesproken op de beheersing van zijn proces en systeem en dat er betalingen worden opgeschort, zodra blijkt dat de beheersing onvoldoende is. betalingsschema aanpassen betalingsschema betalen, tenzij herijken betalingsschema Illustratie 6: relatie tussen het toets- en betaalproces bevindingen/ tekortkomingen uitvoering toetsen kwaliteitssysteem opdrachtnemer betaalproces toetsproces risicoanalyse samenstellen toetsmix/toetsplan De beheersing levert de volgende twee gegevensstromen op: registraties voortvloeiend uit het project- en kwaliteitsmanagementsysteem van de opdrachtnemer voor het betreffende project; registraties voortvloeiend uit de uitgevoerde toetsen van de opdrachtgever. Op basis van deze gegevensstromen wordt aangetoond dat de opdrachtnemer wel/niet een bepaald gedeelte van het werk heeft geleverd, zoals is overeengekomen. Op de volgende pagina staat een schematische weergave van het proces verloop. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

18 Start ON Start OG Inleiding Aanbieding Risicoanalyse en -register Overeenkomst Risicoanalyse en -dossier Gunning Opstellen concept projectmanagementplan Opstellen projectmanagementplan Afstemoverleg risico s en beheersing Opstellen toetsplan Accepteren projectmanagementplan Beleid en strategie Opstellen onderliggende plannen Ontwerpen, verifiëren/ uitvoeren, keuren en registreren Afstemoverleg risico s en beheersing Actualiseren risicodossier Ja Accepteren onderliggende plannen Actualiseren toetsplan Het inkoopproces Vaststellen afwijking? Ja Nemen passende maatregel Hertoets noodzakelijk? Nee Toetsen Nee Nee Bereiken termijn? Ja Informeren opdrachtgever Ja Vaststellen tekortkoming? Nee De theorie Verzoeken om prestatieverklaring (PV) Afgeven prestatieverklaring Verzenden factuur Nee Voldoet aan voorwaarden PV? Ja Versturen PV en archiveren verantwoording De verdieping Einde Einde HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

19 Een kwestie van vertrouwen Luc Batterink, opdrachtgever Rijkswaterstaat Traditie Bij de praktijk van de contractbeheersing raak ik alleen betrokken in het geval dat er iets mis gaat. Wel spreek ik regelmatig met mensen op allerlei niveaus, opdrachtgevers en opdrachtnemers, over de nieuwe manier van werken. In de toepassing van systeemgerichte contractbeheersing is de een wat verder dan de ander. Wij vragen de markt werken zelf tot in detail te ontwerpen, wij vragen de markt het proces waarin het werk tot stand komt zelf vorm te geven en te beheersen. Dan breek je met een lange traditie waarin Rijkswaterstaat gewend is werken te realiseren, dan wel anderen met dat doel te regisseren. Uitleg We laten de teugels nu vieren, houden echter wel een vinger aan de pols. Dit vraagt om vertrouwen van de opdrachtgever in de opdrachtnemer. Dit vraagt ook om opdrachtnemers die dat vertrouwen niet beschamen. Er zijn inmiddels verschillende innovatieve projectcontracten gesloten, maar het gedachtegoed van systeem - gerichte contractbeheersing is niet altijd voor honderd procent in de praktijk verwerkt. Wat ik merk, is dat we snel veel van elkaar leren, maar dat het soms nodig is nog eens duidelijk van gedachte te wisselen over hetgeen we van elkaar verwachten. Prima, dan leg ik dat met plezier nog eens uit. Foto: Ad Hupkes HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

20 Instrumenten Voor systeemgerichte contractbeheersing is een aantal instrumenten beschikbaar. De instrumenten hebben de status van voorgeschreven kader. Alleen met onderbouwing mag hier van worden afgeweken. Inleiding De volgende negen modellen zijn beschikbaar: 1 Contractteksten in Vraagspecificatie deel 2 - De standaardteksten in Vraagspecificatie deel 2 (proceseisen) maken toepassing van systeemgerichte contractbeheersing mogelijk. 2 Contractbeheersplan In het model contractbeheersplan staan de uitgangspunten, de organisatie en de processen ten aanzien van contractbeheersing. 3 Toetsplan Het model toetsplan is een standaardtabel waarin, op basis van de geïdentificeerde risico s, onder andere toetsen en toetsaspecten worden benoemd. 4 Risicodossier Dit model geeft een standaardindeling voor het risicodossier. 5 Systeemtoets Een hulpmiddel ter voorbereiding van de systeemtoets. Het model systeemtoets is een checklist met daarop de te toetsen systeemonderdelen, subonderdelen en toetsaspecten. 6 Toetsverslag Een model toetsverslag waarop gebruikte documenten, bevindingen, conclusies en consequenties van de bevinding worden vastgelegd. Bij dit toetsverslag is een toelichting beschikbaar. 7 Overzicht openstaande tekortkomingen Een standaardtabel waarin de openstaande tekortkomingen kunnen worden geregistreerd. Dit overzicht dient als basis voor het document verantwoording prestatieverklaring. 8 Verantwoording prestatieverklaring - Een formulier waarop de verantwoording voor de prestatieverklaring wordt vastgelegd. Met dit formulier wordt de afgifte van de prestatieverklaring (conform model prestatieverklaring, bijlage a van de UAV-gc 2005) onderbouwd. Beleid en strategie Het inkoopproces De theorie 9 Monitoring en evaluatie Een beoordelingslijst waarmee het functioneren van systeemgerichte contractbeheersing op het project kan worden geëvalueerd. De verdieping Woordenlijst HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

21 Deze documenten dienen ingevuld c.q. gebruikt te worden, voor of na gunning. De volgorde van invullen staat hieronder aangegeven. A Voor de aanbesteding en gunning van het werk: 1 Contractbeheersplan 2 Risicodossier 3 Toetsplan (op hoofdlijnen) 4 Monitoring en evaluatie (eerste deel, op afgesproken tijdstippen) B Na de aanbesteding en gunning van het werk: 1 Risicodossier (dit moet worden geactualiseerd) 2 Toetsplan (nader invullen) 3 Systeemtoets (bij het voorbereiden van de systeemtoets) 4 Toetsverslag (tijdens en na het toetsen gebruiken) 5 Overzicht openstaande tekortkomingen (invullen na het toetsen, bij tekortkomingen) 6 Verantwoording prestatieverklaring (bij het onderbouwen van de prestatieverklaring) 7 Monitoring en evaluatie (tweede deel, op afgesproken tijdstippen) Specifiek: De volgende onderdelen moeten projectspecifiek worden gemaakt: 1 Toetsstrategie 2 Risicodossier 3 Toetsplan 4 Toetsaspecten Alle modellen zijn te vinden in het RWS contractenbuffet: Kijk daar ook naar dossier systeemgerichte contractbeheersing (SCB). HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

22 Het gewenste inzicht Sam de Visser, contractgemachtigde tunnels Swalmen en Roermond en brug over de Swalm (onderdeel project Rijksweg 73-Zuid) Inleiding Foto: Ad Hupkes Over toetsen Het contractbeheersplan is gaande de beheersing van het contract enkele malen bijgesteld. Bijvoorbeeld in de manier van toetsen. Zo bleek in de praktijk dat toetsers systeemtoetsen in de vorm van audits als een zwaar middel beschouwen. We hebben daarom het strikte onderscheid tussen de soorten toetsen laten varen en combineren diverse aspecten in één toets. Dat wil zeggen, als je een werkproces toetst, kun je ook keuringsregistraties en tekeningen op juistheid controleren. Je kunt checken of documenten goed worden beheerd en of er een tweedelijnscontrole heeft plaatsgevonden. Een procestoets met systeemaspecten leidt tot het gewenste inzicht: namelijk of het systeem van de opdrachtnemer betrouwbaar is. Zonder dat je telkens zware audits hoeft uit te voeren. Je moet natuurlijk wel goed plannen op welke onderdelen je toetst en of je de aandacht goed verdeelt. Dat is de verantwoordelijkheid van onze hoofdtoetser. Over grip Dat je via systeemgerichte contractbeheersing meer afstand neemt, wil niet zeggen dat je geen grip hebt op wat er gebeurt. Ten eerste houd je als opdrachtgever nog altijd goed in de gaten hoe het werk verloopt en zie je zelf ook wel waar knelpunten ontstaan. Dat wil zeggen, waar een afweging tussen tijd en kwaliteit moet worden gemaakt. Ten tweede, als het vertrouwen wordt beschaamd en wij gebreken constateren, dan zetten we de betaling stop. Dat het zo ver moet komen, is natuurlijk jammer, doeltreffend is het wel. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst De verdieping De theorie Het inkoopproces Beleid en strategie

23 4 Systeemgerichte contract - beheersing: de verdieping Dit hoofdstuk gaat dieper in op de praktijk van systeemgerichte contractbeheersing en enkele gerelateerde onderwerpen. We behandelen de contractstructuur en -voorwaarden, de eisen aan de opdrachtnemer, risicomanagement, de mix van toetsen, de opvolging van toetsen en het betalingsproces. A. Contractstructuur en -voorwaarden Contractstructuur Zoals eerder staat beschreven, is de UAV-gc 2005 van toepassing bij D&C- en E&C-contractvormen. Dit is het juridisch-administratieve kader van een contract. Onder de UAV-gc worden alle contracten die worden afgesloten op een vaste manier ingedeeld. Een contract bestaat uit een Basisovereenkomst, een Vraagspecificatie deel 1 (technische eisen, Wat) en een Vraagspecificatie deel 2 (proceseisen, Hoe), annexen, de UAV-gc 2005, de aanbieding van de opdrachtnemer, en alle documenten die namens of door de opdrachtnemer zijn geproduceerd in het kader van de werkzaamheden. Contractdocumenten Onderstaande documenten bevatten de rechten en plichten van de opdrachtgever en de opdrachtnemer die van kracht zijn, zodra zij een overeenkomst hebben gesloten: a de Basisovereenkomst inclusief de nota s van inlichtingen en het proces-verbaal van aanwijzing b de Vraagspecificatie (deel 1 en deel 2) c de bij de Vraagspecificatie gevoegde annexen: de vergunningen, ontheffingen, beschikkingen en toestemmingen die door de opdrachtgever worden verkregen; de planning; het acceptatieplan; het toetsplan ontwerpwerkzaamheden; de vrijkomende materialen; het overzicht van werkzaamheden die door nevenopdrachtnemers worden verricht, evenals de tijdstippen waarop zij worden uitgevoerd; de verrekening van wijzigingen van lonen, sociale lasten, prijzen, huren en vrachten; de stelposten; de bankgarantie; de verzekeringen; de geschillenregeling Raad van Deskundigen; de wijzigingen op de UAV-gc 2005 (RWS-specifiek). d de Uniforme Administratieve Voorwaarden voor geïntegreerde contractvormen (UAV-gc 2005) e de aanbieding f alle documenten die door of namens de opdrachtnemer zijn geproduceerd in het kader van de werkzaamheden, als deze ter kennis zijn gebracht van de opdrachtgever. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

24 Contractvoorwaarden De UAV-gc schept voorwaarden voor samenwerking, met duidelijk gescheiden verantwoordelijkheden. De opdrachtnemer is verantwoordelijk voor het kwaliteitsmanagement 1 van alle werkzaamheden, de resultaten van die werkzaamheden en de bijbehorende documenten. De opdrachtnemer legt een projectmanagementplan en eventuele onderliggende plannen (voor zover genoemd in het acceptatieplan) ter acceptatie voor aan de opdrachtgever. Met de acceptatie worden deze documenten onderdeel van het contract (zie kader sub f). De opdrachtnemer is verplicht om op verzoek van de opdrachtgever alle documenten en registraties te verstrekken waarnaar in het projectmanagementplan en onderliggende plannen wordt verwezen, als de opdrachtgever daarom vraagt. De opdrachtgever heeft de bevoegdheid om op de naleving van de overeenkomst door de opdrachtnemer toe te zien door te toetsen en te accepteren. Binnen Rijkswaterstaat wordt de toetsbevoegdheden ingevuld aan de hand van systeem-, proces- en producttoetsen. Wordt bij een van deze toetsen een tekortkoming vastgesteld, dan heeft de opdrachtgever de plicht de opdrachtnemer hierover schriftelijk te informeren, zodat deze zelf maatregelen kan treffen. Bij de invulling van de acceptatiebevoegdheid moet met terughoudendheid worden gehandeld, aangezien het de voortgang van het proces van de opdrachtnemer beïnvloedt. Bovendien worden we (afhankelijk van de door ons ingebrachte deskundigheid en diepgang van de toets ter acceptatie) mede verantwoordelijk voor de gevolgen van fouten in zaken die al geaccepteerd zijn. Ontwerpfase De ontwerpfase is geheel de verantwoordelijkheid van de opdrachtnemer. In die fase willen we in principe geen acceptatiemomenten inbouwen. Wij zijn alleen bevoegd om het volgende te toetsen: de kwalificaties van hulppersonen die de opdrachtnemer wil inschakelen voor de ontwerpwerkzaamheden; de ontwerpdocumenten die uit die werkzaamheden voortkomen. Kiezen we ervoor om op deze twee punten te toetsen, dan moet dat nadrukkelijk zijn opgenomen in het toetsingsplan ontwerpwerkzaamheden 2, op basis waarvan wordt getoetst. Rijkswaterstaat is ook altijd bevoegd om de kwaliteitsborging van de ontwerpwerkzaamheden te toetsen. We bekijken dan of dit gebeurt volgens het projectmanagementplan (en de onderliggende plannen) en de overige eisen die, gelet op de aard en de inhoud van de overeenkomst, aan de kwaliteitsborging worden gesteld. De opdrachtgever is niet verplicht gebruik te maken van zijn toetsingsbevoegdheid. De verdieping De theorie Het inkoopproces Beleid en strategie Inleiding 1 UAV-gc 2005 spreekt van kwaliteitsborging, Rijkswaterstaat gebruikt de overkoepelende term kwaliteitsmanagement. 2 Let op: het toetsingsplan ontwerpwerkzaamheden beschrijft de te toetsen kwalificaties van hulppersonen en ontwerpdocumenten. Het is een ander document dan het toetsplan dat wordt gebruikt bij systeemgerichte contractbeheersing, de bijlage bij het contractbeheersplan waarin de geplande mix van toetsen wordt vastgelegd. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

25 Uitvoeringsfase De opdrachtnemer is in de uitvoeringsfase verplicht om de volgende zaken aan ons ter acceptatie voor te leggen (voor zover dit in het acceptatieplan is opgenomen): a documenten; b zelfstandige hulppersonen die de opdrachtnemer wenst in te schakelen voor de uitvoering van de werkzaamheden; c werkzaamheden; d resultaten van werkzaamheden; e wijzigingen die de opdrachtnemer wenst (deze staan niet in het acceptatieplan beschreven). De opdrachtgever is, net als in de ontwerpfase, altijd bevoegd te toetsen of de kwaliteitsborging van de uitvoeringswerkzaamheden plaatsvindt in overeenstemming met het (kwaliteits)managementsysteem van de opdrachtnemer, het projectmanagementplan (en onderliggende plannen) en de overige eisen die, gelet op de aard en de inhoud van de overeenkomst, aan die kwaliteitsborging kunnen worden gesteld. De opdrachtgever is ook nu niet verplicht gebruik te maken van zijn toetsingsbevoegdheid. Keuringsplan uitvoeringswerkzaamheden Voorzover dat in het acceptatieplan is vastgelegd, legt de opdrachtnemer een keuringsplan uitvoeringswerkzaamheden ter acceptatie voor aan de opdrachtgever. Met de resultaten van de keuringen die in deze plannen zijn opgenomen, moet de opdrachtnemer aantonen dat hij aan de eisen voldoet die voortvloeien uit de overeenkomst. De opdrachtnemer heeft na de uitvoering van een keuring uit zijn keuringsplan de resultaten beschikbaar en maakt deze (in het geval van acceptatie) schriftelijk kenbaar aan de opdrachtgever. Daarbij dient te worden vermeld: op welk onderdeel van de werkzaamheden de keuring betrekking heeft; wie de keuring heeft uitgevoerd; de datum en het tijdstip waarop de keuring is uitgevoerd; of het resultaat van de uitgevoerde keuring beantwoordt aan de eisen die volgens de overeenkomst aan de werkzaamheden zijn gesteld. Bijwoon- en stoppunten In het toetsingsplan ontwerpwerkzaamheden en acceptatieplan kunnen we voor gunning al bepalen welke onderdelen ter toetsing en acceptatie van de opdrachtgever zijn. Worden deze lopende het project aangepast, dan leidt dit tot een contractwijziging. Een acceptatieplan is immers één van de annexen van de overeenkomst. Om ervoor te zorgen dat er geen contractwijziging hoeft plaats te vinden, biedt de UAV-gc de mogelijkheid tot het opnemen van bijwoon- en stoppunten in het keuringsplan van de opdrachtnemer. Dit moet plaatsvinden uiterlijk op het moment waarop acceptatie van een keuringsplan plaatsvindt. Hiermee wordt de toets- en acceptatiebevoegdheid van de opdrachtgever dus uitgebreid. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

26 Cruciale punten Bijwoon- en stoppunten zijn momenten in de contractbeheersing waarbij werkzaamheden worden verricht die voor de opdrachtgever zo cruciaal zijn dat hij zelf aanwezig wil zijn om een toets uit te voeren. Een bijwoonpunt is een moment tijdens uitvoering waarbij de opdrachtgever zelf wil toetsen of de wijze waarop de werkzaamheden worden uitgevoerd en de resultaten van die werkzaamheden beantwoorden aan de eisen van de overeenkomst. Een stoppunt is een moment tijdens de uitvoering waarbij de opdrachtnemer het werk stil legt en de opdrachtgever werkzaamheden, resultaten van werkzaamheden of resultaten van keuringen ter acceptatie voorlegt. De opdrachtnemer informeert de opdrachtgever vooraf schriftelijk over het tijdstip waarop een stop- of bijwoonpunt wordt bereikt, tenzij in overleg tussen partijen een termijn is overeengekomen. Vervolgens legt de opdrachtnemer de werkzaamheden en/of de resultaten van die werkzaamheden die in het keuringsplan worden genoemd voor. Ook de resultaten van keuringen van werkzaamheden, waarmee het voldoen aan de eisen wordt aangetoond, kunnen bij een stop- of bijwoonpunt onderdeel van een toets of acceptatie zijn. De opdrachtgever besluit op het moment dat een stop- of bijwoonpunt wordt gemeld of hij ook werkelijk gebruik wil maken van zijn toets- of acceptatiebevoegdheid. Dit doet hij op basis van zijn geplande toetsen en eventuele eerdere bevindingen. Kiest de opdrachtgever ervoor geen gebruik te maken van zijn toetsbevoegdheid, dan informeert hij de opdrachtnemer hierover. Let op: in het geval van een acceptatie (c.q. stoppunt) wordt dan geaccepteerd zonder te toetsen. Dit moet in de schriftelijke acceptatie kenbaar worden gemaakt. Inleiding Beleid en strategie Het inkoopproces Voorbeeld stoppunt Voor het plaatsen van hoogspanningskabels in een wegberm geldt een minimale ingraafdiepte. Omdat deze ingraafdiepte cruciaal is, kan de opdrachtgever wensen het resultaat van het werk van de opdrachtnemer dagelijks te toetsen (meting diepteligging van de kabel en deze vergelijken met de keuringsresultaten van de opdrachtnemer). De opdrachtgever (contractmanager) moet dan eerst toestemming geven voordat de opdrachtnemer de gleuven dicht kan gooien. Verschijnt de toetser bij een stoppunt niet op het afgesproken tijdstip, dan loopt Rijkswaterstaat de kans dat de opdrachtnemer een claim indient voor stagnatiekosten. De theorie Voorbeeld bijwoonpunt Als de opdrachtgever het resultaat niet dagelijks wil toetsen, kan worden afgesproken dat de opdrachtnemer hem informeert over de dagen waarop hij bezig is met het ingraven van de kabels. De opdrachtnemer kan dan zelf bepalen wanneer hij de toets wil uitvoeren. De opdrachtnemer hoeft bij een bijwoonpunt niet te wachten met het dichtgooien van de kabelgleuven. Het is aan de opdrachtgever dat hij zijn geplande toets(en) op tijd uitvoert. Het gaat er bij een bijwoonpunt om dat de opdrachtgever de mogelijkheid heeft om een oordeel te kunnen vormen over de kwaliteitsborging. Het gaat dus niet om het verkrijgen van een acceptatie. De verdieping Opmerking: Gelet op het principe van systeemgerichte contractbeheersing om te toetsen op de kwaliteitsborging en in mindere mate op producten, dienen stoppunten alleen te worden benoemd als resultaten achteraf niet meer (of met extra kosten) te toetsen zijn. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

27 B. Eisen aan de opdrachtnemer: IPM en kwaliteits - management Kwaliteitsmanagement in de Vraagspecificatie In de Vraagspecificatie deel 2 worden enkele specifieke eisen gesteld aan het projectmanagement en de kwaliteitsborging (Hoofdstuk 8.1, Vraagspecificatie deel 2) waarmee we willen bereiken dat de opdrachtnemer product- en proceskwaliteit op beheerste, expliciete en transparante wijze realiseert. Ook moet de opdrachtnemer de geleverde proces- en productkwaliteit meten, analyseren, verbeteren en eventuele afwijkingen beheersen. Hanteren (kwaliteits)managementsysteem De opdrachtnemer moet gedurende de looptijd van de opdracht beschikken over een kwaliteitssysteemcertificaat op basis van de norm ISO 9001:2000 dat van toepassing is op de aard van de werkzaamheden. In geval van een aannemerscombinatie zijn er aanvullende eisen aan het toe te passen (kwaliteits)managementsysteem. Medewerking verlenen aan audits en toetsen van de opdrachtgever De opdrachtnemer moet aan de opdrachtgever medewerking verlenen om systeem-, proces- of producttoetsen te (laten) verrichten. Hiervoor moet hij de benodigde documenten en informatie leveren. Hierbij hebben wij als opdrachtgever (eventueel begeleid door experts) toegang tot alle bouw- en werkterreinen, fabrieken, werkplaatsen en loodsen, zelfstandige hulppersonen en leveranciers van de opdrachtnemer. Plannen en uitvoeren audits De opdrachtnemer moet minimaal een keer per kwartaal een interne audit uitvoeren op het werk. De opdrachtnemer dient audits te plannen, uit te voeren en te rapporteren. Vervolgens moeten maatregelen ter verbetering worden getroffen. Identificeren en registeren van afwijkingen De opdrachtnemer dient afwijkingen te identificeren en te rapporteren om vervolgens (voor het afronden van het werkpakket) maatregelen ter verbetering te treffen (correctieve en corrigerende maatregelen). Deze verplichting geldt ook voor negatieve bevindingen en tekortkomingen die door de opdrachtgever zijn geconstateerd en gemeld zijn aan de opdrachtnemer. Als een afwijking niet gecorrigeerd kan worden en van blijvende aard is, moet de opdrachtnemer een wijzigingsvoorstel indienen. Dit kan een contractwijziging inhouden. Verbeteringen doorvoeren en bewaken De opdrachtnemer dient een directiebeoordeling voor het project uit te voeren om de effecten van de getroffen corrigerende en preventieve maatregelen te beoordelen en, indien nodig, maatregelen te treffen voor het doorvoeren van gewenste verbeteringen. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

28 Continu verbeteren Voor elk bedrijfsproces wordt de Deming-cirkel doorlopen om zo tot optimalisatie van het proces te komen en het resultaat van het proces te maximaliseren. Deze cyclus eindigt dus niet na één doorloop. De Deming- cirkel stelt immers een continu verbeterproces voor. Inleiding VRAAG/ANTWOORD Plan: De planningsfase. De doelstellingen voor het proces Plan worden SMART gedefinieerd. Er moet duidelijk worden wat de gewenste resultaten van het proces zijn. Daarnaast is er aandacht voor de randvoorwaarden (beschikbaarheid middelen) en de belangen van de betrokkenen. Act Proces Do: Het proces wordt uitgevoerd en de resultaten worden gemeten. Do Check: De bereikte resultaten worden vergeleken met de doelstellingen. Act: Indien nodig worden acties uitgezet om de Check resultaten te verbeteren. Vervolgens herhaalt de cyclus zich. De bedoeling is dat het doorlopen van de cirkel leidt tot Illustratie 8: Deming-cirkel continue verbetering van de resultaten. De cyclus zorgt daarmee voor zowel kwaliteitsborging als kwaliteitsverbetering. Als het kwaliteitssysteem van de opdrachtnemer onvoldoende functioneert, moeten we dan toch op processen gaan toetsen? Is er een vangnet waar we op terug kunnen vallen? Als uit systeemtoetsen blijkt dat het systeem van de opdrachtnemer onvoldoende functioneert, is het niet zinvol om uitgebreid op processen en producten te toetsen. Het is zeker niet de bedoeling dat wij als opdrachtgever de keuring van de opdrachtnemer gaan overnemen om zo het voldoen aan de eisen vast te stellen. Het bijsturen van de opdrachtnemer doen we in dit geval door het rapporteren van negatieve bevindingen, tekortkomingen en het opschorten van betalingen. Als het werk van de opdrachtnemer ondanks deze sancties niet verbetert, dan ligt het escaleren naar de opdrachtgever voor de hand. Uiteindelijk kan een ingebrekestelling en eventuele ontbinding van de overeenkomst als laatste optie overblijven. Integraal Projectmanagement Het integraal projectmanagement-model (IPM), zie illustratie 9, is ontwikkeld om infrastructurele projecten op een integrale wijze beheerst te realiseren. De managementactiviteiten zijn gegroepeerd in projectmanagement (omgevingsmanagement, technisch management en inkoopmanagement), projectbeheersing (risicomanagement, planningsmanagement, configuratie - management en financieel management) en projectondersteuning (kwaliteitsmanagement, V&G-management, organisatiemanagement en document management). HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst De verdieping De theorie Het inkoopproces Beleid en strategie

29 Opdrachtgever Omgeving/ stakeholders omgevingsmanagement Projectmanagement technisch management inkoopmanagement Markt Projectbeheersing risico - plannings - configuratie - financieel management management management management Projectondersteuning kwaliteits - management V&Gmanagement organisatie - management document - management Illustratie 9: IPM-model. Op basis van dit model, dat door Rijkswaterstaat wordt toegepast, zijn de eisen aan de opdrachtnemer over integraal projectmanagement geformuleerd. De opdrachtnemer is door de eisen uit Vraagspecificatie deel 2 verplicht integraal projectmanagement op het project toe te passen. De opdrachtnemer beschrijft in een projectmanagementplan en eventuele onderliggende plannen de werking van integraal projectmanagement. Het projectmanagementplan en daarvan afgeleide plannen kunnen worden beschouwd als het kwaliteitsplan, zoals is beschreven in de bepalingen van de UAV-gc Documenten en registraties Met de introductie van technisch management en werkpakketmanagement in de Vraagspecificatie deel 2 wijzigt de structuur van de plannen. Zo worden verificatie- en keuringsplannen niet meer als onderdeel van kwaliteitsmanagement gezien, maar als onderdeel van het technisch management. Vroeger In het verleden werd vanuit het kwaliteitsmanagement van een opdrachtnemer gevraagd om een projectkwaliteitsplan met verschillende deelkwaliteitsplannen voor de ontwerp-, de uitvoerings- en onderhoudsfase. In de ontwerpfase maakte de opdrachtnemer een verificatieplan. In dit plan werd beschreven hoe en wanneer verificaties werden uitgevoerd, waarmee de opdrachtnemer het voldoen van het ontwerp aan de eisen uit de overeenkomst aantoonde. In de uitvoerings- en eventuele onderhoudsfase maakte de opdrachtnemer een keuringsplan. Hierin stond beschreven hoe en wanneer de opdrachtnemer zijn keuringen uitvoerde waarmee hij aantoonde dat het product aan de eisen van de overeenkomst voldeed. De uitkomsten van de verificaties, keuringen en testen nam de opdrachtnemer op in verificatie-, keuring- en testrapporten en een bovenliggende verificatienota. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

30 ontwerpfase uitvoering onderhoudsfase Kwaliteitsmanagement Inleiding Projectkwaliteitsplan Deelkwaliteitsplan Deelkwaliteitsplan Deelkwaliteitsplan Werkplan Werkplan Werkplan Verificatieplan Keurings- en testplan Keurings- en testplan Verificatienota & verificatie-, keurings- en testrapporten Beleid en strategie Illustratie 10: traditionele structuur kwaliteitsdocumenten van de opdrachtnemer Rijkswaterstaat vraagt de opdrachtnemer om vóór de start van de werkzaamheden de van toepassing zijnde procedures in een plan ter acceptatie in te dienen. Hoe de opdrachtnemer het projectmanagementplan en eventuele onderliggende deelplannen noemt en inricht, mag hij zelf bepalen. Welke indeling de opdrachtnemer ook kiest, de structuur van de plannen en de onderliggende relaties met de functionele eisen (eisenboom) en de vertaling daarvan naar objecten (objectenboom) en activiteiten moet duidelijk zijn beschreven. De opdrachtnemer kan ervoor kiezen om alle procedures in één plan vast te leggen of om per werkpakket een apart werkplan te maken of om werkplannen te clusteren. De Work Brakedown Structure (onderverdeling van het werk in werkpakketten) kan worden gebruikt als een kapstok om plannen, documenten en registraties aan op te hangen. Het onderstaande figuur maakt dit inzichtelijk: Het inkoopproces De theorie (Kwaliteits)managementsysteem Projectmanagementplan Specificatie Verificatieplan Deelplan werkpakket Deelplan werkpakket Deelplan werkpakket Relevante procedures en documenten Technisch Management per object Ontwerpnota Verificatienota Verificatie rapport Keuringsplan Keuringsrapport De verdieping As Built Gegevens Illustratie 11: voorbeeld indeling kwaliteitsdocumenten, waarbij de Documenten Technisch Management per object Work Brakedown Structure is gebruikt voor het uitwerken van deelplannen. Elk deelplan bevat een werkpakketbeschrijving, relevante procedures en, per object, documenten van het technisch management. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

31 Een adviserende rol Kees Scheurwater, projectmanager Verbreding A2 tussen Everdingen en Deil Over zijn rol Als projectmanager beoordeel ik de opzet en inhoud, inclusief risicoanalyse, van het contractbeheersplan dat is opgesteld door de contractmanager. In overleg met de opdrachtgever krijgt de contractmanager een budget toegewezen. Aan de opdrachtgever leg ik verantwoording af over de voortgang en de kosten van het project. Vragen De contractbeheersing is primair de verantwoordelijkheid van de contractmanager. In sommige gevallen raak ik betrokken. Op verzoek van de aannemer kan de Vraagspecificatie en/of het contract worden aangepast. Het komt ook voor dat het ontwerp wel voldoet aan de Vraagspecificatie, maar niet datgene is wat Rijkswaterstaat ervan verwacht. Aanpassingen van het contract en/of de vraagspecificatie zijn voorbehouden aan de opdrachtgever. Bij dergelijke besluiten heb ik een adviserende rol. Foto: Ad Hupkes HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

32 C. Risicomanagement Risicomanagement is een onderdeel van integraal project mana gement. Het maakt de onzekerheden in een project op gestruc tureerde wijze inzichtelijk en expliciet, en reikt hulpmiddelen aan om deze onzekerheden op proactieve wijze te beheersen. De risicoinformatie die van invloed is op het risicomanagement verandert door de verschillende fasen van infrastructuur- en onderhoudsprojecten heen. Ook zullen belangrijke verschuivingen optreden tussen de drie belangrijkste grootheden waarop risicobeheersing in het project nodig is: tijd, geld, kwaliteit (scope). Risicomanagement als continu proces Risicomanagement is zowel een taak van de opdrachtnemer als van de opdrachtgever en bestaat uit de volgende activiteiten: identificeren, kwantificeren, vastleggen en toedelen van risico s; bepalen van de beheersmaatregelen en het managen van die maatregelen; bepalen van de uit te voeren controles en controleaspecten/toetsen en toetsaspecten; monitoren en evalueren van het risicomanagement, inclusief de daarbij gedefinieerde beheersmaatregelen. Evalueren beheersmaatregelen Uitvoeren risicoanalyse (RISMAN-methode) Evalueren beheersmaatregelen Uitvoeren beheersmaatregelen Kiezen beheersmaatregelen Illustratie 12: het continue proces van risico management In principe wordt van twee afzonderlijke risicodossiers uitgegaan, een van de opdrachtgever en een van de opdrachtnemer. De theorie Het inkoopproces Beleid en strategie Inleiding In deze paragraaf beschrijven we de rol van risicomanagement in relatie tot contractbeheersing. Contractbeheersing is immers gericht op het op een acceptabel niveau houden van risico s voor de opdrachtgever. De verantwoordelijkheid voor het beheersen van deze contractrisico s ligt grotendeels bij de opdrachtnemer. De opdrachtgever draagt wel de verantwoordelijkheid voor de gevolgen als een ongewenste gebeurtenis zich voordoet. We hebben het dan met name over gevolgen voor: veiligheid; bereikbaarheid/beschikbaarheid; financiën; keteneffect op andere relevante projecten; imago van Rijkswaterstaat. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE De verdieping Woordenlijst

33 Risicomanagement bij de opdrachtgever De opdrachtgever bewaakt de project- en contractrisico s in een risicodossier (vaak in de vorm van een database). De opdrachtnemer bewaakt gedurende alle fasen van het werk de geïdentificeerde risico s in een risicoregister. Onderstaande figuur geeft aan welke risico s uit de database van de opdrachtgever input zijn voor de contractbeheersing. Risicoregister ON Risicodossier project OG ON ON OG OG OG Geen mogelijk (rest)gevolg voor OG Mogelijke (rest)gevolgen voor OG Contract (ON invloed op beheersing) Contract (ON geen invloed op beheersing) Project Input contractbeheersing Illustratie 13: selectie uit het project-risicodossier dat relevant is voor de contractbeheersing Bij het opstellen van de overeenkomst en het contractbeheersplan wordt een risicoanalyse uitgevoerd. De resultaten hiervan worden opgenomen in het model risicodossier. In dit model worden de risico s en de beheersmaatregelen tijdens de uitvoering van het contract benoemd. De beheersmaatregelen van de opdrachtnemer (op te stellen en te accepteren plannen) en die van de opdrachtgever (toetsen en toetsaspecten) worden er in opgenomen. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

34 Inleiding Illustratie 14: model risicodossier De risico s in de database zijn in te delen in standaard en bijzonder. De standaardrisico s (bijvoorbeeld het niet functioneren van de kwaliteitsborging, het niet naleven van de planning, en diverse technische ontwerp/uitvoeringsrisico s) zijn opgenomen in het model risicodossier. De bijzondere risico s zijn de risico s die bij de aard en omvang van het project en de lokale situatie horen. Deze risico s moeten door het project aan het risicodossier worden toegevoegd. Het risicodossier moet, indien nodig, op bepaalde momenten worden geactualiseerd: na het afstemmingsoverleg met de opdrachtnemer; bij het accepteren van het projectmanagementplan en onderliggende plannen van de opdrachtnemer; bij het afronden van een toetsperiode of direct naar aanleiding van de bevindingen van een toets. Het risicodossier is het uitgangspunt voor het bepalen van de toetsen en toetsaspecten in het toetsplan. Gedurende de looptijd van de overeenkomst is het risicodossier de basis voor het toetsplan. Met het risicodossier moet uit te leggen zijn waarom gekozen is voor een bepaalde toetsmix met bijbehorende toetsaspecten. In principe kunnen alle geïdentificeerde risico s uit de database, die input zijn voor het toetsproces, worden omgezet in toetsaspecten. Op welke wijze hiermee wordt omgegaan, kan per project verschillen. Afhankelijk van de categorie-indeling (kans x gevolg) kan met een risicoclassificatie (score) worden aangegeven bij welke classificatie minimaal één toets wordt ingepland. Op de volgende pagina s staan twee voorbeelden van projectspecifieke risicoclassificatie. De verdieping Beleid en strategie Het inkoopproces De theorie Woordenlijst HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

35 CATEGORIE KANS GEVOLG IN TIJD GEVOLG IN GELD GEVOLG IN VEILIGHEID GEVOLG IN KWALITEIT GEVOLG IN OMGEVING Veilig Eis wordt gehaald ,5% < 1 WEEK < Lichte blessure Onzicht - baar / Reparabel Belevingshinder Lokale overlast voor beperkte duur 2 0,5-5% 1-4 WEKEN Licht gewond Reparabel / Reparatie zichtbaar Weken overlast Lichte schade % 4-12 WEKEN Zwaar gewond Afwijking niet reparabel Nacht/avond overlast Omvangrijke schade Overlast gezondheid % WEKEN Blijvend letsel Blijvend functie - verlies Schade met neveneffecten Evacuatie 1-3 dagen Omzetderving 1-3 maanden 5 > 50% > 52 WEKEN > WAO. Dodelijk letsel Afwijking niet acceptabel Instortingsgevaar Evacuaties > 3 dagen Sluiting, omzetderving > 3 maanden Illustratie 15: voorbeeld waarbij risicoclassificatie bepalend is voor het uitvoeren van toetsen. Voor het gemarkeerde deel van de tabel moeten toetsen worden ingepland. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

36 Gevolg Kans Zeer klein Geld Tijd Kwaliteit Veiligheid Klein Geld Tijd Kwaliteit Veiligheid Serieus Geld Tijd Kwaliteit Veiligheid Groot Geld Tijd Kwaliteit Veiligheid Zeer groot Geld Tijd Kwaliteit Veiligheid Komt zelden of nooit voor 0-1% Onwaar - schijnlijk 1-5% Kans bestaat, niet groot 5-10% Er is een reële kans 10-25% Grote kans >25% Inleiding Beleid en strategie Het inkoopproces Illustratie 16: voorbeeld waarbij risicoclassificatie bepalend is voor het uitvoeren van toetsen. Voor het gemarkeerde deel van deze tabel moeten toetsen worden ingepland. Risicomanagement bij de opdrachtnemer Ook de opdrachtnemer is verplicht risicomanagement toe te passen (zie Vraagspecificatie deel 2). De opdrachtnemer dient de risico s voor het ontwerp te identificeren en de risico s voor het uitvoeren van de werkzaamheden (met gevolgen voor bijvoorbeeld productkwaliteit, veiligheid en gezondheid en omgeving). Voor de geïdentificeerde risico s (inclusief de door de opdrachtgever aangedragen risico s) moet de opdrachtnemer beheersmaatregelen treffen. Deze beheersmaatregelen worden verwerkt in het projectmanagementplan (PMP) en de onderliggende plannen van de opdrachtnemer. Afstemmen met de opdrachtnemer In geplande afstembijeenkomsten wordt informatie uitgewisseld over de contractrisico s en beheersmaatregelen. Hierna passen opdrachtnemer en opdrachtgever, indien nodig, hun risicodossier aan. Aandachtspunten tijdens het afstemmingsoverleg zijn: inzicht in risico s (oorzaken en gevolgen) verduidelijken; geen verantwoordelijkheden overnemen; niet over oplossingen onderhandelen; zelf beheersmaatregelen treffen in de vorm van toetsen. De theorie De verdieping HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

37 VRAAG/ANTWOORD Hoe moet worden omgegaan met de spanning tussen de SCB-systematiek en opdrachtgeverbelangen (bijvoorbeeld als onder druk van de planning en politieke mijlpalen de toepassing van het kwaliteitsmanagement van de opdrachtnemer in het gedrang komt)? Dit dilemma kan worden voorkomen door een goede planning en voorbereiding aan zowel opdrachtgever- als opdrachtnemerzijde. In conflict - situaties kan worden geëscaleerd aan de intern opdrachtgever, die de verschillende belangen afweegt. Hierbij is het van belang dat de interne opdrachtgever in lijn handelt met de gekozen strategie van contact - beheersing en dat hij bij het maken van keuzes de belangen en geloofwaardigheid van zijn contractbeheersteam niet uit het oog verliest. Als het belang van de interne opdrachtgever boven dat van het contract - beheersteam en de SCB-systematiek uitgaat, dient dit goed te worden gecommuniceerd met de opdrachtnemer en de project- en contract - manager. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

38 KOSMOS: beheerst omgaan met risico s Marcel Polet Inleiding Foto: Hans Sodenkamp, RWS Noord-Holland Als Rijkswaterstaat binnen drie jaar grootschalig onderhoud aan de Nederlandse kunstwerken wil laten uitvoeren, dan bieden contracten per kunstwerk geen uitkomst. Daarom is voor het KOSMOSproject besloten om een overkoepelend E&C-contract toe te passen op basis van de UAV-gc 2005, met systeemgerichte contractbeheersing als beheersingsstrategie. Voor het project zijn op tien gebieden tien contracten afgesloten. Er zijn drie soorten contracten: een nat, een droog/nat- en een hogesterktebeton-contract. Marcel Polet van de Bouwdienst zorgt dat de verschillende contractteams van KOSMOS systeemgerichte contractbeheersing op de juiste manier toepassen. Het principe van systeemgerichte contractbeheersing is vrij simpel, vertelt Polet. De opdrachtnemer toont aan, wij toetsen. Hij toont aan dat hij zijn werkzaamheden heeft gedaan zoals hij vooraf had aangegeven, wij Beleid en strategie Het inkoopproces Woordenlijst De verdieping De theorie HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

39 toetsen op risicovolle punten of dat zo is. Waar alle contractteams voor moeten waken, is dat zij bijvoorbeeld bij het constateren van een tekortkoming zelf de oplossingen verzinnen. Houd bij systeemgerichte contractbeheersing altijd in het achterhoofd wie voor het verhelpen van dat probleem verantwoordelijk is. TIS De contracten bestaan uit een fixed price- en een alliantiegedeelte. Omdat de vereiste mate van onderhoud vaak pas tijdens de werkzaamheden blijkt, zijn risico s moeilijk in te schatten. Risico s die vooraf af te dekken zijn, komen in het fixed price-gedeelte van het contract. In het alliantie-gedeelte komen onvoorziene risico s met een extra prijskaartje terecht. Aan het beheersen van risico s wordt binnen KOSMOS dus extra veel aandacht besteed. Polet: Daarom is besloten om naast het contractbeheersteam van Rijkswaterstaat een onafhankelijk toetsteam in te schakelen: de technical inspection service (TIS). Zowel Rijkswaterstaat als TIS voert een risicoscan uit, zodat risico s zoveel mogelijk in kaart zijn gebracht. Wil Rijkswaterstaat een toets laten uitvoeren die al door de TIS is gepland, dan vervalt de toets van Rijkswaterstaat. De TIS komt voort uit de verzekerde garantie. Verzekerings maat - schap pijen moeten in de toekomst garant staan voor het product en komen daarom met een eigen TIS. Het werken met een TIS wordt momenteel uitgeprobeerd in het KOSMOS-project. In dit geval betaalt Rijkswaterstaat de TIS zelf. De TIS bekijkt de grootste risico s op systeem-, proces- en productniveau. Kans klein, effecten groot Hoewel Rijkswaterstaat de uitvoering van het werk op afstand volgt, blijft de vinger aan de pols. Een gezamenlijke risicoanalyse door opdrachtgever en -nemer is een terugkerend onderdeel. De opdrachtnemer neemt de risico s, de oorzaken en de beheersmaatregelen die hij voor ogen heeft op in zijn risicodossier. Rijkswaterstaat toetst alleen op kritieke momenten. Loop je een groot risico, maar is het effect verwaarloosbaar, dan is een toets niet nodig, vertelt Polet. Loop je een klein risico, maar is het gevolg groot, dan moet dat risico worden weggenomen. Een voorbeeld: bij het schilderen van een kunstwerk kunnen ongelukken gebeuren. De kans is klein, maar mogelijkerwijs heeft een ongeluk fatale gevolgen. In zo n geval is een toets essentieel. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

40 D. Mix van toetsen Risico s die in kaart zijn gebracht, bepalen mede de mix van systeem-, procesen producttoetsen die ter voorbereiding van de contractbeheersing worden gepland. Deze mix wordt vastgelegd in het toetsplan. Het ideaalbeeld is dat met een systeemtoets de risico s op een zo hoog mogelijk niveau kunnen worden ondervangen, zodat bij proces- en producttoetsen geen zwaarwegende tekortkomingen meer worden gevonden. Het toetsplan is een levend document. De inhoud van het risicodossier en resultaten van toetsen kunnen leiden tot bijstelling van de mix en dus van het toetsplan. De frequentie van de update van het toetsplan hangt onder andere samen met de duur en de complexiteit van een project. Een update van eens per kwartaal is een redelijke frequentie. Invullen van het toetsplan Het contractbeheersplan is geautoriseerd door de interne opdrachtgever (conform de mandaatregeling van Rijkswaterstaat: de DG, de HID of een directeur Nat of Droog) en wordt volgens een model uit het contractenbuffet opgesteld: het model contractbeheersplan. Het toetsplan is in tegenstelling tot het contractbeheersplan (met daarin de toetsstrategie) een dynamisch document. Het risicodossier vormt daarvoor het uitgangspunt. Aanpassingen in het toetsplan volgen daarom altijd (indien nodig) na een aanpassing van het risico - dossier. Wijzigingen van het toetsplan binnen de kaders van het contractbeheersplan kunnen worden geautoriseerd door de contract- of projectmanager. Voor gunning De eerste opzet van het toetsplan wordt gemaakt voor de gunning. Hiervoor is een model beschikbaar in het RWS-contractenbuffet. De verdieping Inleiding Beleid en strategie Het inkoopproces De theorie Illustratie 17: model toetsplan HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

41 In het toetsplan kunnen vaak nog niet alle kolommen worden ingevuld. Op hoofdlijnen kan wel inzichtelijk worden gemaakt hoe de mix van toetsen is verdeeld over de fasen van het werk. De fasen uit het toetsplan die niet van toepassing zijn, worden verwijderd. In de kolom onderdeel komt het betreffende onderdeel uit de Vraagspecificatie of uit de beheersplannen van de opdrachtnemer te staan. In de kolom soort toets wordt vermeld of het om een systeem-, proces- of producttoets gaat. Als bekend is naar welk onderdeel van de beheersing bij de opdrachtnemer wordt gekeken, kan de kolom toetsaspect worden ingevuld. Bij aanleiding moet een verwijzing worden gemaakt naar een risico uit het risicodossier om het risicogestuurd toetsen aantoonbaar te maken. Tips voor het uitwerken van het toetsplan Algemeen (eenmalig): kies een structuur uit het model toetsplan; bepaal de periode waarop het toetsplan betrekking heeft; gebruik de decompositie in de ontwerp- en realisatiefase; kies voor de verdere invulling voor het volgen van de werkpakketten óf de fasering van de opdrachtnemer óf de structuur van het projectmanagementplan van de opdrachtnemer óf de planning van de opdrachtnemer. Inhoud: stel risicovolle onderdelen vast inclusief het risicovolle aspect; bepaal omvang, looptijd en herhaling; bepaal mate van beheersing door de opdrachtnemer aan de hand van geaccepteerde plannen; bepaal het toetsniveau en het toetsaspect. Uitgangspunten: leg het zwaartepunt op de systeem- en procestoets; maak gebruik van de beheersing en registratie door de opdrachtnemer; houd rekening met de betalingsregeling en de toets op het betalings criterium. NB: Het is niet de bedoeling om de geplande toetsen direct te koppelen aan eisen in de overeenkomst of aan (deel) producten. Een directe relatie tussen toetsen en risico s is wel essentieel. Na gunning Het toetsplan wordt nu steeds gedetailleerder ingevuld. Na het afstemmingsoverleg wordt het toetsplan eventueel bijgesteld vanwege nieuwe inzichten in de werkwijze, de risico s en de beheersmaatregelen die de opdrachtnemer neemt. Als het projectmanagementplan en eventuele deelplannen zijn geaccepteerd, moet het toetsplan voor de eerste toetsperiode passend worden gemaakt, met een planning van wanneer welke toets wordt uitgevoerd. Dit gebeurt op basis van de planning van de opdrachtnemer. Na de toets(periode) Als er naar aanleiding van de bevindingen van de toets reden is om het risicodossier bij te stellen, dan moet het toetsplan worden aangepast. In principe wordt dit na afloop van een toetsperiode (doorgaans vier weken) bekeken. Het toetsplan wordt aangepast aan het risicodossier. Als er tekortkomingen zijn geconstateerd, wordt een hertoets ingepland. Als het toetsplan door deze HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

42 aanpassingen afwijkt van de toetsstrategie moet er worden ingegrepen. In dat geval zal de projectorganisatie bekijken op welke wijze de beheersing moet worden voortgezet. Dit zal vaak leiden tot een aanpassing van de toetsstrategie en een herziening van de contractbeheersing. Om de toetsaspecten op systeemniveau te benoemen, kan gebruik worden gemaakt van het model voor de systeemtoets. Dit model wordt als checklijst gebruikt. Het functioneren van het kwaliteitsmanagement moet standaard worden opgenomen. Hierdoor worden bij elke systeemtoets vragen nagelopen als: hoe verloopt de registratie van afwijkingen?; worden afwijkingen geanalyseerd?; worden er passende maatregelen genomen?. Het is aan te bevelen om naast het onderdeel kwaliteitsmanagement ook risicomanagement, planningsmanagement en inkoopmanagement standaard op te nemen in een systeemtoets. Betaling op planning of voortgang brengt grote gevolgen voor planningsmanagement met zich mee. In de toetsmix zal in dat geval een zwaar accent liggen op het planningsmanagement bij de opdrachtnemer. E. Opvolging toetsen Systeem-, proces- en producttoetsen worden ingepland op basis van het toetsplan. Voor elke toets geldt dat deze wordt uitgevoerd op basis van informatie uit het risicodossier en resultaten van eerdere relevante toetsen. Een geplande toets en de scope daarvan moet altijd worden voorbereid. Welke onderwerpen worden getoetst en met welke diepgang (welke toetsaspecten)? Welke documenten en registraties zijn relevant? Welke medewerkers van de opdrachtnemer moeten bij de toets aanwezig zijn? Is het maken van een afspraak noodzakelijk? Hoeveel tijd hebben we nodig voor de uitvoering van de toets? Dit zijn allemaal belangrijke vragen. Aanpak systeemtoets De systeemtoets wordt uitgevoerd in de vorm van een gesprek met een voor het te toetsen onderdeel relevante medewerker. Bij een systeemtoets bepaalt de (hoofd)toetser vooraf de toetsaspecten aan de hand van de checklist model systeemtoets en relevante onderdelen van het projectmanagementplan. Ter voorbereiding wordt een vragenlijst, een lijst te controleren bewijsdocumenten en een planning voor het gesprek opgesteld. De toetsers hebben een haalplicht, de opdrachtnemer een brengplicht. Door het stellen van de juiste vragen moet de toetser een antwoord krijgen waaruit blijkt dat het kwaliteitsmanagement van de opdrachtnemer goed functioneert. De opdrachtnemer moet zijn antwoorden onderbouwen met bewijsdocumenten. Aanpak procestoets Bij een procestoets bezoekt de toetser het werk, en observeert en registreert of de opdrachtnemer het te toetsen werkproces uitvoert zoals hij dat in zijn projectmanagementplan en onderliggende plannen heeft beschreven. We HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst De verdieping De theorie Het inkoopproces Beleid en strategie Inleiding

43 beoordelen of de juiste activiteiten op het juiste moment door de juiste personen worden uitgevoerd. Hiervoor gebruiken we ter controle ook registraties van de opdrachtnemer. Verder is er de mogelijkheid om aan de contactpersoon van de opdrachtnemer aanvullende vragen te stellen. Aanpak producttoets Bij een producttoets levert de opdrachtnemer verificatie-, keurings- of testresultaten van een bepaald product aan. Vervolgens voert de toetser een eigen berekening of meting uit op dat product. Deze resultaten worden vervolgens vergeleken met de resultaten van de opdrachtnemer. Deze dienen met elkaar overeen te komen. De verschillende toetsen kunnen in de praktijk worden gecombineerd. Zo kan tijdens een procestoets tegelijkertijd een producttoets worden uitgevoerd. Dit levert tijdbesparing op bij de opdrachtgever en de opdrachtnemer. Bovendien kunnen de bevindingen van de verschillende toetsen elkaar versterken. Tips voor het uitvoeren van een toetsgesprek Opbouw van een interview: Introductie: kennismaking tussen toetser en getoetste; noem doel en achtergrond van de toets; noem de geplande tijdsduur; leg methode uit (het stellen van vragen, gebruik van documenten); maak afspraken over de verslaglegging. Kern: kies een insteek om het onderwerp te bespreken (bijvoorbeeld volgens de toetsprocedure of aan de hand van een concrete praktijksituatie); start met een open vraag, dit nodigt uit tot het geven van informatie; vraag door, vraag om nadere uitleg of toelichting; zoek onderbouwing of ontkrachting van het verhaal in beschikbare registraties; sluit af met een gesloten vraag (waarop alleen een ja- of nee-antwoordmogelijk is) op basis waarvan de conclusie getrokken kan worden of conform de referentie is gewerkt. Is er sprake van een positieve of negatieve bevinding?; vat de bevinding samen en controleer zo of de getoetste instemt met de conclusie; volgend onderwerp. Afronding: vat besproken onderwerpen en bevindingen samen; maak een vervolgafspraak (vertel op welke termijn het verslag en de vervolgmaatregelen volgen); dank voor tijd en medewerking. Denk bij het afnemen van een interview aan de volgende aandachtspunten: een professionele en zakelijke houding; zoek naar feiten en niet naar de bevestiging van uw mening of vooroordeel; stel geen suggestieve vragen of vragen waarin een antwoord besloten ligt; stel geen dubbele vragen (vraag in een vraag); voer geen of zeer beperkt discussie; onderhandel niet over te nemen maatregelen; geef geen adviezen. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

44 Toetsers De hoofdtoetser en de toetser hebben allebei hun eigen taken, maar delen wel dezelfde competenties. Zo zijn ze beiden samenwerkingsgericht, motiverend en flexibel. Daarnaast zijn zij communicatief vaardig en nieuwsgierig. Ook richten zij zich allebei op processen en bewaken daar de voortgang van. Hieronder volgt een overzicht van de taken van de hoofdtoetser en toetser. Taken hoofdtoetser: het (laten) uitvoeren van risicoanalyses en beoordelen van het integraal projectmanagement van de opdrachtnemer, en het kwaliteitsmanagement in het bijzonder; het op basis van de eigen ervaring en deskundigheid adviseren over de uit te voeren toetsen en toetsmomenten; het uitvoeren van toetsen en het opstellen van toetsverslagen; het opstellen van toets- en acceptatieadviezen; de coördinatie met betrekking tot ontwerp en uitvoering; het bewaken en bespreken van de voortgang met de opdrachtnemer; het maken van technische en omgevingsgerelateerde afspraken met de opdrachtnemer; het aansturen van toetsers (intern en extern) bij het uitvoeren en rapporteren van toetsen; het aansturen van de waarnemer en het verwerken van diens bevindingen. Taken toetser: het beoordelen van het integraal projectmanagement van de opdrachtnemer, en het kwaliteitsmanagement in het bijzonder; het uitvoeren van toetsen en het opstellen van toetsverslagen; het opstellen van toets- en acceptatieadviezen; het leveren van input voor het risicodossier; het (mede) bewaken en bespreken van de voortgang met de opdrachtnemer; het maken van technische en omgevingsgerelateerde afspraken met de opdrachtnemer(s); het verwerken van de bevindingen van de waarnemer; het (mede) beoordelen van afwijkingen en het opstellen van advies aan de hoofdtoetser. Bevindingen De bevindingen geven een beeld van het functioneren van het kwaliteitsmanagement, de beheersing van processen en de betrouwbaarheid van gegevens van de opdrachtnemer. Tijdens een toets worden de feiten (gegevens uit interview, observatie of meting) vergeleken met de referentie (de eisen uit het contract of daarvan afgeleide eisen in het projectmanagementplan of daarvan afgeleide plannen) en de bewijsdocumenten/registraties van de opdrachtnemer. Wanneer deze met elkaar overeenkomen, is er sprake van een positieve bevinding. Wijken ze van elkaar af, en heeft de opdrachtnemer dit zelf niet geconstateerd en beschreven in zijn afwijkingenregister, dan is er sprake van een negatieve bevinding. De verdieping De theorie Het inkoopproces Beleid en strategie Inleiding HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

45 Referenties Bevinding Feiten Bewijs Illustratie 18: bevindingendriehoek. Bij het rapporteren van de bevinding van een toets moeten zowel referentie (bijvoorbeeld eis in het contract of getoetste procedure), feiten (observaties of beschrijving van werkwijze of waarden van metingen of berekeningen) en bewijs (identificatie van beoordeelde registraties) worden beschreven. Hiermee wordt de bevinding zorgvuldig onderbouwd en is deze goed navolgbaar. De bevindingen van iedere toets moeten door de toetser worden vastgelegd op het model toetsverslag. Negatieve bevinding of tekortkoming Als de toetser een negatieve bevinding vaststelt, wordt deze door de contractmanager beoordeeld om vast te stellen of de bevinding dermate zwaar - wegend is dat deze als tekortkoming moet worden aangemerkt. Er is geen standaardlijst waarin beschreven staat welke negatieve bevinding een tekortkoming is. De contractmanager bepaalt dat mede op basis van zijn vakmanschap. Hij heeft wel enkele richtlijnen: als het onderliggende risico van de negatieve bevinding in de Top 10-risico s zit; als de negatieve bevinding op systeemniveau ligt; als de negatieve bevinding zich herhaalt en er dus sprake is van een trend. De richtlijnen voor het benoemen van tekortkomingen moeten worden beschreven in het contractbeheersplan. De afwegingen die leiden tot een tekortkoming worden vastgelegd in het toetsverslag. Wordt een negatieve bevinding een tekortkoming, dan wordt de reden voor dit besluit op het toetsverslag ingevuld. Vervolgens wordt de tekortkoming geregistreerd in de contractadministratie (overzicht tekortkomingen) en kan het toetsverslag worden vastgesteld door de gemachtigde van de opdrachtgever. Dit is over het algemeen de contractmanager. NB: Het constateren van tekortkomingen leidt mogelijk tot nieuwe risico s in het risicodossier. Om deze te beheersen, wordt het toetsplan eventueel aangepast. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

46 Toetsverslag Inleiding Volgnummer: Soort toets: Systeem/Proces/Product/Hertoets Onderdeel/Object:... Omschrijving toets:... Referentie gebruikte documenten : Datum:. Plaats:. Toetser:... Gesproken met:.. Beleid en strategie Toetsaspect : Bevinding : + - Het inkoopproces Tekortkoming (zwaarwegende negatieve bevinding) : Onderbouwing (waarom) : De theorie Consequenties Hertoets(en) inplannen Aanpassen risicodossier en toetsplan Aanpassen contractbeheersplan Vaststelling en archivering Naam (hoofd)toetser: Handtekening: Datum: Naam gemachtigde OG:.. Handtekening: Datum:.. Illustratie 19: model toetsverslag Kopie aan: Opdrachtnemer:.. Opdrachtgever: Archiveren in: Contractdossier HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE De verdieping Woordenlijst

47 Opvolging toetsen Alle bevindingen moeten binnen de afgesproken termijn aan de opdrachtnemer kenbaar worden gemaakt. In geval van een negatieve bevinding of een tekortkoming moet de opdrachtnemer zelf correctieve maatregelen doorvoeren, controleren of deze worden uitgevoerd en of ze het gewenste effect hebben. De gevolgen van de afwijkingen en de maatregelen dienen door de opdrachtnemer (kwalitatief, financieel, planmatig) inzichtelijk te worden gemaakt. Aanvullend moet hij corrigerende maatregelen nemen om herhaling van de afwijkingen te voorkomen. Als de opdrachtnemer maatregelen heeft getroffen, wordt bij een tekort - koming een hertoets ingepland en uitgevoerd. Een hertoets hoeft niet per se een producttoets te zijn. Als de afwijking voortkomt uit het niet naleven van procedures is een procestoets van toepassing. De opdrachtnemer neemt die voorgestelde maatregelen op in zijn documenten en de opdrachtgever neemt de hertoets op in het toetsplan. Blijkt uit de resultaten van de hertoets dat de opdrachtnemer geen toereikende maatregelen heeft getroffen, dan voldoet hij niet aan de contracteisen. Een (wan)prestatie van een opdrachtnemer heeft een directe relatie met de betaling. Is er sprake van een tekortkoming, dan kan dit leiden tot een volledige of gedeeltelijke opschorting van de betaling. De opschorting van betaling wordt pas opgeheven wanneer uit een hertoets blijkt dat de tekortkoming is opgeheven. Gedeeltelijke opschorting Een deel van de betaling wordt opgeschort als een openstaande tekortkoming betrekking heeft op één specifieke betaalpost. In dit geval kan een prestatieverklaring worden afgegeven voor een deel van de prestatie. Volledige opschorting De volledige betaling van de termijn wordt opgeschort bij openstaande tekortkomingen op het systeem van integraal projectmanagement. Als de volledige termijn wordt opgeschort, dan betekent dit dat het kwaliteitssysteem van de opdrachtnemer niet werkt. Dit heeft gevolgen voor de werkprocessen en producten. VRAAG/ANTWOORD Zijn wij als opdrachtgever verantwoordelijk voor gevolgen van een fout in de uitvoering als op dit onderdeel door ons een acceptatie is uitgevoerd? De juridische consequentie van toetsing, acceptatie en oplevering is beschreven in de UAV-gc 2005 (zie paragraaf 20-4, 21-10, 22-3, 28-1 en 32-1 sub b en de toelichting). We zijn verantwoordelijk voor de fout als we deze tijdens de toets (ter acceptatie) hebben opgemerkt, maar niet hebben gemeld aan de opdrachtnemer. Als aannemelijk kan worden gemaakt dat we de fout niet hebben opgemerkt, dan blijft de opdrachtnemer verantwoordelijk voor de gevolgen. De mate waarin we verantwoordelijk zijn voor de gevolgen van deze fout is dus afhankelijk van hoe er feitelijk is getoetst en hoe deskundig dat is gebeurd. Daarom is het van groot belang om goed na te denken en vast te leggen of en hoe gebruik gemaakt wordt van de toetsbevoegdheid. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

48 F. Betalingsproces Voor elke nieuwe betalingstermijn dient de opdrachtnemer een verzoek in voor een prestatieverklaring. Op basis van onderbouwing in de contractadministratie wordt besloten om al dan niet een prestatieverklaring af te geven. Inleiding De betalingsregeling Voor D&C- en E&C-contracten in het contractenbuffet is een model betalingsregeling beschikbaar. In een handreiking worden drie mogelijke betalingsregelingen beschreven met bijpassende contractteksten: Bij betaling op planning worden werkpakketten betaald volgens een lineaire verdeling van kosten over de geplande tijdsduur, zolang niet wordt afgeweken van het kritieke pad. De basis wordt gevormd door een geaccepteerde termijnstaat en geaccepteerde actuele planning. Bij betaling op voortgang worden seriematige werkpakketten betaald op basis van de voortgang in het werk. De basis wordt gevormd door een geaccepteerde termijnstaat en gerealiseerde voortgang. Een betaling op product geldt voor de betaling van werk met een doorlooptijd korter dan drie maanden. Er wordt betaald zodra het resultaat van het product gereed is. De voorkeur gaat uit naar betaling op planning, omdat hiermee de werkelijke besteding van de opdrachtnemer beter benaderd wordt dan bij bijvoorbeeld productbetalingen. Bovendien stelt deze regeling ons optimaal in staat om op afstand te beheersen. Beleid en strategie Het inkoopproces Meer informatie over betalingsregelingen is te vinden op: Wanneer de toetsen volgens plan zijn uitgevoerd, kan de verantwoording van de prestatieverklaring worden opgesteld. Op basis van de toetsverslagen en het overzicht met openstaande tekortkomingen wordt op het betaalmoment volgens de geaccepteerde termijnstaat vastgesteld of de prestatie wel, niet of voor een deel is geleverd. De prestatie is geleverd als er geen tekortkomingen openstaan. Staan er nog tekortkomingen open, dan is dit een reden om de betaling van de termijn volledig of gedeeltelijk op te schorten. De theorie De verantwoording van de prestatieverklaring wordt onderbouwd met: een toetsplan gebaseerd op het risicodossier; de uitgevoerde toetsen conform het toetsplan; eventuele verantwoording van afwijking van het toetsplan; de registraties van de bevindingen uit toetsen; de beoordeling van bevindingen om te bepalen of er sprake is van een tekortkoming; de registratie van tekortkomingen (inclusief opvolging) per betaalperiode. De verdieping Een deel van de betaling wordt opgeschort als een openstaande tekortkoming betrekking heeft op een procestoets van een werkpakket of op een producttoets, en als een koppeling kan worden gemaakt met een betaalpost. In dit geval kan een prestatieverklaring worden afgegeven voor een deel van de HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

49 prestatie. Als de volledige termijn wordt opgeschort, wordt geen prestatieverklaring afgegeven. De opdrachtgever maakt dit schriftelijk bekend aan de opdrachtnemer. De volledige of gedeeltelijke opschorting van de betaling wordt opgeheven wanneer de tekortkoming bij een hertoets blijkt te zijn verdwenen. De functie van een prestatieverklaring is tweeledig. Voor de opdrachtnemer staat een prestatieverklaring gelijk aan toestemming om te factureren. Voor Rijkswaterstaat staat een prestatieverklaring gelijk aan een interne verantwoording dat de betalingstermijn betaalbaar gesteld kan worden. De contractmanager verstrekt de verantwoording van de prestatieverklaring aan de projectadministratie. De opdrachtnemer stuurt een kopie van de prestatieverklaring en de factuur. De projectadministratie controleert of de drie documenten met elkaar overeenkomen. Is dat het geval, dan wordt dit geregistreerd in SAP en wordt betaling mogelijk. NB: Er is nadrukkelijk geen koppeling tussen het afgeven van een prestatieverklaring en een acceptatie. Met het afgeven van de prestatieverklaring en het doen van betalingen hebben we geen documenten, werkzaamheden, resultaten van werkzaamheden, het werk of het gerealiseerde meerjarig onderhoud geaccepteerd (zie 33-8 van de UAV-gc). Toets op betaalcriterium Tijdens de overbrugging van de theorie naar de praktijk wordt in de implementatieperiode tot eind 2007 in elke termijn een toets uitgevoerd op het betalingscriterium. Na evaluatie wordt bekeken of deze tijdelijke maatregel kan vervallen. Met deze toets op het betaalcriterium is de volgende situatie denkbaar. In een termijn waarin alleen betaalposten zitten waarvoor geen risico s zijn onderkend, kan rechtmatig worden betaald zonder dat er toetsen worden uitgevoerd. Dit moet dan wel onderbouwd zijn met het resultaat uit de mix van toetsen uit een eerdere termijn, inclusief een toets op het betalingscriterium in die betreffende termijn. Voor betaling op planning betekent een toets op het betaalcriterium dat er getoetst is of de stand van het gerealiseerde werkpakket dat op het kritieke pad ligt, overeenkomt met de stand die de opdrachtnemer heeft opgegeven. Een vooraf gedefinieerde marge van het kritieke pad mag niet worden overschreden. De informatie over de planning kan voortkomen uit een systeem (planningsmanagement), proces (planningsproces) of producttoets (steekproef op de gerealiseerde planning van de opdrachtnemer). Voor betaling op voortgang betekent een toets op het betaalcriterium dat er getoetst is of de feitelijke voortgang van het werk overeenkomt met de door de opdrachtnemer opgegeven voortgang. De informatie over de voortgang kan voortkomen uit een systeem- (planningsmanagement), proces- (planningsproces) of producttoets (steekproef op de voortgangsrapportage van de opdrachtnemer). Voor betaling op product betekent een toets op het betaalcriterium dat er getoetst is of het product van de betaalpost ook feitelijk is geleverd overeenkomstig de opgave van de opdrachtnemer. De informatie over het product komt voort uit een producttoets (steekproef op de aangeleverde productgegevens van de opdrachtnemer). HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

50 Inleiding Start betaalprocedure ON Start (Gepland betaalmoment) Nee Opstellen verantwoording prestatieverklaring Accoord? Verantwoording prestatieverklaring Beleid en strategie Ja Verzoek afgifte prestatieverklaring van ON Registreren in SAP Recht op PV vlgns verzoek? Nee Informeren ON conform par 33.5 UAV-GC Nee Recht op een deel PV? Brief OG aan ON Het inkoopproces Ja Ja Nee Opstellen prestatieverklaring Model A UAV-GC Accoord? Informeren ON conform par 33.5 UAV-GC Brief OG aan ON De theorie Ja Afgeven prestatieverklaring Model A UAV-GC Betaalproces Goedgekeurde prestatieverklaring Model A UAV-GC De verdieping Illustratie 20: proces afgeven prestatieverklaring HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

51 G. Oplevering Keuring bij oplevering In de UAV-gc 2005 wordt de term keuren in principe alleen gebruikt voor een activiteit van de opdrachtnemer waarmee hij aantoont dat hij aan eisen uit de overeenkomst voldoet. In de context van de oplevering wordt binnen de UAV-gc de term keuren wél voor een activiteit van de opdrachtgever gebruikt. Hiermee wordt aangesloten bij artikel 7:758 lid 1 van het Burgerlijk Wetboek. Het hier bedoelde keuren wordt in paragraaf 24 als volgt beschreven: voorafgaande aan de aanvaarding of de weigering van het werk kan de opdrachtgever de kwaliteit van het werk toetsen. De oplevering van een werk heeft juridische gevolgen voor de aansprakelijkheid. Dit geeft aanleiding tot het uitvoeren van een laatste keuring. In ieder geval dient het opleverdossier ter acceptatie te zijn voorgelegd. In dit dossier (dat is opgebouwd uit de afleverdossiers per betaalpost) zijn documenten zoals revisietekeningen en dergelijke opgenomen. Het acceptatieplan vermeldt aan welke criteria dit dossier moet voldoen en welke documenten daar deel van uitmaken. Het initiatief voor de laatste keuring ligt bij de opdrachtnemer. Als hij denkt dat het werk gereed is voor aanvaarding door de opdrachtgever, dan deelt hij dit schriftelijk mee. De opdrachtgever gaat hier al dan niet op in. Ook deze laatste keuring doen wij op basis van een systeem-, proces- en/of producttoets. De insteek is wederom risicogestuurd. Blijkt uit de keuring dat er grote gebreken zijn, dan wordt besloten om niet tot aanvaarding van het werk over te gaan. Kleine gebreken mogen geen reden tot weigering van het werk zijn, mits zij een eventuele ingebruikneming niet in de weg staan. De opdrachtnemer dient deze gebreken zo spoedig mogelijk te herstellen. Overdracht contractdossier Het contractdossier van de contractmanager wordt overgedragen aan de projectleider. Het contractdossier bevat de volgende documenten: contract; risicodossier; toetsplan; toetsverslagen; overzicht tekortkomingen (en reactie opdrachtnemer); onderbouwing prestatieverklaring; prestatieverklaring. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

52 VRAAG/ANTWOORD Hoe wordt de deskundigheid van personeel geborgd bij systeemgerichte contractbeheersing? IMG verzorgt in samenwerking met het CLC en SDG (C&T) verschillende trainingstrajecten. Dit jaar gaat de tweedaagse praktijktraining voor toetsers en contractmanagers van start. Vanuit het CLC worden verdiepingsmodulen voor project- en contractmanagers verzorgd. Verder wordt gestreefd naar gelijke normen en waarden voor systeemgerichte contractbeheersing door regelmatige afstemming tussen betrokkenen bij contractmanagement in de volgende gremia: de kenniskring SCB, het netwerk contractmanagers (in oprichting, vanuit Top 50-projecten) en de kenniskring contractmanagement. Gelijke interpretatie en toepassing van systeemgerichte contractbeheersing wordt onder andere gecontroleerd door collegiale toetsing van het contractbeheers- en toetsplan. Andere instrumenten zijn: coaching van toetsers door de contractmanager, het opnemen van naleving van de systematiek, en houding en gedrag in RKW-gespreken, en ondersteuning en toetsing door BIO- en BCT-afdelingen. Tenslotte wordt gewerkt aan het vastleggen en verspreiden van kennis door het uitwerken van standaardinstrumenten (zoals contractteksten, model contractbeheersplan, checklists en dergelijke) en het maken van handreikingen voor de toepassing van deze instrumenten. De verdieping Inleiding Beleid en strategie Het inkoopproces Woordenlijst De theorie HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

53 Verklarende woordenlijst Aanbieding volgens EMVI (Economisch Meest Voordelige Inschrijving) Contractdocument waarmee een opdrachtnemer te kennen geeft het werk en eventueel het meerjarig onderhoud te willen realiseren conform het bepaalde in de overeenkomst tegen betaling van de in de Basisovereenkomst vastgelegde prijs. Acceptatie Schriftelijke mededeling waarin de opdrachtgever verklaart aan de opdrachtnemer geen bezwaar te hebben tegen door de opdrachtnemer ter acceptatie voorgelegde documenten, zelfstandige hulppersonen, werkzaamheden, resultaten van werkzaamheden of wijzigingen. Afstemmingsoverleg Overleg tussen opdrachtgever en opdrachtnemer over het uitwisselen van informatie over de uit te voeren werkzaamheden, bijbehorende risico s en te treffen beheersmaatregelen. Doel van het overleg is om de procesbeheersing en de beschrijving daarvan in (deel)kwaliteitsplannen bij de opdrachtnemer helder te krijgen. In het overleg kunnen nadere afspraken gemaakt worden over kritieke processen en punten, aan te tonen eisen en daaraan gerelateerde stop- en bijwoonpunten. Het eerste afstemmingsoverleg valt samen met de projectstartbijeenkomst. Afhankelijk van het risico profiel kan meer dan één afstemmingsoverleg worden ingepland. Afwijking Het niet voldoen aan een eis. Beheersmaatregel Maatregel waarmee een geïdentificeerd risico kan worden beheerst. Dit kan een maatregel zijn die de oorzaak of het gevolg van het risico wegneemt of verkleint. Beheersing inkoop De activiteiten van de opdrachtgever vanaf het moment van het specificeren van de eisen tot en met het afsluiten van de opdracht gericht op de optimale inkoop van een werk waarbij de risico s voor de opdrachtgever op een acceptabel niveau blijven. De activiteiten zijn onderdeel van de beheersing van het project. Betaling op planning Wijze van betalen waarbij de betalingen in de tijd lineair zijn uitgezet. Betaling op product Wijze van betalen waarbij de betalingen in de tijd zijn uitgezet op basis van gerealiseerde producten. Betaling op voortgang Wijze van betalen waarbij de betalingen in de tijd zijn uitgezet op basis van de werkelijke voortgang. Bevinding Een feit dat de opdrachtgever met een toets heeft vastgesteld. Dit kan zowel een positieve als een negatieve bevinding zijn. Bijwoonpunt Het moment tijdens de contractbeheersing waarop de opdrachtgever zelf wil toetsen of de kwaliteitsborging van de opdrachtnemer betrouwbaar is. Hiertoe dienen de bijwoonpunten in de (deel)kwaliteitsplannen, verificatieplannen en keuringsplannen bij acceptatie door de opdrachtgever te worden vastgesteld. De opdrachtnemer is verplicht om de opdrachtgever te informeren wanneer dat bijwoonpunt is bereikt. Configuratie Functionele en materiële eigenschappen van een product, zoals omschreven in technische documentatie en gerealiseerd in het product. Configuratiemanagement Het geheel aan activiteiten gericht op het beheersen van de configuratie. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

54 Contractbeheersing De activiteiten van de opdrachtgever vanaf het moment van gunning gericht op het zekerstellen dat de eisen uit de overeenkomst worden gehaald en dat de risico s voor de opdrachtgever op een acceptabel niveau blijven. De activiteiten zijn onderdeel van de beheersing van de inkoop. Contractbeheersplan Door de formele opdrachtgever geautoriseerd plan waarin de beschrijving van de organisatie en alle activiteiten met betrekking tot de contractbeheersing zijn opgenomen. Onderdeel van het contractbeheersplan is het toetsplan. Dit toetsplan wordt concreter zodra de procesbeheersing door de opdrachtnemer nader is ingevuld. Corrigerende maatregel Maatregel om de oorzaak van een waargenomen afwijking of andere ongewenste situatie weg te nemen. Documenten Alle informatie door of namens de opdrachtnemer geproduceerd in het kader van de werkzaamheden, ongeacht de aard van de informatiedrager waarop of waarin deze informatie is vastgelegd. Eis Behoefte of verwachting die kenbaar is gemaakt, vanzelfsprekend of dwingend voorgeschreven. Gebrek Afwijking in het werk geconstateerd na oplevering. Gemachtigde van de opdrachtgever De door de opdrachtgever aangewezen persoon die namens de opdrachtgever optreedt voor de beheersing van het contract, met uitzondering van beschikkende zaken. De gemachtigde van de opdrachtgever vertegenwoordigt de opdrachtgever voor zover de bevoegdheid daartoe uitdrukkelijk en schriftelijk aan de opdrachtnemer is meegedeeld. Hertoets Een toets door de opdrachtgever om te beoordelen of de getroffen maatregel door de opdrachtnemer naar aanleiding van een eerder geconstateerde tekortkoming is uitgevoerd. Referentie is de maatregel (correctief, corrigerend of preventief) die de opdrachtnemer heeft opgenomen. Informatiemanagement Het geheel van activiteiten gericht op het verschaffen van relevante, tijdige, complete, juiste en, indien noodzakelijk, vertrouwelijke informatie aan de juiste partijen gedurende de levenscyclus van een project. Inkoopmanagement Het geheel aan activiteiten gericht op het inkopen, vanaf het vaststellen van de inkoopbehoefte tot en met de oplevering van het werk. De theorie Het inkoopproces Beleid en strategie Inleiding Inspecteren Beoordelen of het in stand te houden product voldoet aan de eisen. Inspectieplan Document waarin wordt beschreven hoe en wanneer inspecties worden uitgevoerd. Inspectierapport Document met objectief bewijs of nog steeds (of niet) wordt voldaan aan gespecificeerde eisen. Integraal Project Management Integrale beheersing van de verschillende werkprocessen binnen een project. Keuren Beoordelen of het gerealiseerde product voldoet aan de eisen. De verdieping Keuringsplan Document waarin wordt beschreven hoe en wanneer de opdrachtnemer keuringen uitvoert. Keuringsrapport Document met objectief bewijs of (wel of niet) wordt voldaan aan gespecificeerde eisen. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE Woordenlijst

55 Kostenmanagement Het geheel van activiteiten gericht op het beheersen van uitgaven en inkomsten in heden, verleden en toekomst. Kwaliteit De mate waarin een geheel van eigenschappen en kenmerken voldoet aan de eisen van kwaliteitsborging. Kwaliteitsmanagement De gecoördineerde activiteiten om een organisatie te sturen en te beheersen met betrekking tot kwaliteit. Kwaliteitsborging Het aspect van kwaliteitsmanagement gericht op het geven van vertrouwen dat aan kwaliteitseisen zal worden voldaan. Managementplan Document dat specificeert hoe, wanneer en door wie specifieke doelen moeten worden bereikt en hoe gedefinieerde doelstellingen in resultaten, tijd, kosten en kwaliteit kunnen worden gerealiseerd. Opdrachtgever In de Basisovereenkomst genoemde natuurlijke of rechtspersoon die de opdrachtnemer opdraagt het werk en, indien overeengekomen, het meerjarig onderhoud te realiseren. Opdrachtnemer In de Basisovereenkomst genoemde natuurlijke of rechtspersoon aan wie de realisatie van het werk en, indien overeengekomen, het meerjarig onderhoud is opgedragen. Overeenkomst De tussen de opdrachtgever en de opdrachtnemer tot stand gekomen overeengekomen afspraken over de totstandkoming van werk. Organisatiemanagement Het geheel van activiteiten gericht op het leveren van de juiste mensen voor het bereiken van de doelstellingen van het project. Planningsmanagement Het geheel van activiteiten gericht op het beheersen van het aspect tijd over de gehele levenscyclus van een project. Prestatieverklaring Verklaring door de opdrachtgever die de opdrachtnemer recht verschaft op de betaling van een bepaalde termijn. Hiertoe wordt het model gebruikt uit bijlage A van het model Basisovereenkomst. Om de verklaring te kunnen opstellen, dient Rijkswaterstaat een verantwoording van de prestatieverklaring te hebben. Preventieve maatregel Maatregel om de oorzaak van een mogelijke toekomstige afwijking of andere ongewenste mogelijke situatie weg te nemen. Maatregel te nemen door de opdrachtnemer in verband met de eisen van de EN-ISO 9000:2000. Proces Geheel van samenhangende of elkaar beïnvloedende activiteiten die input omzet in output. Procestoets Een toets door de opdrachtgever op functioneren van de processen die door de opdrachtnemer zijn beschreven in het projectmanagementplan en afgeleide deelplannen zoals een projectkwaliteitsplan, werkplannen, en keurings-, test-, of verificatieplannen. Het gaat bij deze toets om een beoordeling of de beheersmaatregelen door de opdrachtnemer worden uitgevoerd volgens de plannen. Product Het resultaat van een proces. Producttoets Een toets ter beoordeling of producten voldoen aan gestelde eisen en/of technische specificaties, met het doel de betrouwbaarheid van de gegevens van de opdrachtnemer te verifiëren. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

56 Projectbeheersing Geheel van activiteiten gericht op het beheersen van tijd, geld en kwaliteit en ondersteuning door organisatie en informatie. Projectbeheersing is ter ondersteuning van projectmanagement (staffunctie). Projectkwaliteitsplan Document van de opdrachtnemer dat specificeert welke procedures en bijbehorende middelen door wie en wanneer voor een specifiek project, product, proces of contract moeten worden toegepast. Projectmanagement Het geheel aan activiteiten gericht op het inrichten en bijsturen van het project, zodat het project beheerst verloopt en resultaten worden gerealiseerd binnen de gestelde kaders van tijd, geld en kwaliteit. Projectmanagement betreft ook alle activiteiten gericht op het informeren van de opdrachtgever over de voortgang van het project. Risico Gebeurtenis die al dan niet kan optreden en die kan leiden tot uitloop van het project, een kostenoverschrijding of tot het niet voldoen aan de gestelde kwaliteitseisen. Risicoanalyse Inventarisatie van risico s met inschatting van kansen en gevolgen van optreden inclusief de geplande beheersmaatregelen. Risicodossier Actueel overzicht van de risico s en de geplande beheersmaatregelen en hun status. Met status wordt bedoeld: of er wel/geen beheersmaatregel is gepland, of deze maatregel is uitgevoerd en of er nog een restrisico bestaat. Risicomanagement Het geheel van activiteiten gericht op het beheersen van risico s. Risicoprofiel Een overzicht van de verwachtingswaarde (kans van optreden) van de risico s en de gevolgen op de projecteisen gemeten in tijd, geld en kwaliteit. Inleiding Beleid en strategie Het inkoopproces Risicoregister Het risicodossier van de opdrachtnemer. Specificatie Document dat eisen kenbaar maakt. Stoppunt Het moment tijdens de contractbeheersing waarop de opdrachtgever zelf wil toetsen of de kwaliteitsborging van de opdrachtnemer betrouwbaar is. Deze toetsen hebben een directe relatie met een acceptatiemoment. Hiertoe dienen de stoppunten in de (deel)kwaliteitsplannen, verificatieplannen en keuringsplannen bij acceptatie door de opdrachtgever te worden vastgesteld. De opdrachtnemer is verplicht om de opdrachtgever te informeren wanneer het stoppunt is bereikt. Systeem Geheel van samenhangende of elkaar beïnvloedende elementen. Systeemgerichte contractbeheersing Methode van contractbeheersing waarbij de opdrachtgever gebruikmaakt van de gegevens die voortkomen uit het systeem van kwaliteitsborging door de opdrachtnemer in relatie tot de gemaakte afspraken in de overeenkomst. Door de belangrijkste risico s om te zetten in een op het project passende mix van toetsen (combinatie van systeem-, proces- en producttoetsen) stelt de opdrachtgever vast of het aannemelijk is dat aan de eisen van het contract is voldaan. Systeemtoets Een toets door de opdrachtgever op het systeem van integraal projectmanagement zoals dat door de opdrachtnemer is beschreven in het projectmanagementplan en afgeleide deelplannen zoals o.a. projectkwaliteitsplan(nen). Het gaat bij deze toets om de risicovolle aspecten van het projectmanagement bij de opdrachtnemer. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE De theorie De verdieping Woordenlijst

57 Technisch proces Het geheel van activiteiten gericht op het beheerst en expliciet ontwerpen, realiseren, onderhouden en slopen van een systeem. Tekortkoming Een negatieve bevinding die naar het oordeel van de contractmanager als zwaarwegend wordt aangemerkt. Op basis van een tekortkoming wordt een (deel van een) betaaltermijn opgeschort tot de tekortkoming aantoonbaar is opgeheven. Termijnstaat Overzicht waarin is aangegeven in welke termijnen de betaling van de aannemingssom zal plaatsvinden. Toetsen Vergelijken van waarnemingen met referenties. Voorbereiden, uitvoeren conform het toetsplan en rapporteren van de bevindingen conform het model toetsverslag. Rijkswaterstaat hanteert het principe dat er op drie niveaus (systeem, proces, product) kan worden getoetst. Toetsingsplan ontwerpwerkzaamheden Annex bij de Vraagspecificatie waarmee de opdrachtgever de toetsingsbevoegdheid heeft afgebakend door middel van een opsomming van de ontwerpdocumenten die de opdrachtnemer aan de opdrachtgever ter toetsing moet overhandigen. Rijkswaterstaat gaat niet meer feitelijk alle ontwerpdocumenten toetsen, maar geeft een oordeel op basis van de mix van systeem-, proces- en producttoetsen. Toetsplan Onderdeel van het contractbeheersplan waarin de uit te voeren toetsen qua soort, inhoud, uitvoerende, - frequentie, methode, gebruikte norm en registratie beschreven zijn. Onderbouwing van de in te plannen toetsen is beschreven in het risicodossier. Toetsverslag Registratie door de opdrachtgever van de bevindingen tijdens de toets. Veiligheid- en gezondheidsmanagement Het geheel aan activiteiten gericht op een veilige en gezonde werkwijze gedurende de levenscyclus van een systeem. Verantwoording van de prestatieverklaring Document waarin op basis van de betalingsregeling gestelde voorwaarden en de principes van systeemgerichte contractbeheersing wordt onderbouwd waarom een prestatieverklaring kan worden afgegeven. Verifiëren Het beoordelen of het gekozen en/of ontworpen product na realisatie voldoet aan de eisen. Verificatienota Overzicht per fase in het project waarin is aangegeven in welke registraties bij de opdrachtnemer objectief bewijs is te vinden dat aan de eisen uit de Vraagspecificatie wordt voldaan. Objectief bewijs wordt verkregen door: verifiëren, keuren, testen en inspecteren. Verificatieplan Document waarin wordt beschreven hoe en wanneer verificaties worden uitgevoerd. Verificatierapport Document met objectief bewijs of (wel of niet) na realisatie aan gespecificeerde eisen zal worden voldaan. Werk Het in de Basisovereenkomst omschreven werk dat de opdrachtnemer op basis van de Vraagspecificatie en de aanbieding door ontwerp- en uitvoeringswerkzaamheden dient te realiseren. HANDREIKING SYSTEEMGERICHTE CONTRACTBEHEERSING - VERSIE

58