Handreiking Procesgericht risicomanagement ten behoeve van SCB

Transcriptie

1 Handreiking Procesgericht risicomanagement ten behoeve van SCB Datum Versie 2.0 Status definitief

2 Colofon Informatie Eldert van der Lee Telefoon Mail Datum Status definitief Versienummer 2.0 Versie 0.1 Eerste concept 0.2 Na overleg met diverse betrokkenen en advies expertgroepen CM en PB 0.3 Definitief concept na aanpassingen en toevoeging bijlagen 1.0 Opmerkingen SCB-experts verwerkt 2.0 Wijziging status van Best Practice naar Handreiking Nieuwe versie van de handleiding Procesgericht risicomanagement ten behoeve van SCB in Riskscope opgenomen. Pagina 2 van 13

3 Inhoud 1 Inleiding Aanleiding en doel Leeswijzer 4 2 Stappenplan Stap 1: opstellen procesanalyse en processen koppelen aan PMP wanneer dit beschikbaar is Stap 2: Benoemen risicovolle processen, incl argumentatie Stap 3: Risicovolle processen vertalen naar procesrisico s Stap 4: Procesrisico s opnemen in RiskScope Stap 5: Evalueren onderliggende risico s Stap 6: Koppelen van risico s aan processen Stap 7: Toepassen toetsdrempel Stap 8: Risico s overnemen naar URSCB Stap 9: Opstellen van toetsplanning, incl onderbouwing Stap 10: Uitvoeren van toetsen Stap 11: Evalueren risico s per individuele toets Stap 12: Periodiek evalueren functioneren van het KMS van Opdrachtnemer Stap 13: Periodiek evalueren van procesrisico s 11 3 Bijlagen 13 Pagina 3 van 13

4 1 Inleiding 1.1 Aanleiding en doel Essentieel bij het toepassen van SCB is dat er uiteindelijk een uitspraak gedaan kan worden of er gesteund kan worden op het kwaliteitsmanagementsysteem van de opdrachtnemer. Om tot dit oordeel te komen worden er risicogestuurd toetsen uitgevoerd (systeem, proces en product). Ervaring leert dat een goed risicodossier waarin de risico s op het juiste niveau en in goede onderlinge samenhang zijn opgenomen een belangrijke bijdrage levert aan een efficiënte en effectieve toepassing van SCB. Veel projecten hebben in het verleden geworsteld met een omvangrijk risicodossier waarin veel risico s op laag detailniveau (veel op productniveau) zijn opgenomen. Het is met een dergelijk risicodossier heel lastig om te komen tot een juiste toetsmix waarin met name aandacht wordt besteed aan toetsen op systeem- en procesniveau. Binnen een aantal projecten is een methodiek ontwikkeld om vanuit een analyse van de processen die door de opdrachtnemer worden uitgevoerd en dit vervolgens uit te werken naar helder gedefinieerde risico s op verschillende niveaus tot een goede toetsmix te komen. De ervaringen zijn gebundeld in deze handreiking die als hulpmiddel dient voor projecten bij het inrichten en toepassen van SCB. Uniformiteit staat hoog op de agenda, zowel uniformiteit in ons eigen werken als de uniformiteit richting de markt. Deze handreiking beoogt daar een sterke bijdrage aan te leveren. SCB kan niet meer zonder het leggen van een koppeling tussen de risico s en de processen van de opdrachtnemer. Wanneer iedereen dit volgens deze handreiking doet trekken we daar uniform in op. En mocht je tegen knelpunten aanlopen of mogelijkheden zien de werkwijze te verbeteren houd dit dan niet voor jezelf door het alleen op je eigen project anders te doen maar meld het terug zodat we de verbeteringen met iedereen kunnen delen! De aanpak zoals beschreven in dit document past binnen het kader SCB. 1.2 Leeswijzer Deze handreiking is opgebouwd vanuit een stappenplan zoals dit bij de voorbeeld projecten is toegepast. Bij elke stap is, voor zover van toepassing, een verwijzing gemaakt naar voorbeelddocumenten die apart beschikbaar zijn gesteld. In de bijlage is een overzicht van deze documenten opgenomen. De methodiek is toepasbaar bij meerdere contractvormen. Er is in de praktijk al ervaring mee opgedaan bij D&C-contracten, prestatiecontracten en contracten onder de samenwerkingsovereenkomst ingenieursdiensten (planstudie). Alleen DBFM-contracten vormen hier een uitzondering op omdat daar in het contract een aantal borgingsmaatregelen zijn opgenomen zoals certificatie van de projectorganisatie volgens NEN-EN-ISO 9001 en het aantoonbaar voldoen aan de Pagina 4 van 13

