Systeemgerichte contractbeheersing

Transcriptie

1 Systeemgerichte contractbeheersing ECO vooronderzoek naar ICT ondersteuning Rijkswaterstaat Bouwdienst Documentnummer : BSRAP-R Status : Definitief Datum : 09 mei 2005 Opsteller : I. Roos

2 1 Inhoud 1 Inhoud Samenvatting Uitgangspunten De samenhang met andere systemen Scope van een SCB systeem Scenario s voor ontwikkeling van een SCB systeem Aanbeveling Inleiding Opzet Systeemgerichte contractbeheersing De Methodiek De toetsen Het proces Projectenpraktijk ICT ondersteuning Functionele eisen SCB Processen Registeren van risico s Opstellen Toetsmix Uitvoeren toetsen Accepteren van geleverde resultaten Betaling Contractvormen en contractbeheersingsmethodiek Innovatieve contractvormen Standaard contractvormen Gevolgen voor systeem: Functionele eisen aan het systeem Technische Eisen Samenhangende systemen en ontwikkelingen Opstellen en onderhouden van contracten, betaling Projectmanagement Risicomanagement Functioneel Specificeren Bestar/Werk Bestaande applicaties en tools voor (deel van) SCB ATP Achtergrond Functionaliteit Ontwikkelingen rond ATP Technisch Tijd Kosten Voordelen Nadelen N Achtergrond Functionaliteit Ontwikkelingen rond het N31 systeem...29 Pagina 2 of 43

3 7.2.4 Technisch Tijd Kosten Voordelen Nadelen StraitVISI Achtergrond Functionaliteit Ontwikkelingen rond StraitVISI Technisch Tijd Kosten Voordelen Nadelen ProRail systeem Achtergrond Functionaliteit Ontwikkelingen rond ProRail systeem Technisch Tijd Kosten Voordelen Nadelen SAP Functionaliteit Ontwikkelingen in en rond SAP Technisch Tijd Kosten Voordelen Nadelen Scenario s Vaste onderdelen voor elk scenario: Analyse Scenario 0: Niets doen Aanpak Kosten scenario niets doen Voordelen Nadelen Scenario 1: SAP Aanpak Nadelen Scenario 2: N31 in combinatie met SAP Aanpak: Openstaande punten Aanbeveling...43 Pagina 3 of 43

4 2 Samenvatting 2.1 Uitgangspunten In het kader van Professioneel opdrachtgeverschap gaat RWS gebruik maken van de methodiek systeemgerichte contractbeheersing (SCB). In deze methodiek worden de contracteisen beheerst door gebruik te maken van de kwaliteitsborging van de opdrachtnemer. De opdrachtgever toetst het functioneren van het kwaliteitsplan van de opdrachtnemer (systeem- en procestoetsen) en de betrouwbaarheid van de registraties (producttoetsen). Er is behoefte aan RWS brede ICT oplossing om SCB te ondersteunen. Doel van dit vooronderzoek is het aandragen van de oplossingsrichting voor het ontwikkelen van een dergelijk ICT systeem. Uitgangspunten hierbij zijn: o Het systeem moet passen in de ontwikkeling van het totaal aan ICT oplossingen voor het gehele contractbeheersingsproces; o De basis voor gewenste functionaliteit zijn de ervaringen die binnen een aantal projecten zijn opgedaan met de systematiek van SCB en al bestaande ICT systemen. 2.2 De samenhang met andere systemen Om de juiste scope te bepalen voor het toekomstige SCB systeem, is gekeken welke processen samenhangen met systeemgerichte contractbeheersing. Voor (een deel van) deze processen zijn RWS breed systemen beschikbaar of in ontwikkeling. Daarom is ook gekeken met welke systemen behorende bij die processen eventueel gegevens uitgewisseld moeten worden. Zowel processen als systemen worden in onderstaande figuur getoond. Opstellen van Contracten VOC Onderhouden van Consys Contracten Risico Management Projectmanagement Functioneel Specificeren nieuw pakket Systeem gerichte contractbeheersing Betaling SAP Bestar / Werk Figuur 5 omgevingsscan Momenteel wordt een V&W brede architectuur ontwikkeld voor het totale inkoopproces. Hierin wordt o.a. vastgelegd welke systemen vervangen dienen te worden en welke delen van het inkoopproces in SAP belegd worden. Systeemgerichte contractbeheersing is ook onderdeel van deze architectuur. Omdat het systeemplaatje en daarmee ook de interfaces tussen de systemen nog onduidelijk zijn, zal bij de Pagina 4 of 43

5 ontwikkeling van het SCB systeem rekening worden gehouden met het functioneel kunnen verwerken en versturen van gegevens, maar worden er nog geen geautomatiseerde interfaces ontwikkeld. De systemen Bestar en Werk zijn gericht op hoeveelhedenadministratie en (technisch) sterk verouderd. Er is gekeken hoe deze applicaties vervangen kunnen worden, vanuit het uitgangspunt is dat er geen of nauwelijks nieuwe RAW bestekken bijkomen: Het rekenen met hoeveelheden wordt ondervangen door een (nieuw) marktpakket. Een gedeelte van de specifieke functionaliteit vervalt, omdat een aantal (risico) regelingen vervallen. Gezien het aantal en de grootte van de projecten dat nu nog met Bestar/Werk werkt, is het advies deze applicaties in een aantal jaar uit te faseren. 2.3 Scope van een SCB systeem Op basis van de ECO methodiek voor systeemgerichte contractbeheersing en ervaringen van een aantal grote projecten met innovatieve contracten, is bepaald welke functionaliteit een SCB systeem moet bieden: o Registreren van risico s (uitkomsten van risico analyse) o Registeren Toetsstrategie o Opstellen Toetsmix o Toetsen uitvoeren o Bevindingen registratie (inclusief afwijkingen) o Koppeling met prestatieverklaring / betalingschema (aanmaken onderbouwing prestatieverklaring voor betaaltermijn) Buiten het systeem vallen: o Risicomanagement (ondersteunen van bijv. de RISMAN methodiek) o Betalen o Onderhouden van betalingsregimes 2.4 Scenario s voor ontwikkeling van een SCB systeem Om te bepalen welke bestaande systemen interessant zijn om verder te bekijken, is gekeken naar vier belangrijke aspecten: 1. de mate waarin het systeem de gewenste SCB-functionaliteit al ondersteunt; 2. de te verwachten kosten voor ontwikkeling, implementatie en beheer; 3. de verwachte doorlooptijd van verdere ontwikkeling en implementatie; 4. de mate waarin de applicatie past binnen de RWS (ICT) standaarden; Het N31 systeem komt naar voren als systeem dat al de meeste functionaliteit biedt, de minste ontwikkelkosten en ontwikkeltijd in beslag neemt en voldoet aan de RWSbrede, technische eisen. SAP is eerste keus wat betreft RWS-standaard, maar scoort zowel op al bestaande functionaliteit als ontwikkelkosten en tijd als slechtste. Elk scenario waarin een systeem ontwikkeld wordt, zal moeten beginnen met eenzelfde stap, namelijk het vastleggen van gedetailleerde procesbeschrijvingen en specificaties. Dit vaste onderdeel wordt daarom eerst beschreven. Op basis van de bevindingen zijn de volgende scenario s uitgewerkt: Pagina 5 of 43

6 Vast onderdeel van alle scenario s: Analyse Scenario 0: De huidige situatie laten voortbestaan (niets doen); Scenario 1: Ontwikkeling in SAP; Scenario 2: Ontwikkeling in N31/SAP. Analyse Aanpak Aan de hand van bestaande procesbeschrijvingen, specificaties van bestaande systemen, interviews met deskundigen worden processen in kaart gebracht. Het analysetraject start met de organisatie van een representatieve klankbordgroep, waarin gebruikers van verschillende diensten meedenken en oordelen over de specificaties voor het SCB systeem. De ECO methodiek Systeemgerichte Contractbeheersing vormt hiervoor het kader. Kosten Intern / extern projectteam (320 uur * 100,-- p.u) ,-- Tijd Doorlooptijd 4 maanden Totaal aantal uren projectteam 320 uur Uren deskundigen 120 Scenario 0: Niets doen Aanpak Er wordt (voorlopig) geen RWS-breed systeem ontwikkeld dat contractbeheersing ondersteunt. Ieder project richt op eigen wijze het vastleggen van toetsstrategie, toetsplanning en resultaten, op basis van de SCB methodiek. Kosten De volgende uitgangspunten zijn bij de inschatting gehanteerd: Extra administratieve lasten wanneer er geen RWS breed systeem voor SCB ontwikkeld wordt per project, per betalingstermijn 1 tot 3 mandagen Twaalf projecten per jaar, met ieder 12 betalingstermijnen. De kosten van een manuur worden gehouden op 100,-- Eén op de drie projecten laat een eigen systeem ontwikkelen, kosten voor zo n applicatie zijn minimaal ,-- per project. Totale kosten per jaar, zonder ontwikkelen eigen systemen ,-- (1,5 dag * 800,-- per dag * 12 termijnen * 12 projecten) Geschatte ontwikkelkosten op projecten ,-- ( ,-- * 4 projecten) Totale kosten per jaar ,-- Tijd n.v.t. Pagina 6 of 43

7 Voordelen Besluit over standaardsysteem kan worden uitgesteld, totdat er meer duidelijkheid en ervaring in de organisatie is opgedaan met nieuwe contractvormen, de methodiek van systeemgerichte contractbeheersing, SAP. Nadelen Het ontbreken van een standaard ICT-tool bemoeilijkt het invoeren van een uniforme werkwijze voor systeemgerichte contractbeheersing, er wordt meer ruimte overgelaten aan eigen interpretatie. Wanneer zo n systeem er uiteindelijk wel komt, is het moeilijker alsnog een uniforme werkwijze door te voeren. Er is nu al veel vraag naar een tool voor het ondersteunen van contract beheersing. Wanneer er geen standaardtool beschikbaar komt, zal men per project zelf iets ontwikkelen, op papier of in Excel contractbeheersing blijven ondersteunen. Gevolg: per project worden extra kosten gemaakt voor ontwikkeling van een applicatie of voor extra tijd/capaciteit, hergebruik van ontwikkelde systemen wordt niet gegarandeerd. Deze extra kosten zijn hierdoor niet zichtbaar. Scenario 1: SAP Aanpak Parallel aan de procesbeschrijvingen wordt een onderzoek gedaan naar de mogelijkheden en onmogelijkheden van een aantal, door een SAP consultant geselecteerde, modules. In het bijzonder wordt naar Record management gekeken. Na procesbeschrijving wordt de gewenste functionaliteit in SAP ontwikkeld. Totdat het SAP systeem geïmplementeerd wordt, wordt op projecten op dezelfde manier doorgewerkt als dat nu gebeurt. De kosten hiervoor zijn voor rekening van de projecten zelf. Kosten Totale ontwikkelkosten ,-- ( 3200 uur * 150,-- p/u + inschatting licentiekosten ,--) Onderhoudskosten per jaar, geschat op 10% van totale ,-- ontwikkelkosten (excl. licentiekosten) Tijd Doorlooptijd (inclusief analyse traject) 15 maanden Totaal aantal uren projectteam 3200 uur Uren deskundigen 240 Voordelen Past in RWS beleid SAP tenzij voor bedrijfsvoeringsystemen Integratie met andere SAP systemen is eenvoudiger Mogelijk minder ontwikkelkosten voor tijdelijk systeem Nadelen Pagina 7 of 43

8 De ontwikkeling en implementatie van het SCB-systeem is afhankelijk van de beschikbare capaciteit van het SAP ontwikkelteam Doorlooptijd is, na procesbeschrijvingen, nog 1 jaar. Dit betekent dat projecten nog langer op de oude voet verder gaan met alle nadelen vandien (zelf iets ontwikkelen, extra kosten per project, geen uniforme werkwijze t.a.v. SCB) De SAP module die voor SCB gebruikt kan worden, levert geen functionaliteit maar bouwstenen om een maatwerksysteem te maken Geen van de systemen waarvoor deze module wordt gebruikt (ook buiten V&W), zijn op dit moment al in productie. Er is daardoor weinig tot geen ervaring met praktisch gebruik. Het ontwikkelen is duur Er is nu binnen RWS nog geen ervaring met het specifiek ontwikkelen van functionaliteit in SAP modules. Scenario 2: N31 in combinatie met SAP Aanpak Ontwikkeling N31 systeem: Parallel aan het analysetraject wordt bepaald welke contractvorm (licenties eigendom RWS, leasen van licenties, abonnement op services inclusief licenties etc.) met de leverancier van de N31 het beste is voor RWS. Op basis van de specificaties uit het analysetraject wordt de bestaande applicatie aangepast en uitgebreid. Er volgt een testperiode, waarin gebruikers de kans krijgen het systeem in een (simulatie) praktijksituatie te testen. Na deze periode volgt (technische) implementatie en is het systeem beschikbaar voor elk project. Ontwikkeling SAP: Ontwikkelingen rond SAP worden continu gevolgd, zowel binnen RWS (BVS) als daarbuiten (bijv. voorbeelden toepassingen bij andere organisaties). Of, en wanneer besloten wordt om de ontwikkeling in SAP te starten, hangt o.a. af van: Het moment waarop meer duidelijkheid is over de ontwikkeling van gerelateerde systemen in SAP en de benodigde gegevensuitwisseling met deze systemen; De beschikbaarheid van het RWS-SAP team bij BVS (wanneer is er capaciteit om met ontwikkeling SCB in SAP te beginnen); Het moment waarop zoveel ervaring met SAP is opgedaan dat ontwikkeling sneller en goedkoper kan. Kosten Totale ontwikkelkosten N ,-- Onderhoudskosten per jaar N ,-- Totale ontwikkelkosten SAP in 2 e stadium Nader te bepalen (Opnieuw ontwikkelen van totale systeem in SAP, of het ontwikkelen van interfaces) Tijd Doorlooptijd N31 (inclusief analysetraject) 7 maanden Doorlooptijd SAP in 2 e stadium Nader te bepalen Totaal aantal uren projectteam N uur Pagina 8 of 43

9 Uren deskundigen N Voordelen Het doorontwikkelen van het N31 systeem is aanzienlijk sneller dan ontwikkeling in SAP, waardoor er eerder een RWS breed, standaard systeem beschikbaar is dat een uniforme werkwijze ondersteund; Er kan eerst ervaring worden opgedaan met ontwikkelen in SAP en Recordmanagement in het bijzonder. De verwachting is dat meer ervaring betekent dat het ontwikkeltraject hiermee aanzienlijk sneller en daarmee goedkoper kan worden gerealiseerd. Nadelen Investering in tijdelijk systeem. Totale kosten (nog) niet bekend 2.5 Aanbeveling Om de invoering van een uniforme SCB werkwijze vanuit ECO te ondersteunen en te kunnen voldoen aan de vraag vanuit projecten naar een systeem dat het toetsproces ondersteunt is het gewenst op korte termijn een RWS breed systeem beschikbaar te stellen. Ontwikkeling van een SCB systeem in SAP laat te lang op zich wachten. Het N31 systeem kan binnen redelijke termijn voor heel RWS beschikbaar gesteld worden. Ook zijn de kosten voor ontwikkeling significant lager dan de SAP ontwikkelkosten. De tweede fase, het ontwikkelen van een SAP applicatie, is opportuun op het moment dat er voldoende capaciteit beschikbaar is om ook daadwerkelijk aan de ontwikkeling te kunnen beginnen en er meer ervaring is met de SAP module Recordmanagement. Ervaringen die worden opgedaan met het N31 systeem kunnen in een later stadium meegenomen worden in een te ontwikkelen SAP applicatie. Mogelijk leidt meer praktijkervaring met zowel SCB als ontwikkelen in SAP tot lagere ontwikkelkosten en tijd. Pagina 9 of 43

10 3 Inleiding In het kader van Professioneel opdrachtgeverschap gaat RWS gebruik maken van de methodiek systeemgerichte contractbeheersing om het inkoopproces zo goed mogelijk te beheersen. Er is behoefte aan RWS brede ICT die deze methodiek ondersteunen. In dit document wordt een voorstel gedaan voor een ICT oplossing waarmee contractbeheersing ondersteund kan worden tijdens de fase van opdracht. Binnen het project vooronderzoek ECO SCB wordt gekeken welke oplossingsrichting gekozen moet worden om een ICT systeem voor contractbeheersing in de fase van opdracht beheersen te ontwikkelen. Hierbij gelden de volgende uitgangspunten: o Het systeem moet passen in de ontwikkeling van het totaal aan ICT oplossingen voor het gehele contractbeheersingsproces o De basis voor gewenste functionaliteit zijn de ervaringen die binnen een aantal projecten zijn opgedaan met de systematiek van SCB en al bestaande ICT systemen o Er wordt gekeken naar al ontwikkelde ICT systemen die (een deel van) opdrachtbeheersing ondersteunen. Wellicht kan één van deze systemen als basis dienen voor verdere ontwikkeling, dan wel kunnen een aantal ideeën worden overgenomen. 3.1 Opzet In dit document staan de eisen beschreven, die aan een ICT systeem voor contractbeheersing worden gesteld. Hiertoe wordt eerst een korte beschrijving gegeven van Systeemgerichte contractbeheersing. Daarna worden kort de belangrijkste conclusies weergegeven uit de gesprekken met de verschillende projecten. Vervolgens worden kort de processen beschreven, die op basis van theorie en de gesprekken ondersteund moeten gaan worden, gevolgd door een lijst met functionele eisen, aangevuld met een aantal technische eisen. Er wordt kort beschreven met welke systemen er (in de toekomst) gegevens uitgewisseld moeten kunnen worden. Een apart onderwerp is de applicatie Bestar/Werk. Afhankelijk van het besluit over RAW bestekken, zal functionaliteit uit deze systemen wel of niet overgenomen moeten worden. Tevens moet nagedacht worden over eventuele conversies. De verschillende applicaties die zijn bekeken worden beschreven en beoordeeld op basis van de functionele en technische eisen. Hierbij wordt ook per systeem aangegeven wat de kosten, voor- en nadelen. Op basis van de scores volgen een aantal scenario s, gevolgd door een aanbeveling over het te volgen scenario. Voor een uitgebreide beschrijving van de methodiek Systeemgerichte contract beheersing wordt verwezen naar handreiking, hier volgt een korte beschrijving van de totale methodiek en wordt dieper ingegaan op de theorie en praktijk met opdrachtbeheersing. Pagina 10 of 43

11 4 Systeemgerichte contractbeheersing 4.1 De Methodiek Bij systeemgerichte contractbeheersing (SCB) worden de contracteisen beheerst door gebruik te maken van de kwaliteitsborging van de opdrachtnemer. De opdrachtgever toetst het functioneren van het kwaliteitsplan van de opdrachtnemer (systeem- en procestoetsen) en de betrouwbaarheid van de registraties (producttoetsen) De toetsen De toetsing vindt plaats door met enige regelmaat systeemtoetsen uit te voeren, aangevuld met proces- en producttoetsen. Onderstaande figuur geeft op hoofdlijnen de drie invalshoeken van de mix van toetsen. figuur 1 Een systeemtoets toetst het functioneren van het kwaliteitsplan van de opdrachtnemer zodat de opdrachtgever een oordeel kan vellen over het functioneren van de kwaliteitsborging (met als belangrijk aspect het corrigerend vermogen) bij de opdrachtnemer. De minder risicovolle aspecten van de eisen worden door middel van de systeemtoets ondervangen. Een systeemtoets heeft de vorm van een audit. Procestoetsen zijn gericht op risicovolle processen c.q. processtappen. Een procestoets toetst of de werkprocessen (het verdichten van zand, het walsen van asfalt e.d.) die in het kwaliteitsplan worden genoemd, ook volgens opgave worden uitgevoerd en beheerst. Toetsen op procesniveau richten zich bijvoorbeeld op de vereiste vakdeskundigheid, specifieke richtlijnen of rekenhulpmiddelen, volledige en juiste uitgangspunten, aansturing van de werkzaamheden, controles en corrigerende maatregelen. Procestoetsen kunnen ook observaties zijn tijdens het uitvoeren van werkzaamheden (rondje werk). Bij producttoetsen toetst de opdrachtgever producten (zelf keuren, nameten, narekenen, etc.) en vergelijkt de uitkomsten met de eisen uit het contract en met de registraties die de opdrachtnemer heeft (keurings-, meetregistraties, berekeningen, etc.). Doel is om de betrouwbaarheid van de gegevens van de opdrachtnemer te verifiëren en dus niet om het voldoen aan de eisen vast te stellen. De toetsen volgen uit de borging van de werkwijze van de opdrachtnemer (het kwaliteitsplan), risicovolle processen (risicoanalyse) en de eisen aan de gerealiseerde producten (o.a. duurzaamheid, risicoprofiel). Pagina 11 of 43

12 4.1.2 Het proces Systeemgerichte contractbeheersing grijpt in op het RWS-inkoopproces door een aantal stappen in het inkoopproces specifieker in te vullen. Voor een aantal andere stappen geldt geen specifieke(re) invulling. Figuur 2 toont het standaard inkoopproces en het inkoopproces waarin systeemgerichte contractbeheersing wordt toegepast Voor een beschrijving van het totale inkoopproces wordt verwezen naar de POG-site. Hieronder wordt aangegeven welke stappen van het inkoopproces van belang voor systeemgerichte contractbeheersing. Inkoopproces Systeemgerichte contractbeheersing I Vaststellen inkoopbehoefte Rijkswaterstaat I Vaststellen inkoopbehoefte Opdrachtnemer Opdracht voorbereiden II Opstellen inkoopplan III Opstellen contract, beheersplan en raming II III Opstellen inkoopplan Opstellen contract, beheersplan en raming Uitvoeren Risico analyse IV Aanbesteden IV + V Aanbesteden en gunnen Opdracht verlenen V Gunnen VI Actualiseren risicoanalyse Opdracht beheersen VI VII VIII Voorbereiden contractuitvoering en -beheersing Vaststellen geleverde prestatie Betalen VI Afstemmen risicoanalyse Invullen VI contract Beoordelen Opstellen kwaliteitsplan beheersing kwaliteitsplan VII Vaststellen Uitvoeren volgens geleverde prestatie kwaliteitsplan en contract VIII Betalen Opleveren en factureren Opdracht afronden IX X Evalueren Afsluiten opdracht IX X Evalueren Afsluiten opdracht Evalueren Figuur 2: inkoopproces & Systeemgerichte contractbeheersing Stap I Vaststellen van de inkoopbehoefte. In dit stadium komt contractbeheersing nog niet aan bod. stap II Opstellen inkoopplan. Hierbij wordt ook bepaald welke contractbeheersings-strategie gehanteerd gaat worden. stap III Opstellen van een contract, raming en een contractbeheersingsplan. Een belangrijke activiteit binnen deze stap is (het actualiseren van) de risico analyse. Deze vormt de basis voor het contractbeheersplan, waarin ook een eerste uitwerking van de mix van systeem-, proces- en producttoetsen in een concept toezichtsmatrix. Stap IV Aanbesteden. Marktpartijen dienen hun inschrijving in. Systeemgerichte contractbeheersing is in deze fase zichtbaar in de criteria die aan de marktpartijen worden meegegeven. Pagina 12 of 43