5 ISO die een iets afwijkende werkwijze vragen. Dit zal worden opgenomen in de best practice van het contractbeheersplan voor DBFM-contracten. Deze handreiking wordt ook ondersteund door de presentatie Procesgericht risicomanagement ten behoeve van SCB en de bijbehorende film. Voor de wijze waarop deze methodiek wordt ondersteund vanuit Riskscope is een aparte handreiking opgesteld: Procesgericht risicomanagement ten behoeve van SCB in Riskscope, hoe de (proces)risico s in de risicodatabase op te nemen. Pagina 5 van 13

6 1.3 Ondersteuning Voor meer informatie over deze methodiek kun je terecht bij: - Eldert van der Lee : algemene informatie en specifiek toepassing SCB - Kim Maas : toepassing risicomanagement Aan deze handreiking zijn enkele praktijkvoorbeelden uit enkele projecten toegevoegd. We beseffen dat de werkwijze zich steeds verder zal doorontwikkelen. Mocht je betere voorbeelden hebben of goede aanvullingen laat het ons vooral weten. Pagina 6 van 13

7 2 Stappenplan 2.1 Stap 1: opstellen procesanalyse en processen koppelen aan PMP wanneer dit beschikbaar is We moeten uiteindelijk komen tot een uitspraak over het functioneren van het kwaliteitsmanagementsysteem van de opdrachtnemer op ons project. Dit managementsysteem kun je beschouwen als een samenstel van onderlinge samenhangende processen. Om hierover iets te kunnen zeggen heb je dus inzicht nodig in welke processen de opdrachtnemer toepast binnen het managementsysteem; een analyse van de processen. Om tot een gestructureerde aanpak te komen kun je gebruik maken van verschillende bronnen zoals de NEN- EN-ISO 9001, de vraagspecificatie proces of van de door de opdrachtnemer benoemde processen (bijvoorbeeld in het PMP). Vanuit een aantal projecten is een basis processtructuur gemaakt die is gebaseerd op de ISO 9001 en de vraagspecificatie proces. Bij de uitwerking van de procesanalyse is een bewuste keuze gemaakt in de mate van detail. Een te gedetailleerde analyse resulteert in erg veel processen en maakt het lastig om de juiste focus te leggen. Daarom is in het voorbeeld de analyse op een hoger niveau gehouden en is de diepgang meer zichtbaar gemaakt in de toelichting die bij elk proces is meegegeven en in de toevoeging van de oorzaken en gevolgen (zie stap 3). Opmerkingen bij dit voorbeeld: - uniform toepasbaar; - bij elk project goed kijken of deze past bij de scope van het contract; - voordat je processen toevoegt kijk goed of deze al niet zijn afgedekt in de andere processen (kijk hiervoor vooral naar de toelichting per proces); - bereik in je team overeenstemming over de inhoud/afbakening van elk proces (zie de kolom toelichting in het voorbeeld); - voor verschillende contracten te gebruiken, verschil per contractvorm zit vooral bij het technisch management; - soms wordt EMVI als apart proces toegevoegd. Hiermee positioneer je het voldoen aan de aangeboden kwaliteit op de EMVI-criteria door de opdrachtnemer als apart proces. Je kunt het echter ook benaderen als een onderdeel van de verschillende processen waarop de EMVI-criteria zich richten. Een EMVI-criterium als beperken verkeershinder kun je zo ook meenemen onder het proces verkeersmanagement. In de laatste benadering ga je meer uit van (de toetsing van) het proces waarin het voldoen aan het EMVIcriterium vooral wordt beïnvloed. Vanuit de processtructuur kan vervolgens de relatie gelegd worden naar de processen zoals die door opdrachtnemer worden onderkend door in het schema per proces aan te geven waar dit in het PMP (of een ander door opdrachtnemer opgesteld plan) is opgenomen. Bijbehorende voorbeelden: 1.a voorbeeld procesanalyse aanleg en GVO (D&C-contracten) 1.b voorbeeld procesanalyse onderhoud (prestatiecontracten) Pagina 7 van 13