13 Stap V Gunnen. De inschrijvingen worden getoetst aan de gunningscriteria en de raming. Na accordering van het gunningsadvies wordt overgegaan tot gunning. De opdrachtgever en nemer sluiten het contract voor de uit te voeren opdracht. Stap VI Het voorbereiden van contractuitvoering en beheersing. De risico s en beheersmaatregelen, het contractbeheersingsplan met toezichtmatrix worden geactualiseerd. De toezichtsmatrix wordt zover uitgewerkt, dat vaststaat wat er getoetst wordt, met welke frequentie en (afgestemd op de planning van de opdrachtnemer) wanneer. Stap VII Vaststellen geleverde prestatie. Tijdens de uitvoeringsfase worden op basis van de toezichtsmatrix systeem-, proces- en producttoetsen uitgevoerd. De bevindingen die hieruit komen, worden gebruikt om te beoordelen of de opdrachtnemer volgens contract en kwaliteitsplan werkt. De opdrachtnemer wordt aangesproken op het al dan niet functioneren van de kwaliteitsborging. De bevindingen van de toetsen kunnen aanleiding vormen om risico s te actualiseren en de toezichtsmatrix aan te passen. Bij het bereiken van een betalingstermijn wordt een prestatieverklaring opgesteld op basis van het geheel van systeem-, proces-, en producttoetsen. Stap VIII Betalen. De opgestelde prestatieverklaring uit stap VII wordt vergeleken met de ingekomen factuur en met de bepalingen in het contract. Wanneer deze vergelijking geen afwijkingen laat zien kan worden overgegaan tot betaling volgens het vooraf bepaalde betalingsregime. Stap IX Evalueren. Projectinformatie wordt verzameld en geanalyseerd. Vervolgens kunnen de evaluatiegegevens worden verwerkt in een rapportage en, na goedkeuring, worden overgedragen aan kenniscentra. Het evaluatietraject is voor een project waarbij systeemgerichte contractbeheersing wordt gehanteerd, niet anders dan voor andere methodieken. 4.2 Projectenpraktijk Tijdens het onderzoek is gesproken met projectleiders van verschillende projecten, waarin op één of andere manier systeemgerichte contractbeheersing wordt toegepast. In de beschrijving van de functionele eisen zijn de resultaten (welke eisen worden gesteld) opgenomen, hieronder volgt een korte samenvatting van de resultaten. Samengevat komen de volgende globale algemene kenmerken over de werkwijze naar voren: o Vanaf de start van het project worden risico s ingeschat, geregistreerd en beheerst. o Bij alle projecten geldt dat de risico s worden gerelateerd aan een fase, (hoofd)proces of processtap en/of aan een specifiek object. o Op basis van de (projectspecifieke) eisen en de risico s wordt gekeken wat en hoe er getoetst wordt. o Welke risico s uiteindelijk uitmonden in toetsen, is project afhankelijk. De contractvorm (en daarmee de verdeling van verantwoordelijkheid en risico s) die tussen opdrachtgever en opdrachtnemer is afgesproken speelt hierbij een belangrijke rol. Pagina 13 of 43

14 o Het samenstellen van de juiste mix aan toetsen is een complexe taak. Een systeem kan hier hooguit ondersteunend en signalerend zijn, maar kan geen toetsen afdwingen. o Resultaten die worden verkregen uit toetsuitvoering kunnen reden zijn tot het aanpassen van het toetsplan en/of de toetsplanning (bijv. omdat de frequentie van de toetsen omlaag kan). o Bevindingen uit toetsen leiden tot het opnieuw uitvoeren van (dezelfde) toetsen, of het verwerken van afwijkingen, wat weer leidt tot nieuwe toetsen. o Elk project ken zijn eigen afgesproken bepalingen over betalingen en betalingsregimes. De (hoogte van) betalingen zijn gekoppeld aan uitkomsten van toetsen (en daarmee aan het wel of niet voldoen aan de eisen), maar deze koppeling kan ook indirect zijn. o Het beoordeling van toetsresultaten en eventuele gevolgen voor het betalingsregime zijn de verantwoordelijkheid van de projectleider en toetsers, een systeem kan hier hooguit ondersteuning bieden d.m.v. een signalering ICT ondersteuning Binnen alle projecten is behoefte aan een ICT oplossing die contractbeheersing ondersteund. In vrijwel alle gesprekken kwam als gewenste functionaliteit in ieder geval het onderhouden van risico s, het definiëren van toetsen bij risico s, het plannen van toetsen, vastleggen toetsresultaten en afwijkingen en het genereren van managementoverzichten uit deze informatie. Zowel het N31-systeem als ATP zijn speciaal hiervoor ontwikkelde applicaties, die beide nu voor het eerst in echte projectsituaties gebruikt (gaan) worden. Bij de N11 en het HSL project werd vooral gebruik gemaakt van Excel. Pagina 14 of 43

15 5 Functionele eisen SCB 5.1 Processen Kijkend naar zowel de theoretische beschrijving als de interviews over de praktijkprojecten, zal het SCB systeem de volgende functionaliteit moeten bieden: o Registreren van risico s (uitkomsten van risico analyse) o Registeren Toetsstrategie o Opstellen Toetsmix o Toetsen uitvoeren o Bevindingen registratie (inclusief afwijkingen) o Koppeling met prestatieverklaring / betalingschema (accepteren en betalen) Buiten het systeem vallen: o Risicomanagement o Betalen en onderhouden van betalingsregimes Registeren van risico s. Er is niet ingegaan welke methode er gebruikt is om risico s in te schatten, behalve bij het N31 project. Binnen dit project worden risico s in drie klassen ingedeeld: o Risico s die bij de opdrachtgever liggen (interne kwaliteitsborging); o Risico s die bij de opdrachtnemer liggen en die verder geen gevolgen hebben voor de opdrachtgever. Deze zijn voor de opdrachtgever niet interessant; o Risico s waarvan de beheersmogelijkheden bij de opdrachtnemer liggen, maar die wel van belang zijn voor de opdrachtgever. Deze zijn onderwerp van de externe kwaliteitsborging. Alleen de laatste categorie zijn van belang voor systeemgerichte contractbeheersing. Risico s zijn gerelateerd aan processen, processtappen, en objecten. De relatie tussen risico s, processen, eisen en objecten zoals gebruikt in het N31 project is hieronder weergegeven: Proces Eis Risico Object Figuur 3: Relatie tussen eis, proces, object en risico. Vanaf het maken van een inkoopplan wordt begonnen met het inschatten van risico s en gedurende het gehele project worden risico s toegevoegd, gewijzigd of verwijderd. Gedurende het traject gaat men van risico s op het niveau van het totale werk naar risico s op onderdelen, de werkprocessen en de kwaliteitsborging van de opdrachtnemer. Het aanvullen en actualiseren van de risico analyse is daarmee een steeds terugkomende activiteit, afhankelijk van het verloop van de contractuitvoering. Risico management is een proces op zich, met een eigen onderliggende methodiek. Voorstel is om in het contractbeheersingssysteem te beginnen met eenvoudige Pagina 15 of 43

16 risicoregistratie, zodat de koppeling met toetsen gemaakt kan worden zonder het risico-analyseproces in detail te ondersteunen Opstellen Toetsmix Vanuit de eisen en de risico analyse wordt (per hoofdproces) een toetsstrategie ontwikkeld, die de basis vormt voor de toezichtsmatrix (wat wordt getest en hoe). Contract eis Risico Toets Figuur 4: Relatie tussen contracteisen, risico s en toetsen Het samenstellen van de gewenste mix van systeem-, proces- en producttoetsen voor een specifiek traject is de verantwoordelijkheid van de directie UAV. Van elke toets wordt vervolgens de frequentie bepaald, de benodigde capaciteit en middelen en worden (afhankelijk van de planning van de opdrachtnemer) de toetsen in de tijd ingepland. Het aanpassen van contractbeheeringsplan en de toezichtmatrix is een steeds terugkomende activiteit, bijvoorbeeld na het actualiseren van de risico s of n.a.v. toetsresultaten Uitvoeren toetsen De toetsen worden op basis van de toezichtmatrix uitgevoerd. De resultaten van de toetsen moeten worden vastgelegd, zodat de toets achteraf navolgbaar is. Uit de toetsresultaten blijkt of er sprake is van een afwijking. Een afwijking is een proces, beheersingsmaatregel of product dat niet op de voorgeschreven wijze tot stand komt en/of niet voldoet aan een gespecificeerde eis. Hoe het afwijkingenproces precies verloopt en welke documenten daarbij horen, is afhankelijk van de consequenties die het afwijkingsvoorstel heeft voor planning, kwaliteit en budget. Bij elke afwijking wordt gekeken of dit leidt tot het opnieuw plannen van bestaande toets of het definiëren en inplannen van een nieuwe. Ook kunnen toetsen vervallen, wanneer ze niet meer van toepassing zijn op de nieuw ontstane situatie. De toetsresultaten kunnen aanleiding zijn om voor een andere samenstelling van toetsen in soort en frequentie te kiezen, zowel in positieve als negatieve zin, bijv: Toetsresultaten zijn positief, waardoor vertrouwen in de opdrachtnemer zo toeneemt dat besloten wordt minder vaak te toetsen; Er worden zo vaak afwijkingen geconstateerd dat besloten wordt vaker te toetsen en meer toetsen toe te voegen. Ook het risicodossier wordt actueel gehouden op basis van informatie uit de toetsen. Wanneer de toetsresultaten daartoe aanleiding geven, kan besloten worden de in het contractvermelde sanctiemaatregelen toe te passen. Voorbeelden hiervan zijn: Stopzetten van de betaling. Pagina 16 of 43

17 Inzet van een OFA op kosten van de opdrachtnemer. Stilleggen werkzaamheden totdat bepaald tussenresultaat is opgeleverd en voldoet aan de eisen. Toepassen van kortingen op aanneemsom. Instellen van meer stoppunten. Uitbreiden hoeveelheid aan te tonen eisen. Extra toezicht op kosten van de opdrachtnemer. Sancties kunnen gevolgen hebben voor de mix aan toetsen (het extra toetzicht), de (toets)planning, betaling etc Accepteren van geleverde resultaten Wanneer het werk gereed is, wordt op basis van de toetsresultaten besloten de resultaten al dan niet te accepteren. Afhankelijk van de betalingsregeling die is overeengekomen vinden naast de eindacceptatie er doorgaans ook tussentijdse acceptaties plaats van (deel)resultaten. Acceptatie van resultaten van de opdracht moet formeel worden vastgelegd en met de opdrachtnemer worden gecommuniceerd. In een prestatieverklaring wordt omschreven welke resultaten zijn geaccepteerd en dus mogen worden gefactureerd. Als de opdrachtnemer tijdens de uitvoering voor een aantal contracteisen schriftelijk heeft moeten aantonen dat aan de eisen voldaan werd, dient deze informatie als input voor het al dan niet accepteren van resultaten. De informatie moet worden gecontroleerd op tijdigheid en volledigheid in de toezichtsmatrix kan zijn opgegeven dat de informatie op betrouwbaarheid wordt geverifieerd door middel van een producttoets Betaling Betaling kan pas plaatsvinden, wanneer de prestatie die aan de betaling is gerelateerd, geleverd is. Betaling vindt meestal plaats door onderverdeling in betaalposten, van welke soort dan ook (hoeveelheden, afgeleverd werk, voortgang, beschikbaarheid van de weg).voor sommige projecten is de relatie tussen betaalpost en toetsresultaat 1 op 1. Voor andere is die relatie indirect. De mogelijke betalingsregimes en de verschillende consequenties van verschillende sancties zouden nog verder uitgediept moeten worden, wil het systeem deze kunnen ondersteunen. Voor een eerste versie lijkt het verstandig om betaalposten (incl. bedragen) door gebruiker te laten definiëren en aanpassen. 5.2 Contractvormen en contractbeheersingsmethodiek Innovatieve contractvormen De keuze voor een contractbeheersingsstrategie gebeurt op basis van een combinatie van de volgende factoren: de complexiteit van het werk, de risico s van het werk, de duurzaamheid van het product. Pagina 17 of 43