8 Opmerking: in het bijgevoegde voorbeelden voor aanleg/gvo en vast en klein variabel onderhoud is recent het proces verifiëren en valideren toegevoegd (in het verleden was dit onderdeel van de processen ontwerpen en uitvoeren). Met deze aanpassing sluit het voorbeeld beter aan bij het model VSP van de D&C-contracten. Er zijn ook voorbeelden voor contracten in de planstudiefase in ontwikkeling. 2.2 Stap 2: Benoemen risicovolle processen, incl argumentatie. Van elk proces kan bepaald worden in welke mate het risicovol is. Deze waardering kan variëren over de looptijd van het contract. Kijk bij de waardering per proces naar de kans dat het fout gaat en naar de gevolgen die dit heeft voor het realiseren van de projectdoelstellingen. Beperk je in de waardering tot het aangeven van bijv. hoog, midden of laag. Meer gedetailleerde waardering is op dit procesniveau bijna niet mogelijk en geeft ook geen toegevoegde waarde. Tips bij het komen tot deze waardering: 1. doe dit los van de inhoud van het reeds aanwezige risicodossier; 2. betrek het hele projectteam, bijv. door ieder vooraf als huiswerk de processen individueel te laten scoren en dit in een sessie samen te brengen tot een totaalbeeld; 3. leg ook de argumenten waarom een proces een bepaalde waardering krijgt vast. Zorg voor een goede onderbouwing bij de inschatting van de risico s. Door goed de argumenten vast te leggen waarom een proces wel of niet als risicovol gezien wordt kom je tot een transparante werkwijze en het geeft extra informatie die je later nodig hebt om de toetsen voor te bereiden en om na het uitvoeren van een toets de risicowaardering te kunnen heroverwegen. Bijbehorende voorbeelden: 2.a voorbeeld risicowaardering processen N50 (D&C-contract) 2.b voorbeeld risicowaardering processen prestatiecontract droog Noord-Holland 2.3 Stap 3: Risicovolle processen vertalen naar procesrisico s Het resultaat van stap 2 is een waardering van alle processen in de mate waarin zij risicovol zijn met een bijbehorende argumentatie. Om het gebruik hiervan bij het vaststellen van de toetsmix en bij het voorbereiden en uitvoeren van de toetsen te versterken is het zinvol de processen uit te werken naar specifieke risico s. Binnen diverse projecten is dit gedaan door elk proces als één risico te benoemen; het proces xxxxx wordt onvoldoende beheerst. Benoem vervolgens bij elk procesrisico de oorzaken en gevolgen. Hiervoor kun je goed putten uit de argumenten die bij stap 2 zijn genoemd. In het bijbehorend voorbeeld is deze uitwerking voor een D&C-contract opgenomen. Neem deze niet één op één over maar kijk goed of deze aansluit bij je eigen proces-analyse van stap 1 en of de oorzaken en gevolgen aansluiten bij de scope van je contract. Bijbehorende voorbeelden: 3.a Procesrisico s met oorzaak en gevolg voor aanleg en GVO 3.b Procesrisico s met oorzaak en gevolg voor vast en klein variabel onderhoud Opmerking: stappen 2 en 3 kunnen ook worden omgedraaid. Voordeel het uitvoeren van stap 2 voor stap 3 is dat de argumenten die bij stap 2 boven tafel komen Pagina 8 van 13