18 Bij de beheersing van de innovatieve contractvormen schrijft RWS voor dat gekozen wordt voor Systeemgericht beoordelen van de kwaliteit van het werk van de opdrachtnemer, dat wil zeggen door gebruik te maken van de kwaliteitsborging bij de opdrachtnemer Standaard contractvormen Voor inkoop zal zoveel mogelijk gebruik gemaakt gaan worden van een contractenbuffet, met daarin standaard (raam)contracten. De keuze voor een bepaalde contractvorm hangt af van de risico's, en waar die het beste kunnen worden gelegd. Bijvoorbeeld: voor incidentmanagement wordt gebruik gemaakt van een raamcontract; voor vast onderhoud wordt gebruik gemaakt van prestatiecontracten, voor variabel onderhoud van E&C-contracten. Op basis van pilots wordt gekeken naar de mogelijkheden van koppeling van variabel en vast onderhoud in gestandaardiseerde contractvormen; voor aanleg is D&C een standaardvorm. voor beleidsondersteuning en advisering wordt gebruik gemaakt van prestatiegerichte raamcontracten. RAW-bestekken (hoeveelheden) worden naar verwachting in de toekomst nog maar in een zeer klein percentage gebruikt. De manier van toetsen die bij dit soort bestekken gebruikt wordt, past binnen de methode van productgericht toetsen, als is het doel van deze toetsen bij RAW bestekken niet zozeer gericht op controle van het proces. Voor het relateren van toetsen aan betalingen en het ondersteunen van betaalposten, geldt een aparte werkwijze voor RAW. In hoeverre RAW bestekken ondersteund dienen te worden, is nog onderwerp van besluitvorming Gevolgen voor systeem: Het nieuwe systeem ondersteunt alleen Systeemgerichte contractbeheersing. Dit betekent dat het alle toetssoorten (systeemtoets, procestoets en producttoets) ondersteund worden, in elke gewenste combinatie. 5.3 Functionele eisen aan het systeem Globaal gezien is de gewenste functionaliteit in te delen in de volgende categorieën: Risico s Toetsen Afwijkingenregistratie Betaalposten Rapportages Documentbeheer Gebruikers en Autorisatie Op meer gedetailleerd niveau werden de volgende eisen genoemd: Risico s registreren, aanpassen tijdens gehele project. Risico s zijn gekoppeld aan één of meerdere categorieën (risico s per hoofdproces, processtap en/of object) Pagina 18 of 43

19 Bij een risico kan een motivatie, weging en kans aangegeven kunnen worden. Risico s kunnen worden gekoppeld aan toetsen en v.v., zodat per risico duidelijk is welke toetsen erbij horen en per toets welke risico s afgedekt worden. (koppeling risico s en toetsen n:m) Risicomanager kan aangeven welke risico s getoetst zouden moeten worden. Wanneer bij zo n risico geen toets gedefinieerd is, geeft het systeem een duidelijke signalering. De beslissing of een risico tot een toets moet leiden, is niet te automatiseren maar behoeft altijd menselijke interactie. (inschatting van de deskundige). Het moet mogelijk zijn om aan te geven dat het toetsen van het risico noodzakelijk is (bijv. door risicomanager). Wanneer er geen toetsen voor gedaan worden, dient bij de risico s aangegeven te worden waarom niet. Systeem maakt zichtbaar of de risico s zijn afgedekt met toetsen Systeem maakt zichtbaar of aan te tonen eisen afgedekt zijn door toetsen. Het systeem kan hooguit een ondersteunende rol spelen bij het samenstellen van de juiste mix van systeem-, proces- en producttoetsen, bijv. door aan te geven dat bepaalde eisen en/of risico s niet gerelateerd zijn aan een toets of v.v. Het inplannen van toetsen wordt ondersteund (datum en capaciteit). Resultaten van toetsen worden vastgelegd. Eventuele relevante documenten van de opdrachtnemer en opdrachtgever worden aan het resultaat gekoppeld (door registratie, een link, ) Afwijkingen registratie, inclusief status Er wordt geen dwingende link in het systeem gelegd, de directie UAV bepaalt of er sancties worden toegepast en zo ja, welke. Het systeem zou hoogstens een signalering kunnen geven. Betaalposten moeten per project gedefinieerd kunnen worden, aangezien ze per project kunnen verschillen. Betaalposten kunnen gedurende het hele project worden opgevoerd, aangepast en verwijderd. Het systeem biedt een overzicht van de toetsresultaten vanuit verschillende invalshoeken (object, fase, periode, proces). Het systeem genereert periodieke overzichten voortgang (termijnstaten) op basis van betaalposten. Er worden verschillende betalingsregimes gehanteerd: voortgang, voldaan aan lijst van projectspecifieke eisen, periodiek, een combinatie van voorgaande (en deze lijst zal nog niet uitputtend te zijn) Wanneer er afwijkingen plaatsvinden die van invloed zijn op één betaling (bijv. een betaling wordt gedeeltelijk gedaan, of opgeschoven in de tijd), kan dit gevolgen hebben voor het totale betaalschema. Het is op dit moment nog niet duidelijk hoe deze consequenties precies worden berekend. Er moet een relatie tussen toetsen en betaalposten gelegd kunnen worden, maar deze is niet verplicht. Het systeem maakt gebruik van autorisatie op functie om te bepalen of een gebruiker geautoriseerd is om gegevens aan te passen. het systeem moet zowel via internet als intranet beschikbaar zijn, onafhankelijk van locatie; Pagina 19 of 43

20 5.4 Technische Eisen Internet/Intranet Het systeem moet locatie onafhankelijk te benaderen zijn. Dit betekent dat er geen installaties op client-zijde noodzakelijk zijn en beveiliging/autorisatie gebonden zijn aan de inloggegevens; Het systeem moet vooral ook bereikbaar zijn vanaf de bouwplaatsen en moet ook een bepaalde snelheid over het internet kunnen halen..net SQLserver of MySQL 6 Samenhangende systemen en ontwikkelingen Systeemgerichte contractbeheersing staat niet op zichzelf, maar hangt samen met andere processen. In onderstaand figuur worden de processen getoond in combinatie met de systemen die deze ondersteunen. Voor Systeemgerichte contractbeheersing is nog geen RWS breed systeem, wel is er de combinatie van Bestar en Werk voor het beheersen van RAW bestekken. Opstellen van Contracten VOC Onderhouden van Consys Contracten Risico Management Projectmanagement Functioneel Specificeren nieuw pakket Systeem gerichte contractbeheersing Betaling SAP Bestar / Werk Figuur 5 omgevingsscan Voor (een deel van) deze processen zijn RWS breed systemen beschikbaar of in ontwikkeling. Momenteel wordt een nieuwe architectuur ontwikkeld voor het inkoopproces. Eén van de aspecten die hierin onderzocht worden, is of de verschillende systemen van het inkoopproces in de architectuur passen en welke delen hiervan al dan niet in SAP ontwikkeld moeten worden. Ook het systeem dat contractbeheersing zal gaan ondersteunen, zal binnen deze architectuur geplaatst worden. Hieronder wordt kort aangegeven wat de invloed is van deze processen en applicaties op de ontwikkeling van een applicatie voor systeemgerichte contractbeheersing. Pagina 20 of 43

21 6.1 Opstellen en onderhouden van contracten, betaling Het SCB systeem heeft als input vanuit het inkoopproces gegevens nodig over de contracteisen en de bestellingen (betaaltermijnen) waarin het contract is verdeeld. Tijdens het proces van contractbeheersing kunnen er voorstellen worden gedaan om het wijzigingen op contracteisen of bestellingen door te voeren. Het besluitvormingsproces rond het al dan niet accepteren van deze afwijkingen ligt (grotendeels) buiten het SCB systeem. Wanneer ze worden geaccepteerd, dienen de gewijzigde gegevens vanuit de inkoopsystemen doorgegeven te worden aan het SCB systeem. Het systeem levert de onderbouwing voor de prestatieverklaring en daarmee de gegevens voor SAP om de prestatie al dan niet te accepteren. Een en ander is samengevat in onderstaand figuur. Systemen voor contractgegevens, betaling/ facturatie (VOC, Consys, SAP) contractgegevens (gegevens bestelling) wijzigingen op contract (op bestelling) prestatie verklaard ja/nee SCB Figuur 6: gegevensuitwisseling tussen SCB en de omgeving Er zijn momenteel twee systemen die het opstellen en onderhouden van contracten ondersteunen, VOC en Consys: VOC (Vereenvoudigd Opstellen van Contracten) stuurt de gebruiker bij het opstellen van contracten. In de applicatie Consys worden contract gegevens en mutaties vastgelegd. De financiële systemen(en daarmee betaling) zijn momenteel al in SAP gerealiseerd. In de nieuwe RWS organisatie, waarin met toe wil naar nieuwe contractvormen en een contractenbuffet waarin een aantal standaard contractvormen zijn opgenomen, voldoen het huidige VOC en Consys niet meer. Beide systemen zijn daarom ook onderdeel van het architectuur onderzoek zoals hierboven beschreven. Het SCB systeem zal gebruik maken van en gegevens uitwisselen met de opvolgers van VOC en Consys. Bij de ontwikkeling van het SCB systeem wordt rekening gehouden met het ontwikkelen van een interface om contractgegevens uit te wisselen ( al dan niet in VOC en/of Consys) in een later stadium. Dit betekent dat in eerste instantie deze gegevens handmatig in het systeem gezet zullen worden, maar dat de vervanging door een automatische interface het systeem verder niet aangepast hoeft te worden. De minimale gegevensuitwisseling met betaling bestaat uit het oversturen van de melding dat een prestatie is goedgekeurd en het vinkje in SAP gezet kan worden. Of dit automatisch dan wel handmatig gebeurt is onder andere afhankelijk van het Pagina 21 of 43

22 werkproces: bijvoorbeeld of menselijke tussenkomst nog vereist is voordat het vinkje in SAP wordt gezet. 6.2 Projectmanagement De link tussen systeemgerichte contractbeheersing en projectmanagement bestaat voornamelijk uit het bewaken van de toetsplanning en de gevolgen die de toetsresultaten kunne hebben voor planning, budget en scope (bijvoorbeeld omdat een afwijking tot een contractmutatie leidt). Verschillende aspecten van projectmanagement zijn in verschillende RWS brede tools terug te vinden, zoals PPS (project planning systeem, waarin capaciteit geregeld wordt) en MS Project. Vooralsnog is geen gegevensuitwisseling tussen SCB en een specifiek projectmanagementsysteem geïdentificeerd. 6.3 Risicomanagement Risicomanagement en systeemgerichte contractbeheersing hebben een sterke onderlinge samenhang. De resultaten van de risicoanalyse (de geïdentificeerde risico s en de bijbehorende inschatting wat betreft kans en gevolg) zijn de basis om te bepalen welke toetsstrategie moet worden opgezet en welke toetsen worden ingepland. Omgekeerd kunnen de toetsresultaten aanleiding zijn om de risico analyse bij te stellen. Er is geen systeem dat specifiek de risicomanagement methode ondersteund. Voorlopig zal in het SCB systeem dan ook de risico s handmatig moeten worden ingevoerd. Er zal rekening gehouden worden met een latere automatische interface. 6.4 Functioneel Specificeren In het proces functioneel specificeren worden de eisen bepaald, die inhoudelijk/ technisch gezien aan het gewenste werk gesteld worden. De specificaties vormen het startpunt voor het gehele inkoopproces: Deze eisen bepalen bijvoorbeeld voor een groot deel de inhoud van het contract. Vanuit systeemgerichte contractbeheersing vormen de eisen het startpunt voor de risico analyses, toetsstrategie en toetsplannen. Vanuit contractbeheersing kunnen geconstateerde afwijkingen weer resulteren in gewijzigde eisen. De werkwijze rond functioneel specificeren is nog niet zijn uitontwikkeld en ingeburgerd in de organisatie. Voor functioneel specificeren loopt momenteel een selectietraject om RWS breed een pakket te implementeren. Voor het SCB systeem geldt, dat de eisen op een of andere manier in het startpunt zal in staat moeten zijn om in een later stadium eisen uit een systeem voor functioneel specificeren over te kunnen nemen. Pagina 22 of 43