9 kunnen worden gebruikt bij de formulering van de oorzaken en gevolgen in stap 3. Wanneer je eerst stap 3 uitvoert heb je het voordeel dat de risico s scherper geformuleerd zijn om tot een goede waardering bij stap 2 te komen. 2.4 Stap 4: Procesrisico s opnemen in RiskScope De procesrisico s worden opgenomen in Riskscope. Zie hiervoor de handreiking Procesgericht risicomanagement ten behoeve van SCB in Riskscope, hoe de (proces)risico s in de risicodatabase op te nemen. 2.5 Stap 5: Evalueren onderliggende risico s Het bestaande risicodossier bevat een schat aan informatie die we zeker moeten meenemen in de contractbeheersing. Ervaring leert wel dat er in de loop van het project veel risico s in zijn opgenomen waarop in de contractvoorbereiding wel beheermaatregelen zijn genomen zonder dat het dossier hierop is aangepast. Het moment van het sluiten van het contract is ook een duidelijke mijlpaal met betrekking tot de manier waarop we omgaan met de risico s. Veel risico s zijn in het contract gealloceerd bij de opdrachtnemer. Dit betekent dat primair de opdrachtnemer aan de lat staat voor de beheersing van deze risico s. Wij moeten niet de illusie wekken (noch bij de opdrachtnemer noch binnen het eigen team) dat wij deze risico s beheersen, bijvoorbeeld door het uitvoeren van toetsen. Een goede evaluatie van het risicodossier is van belang. Neem daarbij de volgende aandachtspunten mee: 1. maak duidelijk onderscheid tussen project en contractrisico s 2. ga er van uit dat risico s die bij de opdrachtnemer liggen ook door hem worden beheerst. Neem deze risico s ook niet allemaal op in het eigen dossier. Stem ze vooral af met de opdrachtnemer, kijk of ze in zijn dossier zitten, en bespreek deze risico s in de verschillende overleggen die er zijn met de opdrachtnemer. 3. ga na of de inhoud van het risicodossier ook aansluit op de ongewenste topgebeurtenissen van het project. Waar ligt de opdrachtgever wakker van? Is dit ook herkenbaar in het risicodossier of zijn er lopende het traject veel risico s ingeslopen waar je je eigenlijk geen zorgen over hoeft te maken. Probeer te komen tot een beperkt overzicht van contractrisico s. Uitgebreide dossiers bieden beperkte toegevoegde waarde als stuurinstrument. 2.6 Stap 6: Koppelen van risico s aan processen De volgende stap is het koppelen van de onderliggende risico s aan de processen. Ga hierbij uit van de bij het risico benoemde oorzaken en bepaal daaruit door welk proces van de opdrachtnemer het risico wordt beïnvloed. Wees hierbij beperkt in het koppelen aan meerdere processen. Bij voorkeur elk risico koppelen aan 1, max. 2 processen. Hierdoor behoud je de focus. De koppeling kun je weergeven in een excel-spreadsheet (gehanteerde benamingen hiervoor zijn kruisjeslijst of risicokaart ) en kan ook worden opgenomen in Riskscope. Voor dit laatste zie de handreiking Procesgericht risicomanagement ten behoeve van SCB in Riskscope, hoe de (proces)risico s in de risicodatabase op te nemen. Wanneer deze koppeling is aangebracht is het interessant te kijken hoe het uiteindelijke beeld er uit ziet. Is er bijvoorbeeld sprake van processen die als hoog risico zijn aangemerkt maar waar geen onderliggende risico s aan zijn gekoppeld? Of andersom; processen die niet risicovol worden beschouwd maar waar wel veel onderliggende risico s aan hangen. Wanneer hier een groot verschil tussen zit Pagina 9 van 13