23 6.5 Bestar/Werk Bestar en Werk zijn applicaties waarmee de besteksadministratie wordt ondersteund voor bestekken, waar gerekend wordt met hoeveelheden (zoals RAW, RAW+). De technologie van deze applicaties is verouderd en daarmee ongeschikt om als basis voor een contractbeheersingssysteem te dienen, dat alle soorten contracten ondersteunt. Het is daarom noodzakelijk te bepalen welke functionaliteit uit Bestar/Werk ook in een nieuw contractbeheersingssysteem moet worden meegenomen Functionaliteit In Werk worden de daghoeveelheden omgerekend naar weekhoeveelheden, vervolgens worden hoeveelheden die door de opdrachtnemer worden verstrekt, vergeleken met die van de toezichthouder. Als na deze controle de hoeveelheden worden goedgekeurd, worden ze in Bestar geregistreerd (dit kan ook handmatig, ook dan kunnen hoeveelheden nog vergeleken worden) en gekoppeld aan besteksposten en prijzen. In Bestar is de logica opgenomen om voor de verschillende typen betaalposten de benodigde verrekeningen te maken, rekening houdend met UAV, RAW en RWS regelgeving. Ook kunnen termijnstaten en de eindafrekening worden gemaakt. Bestar is niet gericht op het vaststellen van de rechtmatigheid, of het aanmaken van een prestatieverklaring. De werkwijze (incl. de manier waarop nummers worden uitgegeven en de verschillende berekeningen) van Bestar is goedgekeurd door accountants. De toekomst en Bestar/Werk In hoeverre het nieuwe contract beheersingssysteem de functionaliteit van Bestar/Werk moet vervangen, is deels afhankelijk van de keuze om RAW bestekken wel of niet meer te ondersteunen. Hierbij zijn de volgende overwegingen van belang: Wat is de omvang van RAW contracten in de toekomst? Momenteel zijn een substantieel deel van alle contracten RAW contracten, die nog een tijd kunnen doorlopen (laatste: 2010). Vanaf 2006 gaat dit aantal sterk afnemen, nieuwe RAW contracten worden tot een minimum beperkt. Welke functionaliteit moet uit Bestar/Werk worden overgenomen? Bij RAW bestekken gaat om een grote hoeveelheid posten, waarbij veel rekenwerk komt kijken. Er is daardoor een grote kans op fouten. In Bestar zit veel kennis hoe er met bepaalde regels/afspraken gerekend moet worden, wanneer men met aparte spreadsheets werkt, blijkt dat niet altijd alle regels bekend zijn en worden meegenomen. Hieronder staan de belangrijkste functionaliteit van Bestar/Werk opgesomd, met daarachter de manier waarop deze bij het verdwijnen van Bestar/Werk opgevangen kunnen/moeten worden. Automatisch confronteren van hoeveelheden; Automatisch laten rekenen met risicoregelgeving; Verrekenen van besteksposten met daarin automatisch de UAV-, standaard RAWen RWS regelgeving; Verrekenen van voortgang op betaalposten. Pagina 23 of 43

24 Vanuit ECO is aangegeven dat er gewerkt gaat worden met een nieuwe methodiek om hoeveelheden te verrekenen en te confronteren (OQS). De risicoregelingen (hoe om te gaan met prijsverschillen in de toekomst voor lonen, brandstoffen en materialen) worden binnen RWS hoogstwaarschijnlijk niet meer toegepast. Deze functionaliteit hoeft dus niet overgenomen te worden in een nieuw contractbeheersingssysteem. Het verrekenen van voortgang op betaalposten zal ook in het nieuwe SCB systeem opgenomen moeten worden. Ook het verrekenen van besteksposten, meer- en minderwerk, etc., zal op één of andere manier terugkomen in het SCBsysteem, al zal dit niet alleen op RAW gericht zijn. Wanneer het SCB systeem en de OQS methodiek geïmplementeerd zijn, is Bestar/Werk niet meer nodig voor nieuwe projecten. Het converteren van projecten die al in Bestar/Werk zijn ingevoerd naar het nieuwe systeem betekent echter veel werk, het lijkt beter Bestar/Werk in een aantal jaar uit te faseren. Functionaliteit wordt overgenomen door het nieuwe contractbeheersingssysteem, voorzover deze ook voor andere contractvormen van toepassing is (zoals verrekenen van voortgang op betaalposten). Pagina 24 of 43

25 7 Bestaande applicaties en tools voor (deel van) SCB Vanuit de projecten, die binnen dit onderzoek meegenomen zijn, komen drie systemen naar voren die in meer of mindere mate contractbeheersing ondersteunen: ATP, N31 systeem en StraitVISI. Daarnaast is gekeken naar een systeem dat bij Prorail gebruikt wordt (omdat de projecten in deze organisatie in zekere zin vergelijkbaar zijn met de projecten bij RWS) en naar SAP, omdat RWS breed geldt: SAP, tenzij. Hieronder wordt voor elk van deze systemen beschreven: de achtergrond, de al bestaande en mogelijk functionaliteit, indien van toepassing toegespitst op de verschillende onderdelen van SCB, de technische aspecten, de lopende ontwikkelingen, een overzicht van de reeds gemaakte kosten en ontwikkeltijd, een globale inschatting van de te verwachten ontwikkelkosten indien het systeem (verder) ontwikkeld wordt om SCB te ondersteunen, de voor- en nadelen van het systeem, uitgaande van de huidige status van het systeem. De inschatting van de nog benodigde ontwikkeltijd en -kosten is gemaakt op basis van de verhouding tussen al bestaande functionaliteit en nog in te bouwen functionaliteit. Het gaat om een globale indicatie van kosten, doorlooptijd en benodigde uren. Bij het ramen is ook rekening gehouden met het gebruik van de applicatie voor meerdere contractvormen. De schattingen zijn exclusief het voortraject, waarin de procesbeschrijvingen en specificaties gemaakt worden. Dit voortraject wordt namelijk altijd uitgevoerd, ongeacht welk systeem als basis voor het SCB systeem geselecteerd wordt. 7.1 ATP Achtergrond Twee jaar geleden is gestart met de ontwikkeling van ATP (Automatisering Toetsproces), waarvan inmiddels twee systeemversies beschikbaar zijn: Automatisering Toets Proces (ATP) om het gehele toetsproces te ondersteunen, Uniforme Registratie Afwijkingen en CMF s (URAC), ook wel bekend als ATP light. In deze versie wordt de afhandeling van afwijkingen, cmf-en en betalingen ondersteund, alles wat met toetsen te maken heeft, wordt achterwege gelaten. De functionaliteit van URAC is ook onderdeel van de functionaliteit van ATP. URAC wordt daarom niet apart besproken. Uitgangspunt bij het ontwikkelen van ATP is dat de toetser en contractgemachtigde verantwoordelijk blijven en de besluiten nemen. Het systeem legt niet op wat er in welke situatie moet gebeuren, maar heeft een signaleringsfunctie. Pagina 25 of 43

26 7.1.2 Functionaliteit In de basis is ATP is een registratiesysteem, waarin alles wat met toetsen te maken heeft, vastgelegd wordt. De kapstok hiervoor zijn de hoofdprocessen die in het project onderkend worden. Aan de hoofdprocessen worden betaalposten, producten, toetsen, toetsstrategieën, toetsplannen, kritieke punten, PSE s en materiaal eisen gekoppeld. Hieronder staat per categorie aangegeven welke functionaliteit nu geboden wordt. Risico s In ATP worden risico s niet als zodanig geregistreerd, wel de toetsstrategieën die uit de risico analyses voortkomen. Ook de kritieke punten - ook een soort risico s - zijn apart terug te vinden. Toetsen De toetsstrategie per hoofdproces leidt tot toetsen, toetsplanning, de status van de toetsen en de daarmee samenhangende status van betalingen. De toetsen zijn gekoppeld aan betaalposten, bevindingen en daaruit voortkomende contractmutaties. Procestoetsen worden gedefinieerd bij elk hoofdproces. Systeemtoetsen worden onder het apart gedefinieerde hoofdproces Kwaliteitsborging gedefinieerd. Kwaliteitsborging is gekoppeld aan alle andere hoofdprocessen, zodat de systeemtoetsen ook bij deze hoofdprocessen te zien zijn. Toetsen kunnen gedurende het gehele project worden ingepland. Er wordt bijgehouden wanneer en hoe vaak ze uitgevoerd (gaan) worden en in het kort wat het resultaat van de toetsen is. Daarnaast kan verwezen worden naar het document waarin uitgebreid(er) staat beschreven wat en hoe er is getoetst en het waarom van het resultaat. Bevindingen zijn ook te koppelen aan afwijkingen en contractmutaties. Afwijkingen registratie De status van afwijkingen en contractmutaties zijn in het systeem vastgelegd, waardoor te volgen is hoe ver ze in het proces zijn en door wie wat is afgehandeld. Betaalposten Betaalposten worden geregistreerd, de status van betaalposten is vastgelegd en te traceren. Aan één betaling kunnen meerdere hoofdprocessen gekoppeld worden, om ook betaling op voortgang te kunnen ondersteunen. Rapportages Er worden termijnstaten aangemaakt voor het financiële overzicht van de betaalposten en kan ook een financiële bijsluiter worden aangemaakt. Het is daarnaast mogelijk overzichten te genereren van afwijkingen en contractmutaties. Document beheer Er is een bewuste keuze gemaakt om ATP los te koppelen van een documentbeheersysteem. Van de documenten die tijdens het toetsproces worden gemaakt (toetsplannen, bewijsdocumenten, afwijkingsrapporten), zijn referenties in het systeem terug te vinden. Deze kunnen ook weer aan de betaalposten, toetsplannen etc. worden gekoppeld. Pagina 26 of 43

27 Gebruikers en autorisatie De gebruikers van ATP zijn de projectleider, contractgemachtigde en de toetsers. Hoewel er rekening is gehouden in de functionaliteit om ook de aannemer als gebruiker in het systeem toe te laten, wordt dit laatste voorlopig niet gebruikt (intranet i.p.v. internet). Ook is de autorisatie per functie/functionaliteit nog niet in ATP ingepast, dit kan wel eenvoudig gebeuren. ATP heeft, naast een aantal gegevens die algemeen toegankelijk zijn, voor elke partij in het project een tabblad met specifiek op die partij afgestemd gegevens Ontwikkelingen rond ATP Doordat de uitvoeringsfase van het project Vondelingenplaat en de ontwikkeling van ATP parallel liepen, is ATP niet meer in praktijk voor de Vondelingenplaat gebruikt. Dit gaat wel gebeuren in het project Nootdorp. Daarnaast is ATP gedemonstreerd op een landelijke workshop voor projectleiders, daar waren de reacties positief. De terminologie die in ATP gebruikt wordt, is gebaseerd op EKB en daarmee op de kwaliteitborgingsmethodiek van de Bouwdienst. Dit geeft sommige projectleiders van buiten de Bouwdienst het idee dat het niet bruikbaar zou zijn voor de RD s. Wanneer ATP als RWS systeem ingezet gaat worden, is het dus zaak aandacht aan de terminologie te besteden Technisch PHP en MySQL, draait voorlopig op intranet maar is ook geschikt voor internet Tijd Ontwikkeltijd tot nu toe Ontwikkeling eerste en tweede versie van ATP en aparte light versie Toelichting 24 maanden Inclusief specificeren functionaliteit verder ontwikkelen SCB systeem Nog benodigde ontwikkeltijd (doorlooptijd) na gereedkomen procesbeschrijving Totaal aantal ontwikkeluren maanden (inclusief testen, exclusief implementatie) Kosten Kosten tot nu toe Reeds gemaakte ontwikkel kosten: ,-- Licentiekosten n.v.t. Toelichting verder ontwikkelen SCB systeem Nog benodigde ontwikkelkosten ,-- ( 1200 uur * 80,-- p/u) Licentiekosten n.v.t. Eventueel omzetten naar huidige RWS ,-- standaards (.Net) Onderhoudskosten per jaar ,-- Geschat op 10% van totale ontwikkelkosten Pagina 27 of 43