10 betekent dit niet dat de één van beide resultaten fout is. Het geeft vooral aanleiding om de onderlinge samenhang nog eens goed te bekijken. Opmerking: De onderliggende risico s hebben vaak vooral betrekking op de ongewenste gebeurtenis dat de door de opdrachtnemer te leveren producten niet voldoen aan de contractuele eisen. Oorzaak hiervan is primair dat de processen die in de procesanalyse vallen onder Realisatie van het product niet of onvoldoende worden beheerst. Het risico dat deze processen niet of onvoldoende beheerst worden hebben vaak weer hun oorzaak in het feit dat de processen in de blokken managementverantwoordelijkheid, management van middelen en meten, analyseren en verbeteren onvoldoende worden beheerst. Dit is een mogelijke verklaring voor het feit dat je veel onderliggende risico s op bijvoorbeeld de technisch processen hebt terwijl de procesrisico s op bijv. managementsturing en verbetering juist als hoog worden gekwantificeerd. Bijbehorende voorbeelden: 6.a voorbeeld koppeling van risico s N50 (D&C-contract) 6.a Voorbeeld koppeling van risico s prestatiecontract droog Noord-Holland Opmerking bij dit voorbeeld: Bij de N50 wordt gebruik gemaakt van Best Value Procurement (BVP). Hierbij wordt het risicodossier (dus zowel projectrisico s als contractrisico s) beheerd door de opdrachtnemer. Voorwaarde hierbij is wel dat door het projectteam van de opdrachtgever wel een eigen dossier met procesrisico s wordt gehanteerd en dat het projectteam ook een duidelijke stem heeft in de beschrijving en kwantificering van de risico s in het gezamenlijke dossier. Bij de N50 is voor het koppelen een selectie gemaakt uit dit dossier van risico s die gebruikt worden als input voor SCB en deze zijn gekoppeld aan de processen. 2.7 Stap 7: Toepassen toetsdrempel De toetsdrempel kun je zowel definiëren voor de procesrisico s als voor de onderliggende risico s. Voor de onderliggende risico s kan dit in de vorm van een waarde totaalscore van een risico en door het vaststellen van een drempel voor de gevolgen op de verschillende aspecten. De kwantificering van de procesrisico s gaat niet verder dan hoog, midden of laag. Ook hier kun je drempels aan verbinden door te benoemen hoe je met toetsing omgaat in relatie tot deze score. Bijvoorbeeld: - Hoog risico: toetsen in komende toetsperiode (mits dit aansluit bij de planning van de opdrachtnemer) - Midden risico: toetsen in het komende jaar, afhankelijk van planning opdrachtnemer - Laag risico: niet toetsen Opmerking: het kan voorkomen dat je in een meer integrale toets, waarin je niet alleen individuele processen toetst, maar ook de samenhang tussen enkele processen, ook processen in de scope van de toets meeneemt die je als laag risico hebt gekwantificeerd. 2.8 Stap 8: Risico s overnemen naar URSCB Risico s die boven de drempel scoren worden vervolgens overgenomen in URSCB. Je kunt er ook voor kiezen in e en toets meerdere processen te toetsen waarbij je Pagina 10 van 13