28 7.1.7 Voordelen o Met ATP is het mogelijk om op elk gewenst moment overzicht te hebben over en inzicht te hebben in de toetsstrategie, planning, uitvoering, resultaten van de toetsen en de koppeling aan betaling ( heb ik alles, voldoen registraties aan PSE s ). o ATP biedt één uniforme manier van vastleggen en vereenvoudigt het aantoonbaar maken van rechtmatigheid van betalingen. o Voordeel is daarnaast dat de bijsluiter makkelijker aan te maken (wordt gegenereerd) Nadelen o ATP is ontwikkeld met techniek die voldeed aan oude standaarden, maar niet meer aan nieuwe; o De relatie tussen risico s en toetsen is (nog) niet gerealiseerd in ATP o Autorisatie moet nog gerealiseerd worden. 7.2 N Achtergrond Het project N31 kenmerkt zich door een innovatief DBMF (Design, Build, Maintenance, Finance) contract. Het N31 systeem is speciaal ontwikkeld voor het N31 project. De bedoeling is dat het systeem de volledige contractduur van 20 jaar (5 jaar realisatie, 15 jaar beheer en onderhoud). Gekozen is voor een aanpak waarbij in eerste instantie beperkte functionaliteit aangeboden wordt, waar later indien gewenst extra functionaliteit aan kan worden toegevoegd. In de opzet van het systeem is hier rekening mee gehouden, extra functionaliteit kan makkelijk ingepast worden Functionaliteit De intranet applicatie die in het N31 project gebruikt wordt, ondersteunt contractbeheersing vanaf het moment dat risico s geïdentificeerd zijn. Eisen, risico s, toetsen, toetsplanning en toetsresultaten zijn aan elkaar gekoppeld en vanuit een boomstructuur per proces of combinatie van proces met object in het systeem terug te vinden. Risico s De huidige module is opgezet conform de RISMAN methodiek, maar wordt aangepast aan specifieke projectwensen. Er is in beperkte mate ondersteuning bij het evalueren (inschatten van kansen en gevolgen) van risico s. Risico s zijn gekoppeld aan processen, processtappen en/of objecten. Toetsen Vanuit de eisen en geïdentificeerde risico s wordt bepaald hoe er getoetst wordt en met welke frequentie. Bij een hoger risico wordt intensiever getoetst dan bij lager ingeschat risico. Het systeem ondersteunt het opstellen van een toetsplanning (datum en toetser worden aan toets gekoppeld). De risico inschatting kan tijdens het project wijzigen, waardoor ook een andere Pagina 28 of 43

29 toetsfrequentie en toetsplanning nodig is Per toets kan het resultaat worden aangegeven. Wanneer er meerdere toetsen bij een eis gedefinieerd zijn, toont het systeem de eis als niet goedgekeurd totdat alle bij de eis behorende toetsen zijn goedgekeurd. Er is bewust voor gekozen om eventuele consequenties van toetsresultaten niet te automatiseren. De verantwoordelijkheid en beslissingen hiervoor liggen bij de daarvoor aangewezen functionaris. Afwijkingenregistratie Het afwijkingenproces wordt niet ondersteund. Wanneer er besloten wordt tot een afwijkingen, kunnen de hierdoor ontstane wijzigingen in eisen, risico s, toetsen, toetsplanning etc. worden aangepast. Betaalposten In het N31 proces is het betalingsproces meer gescheiden van het toetsproces. Het maken van een prestatieverklaring, een termijnstaat is (nu nog) niet in het systeem opgenomen. Koppeling met betaling is in de toekomst wel mogelijk. Rapportages Het systeem biedt de mogelijkheid om via allerlei dwarsdoorsneden informatie te rapporteren voor management en toetsers en voor verantwoording naar o.a. accountants. Documentbeheer Momenteel is het mogelijk om documenten te koppelen en in de bijbehorende applicatie (Word, Excel, etc) te openen. Daarnaast kunnen metagegevens van projectdocumenten worden opgeslagen. Alleen geautoriseerde personen kunnen documenten aan het N31 systeem toevoegen. Het is niet mogelijk/ gewenst om de documenten via het N31 systeem te openen/ te bewerken en weer op te slaan. Gebruikers en autorisatie Welke functionaliteit en gegevens een gebruiker ter beschikking heeft, is afhankelijk van de gebruikersgroep waar hij toe behoort Ontwikkelingen rond het N31 systeem Het systeem bevindt zich in de implementatiefase. Momenteel worden aanpassingen doorgevoerd n.a.v. reacties van gebruikers. Het betreffen voornamelijk aanpassingen met betrekking tot de gebruikersvriendelijkheid. De resultaten blijven tot dusver beperkt tot de output: overzichten van de toetsgegevens. Het is momenteel nog te vroeg om van gebruikerservaringen te spreken Technisch Het systeem is een intranet applicatie, ontwikkeld in VB.Net, WSQL server. Er wordt gebruik gemaakt van vier databases (Eis, Risico, Proces, Object) waarvan de gegevens aan elkaar gekoppeld zijn. Pagina 29 of 43

30 7.2.5 Tijd Ontwikkeltijd Toelichting tot nu toe Ontwikkeling eerste versie 4 maanden (Exclusief specificeren functionaliteit van 6 maanden) verder ontwikkelen SCB systeem Nog benodigde ontwikkeltijd (doorlooptijd) na gereedkomen procesbeschrijving Totaal aantal ontwikkeluren 3 maanden (inclusief testen, exclusief implementatie) 800 uur Kosten Kosten tot nu toe Reeds gemaakte ontwikkel kosten: ,-- Licentiekosten n.v.t. Toelichting verder ontwikkelen SCB systeem Nog benodigde ontwikkelkosten ,-- ( 800 uur * 90,-- p/u) Licentiekosten ,-- Niet bekend, schatting!! Onderhoudskosten per jaar ,-- Geschat op 20% van totale ontwikkelkosten N.B. leverancier biedt ook de mogelijkheid om een abonnement te nemen, waarbij ontwikkel, licentie en onderhoudskosten verder vervallen ,-- per maand RWS brede ondersteuning van alle projecten Voordelen o Het N31 systeem begint al bij het ondersteunen van risico evaluatie en koppelt eisen, risico s en toetsen aan elkaar en aan processen en objecten. o N31 systeem heeft veel ondersteunde functionaliteit, zoals beperkt documentbeheer o Het systeem is ontwikkeld volgens huidige RWS standaards. o De ontwikkeling van het systeem is relatief goedkoop en kan snel gebeuren Nadelen o Het systeem ondersteunt niet het afhandelen van afwijkingen en contractmutaties o Het systeem is erg uitgebreid en biedt erg veel functionaliteit. In sommige gevallen staat dit op gespannen voet met het gebruiksgemak. Dit kan ondervangen worden door van te voren een duidelijke keus te maken om de functionaliteit in eerste instantie beperkt te implementeren. Pagina 30 of 43

31 7.3 StraitVISI Achtergrond Het systeem StraitVISI is ingericht voor het pilotproject Brandblusinstallatie Coentunnel. Het doel is het ondersteunen van de formele communicatie tussen opdrachtgever en opdrachtnemer. Het opzetten van een geautomatiseerd, formeel berichtenverkeer heeft echter geen toegevoegde waarde wanneer er geen koppeling is met projectomgevingen en interne processen. Daarom is het berichtenverkeer gekoppeld aan ondersteunende functionaliteit als workflow en (beperkt) documentbeheer Functionaliteit StraitVISI biedt workflow ondersteuning, (eenvoudig) documentbeheer en gestandaardiseerd berichtenverkeer voor processen in een project. In deze pilot gaat het om de volgende processen: o Uitwisselen van post, o Aanleveren en keuren van bewijsdocumenten, o Betaalbaarstellen van een betaalpost, o Afwijkingen (inclusief aanmaken en keuren van een stelpostbon of CMF), o Eindafrekening, o Toetsen van (ontwerp)tekeningen. Risico s Het registeren van risico s is niet specifiek ondersteund. Toetsen Het inplannen van toetsen wordt niet specifiek ondersteund. Het systeem biedt workflow ondersteuning voor het proces van opleveren van bewijsdocumenten vanaf de opdrachtnemers kant, en het keuren van deze documenten en werk op zich door de opdrachtgever. Afwijkingenregistratie Voor het proces van afwijkingenregistratie en verwerking (al dan niet tot stelpost of contractmutatie) wordt d.m.v. workflow ondersteund. Ook worden de documenten gegenereerd, waarbij zoveel mogelijk gegevens uit berichten al worden voorgevuld. Bijv. indien een afwijking resulteert in contractmutatie of stelpost, genereert StraitVISI een CMF of stelpostbon. Deze worden elektronisch al dan niet goedgekeurd. Een contractmutatie kan aan meerdere betaalposten worden gekoppeld, waarbij het meer- en minderwerk bedrag van de CMF over die betaalposten kan worden verdeeld. Betaalposten De betaalposten vormen de kapstok van het systeem, hieraan worden de projectspecifieke eisen (PSE s) gekoppeld. Bewijsdocumenten en eigen waarnemingen worden weer gekoppeld aan de betreffende PSE s. Wanneer de betaalpost betaalbaar gesteld wordt (in deze pilot: alle PSE s zijn getoetst en elektronisch geaccepteerd), maakt StraitVISI een prestatieverklaring (inclusief bijsluiter) aan. Pagina 31 of 43

32 Rapportages Er zijn verschillende rapportages, zoals de termijnstaat, prestatieverklaring, (status)overzichten van afwijkingen en betaalposten. Er kan op elk gewenst moment een totaal kostenoverzicht van betaalposten, stelposten en contractmutaties worden gegenereerd (eindafrekening). Documentbeheer Het systeem biedt een eenvoudige vorm van documentbeheer, waarbij op basis van metagegevens documenten automatisch in de juiste map worden gezet en door gebruikers gevonden kunnen worden. Het aanpassen van documenten kan niet binnen het systeem. Wel is het mogelijk er via de viewer in te tekenen en te schrijven. Dit commentaar wordt aan het document gekoppeld, maar er los van bewaard. Gebruikers en autorisatie Gebruikers krijgen alleen beschikking over de functionaliteit die bij hun rol hoort Ontwikkelingen rond StraitVISI Momenteel is de eerste pilot met StraitVISI afgesloten. Omdat nog niet besloten is voor welke projecttypen de Bouwdienst verder wil met VISIpilots, is er geen verdere ontwikkeling gepland. Mogelijk gaan in 2005 nieuwe pilottrajecten van start Technisch StraitVISI is een standaardpakket, dat kan worden ingericht naar de specifieke eisen van het project. Het maakt gebruik van SmarTeam functionaliteit, SmarTeam is een document management systeem. Het is momenteel beschikbaar via een externe provider. De applicatie is gebaseerd op client-server technologie. Webtechnologie is voor SmarTeam ook beschikbaar, voor StraitVISI is dit nog niet bekend Tijd Ontwikkeltijd Toelichting tot nu toe Ontwikkeling eerste versie 3 maanden (Exclusief specificeren functionaliteit van 3 maanden) verder ontwikkelen SB systeem Nog benodigde ontwikkeltijd (doorlooptijd) na gereedkomen procesbeschrijving Totaal aantal ontwikkeluren 4 maanden (inclusief testen, exclusief implementatie) 1200 uur Pagina 32 of 43