11 naast de individuele processen vooral ook kijkt naar de onderlinge samenhang tussen de processen (gaat het op de procesovergangen goed?). Om dit mogelijk te maken moet je zorgen dat alle hierop betrekking hebbende procesrisico s als input worden meegenomen voor de toets, dus ook eventuele procesrisico s die laag scoren. Zie de opmerking bij stap Stap 9: Opstellen van toetsplanning, incl. onderbouwing De mix van toetsen bestaat uit systeem-, proces- en producttoetsen. Er is vaak discussie (verwarring) over de definitie van deze verschillende vormen van toetsen en hoe deze er in de praktijk uitzien. In relatie tot de procesanalyse kun je dit als volgt invullen: - een systeemtoets is een toets op één of meerdere van de processen uit de blokken projectmanagement, management van middelen of meting, analyse en verbetering en/of een toets waarbij gelijktijdig meerdere processen (ook die uit het blok realisatie van het product ) in onderlinge samenhang worden getoetst; - een procestoets is een toets op een proces behorend tot het blok realisatie van het product ; - een producttoets is een toets op de output van een proces ( meting op een product ) inclusief de confrontatie van deze uitkomst met de eigen verificatiecq. keuringsresultaten van de opdrachtnemer. Ga bij het maken van de toetsplanning in eerste instantie uit van de procesrisico s. Deze geven een goed beeld om de toetsen op systeem- en procesniveau te kunnen plannen. De onderliggende risico s gebruik je vervolgens vooral om in de voorbereiding van een systeem- of procestoets de diepgang aan te kunnen brengen. Op welke punten moet je tijdens je systeem- of procestoets de diepte ingaan, waar moet je je steekproeven nemen. Kijk hiervoor naar de onderliggende risico s die zijn gekoppeld aan de processen die je gaat toetsen. Daarnaast gebruik je vooral de onderliggende risico s voor het bepalen van je producttoetsen. Waar wil je door het uitvoeren van een producttoets de bevestiging krijgen dat de registraties van de opdrachtnemer betrouwbaar zijn? 2.10 Stap 10: Uitvoeren van toetsen Geen bijzonderheden behorend bij de aanpak met de procesbenadering Stap 11: Evalueren risico s per individuele toets Na de uitvoering van de toets worden de risico s die ten grondslag aan de toets hebben gelegen geëvalueerd; kunnen deze worden bijgesteld of blijven ze gelijk? Dit geldt zowel voor de procesrisico s als voor de onderliggende risico s Stap 12: Periodiek evalueren functioneren van het KMS van Opdrachtnemer Door het analyseren van de processen die onderdeel uitmaken van het KMS van de opdrachtnemer en deze vervolgens uit te werken naar procesrisico s en hier de toetsen uit af te leiden wordt het eenvoudiger een evaluatie van het functioneren van het KMS van de opdrachtnemer uit te voeren Stap 13: Periodiek evalueren van procesrisico s Naast de evaluatie van de risico s na het uitvoeren van een toets kunnen ook de procesrisico s in zijn geheel periodiek geëvalueerd worden. Dit komt neer op een herhaling van de eerder beschreven stap 2. De resultaten hiervan kun je in de tijd Pagina 11 van 13

12 zichtbaar maken. Meerdere projecten doen dit gelijktijdig met de evaluatie van het functioneren van het KMS van de opdrachtnemer (stap 12) en gebruiken dit vervolgens voor het opstellen en onderbouwen van de toetsplanning voor de volgende periode. Hiermee is de cyclus gesloten en ga je weer verder bij stap 9. Bijbehorende voorbeelden: 13.a Procesrisico s met oorzaak en gevolg voor aanleg en GVO Let op: het betreft hier een weergave van de mate waarin een proces risicovol is en niet een waardeoordeel over de mate waarin het proces goed functioneert. Het kan zijn dat een proces (bijvoorbeeld integrale veiligheid) heet goed functioneert maar dat je het toch als risicovol proces beschouwd (grote gevolgen). Pagina 12 van 13

13 3 Bijlagen Vanuit dit document wordt naar een aantal algemene voorbeelden en voorbeelden uit projecten verwezen: Algemeen A Presentatie Procesgericht risicomanagement ten behoeve van SCB Versie mei 2013 B Procesgericht risicomanagement ten behoeve van SCB in Riskscope. Hoe de (proces)risico s in de risicodatabase op te nemen. Versie 5.1 d.d. 2 april 2014 De onderstaande bijlagen zijn opgenomen in een excel-bestand waarin per tabblad één van de genoemde voorbeelden is opgenomen (herkenbaar aan de codering). Stap 1 1.a voorbeeld procesanalyse aanleg en GVO (D&C-contracten) 1.b voorbeeld procesanalyse onderhoud (prestatiecontracten) Stap 2 2.a voorbeeld risicowaardering processen N50 (D&C-contract) 2.b voorbeeld risicowaardering processen prestatiecontract droog Noord-Holland Stap 3 3.a Procesrisico s met oorzaak en gevolg voor aanleg en GVO 3.b Procesrisico s met oorzaak en gevolg voor vast en klein variabel onderhoud Stap 6 6.a voorbeeld koppeling van risico s N50 (D&C-contract) 6.b voorbeeld koppeling van risico s prestatiecontract droog Noord-Holland Stap a Dashboard procesrisico s N50 (D&C-contract) Pagina 13 van 13