33 7.3.6 Kosten Kosten tot nu toe Reeds gemaakte ontwikkel kosten: ,-- Licentiekosten 1200 (per maand voor 5 gebruikers). Toelichting verder ontwikkelen SCB systeem Nog benodigde ontwikkelkosten ,-- ( 1200 uur * 110,-- p/u) Licentiekosten ,-- Niet bekend, schatting!! Onderhoudskosten per jaar ,-- Geschat op 20% van totale ontwikkelkosten Voordelen o Workflow ondersteuning o Standaard marktpakket, waarop verder ontwikkeld wordt o Documentbeheer Nadelen o Geen ondersteuning in risicoregistratie o Systeem is niet primair gemaakt voor het ondersteunen van toetsproces. Het systeem bevat hierdoor functionaliteit die voor het ondersteunen van systeemgerichte contractbeheersing primair niet relevant is, zoals het formele berichtenverkeer. Ondersteuning van contractbeheersing blijft hierdoor redelijk globaal. 7.4 ProRail systeem Achtergrond Bij ProRail wordt gewerkt met een combinatie aan Microsoft producten, die het werk van de projectmanager ondersteund. Het gaat hierbij dus om het totale proces van projectmanagement. Contractbeheersing is hier een onderdeel van. Bij ProRail is echter geen specifieke ondersteuning voor contractbeheersing (en het toetsproces in het bijzonder) ingericht. Of deze specifieke ondersteuning binnen het projectmanagement systeem gerealiseerd kan worden, zou onderdeel van verder onderzoek moeten zijn Functionaliteit Het ProRail systeem biedt de mogelijkheid om projecten te plannen en taken aan projectmedewerkers toe te wijzen. Er kan met activiteiten worden verschoven en het biedt een overzicht van knelpunten en verschuivingen. Ook is het eenvoudig om geplande en gerealiseerde capaciteit en budget naast elkaar te zetten. Bovendien kunnen processen worden ondersteund met workflow management. Projectmedewerkers kunnen door hun eigen pagina te openen, alle taken zien die aan hun zijn toegewezen, van alle projecten waar ze in meewerken (en die via deze tool werken). Pagina 33 of 43

34 7.4.3 Ontwikkelingen rond ProRail systeem Het systeem zoals ontwikkeld voor Prorail, biedt niet de functionaliteit die specifiek voor contractbeheersing gevraagd wordt, zoals het inplannen van toetsen en koppelen van toetsen en risico s. Wel is het systeem dusdanig flexibel, dat ontwikkeling van deze functionaliteit waarschijnlijk ingepast kan worden. Er is hier echter nog geen ervaring mee Technisch Het systeem is opgebouwd uit standaard Microsoft modules Tijd N.B. Omdat er nog geen eerste versie beschikbaar is, is voor het inschatten gekeken naar het N31 systeem (zelfde techniek) en de informatie dat het projectmanagementsysteem in ongeveer 3 maanden doorlooptijd is gerealiseerd. Ontwikkeltijd tot nu toe Niet van toepassing Toelichting verder ontwikkelen SCB systeem Nog benodigde ontwikkeltijd (doorlooptijd) na gereedkomen procesbeschrijving 6 maanden (inclusief testen, exclusief implementatie) Totaal aantal ontwikkeluren 1500 uur (van scratch af aan) Kosten N.B. Omdat er nog geen eerste versie beschikbaar is, is voor het inschatten gekeken naar het N31 systeem (zelfde techniek) en de informatie dat het projectmanagementsysteem in ongeveer 3 maanden doorlooptijd is gerealiseerd. Kosten tot nu toe Niet van toepassing Toelichting verder ontwikkelen SCB systeem Nog benodigde ontwikkelkosten ,-- ( 1500 uur * 100,-- p/u) Licentiekosten ,-- Niet bekend, schatting!! Onderhoudskosten per jaar ,-- Geschat op 20% van totale ontwikkelkosten Voordelen o Ontwikkelen met standaard techniek en op basis van bestaande modules o Functionaliteit is ingebed in projectmanagement omgeving (extra functionaliteit) Nadelen o Van scratch af aan ontwikkelen o Geen ervaring met gebruik van deze modules voor soortgelijke toepassingen Pagina 34 of 43

35 7.5 SAP Het uitgangspunt voor de ontwikkeling van RWS brede systemen binnen bedrijfsvoering is: SAP, tenzij. Voor een beperkt aantal systemen is al met het ontwikkelen in SAP begonnen, voor een aantal andere is de mogelijkheid hiertoe in onderzoek. Zo wordt het financiële systeem naar SAP omgezet. Voor het VOC (vereenvoudigd opstellen van contracten) en Consys (contractregistratiesysteem) is dit momenteel in onderzoek. Deze systemen hangen nauw samen met een contractbeheersingssysteem. Daarom is gekeken of, hoe en wanneer systeem gerichte contractbeheersing in (een) SAP module(s) te realiseren is. Op dit moment is er geen SAP module die specifiek voor contractbeheersing kan worden ingezet. Verschillende modules komen in aanmerking voor een gedeelte van de benodigde functionaliteit. Na een kort onderzoek door een SAP specialist, komt de module Recordmanagement (ook wel Case management genaamd) naar voren als (momenteel) de meest geschikte module. De beschrijving hieronder is dan ook gebaseerd op deze module Functionaliteit De module Recordmanagement biedt geen standaard functionaliteit, maar bouwstenen om verschillende functionaliteit mee te ontwikkelen Ontwikkelingen in en rond SAP Momenteel is men bezig met het ontwikkelen en implementeren van de eerste SAP systemen RWS breed. Er wordt niet massaal nieuwe functionaliteit in SAP ontwikkeld, de aandacht richt zich wel heel nadrukkelijk op Inkoop. De RWS brede SAP ontwikkelingen worden gecoördineerd door BVS. Ook bij het ontwikkelen van het contractbeheersingssysteem zal deze afdeling nauw betrokken moeten zijn. Er is momenteel echter onvoldoende capaciteit om alle systemen die voor SAP in aanmerking komen, hierin ook daadwerkelijk te ontwikkelen. Afhankelijk van de prioriteit die door het management gesteld wordt, kan het zijn dat niet begonnen kan worden met het ontwikkelen van een contractbeheersingsysteem op het gewenst moment. Vanaf het begin van ontwikkeling (na het afronden van de procesbeschrijvingen) moet gerekend worden op een doorlooptijd van een jaar, waarbij drie man fulltime aan de slag zijn Technisch RMA-achtige oplossing, waarin workflow wordt ondersteund. Beide producten zijn onderdeel van de totale suite aan SAP producten. Vanuit de beschrijvingen lijken de producten ook via webinterface te benaderen. Er is nog niet veel ervaringen opgedaan met deze producten in de praktijk. Pagina 35 of 43

36 7.5.4 Tijd Ontwikkeltijd tot nu toe Niet van toepassing verder ontwikkelen SCB systeem Nog benodigde ontwikkeltijd (doorlooptijd) na gereedkomen procesbeschrijving Totaal aantal ontwikkeluren Toelichting 12 maanden (inclusief testen, exclusief implementatie) 3200 uur Kosten Kosten tot nu toe Niet van toepassing Toelichting verder ontwikkelen SCB systeem Nog benodigde ontwikkelkosten ,-- ( 3200 uur * 150,-- p/u) Licentiekosten ,-- Niet bekend, schatting!! Onderhoudskosten per jaar ,-- Geschat op 10% van totale ontwikkelkosten Voordelen o Voldoet aan RWS standaard o Uitwisselen van gegevens met andere systemen kan (in later stadium) via standaard SAP interface Nadelen o Alle benodigde functionaliteit moet (opnieuw) ontwikkeld worden o Ontwikkeltijd is minimaal een jaar nadat procesbeschijving gereed is. In het gunstigste geval is de opleverdatum daarmee maart, april 2006 o Er is geen garantie dat ook daadwerkelijk met de ontwikkeling begonnen kan worden op het gewenste moment, omdat de capaciteit niet aanwezig is. o De voorgestelde module is relatief nieuw, momenteel wordt bij twee andere overheidsorganisaties wel met deze module ontwikkeld, maar op dit moment zijn er nog geen gebruikerservaringen; o Momenteel worden, ook in SAP, interfaces point tot point ontwikkeld, wat betekent dat er toch nog extra aandacht aan het ontwikkelen van de interfaces besteed moet worden. o Het SCB systeem moet ook gebruikt kunnen worden op de bouwplaatsen zelf. Het is de vraag of het SAP systeem op de bouwplaats benaderd kan worden. o Kosten zijn hoog (ongeveer 4x zoveel als doorontwikkelen van een van de bestaande systemen). Pagina 36 of 43

37 8 Scenario s Om te bepalen welk van bovenstaande opties interessant zijn om als scenario verder te bekijken, is gekeken naar vier belangrijke aspecten: 1. de mate waarin de al bestaande de functionaliteit van een applicatie voldoet aan de gewenste SCB-functionaliteit; 2. de te verwachten kosten die het ontwikkelen, implementeren en beheren van de applicatie; 3. de verwachte doorlooptijd van verdere ontwikkeling en implementatie; 4. de mate waarin de applicatie past binnen de RWS standaarden; In onderstaande tabel zijn de scores van de verschillende systemen samengevat. ATP N31 ProRail SAP StraitVISI Functionaliteit risico's toetsen afwijkingenregistratie betaalposten rapportages documentbeheer gebruikers en autorisatie Kosten verder ontwikkelen SCB systeem Nog benodigde ontwikkelkosten , , , , ,-- Onderhoudskosten per jaar , , , , ,-- Tijd verder ontwikkelen SCB systeem Doorlooptijd 6 maanden 3 maanden 6 maanden 12 maanden 4 maanden Totaal aantal ontwikkeluren 1200 uur 800 uur 1500 uur 3200 uur 1200 uur Standaarden RWS ontwikkeld in standaard nee ja ja eerste keus nee Het N31 systeem komt naar voren als systeem dat al de meeste functionaliteit biedt, de minste ontwikkelkosten en ontwikkeltijd in beslag neemt en voldoet aan de RWSbrede, technische eisen. SAP is eerste keus wat betreft RWS-standaard, maar scoort het minst zowel op al bestaande functionaliteit als ontwikkelkosten en tijd. Daarom is ook een scenario uitgewerkt waarbij ontwikkelen in SAP kan worden uitgesteld tot er meer ervaring is opgedaan en ontwikkeltijd en kosten wellicht lager kunnen zijn. Pagina 37 of 43

38 Elk scenario waarin een systeem ontwikkeld wordt, zal moeten beginnen met eenzelfde stap, namelijk het vastleggen van gedetailleerde procesbeschrijvingen en specificaties. Dit vaste onderdeel wordt daarom eerst beschreven. Op basis van de bevindingen zijn de volgende scenario s uitgewerkt: Vast onderdeel van alle scenario s: Analyse Scenario 0: De huidige situatie laten voortbestaan (niets doen); Scenario 1: Ontwikkeling in SAP; Scenario 2: Ontwikkeling in N31/SAP. 8.1 Vaste onderdelen voor elk scenario: Analyse Behalve voor het 0-scenario: niets doen is het voor elk scenario noodzakelijk om de processen, die ondersteund gaan worden, in kaart te brengen. Het gaat hierbij om: Evaluatie en registratie van risico s Toetsproces Vaststellen toetsmix Inplannen toetsen Vastleggen toetsresultaten Afwijkingenproces Vastleggen bevindingen Registreren en beoordelen afwijkingen Vastleggen contractmutaties Betaalproces Vaststellen prestatie Overzicht betalingen Het in kaart brengen gebeurt aan de hand van bestaande procesbeschrijvingen, specificaties van bestaande systemen en interviews met deskundigen. De procesbeschrijvingen worden aangevuld met verdere specifieke eisen. Het analysetraject start met de organisatie van een representatieve klankbordgroep, waarin gebruikers van verschillende diensten meedenken en oordelen over de specificaties voor het SCB systeem. De ECO methodiek Systeemgerichte Contractbeheersing vormt hiervoor het kader. Tijd Doorlooptijd 4 maanden Totaal aantal uren projectteam 320 uur Uren deskundigen 120 Toelichting Kosten Toelichting Intern / extern projectteam ,-- (320 uur * 100,-- p.u) Pagina 38 of 43

39 8.2 Scenario 0: Niets doen Een mogelijkheid is om te besluiten (voorlopig) geen RWS-breed systeem te ontwikkelen dat contractbeheersing ondersteunt Aanpak Er wordt (voorlopig) geen nieuw, RWS breed, contractbeheersingssysteem ontwikkeld. Ieder project richt op eigen wijze de vastlegging en planning op basis van de SCB methodiek. De samenhang van contracteisen, risicomanagement en het nieuwe toetsmethodiek geeft een dusdanig complexe situatie, dat zonder geautomatiseerde ondersteuning de aantoonbaarheid van gegevens een probleem wordt. Men is meer tijd kwijt met het administratieve proces. In een deel van deze projecten zal men kiezen voor het gebruik van spreadsheets of een access applicatie. In een ander deel wordt gekozen voor ontwikkeling van een eigen, op het project toegesneden, applicatie waarin SCB ondersteund wordt. Hergebruik van dit soort applicaties of de spreadsheets is afhankelijk van de ervaring die projectleden ermee hebben en het eigen netwerk Kosten scenario niets doen. De vraag naar ICT-ondersteuning voor systeemgerichte contractbeheersing komt vooral voort uit de vraag naar ondersteuning bij het kunnen beheersen van aantoonbaarheid en rechtmatigheid. Momenteel kost het veel tijd om aan deze verplichtingen te voldoen. Bij het inschatten van de kosten van niets doen zijn de volgende aspecten meegenomen: Tijd die medewerkers kwijt zijn bij het samenstellen van een prestatieverklaring; Tijd die medewerkers kwijt zijn bij het aanleveren van de juiste gegevens aan de AD; Tijd die medewerkers kwijt zijn bij het ontwikkelen van eigen spreadsheets/access toepassing; Tijd die medewerkers kwijt zijn bij het leren van het systeem; Tijd die medewerkers extra kwijt zijn aan het systeem, t.o.v. vastlegging zonder een dergelijk systeem; Wanneer er geen RWS-breed systeem geïmplementeerd wordt, wordt ingeschat dat de volgende kosten worden gemaakt t.o.v. de situatie waarin dit wel het geval is: De extra administratieve lasten zullen per project 1 tot 3 mandagen per betalingstermijn extra in beslag nemen. Voorzichtigheidshalve wordt uitgegaan van 1,5 dag extra per betalingstermijn. Er wordt uitgegaan van ongeveer 12 projecten per jaar, met ieder 12 betalingstermijnen. De kosten van een manuur worden gehouden op 100,-- Ingeschat wordt dat één op de drie projecten toch zelf een systeem laat ontwikkelen en dat de kosten voor zo n applicatie minimaal ,-- per project zijn. Pagina 39 of 43

40 Kosten Toelichting Totale kosten per jaar, zonder ontwikkelen eigen systemen ,-- 1,5 dag * 800,-- per dag * 12 termijnen * 12 projecten Geschatte ontwikkelkosten op projecten , ,-- * 4 projecten Totale kosten per jaar , Voordelen Besluit over standaardsysteem kan worden uitgesteld, totdat er meer duidelijkheid en ervaring in de organisatie is opgedaan met SAP Nadelen Het ontbreken van een standaard ICT-tool bemoeilijkt het invoeren van een uniforme werkwijze voor systeemgerichte contractbeheersing, er wordt meer ruimte overgelaten aan eigen interpretatie. Wanneer zo n systeem er uiteindelijk wel komt, is het moeilijker alsnog een uniforme werkwijze door te voeren. Er is nu al veel vraag naar een tool voor het ondersteunen van contract beheersing. Wanneer er geen standaardtool beschikbaar komt, zal men per project zelf iets ontwikkelen, op papier of in Excel contractbeheersing blijven ondersteunen. Gevolg: per project worden extra kosten gemaakt voor ontwikkeling van een applicatie of voor extra tijd/capaciteit, hergebruik van ontwikkelde systemen wordt niet gegarandeerd. Deze extra kosten zijn hierdoor niet zichtbaar. 8.3 Scenario 1: SAP Het beleidsvoornemen van RWS is SAP tenzij. Een mogelijk scenario is dan ook om één of meerdere modules van SAP te gebruiken Aanpak Parallel aan de procesbeschrijvingen wordt een onderzoek gedaan naar de mogelijkheden en onmogelijkheden van een aantal, door een SAP consultant geselecteerde, modules. In het bijzonder wordt naar Record management gekeken. Na procesbeschrijving wordt gestart met de ontwikkeling van de gewenste functionaliteit in SAP. Totdat het SAP systeem geïmplementeerd wordt, wordt op projecten op dezelfde manier doorgewerkt als dat nu gebeurt. D.w.z. men is vrij om gebruik te maken van Excel, het N31 of het ATP systeem. De kosten hiervoor zijn voor rekening van de projecten zelf. Tijd Toelichting Doorlooptijd 15 maanden Inclusief voortraject Totaal aantal uren projectteam 3200 uur Uren deskundigen 240 Kosten Totale ontwikkelkosten ,-- Onderhoudskosten per jaar ,-- Toelichting Pagina 40 of 43

41 Voordelen Past in RWS beleid SAP tenzij voor bedrijfsvoeringsystemen Integratie met andere SAP systemen is eenvoudiger Mogelijk minder ontwikkelkosten voor tijdelijk systeem Nadelen De ontwikkeling en implementatie van het SCB-systeem is afhankelijk van de beschikbare capaciteit van het SAP ontwikkelteam Doorlooptijd is, na procesbeschrijvingen, nog 1 jaar. Dit betekent dat projecten nog langer op de oude voet verder gaan met alle nadelen vandien (zelf iets ontwikkelen, extra kosten per project, geen uniforme werkwijze t.a.v. SCB) De SAP module die voor SCB gebruikt kan worden, levert geen functionaliteit maar bouwstenen om een maatwerksysteem te maken Geen van de systemen waarvoor deze module wordt gebruikt (ook buiten V&W), zijn op dit moment al in productie. Er is daardoor weinig tot geen ervaring met praktisch gebruik. Het ontwikkelen is duur Er is nu binnen RWS nog geen ervaring met het specifiek ontwikkelen van functionaliteit in SAP modules. 8.4 Scenario 2: N31 in combinatie met SAP Op basis van inschatting van kosten, al gerealiseerde de functionaliteit en gebruikte (standaard) techniek is het N31 systeem het meest geschikt om verder te ontwikkelen Aanpak: Ontwikkeling N31: Parallel aan het traject waarin de procesbeschrijvingen en specificaties worden gemaakt, wordt een traject ingezet waarin bekeken wordt welke contractvorm met de leverancier van de N31 het beste is voor RWS. Er is hier keuze tussen: het aankopen van licenties door RWS, waarbij de leverancier op basis van diensten de applicatie verder ontwikkeld, of het geheel uitbesteden aan de leverancier en een abonnement nemen op de applicatie. Er wordt een vast bedrag per maand betaald, waarbij een pakket aan diensten wordt gehuurd (o.a. gebruiksrechten, onderhoud, verdere ontwikkeling door leverancier). Nadat de specificaties en procesbeschrijvingen gereed zijn wordt de bestaande applicatie aangepast en uitgebreid. Er volgt een testperiode, waarin gebruikers de kans krijgen het systeem in een (simulatie) praktijksituatie te testen. Na deze periode volgt (technische) implementatie en is het systeem beschikbaar voor elk project. Ontwikkeling SAP: Tijdens het ontwikkeltraject worden de ontwikkelingen in en rond SAP nauwlettend gevolgd. Met BVS wordt hierover contact onderhouden. Ook wordt gekeken naar het Pagina 41 of 43

42 gebruik van de Recordmanager bij andere organisaties. Of en wanneer besloten wordt om de ontwikkeling in SAP te starten, hangt o.a. af van: De beschikbaarheid van het RWS-SAP team bij BVS (wanneer is er capaciteit om met ontwikkeling SCB in SAP te beginnen); Het moment waarop de ervaring met SAP dusdanig is, dat de ontwikkeltijd korter is en de ontwikkelkosten daardoor goedkoper; Het moment waarop meer duidelijkheid is over de ontwikkeling van aanpalende systemen in SAP en de manier waarop deze systemen met het SCB systeem moeten interfacen; Tijd Toelichting Doorlooptijd N31 7 maanden Inclusief voortraject Doorlooptijd SAP in 2 e stadium Nader te bepalen Totaal aantal uren projectteam N uur Uren deskundigen N Kosten Totale ontwikkelkosten N ,-- Onderhoudskosten per jaar N ,-- Totale ontwikkelkosten SAP in 2 e Nader te stadium bepalen Toelichting Opnieuw ontwikkelen van totale systeem in SAP, of het ontwikkelen van interfaces. Voordelen: Het doorontwikkelen van het N31 systeem is aanzienlijk sneller dan ontwikkeling in SAP, waardoor er eerder een RWS breed, standaard systeem beschikbaar is dat een uniforme werkwijze ondersteund; Er kan eerst ervaring worden opgedaan met ontwikkelen in SAP en Recordmanagement in het bijzonder. De verwachting is dat meer ervaring betekent dat het ontwikkeltraject hiermee aanzienlijk sneller en daarmee goedkoper kan worden gerealiseerd; Nadelen: Investering in tijdelijk systeem. Totale kosten (nog) niet bekend Pagina 42 of 43

43 9 Openstaande punten Contractenbuffet: welke contractvormen moeten ondersteund worden? In het bijzonder: hoe wordt omgegaan met RAW bestekken? 10 Aanbeveling Om de invoering van een uniforme SCB werkwijze vanuit ECO te ondersteunen en te kunnen voldoen aan de vraag vanuit projecten naar een systeem dat het toetsproces ondersteunt is het gewenst op korte termijn een RWS breed systeem beschikbaar te stellen. Ontwikkeling van een SCB systeem in SAP laat te lang op zich wachten. Het N31 systeem kan binnen redelijke termijn voor heel RWS beschikbaar gesteld worden. Ook zijn de kosten voor ontwikkeling significant lager dan de SAP ontwikkelkosten. De tweede fase, het ontwikkelen van een SAP applicatie, is opportuun op het moment dat er voldoende capaciteit beschikbaar is om ook daadwerkelijk aan de ontwikkeling te kunnen beginnen en er meer ervaring is met de SAP module Recordmanagement. Ervaringen die worden opgedaan met het N31 systeem kunnen in een later stadium meegenomen worden in een te ontwikkelen SAP applicatie. Mogelijk leidt meer praktijkervaring met zowel SCB als ontwikkelen in SAP tot lagere ontwikkelkosten en tijd. Pagina 43 of 43