Evaluatie van het gebruik van een digitaal model voor de Outputspecificatie en het Verificatiemodel
Project PPS Renovatie Financiën
In samenwerking met: Rijksgebouwendienst, ministerie van Financiën, PKM Solutions, ICOP, Strukton, Burgers Ergon, Deerns, GTI
PSIBouw Gouda, 17 september 2007 Versie: 3.2 definitief
Blad /47
1
Inhoud Hoofdstuk 1 Aanleiding en procesgang 1.1 Aanleiding 1.2 Opbouw van het evaluatierapport 1.3 Onderzoeksvraag en proces van evalueren
3 3 4 4
Hoofdstuk 2 Het digitale model 2.1 Requirements Management middels een digitaal verificatiemodel 2.2 Vraagspecificatie voor geïntegreerde contracten 2.3 Het verificatiemodel van Safire
5 5 7 9
Hoofdstuk 3 Constateringen en waarderingen 3.1 Constateringen en waarderingen over de outputspecificatie 3.2 Constateringen en waarderingen over het verificatiemodel en bestek toetsen
11 11 12
Hoofdstuk 4 Conclusies en aanbevelingen 4.1 Conclusies 4.2 Aanbevelingen
13 13 14
Bijlage Bijlage Bijlage Bijlage
16 27 32 33
A: screenvoorbeelden B: vragenlijsten C: respondentenlijst D: besprekingsverslagen
Blad /47
2
Hoofdstuk 1
1.1
Aanleiding en procesgang
Aanleiding
Sinds het najaar van 2006 is PSIBouw actief met het evalueren van het digitale model dat zowel voor de outputspecificatie als het verificatiemodel is gehanteerd bij het project PPS Renovatie Financiën. Het is de eerste keer dat er met een digitale eisen- en verificatiemodel is gewerkt. De renovatie van het ministerie van Financiën is het eerste kantoorgebouw van de rijksoverheid dat in de vorm van publiek-private samenwerking (pps) is aanbesteed. Alle schakels van ontwerp, bouw, financiering, onderhoud tot en met facilitaire diensten zijn in één contract aanbesteed. Deze contractvorm heet DBFMO: Design, Build, Finance, Maintain and Operate. Deelnemers aan de renovatie zijn: de Rijksgebouwendienst (aanbestedende dienst), het ministerie van Financiën en Safire BV. Safire BV is een samenwerkingsverband van ABN AMRO, Strukton, Burgers Ergon, GTI en ISS. De architect is Meyer en Van Schooten Architecten
De aanleiding voor het ministerie van Financiën Het ministerie van Financiën, heeft in overleg met de Rijksgebouwendienst, besloten om voor het opstellen van de Outputspecificatie gebruik te maken van een digitaal model. Zij waren van mening dat papieren contractspecificaties voor de bouw en exploitatie van het gebouw voor de komende 25 jaar te kort zouden schieten. Meerwaarde van het digitale model zagen zij vooral in de consistentie en het wijzigingenbeheer De software Het betreft de zogenaamde PKM software, een database, die in dit geval is gebruikt door ICOP om in eerste instantie de Outputspecificatie te digitaliseren1. Hierbij is voor de opdrachtgever het eerder geschreven Programma van Eisen eenduidig omgezet in de digitale database. Alle eisen en specificaties zijn in het systeem opgenomen middels gegevensobjecten en relaties tussen deze objecten. Elk gegeven is slechts één keer opgenomen en middels de relaties kunnen alle verbanden worden zichtbaar gemaakt. Het Verificatiemodel Uiteindelijk is voor het Verificatiemodel een nieuwe template ontwikkeld, die eveneens gekoppeld is aan de PKM database. Het model is gebaseerd op de Outputspecificatie en dient ervoor om te zorgen dat het consortium dat het project moet realiseren, alle specificaties ook werkelijk in haar ontwerp heeft verwerkt. Hiervoor zijn alle gegevensobjecten uit de Outputspecificatie toebedeeld aan een ontwerpdiscipline. Deze discipline moet in het systeem aangeven of daadwerkelijk aan de gestelde eis is voldaan middels aanvinken van de eis. Opdrachtgever en opdrachtnemer zijn met bepaalde verwachtingen gaan werken met het model. Deze evaluatie laat zien in hoeverre verwachtingen uit zijn gekomen en welke verbeteringen gewenst zijn. De doelstelling is om de opgedane leerervaringen zichtbaar te maken voor zowel de interne organisaties als andere partijen die graag meer willen weten over het werken met digitale modellen in de aanbesteding. Uiteindelijk zal dit rapport in een aantrekkelijke vorm gegoten worden om kennisoverdracht naar deze partijen mogelijk te maken.
1
PKM software bestaat uit een databaseprogramma met voor elke toepassing een specifieke template. In dit geval een template voor de outputspecificatie en een template voor het verificatiemodel. De software is ontwikkeld door PKM Solutions, de templates door ICOP.
Blad /47
3
1.2
Opbouw van het evaluatierapport
Het evaluatierapport beschrijft in hoofdstuk twee het digitale model en de gehanteerde werkwijze. In hoofdstuk drie wordt een overzicht gegeven van de constateringen en waarderingen die voortvloeien uit de interviews. In hoofdstuk vier worden conclusies en aanbevelingen gegeven. In de bijlagen zijn de volgende documenten opgenomen: Bijlage A: screenvoorbeelden Bijlage B: vragenlijsten Bijlage C: respondentenoverzicht Bijlage D: interviewverslagen
1.3
Onderzoeksvraag en proces van evalueren
De volgende onderzoeksvraag is door de betrokken partijen geformuleerd: Welke conclusies en aanbevelingen kunnen, op basis van de ervaringen met de ontwikkeling en het gebruik van het digitale Outputspecificatiemodel en het Verificatiemodel voor de pps- renovatie Financiën, worden gegeven voor het verbeteren van de communicatie bij aanbestedingen en het ontwerp (tot besteksniveau) in de utiliteitsbouw? Het model is bij vier onderscheiden processen ingezet: 1. 2. 3. 4.
ontwikkelen OS door opdrachtgever communicatie OS naar de markt wijzigingenbeheer in OS door opdrachtgever interne verificatie DO/bestek door opdrachtnemer (incl. modelleren stukje BAFO)
Het onderzoek heeft zich geconcentreerd op proces 4 en wat aanvulling op processen 1, 2 en 3 voor zover er nieuwe inzichten waren t.o.v. de evaluatie die daarvoor al gedaan is.
Met betrekking tot processen 1 en 2 kan worden verwezen naar het evaluatierapport van de PPS Renovatie Financiën, (http://www.minfin.nl/nl/organisatie/renovatiefinancien/veel_gestelde_vragen) Voor het evalueren heeft PSIBouw diverse bilaterale interviews afgenomen aan zowel opdrachtgeverals consortiumzijde. Vervolgens zijn er twee rondetafelgesprekken gevoerd na de verificatiefase met zowel eindgebruikers van de opdrachtgever als eindgebruikers van het consortium. Deze waaier aan gesprekken levert een helder beeld op van hoe het systeem processen in de aanbesteding heeft ondersteund en waar verbeteringen mogelijk zijn. Met behulp van een eenvoudige waardering wordt aangegeven hoe het systeem gewaardeerd wordt door de gebruikers aan zowel opdrachtgevers- als opdrachtnemerszijde. Opgemerkt moet worden dat het systeem gedurende het project doorontwikkelde, waardoor sommige tekortkomingen inmiddels reeds opgelost zijn. Deze worden met een asterisk aangegeven. Gedurende het proces konden er ook wensbeelden ontstaan van hoe het systeem in de toekomst gebruikt kan worden. Inmiddels wordt door de RGD in de projecten die volgden na het ministerie van financiën, met doorontwikkelde versies van het systeem gewerkt.
Blad /47
4
Hoofdstuk 2
Het digitale model
In dit hoofdstuk wordt het digitale model zoals zij ontworpen is voor het ministerie van Financiën omschreven. Verwachtingen van het model van zowel de opdrachtgever als het consortium worden hierbij weergegeven. Omdat de hier ontwikkelde aanpak goed past in het gedachtegoed van “Systems Engineering” wordt hieraan in de eerste paragraaf aandacht besteed.
2.1 Requirements Management middels een digitaal verificatiemodel Algemeen Requirements Management is een belangrijk onderdeel van Systems Engineering, waarbij kortweg expliciet moet worden geborgd dat aan alle systeemeisen wordt voldaan. Hierbij wordt in een System Breakdown Structure (SBS) het systeem en al haar onderdelen beschreven. Nadat de SBS is opgesteld dienen alle relevante eisen, als opgelegd door opdrachtgever of derden dan wel onze eigen eisen, te worden gekoppeld aan het systeem.
SBS
EISEN
Value Engineering Trade-Off matrix Validatie Validatie dossier
WBS
PRODUCTEN
Raakvlakkenbeheer Risicobeheersmaatregelen
Verificatie Verificatie dossier
figuur 1. Het iteratieve process van value engineering
Het koppelen van eisen aan de systeemonderdelen is een iteratief proces, waarbij gebruik wordt gemaakt van Value Engineering. De systeem onderdelen dienen te worden afgestemd aan de gewenste prijs en kwaliteit. De keuzes voor oplossingen kunnen worden vastgelegd in een Trade-OffMatrix. Er wordt onderscheid gemaakt in specifieke soorten eisen, met als doel goed afgebakende eisenpakketten te kunnen maken. Om de verschillende subteams effectief te laten werken, worden verzamelingen gemaakt binnen de diverse soorten eisen. Zo wordt voorkomen dat alle projectmedewerkers de gehele outputspecificatie door moeten nemen om de voor hun relevante eisen te filteren.
Blad /47
5
Wanneer de objecten en bijbehorende eisen bekend zijn, kunnen de werkzaamheden welke benodigd zijn om deze te realiseren worden beschreven in de Work Breakdown Structure (WBS). Om de uitwerking van complexe systemen beheersbaar te houden, dient de WBS onderscheid te maken in werkpakketten. Per werkpakket dienen de gestelde eisen, de op te leveren producten (documenten, tekeningen, objecten, ed) en de benodigde activiteiten te worden beschreven. Middels raakvlakkenmanagement worden de externe raakvlakken en de raakvlakken tussen de verschillende pakketten beheerd.
Het toetsen van de oplossingen aan de eisen vindt plaats door middel van het verificatie- en validatieproces. Hieronder een korte toelichting op deze definities. Validatie Bevestiging, door het aanleveren van objectief bewijs, dat aan de eisen voor een specifiek bedoeld gebruik of toepassing wordt voldaan [ISO 9000: 2000] Validatie in een system life cycle context is de set aan activiteiten welke waarborgen en in toenemende mate bevestigen dat een systeem in staat is om het beoogde gebruik, doelen en doelstellingen te vervullen. [ISO 15288] Bij validatie wordt: in de Ontwerpfase de terechtheid en compleetheid van de decompositie van (functionele) eisen naar onderliggende eisen onderbouwd middels vastgestelde validatiemethoden; in de Uitvoeringsfase middels vastgestelde validatiemethoden aangetoond dat (deel)systemen hun geëiste functie daadwerkelijk kunnen vervullen; in de Exploitatiefase middels vastgestelde validatiemethoden periodiek aangetoond dat (deel)systemen hun geëiste functie blijven vervullen. Verificatie Bevestiging, door het aanleveren van objectief bewijs, dat aan specifieke eisen wordt voldaan [ISO 9000: 2000] Verificatie in een system life cycle context is de set aan activiteiten welke de producten van een system life cycle vergelijken met de geëiste karakteristieken van die producten. Hieronder vallen onder andere specifieke eisen, ontwerp beschrijvingen en het systeem zelf. [ISO15288] Bij verificatie wordt: in de Ontwerpfase middels vastgestelde verificatiemethoden aangetoond dat de gedecomponeerde eisen (dus niet de functionele eisen) zijn verwerkt in de ontwerpdocumenten en uitvoeringstekeningen; in de Voorbereiding en Uitvoeringsfase middels vastgestelde verificatiemethoden aangetoond dat het systeem conform de ontwerpdocumenten en uitvoeringstekeningen is gerealiseerd en dat wijzigingen ten opzichte van de ontwerpdocumenten en uitvoeringstekeningen voldoen aan de eisen. in de Exploitatiefase middels vastgestelde verificatiemethoden periodiek aangetoond dat (deel)systemen aan de eisen voldoen.
2.2
Vraagspecificatie voor geïntegreerde contracten
Geïntegreerde contracten (Design, Build, Finance, Maintenance, Operate (DBFMO)) zijn contracten met een lange levensduur (15 – 25 jaar). De vraagspecificatie voor dit type contracten spelen een andere rol dan bij traditionele contracten (D / B-contracten of DB-contracten). In traditionele contracten wordt de vraagspecificatie (het programma van eisen) in de loop van het proces vervangen door het ontwerp en bestek. In geïntegreerde contracten is de vraagspecificatie (Outputspecificatie) een onderdeel van het contract. Gedurende het contract zal de geleverde kwaliteit worden getoetst aan de vraagspecificatie.
Blad /47
6
Omdat de vraagspecificatie bij geïntegreerde contracten een andere rol vervult zal ook meer aandacht moeten worden besteed aan de ‘houdbaarheid’ van de vraagspecificatie. De vraagspecificatie moet eenduidig, consistent en volledig zijn en moet zo zijn opgezet dat het de volledige contractperiode mee kan. Eisen die aan het gebouw en dienstverlening worden gesteld moeten toetsbaar zijn. Daarnaast moet de vraagspecificatie ruimte laten voor het consortium om met de best passende oplossing te komen. De vraagspecificatie voor geïntegreerde contracten voor Rgd-projecten wordt beschreven vanuit de gewenste functionaliteit en kwaliteit. Hiervoor wordt het volgende model gehanteerd gebaseerd op het Nordic Five Level Model.
Figuur 2: model opzet vraagspecificatie geïntegreerde contracten geïntegreerde Rgd projecten
1. Allereerst wordt de doelstelling van de organisatie beschreven (wat willen we bereiken). 2. Op basis van de geformuleerde doelstellingen worden de gewenste uitgangspunten c.q ambities beschreven. Hierin zullen de verschillende waarde zoals architectonische waarden, functionele waarden etc. terug komen. 3. De uitgangspunten worden vervolgens ‘vertaald’ naar prestatie eisen. Prestatie eisen worden zoveel mogelijk geformuleerd vanuit de gewenste kwaliteit en niet vanuit de (mogelijke) oplossing. 4. Prestatie eisen moeten tijdens de ontwerp en exploitatiefase éénduidig getoetst kunnen worden (krijgen we wat we hebben gevraagd). Hiervoor zal per prestatie eis een verificatie/validatiemethode worden beschreven. Dit kan een verwijzing naar (NEN) normering zijn maar ook naar eigen richtlijnen of procedures etc. Het moet echter voor beide partijen op voorhand duidelijk zijn hoe er getoetst gaat worden. 5. Referenties worden gebruikt ten behoeve van de communicatie. De opdrachtgever kan referenties gebruiken (bijv. foto’s, sfeerbeelden etc.) ter toelichting op zijn vraagspecificatie, de opdrachtnemer kan referenties gebruiken ter toelichting op de gekozen oplossing. Omdat de vraagspecificatie een onderdeel is van het (langdurige) contract zal veel aandacht moeten worden besteed aan mogelijke veranderingen gedurende de contractperiode. Hoewel veranderingen moeilijk te voorspellen zijn, moet hier, bij de opzet van de vraagspecificatie, wel rekening mee gehouden worden en moet de vraagspecificatie de nodige flexibiliteit bieden. Voorbeeld prestatie eis Voor bepaalde type werkzaamheden wordt een akoestisch achtergrondgeluidniveau wenselijk geacht. Dit achtergrondgeluidniveau wordt als prestatie eis opgenomen in de vraagspecificatie. De kwaliteit van mogelijke binnenwanden, eisen aan aansluitingen op vloer wanden en plafonds (= oplossing) worden dus uitdrukkelijk niet beschreven. De opdrachtnemer heeft vervolgens de vrijheid om dit naar eigen inzicht op te lossen. Dit kan hij doen door kamers te realiseren met binnenwanden van een bepaalde kwaliteit maar wellicht zijn er ook andere mogelijkheden die passen binnen de uitgangspunten. Met name de relaties tussen de verschillende onderdelen van de vraagspecificatie bevat relevante informatie. Deze relaties zijn moeilijk in papieren vorm weer te geven. Voor het project “PPS Renovatie Financiën” heeft de Rgd samen met het ministerie van Financiën gekozen voor het digitaal vastleggen
Blad /47
7
van de informatie. Digitaliseren van informatie heeft als voordeel dat informatie maar op één plek in een database wordt vastgelegd (verbetering van consistentie) en dat (semantische) relaties tussen de informatie zichtbaar worden. Doordat informatie maar één maal in de database voorkomt is ook het doorvoeren van wijzigingen veel eenvoudiger geworden. Voorbeeld digitaliseren van informatie Om te voldoen aan de wens dat de mens zijn omgeving wil kunnen beïnvloeden zijn te openen ramen gewenst in alle mogelijk ruimten. In een papieren versie zou voor elke ruimte het te openen raam met zijn specificaties beschreven moeten worden. Hierdoor ontstaat de kans dat er fouten optreden in de specificaties van het raam (1 te openen raam per travee, 1 te openen raam per kamer, 0,5 m2 te openen raam per stramien etc.) terwijl telkens hetzelfde raam bedoeld wordt. Men kan er ook voor kiezen te verwijzen naar de specificaties van het raam maar dat betekent veel heen en weer geblader in de, over het algemeen vrij volumineuze, vraagspecificatie. In een digitaal model wordt het te openen raam één maal vastgelegd met de specificaties die daarvoor gelden. Als men in een ruimte wil aangeven dat er een te openen raam aanwezig moet zijn dan verwijst men naar dat raam en hoeft het raam niet telkens opnieuw te beschrijven. De kans op fouten is hierdoor dus drastisch afgenomen en met één druk op de knop ziet men de gewenste specificatie van dat raam. Mocht het zo zijn dat men in een bepaalde ruimte andere specificaties aan het te openen raam wil stellen dan wordt een tweede type te openen raam beschreven en wordt voor die specifieke ruimte naar dat tweede type raam verwezen. Werkwijze Het digitaliseren van de vraagspecificatie vraagt om een andere werkwijze: • Opstellers van de vraagspecificatie moeten meer in structuren kunnen denken. • Het vastleggen van de specificaties moet kort en bondig gebeuren: men beschrijft het kenmerk (de prestatie eis) en de waarde die moet worden gerealiseerd terwijl men in traditionele programma’s van eisen men nog al eens wil vervallen in het opschrijven van veel proza met veel verborgen eisen. • Relaties tussen de verschillende onderdelen moeten weloverwogen worden gelegd anders ontstaat er een informatie ‘overkill’ en schiet het zijn doel voorbij.
2.3 Het verificatiemodel van Safire Door gebruik te maken van de PKM Software en de ICOP gebruikersinterface voor het inrichten van het verificatie- en validatieproces, wordt ondersteuning gegeven voor de systematische en expliciete werkwijze. Deze digitale modellen zijn noodzakelijk door de grote hoeveelheid eisen en de vele onderlinge relaties in de outputspecificatie. Dit is niet meer overzichtelijk hanteerbaar in Excel of zelfs Access. Tevens is een webbased oplossing gewenst doordat de ontwerpteams meestal niet op een locatie zitten. Het gevaar is dat men eigen lijstjes over en weer gaat mailen, met inconsistentie tot gevolg. De Outputspecificatie voor de renovatie van het ministerie van Financiën is opgesteld vanuit een functionele benadering. In de fase van het conceptuele ontwerp, grotendeels in de aanbiedingsfase, is dit geen probleem. Een kernteam van de verschillende disciplines houd zich dan bezig met het ontwerpen van een integrale oplossing op hoofdlijnen. Echter op het moment dat het definitief ontwerp en daarna het uitvoeringsontwerp opgesteld moet worden, is de ontwerporganisatie sterk uitgebreid met allerlei specialisten van de verschillende disciplines. De raakvlakken op detailniveau nemen toe en zonder overzicht op het geheel nemen de kans op fouten navenant toe.
Blad /47
8
De primaire doelstelling van het verificatiemodel was dan ook het expliciet inzichtelijk maken van de eisen en raakvlakken van de werkpakketten van de verschillende disciplines. Daarbij hoort de vastlegging van verantwoordelijkheden van de partijen binnen het Safire consortium, zodat iedereen weet waarvoor hij aan de lat staat. Op deze wijze wordt een demarcatielijst verkregen van niet alleen objecten, maar ook de daarbij behorende verificaties en validaties. Dit was extra van belang aangezien het Safire consortium ervoor had gekozen de verantwoordelijkheid van kwaliteitsborging bij de partijen zelf neer te leggen, waarbij gebruik mocht worden gemaakt van de eigen kwaliteitssystemen. Middels het verificatiemodel wilde Safire de voortgang in de verificaties en validaties monitoren aan de hand van de stand van de projectplanning. Het was in eerste instantie niet de bedoeling om het verificatiemodel te gebruiken om aan de opdrachtgever aan te tonen dat aan alle eisen werd voldaan. Dit zou traditioneel middels hardcopy bestek en tekeningen plaatsvinden. Doordat alle ontwerpdocumenten in het model zouden worden opgenomen is dat wel als mogelijkheid geopperd. Pas in een latere fase konden hier afspraken over worden gemaakt. Bij het opstellen van het technisch ontwerp van de gebruikersinterface is hier dan ook geen rekening mee gehouden. Zo is bijvoorbeeld onvoldoende uitgedacht hoe de testboom met verficaties en validaties het beste ontsloten kon worden vanuit de oorspronkelijke eisenboom (outputspecificaties). Het verificatiemodel is altijd wel beschouwd als projectarchief. Aangezien er op dat moment geen behoefte was aan status- en revisiebeheer, dat vond immers plaats bij de partijen, zouden (definitieve) documenten officieel in het model worden bewaard. Hiervoor zijn aanvullende afspraken gemaakt over enerzijds codering van documenten en anderzijds back-ups van het model. Een bijkomend voordeel hiervan is, dat op een andere locatie, daar waar de server wordt gehost, het archief aanwezig is en deze vanuit elke willekeurige locatie beveiligd benaderbaar is. Met de documentatie is het verificatie- en validatiedossier compleet. Doordat het verificatiemodel pas in een relatief laat stadium van het ontwerp operationeel was, is bewust gekozen om niet de objectenboom uit te werken. Er is gekozen om de testboom met verificaties en validaties direct te koppelen aan de eisenboom (outputspecificaties). De eisenboom is wel uitgebreid met de belangrijkste aanvullingen van de aanbieding (BAFO) van Safire. Zo waren er bijvoorbeeld geen expliciete eisen gesteld aan het atrium. Het atrium is als ruimte aangemaakt in de ruimteboom van de outputspecificatie, waaraan de verificaties en validaties konden worden gekoppeld.
Screenvoorbeelden: zie bijlage A
Blad /47
9
Werkwijze Voor het gebruik van het verificatiemodel was de doelgroep vanaf het begin helder. De projectleiders van de partijen (ofwel disciplines) werden aangewezen als eindverantwoordelijk voor de kwaliteitsborging van hun scope. Daarmee waren zij verantwoordelijk voor het afvinken van de verificaties en validaties. Uit praktische overwegingen zijn er tevens secundanten van de projectleiders als gebruikers in het model opgenomen. Voor het Safire consortium was dit de Ontwerpmanager tezamen met de kwaliteitscoördinatoren voor het ontwerp. Aangezien de gebruikersinterface van PKM/ICOP zeer gebruikersvriendelijk is, is niet specifiek aandacht geschonken aan eventuele specifieke wensen van de gebruikers. Het model spreekt als het ware voor zich en de acties die de projectleiders moesten uitvoeren waren erg simpel. Toen het verificatiemodel was ingericht is er een training van de gebruikers gehouden. Opgemerkt moet worden is dat het verificatiemodel een basisfunctionaliteit had, en dat bij uitbreiding van die functionaliteit, door bijvoorbeeld koppelingen met objecten- activiteiten- of risicobomen, er meer uitleg nodig zal zijn.
Blad /47
10
Hoofdstuk 3
Constateringen en waarderingen
Onderstaand hoofdstuk geeft een overzicht van de constateringen die in de interviews gedaan zijn over het gebruik van zowel de digitale Outputspecificatie als het digitale Verificatiemodel. De waarderingen zijn ingedeeld in de volgende categorieën: -
sterk punt aandachtspunt minpunt
3.1 Constateringen en waarderingen over de outputspecificatie Onderstaande tabel geeft een overzicht van constateringen die zijn gedaan door de opdrachtgever en de opdrachtnemer over de outputspecificatie. Outputspecificatie Sterke punten Er zijn veel fouten, tegenstrijdigheden en dubbelingen uit het papieren programma van eisen verwijderd door te werken met het digitale model Er zijn voldoende mogelijkheden om te controleren op juistheid en compleetheid van gegevens Doordat het systeem digitaal is, is informatie gemakkelijk ontsluitbaar en locatie ongebonden Het systeem fungeerde als naslagwerk Voor de samenwerking tussen partijen was het systeem een handig instrument: je kunt gemakkelijk naar aanvullende documenten verwijzen De outputspecificatie heeft ertoe bijgedragen dat de opdrachtgever een beter passend ontwerp kreeg Het systeem is gebruiksvriendelijk. Er is niet veel training nodig om het te hanteren Aandachtspunten Opdrachtnemer heeft het positief ervaren de Outputspecificatie na gunning als bronbestand te ontvangen. Voor het verificatiemodel was dit echter te laat beschikbaar, waardoor in het verificatiemodel niet optimaal gebruik kon worden gemaakt van de mogelijkheden(*)2 Het ‘modelleren’ van de gegevens vereist nieuwe competenties van de opdrachtgever Algemene normen (zoals bouwbesluit en archiefwet), waarnaar de opdrachtgever verwijst en waaraan de opdrachtnemer moet voldoen, zijn niet als eisen (bolletjes) opgenomen. Hierdoor zijn deze minder zichtbaar en zie je ze snel over het hoofd
2
Punten die gemarkeerd worden met een asterisk zijn inmiddels opgelost.
Blad /47
11
3.2
Constateringen en waarderingen over het verificatiemodel en bestek toetsen
Onderstaande tabel geeft waarderingen en constateringen weer die gedaan zijn door opdrachtgever en opdrachtnemer over het verificatiemodel en het toetsen van het bestek. Verificatiemodel + bestek toetsen Sterke punten Het verificatiemodel was een perfecte checklist voor partijen in het consortium om te bepalen of je aan alle gestelde eisen voldeed Het systeem is gebruiksvriendelijk. Er is niet veel training nodig om het te hanteren Het systeem is een helder tool voor de demarcatie (het verdelen en beleggen van de verantwoordelijkheden) binnen het consortium De vinkjes in het model vormen een goede controleslag voor de opdrachtgever om te controleren of aan alle eisen is voldaan. Echter niet alle verificaties waren met testrapporten onderbouwd (een gevolg van de tijdsdruk in het proces) Aandachtspunten Er is een zoekfunctie aanwezig in het systeem. Echter, deze werkt niet naar verwachting van de gebruikers De codering van de tekeningen zou moeten worden uitgebreid met de naam van de tekening, zodat een tekeningenlijst ontstaat. Dat is nu handmatig gedaan Eisen waar meerdere partijen in het consortium verantwoordelijk voor zijn, zoals logistiek en veiligheid, komen in het digitale systeem bij één partij te liggen. Het is onvoldoende zichtbaar welke partijen mede ook verantwoordelijkheid dragen voor een bepaalde eis, laat staan dat de vereiste afstemming tussen partijen plaatsvindt. Er wordt verondersteld dat er per discipline (werkscopes binnen het consortium) ontworden kan worden Als stuurinstrument voor de managers van het proces is het systeem geschikt, maar wegens tijdsdruk niet zo gebruikt. Partijen vulden pas aan het einde van hun ontwerpproces in dat aan een eis voldaan werd, waardoor niet duidelijk werd wat de stand van zaken is gedurende het ontwerpproces. Hierop moet meer gestuurd worden vanuit ontwerpleider Het toetsen vanaf een computerscherm is vermoeiend en niet altijd goed mogelijk. Gezien de omvang van de tekeningen is het prettiger deze te printen. Er was dus best nog veel papierwerk Voor deze werkwijze was niet altijd duidelijk welke eis op welk moment in het proces(BAFO, Bestek) wordt geverifieerd Normen waarnaar de opdrachtgever verwijst en waaraan de opdrachtnemer moet voldoen zijn niet als eisen (bolletjes) opgenomen. Hierdoor zijn deze minder zichtbaar en zie je ze snel over het hoofd Minpunten Responstijden van de software zijn te hoog (*) Het verificatiemodel is ingericht op basis van disciplines. Voor de opdrachtgever zorgde dat nog wel voor zoektochten naar de complete oplossing voor een bredere multidisciplinaire eis.
Blad /47
12
Hoofdstuk 4 Conclusies en aanbevelingen In dit hoofdstuk worden de conclusies, die het antwoord vormen op de onderzoeksvraag geformuleerd. De conclusies zijn onderverdeeld in drie typeringen: organisatie, procedure en technisch. Vervolgens worden in paragraaf 4.2 aanbevelingen voor zowel het systeem zelf als de organisatie rondom het systeem opgesomd. De onderzoeksvraag Welke conclusies en aanbevelingen kunnen, op basis van de ervaringen met de ontwikkeling en het gebruik van het digitale Outputspecificatiemodel en het Verificatiemodel voor de PPS Renovatie Financiën, worden gegeven voor het verbeteren van de communicatie bij aanbestedingen en het ontwerp (tot besteksniveau) in de utiliteitsbouw?
4.1
Conclusies
Algemeen In het algemeen kan geconcludeerd worden dat alle partijen (Ministerie van Financiën, RGD, Consortium) zo enthousiast over het resultaat zijn, dat zij door gaan met de verdere ontwikkeling. Zij hebben ervaren dat de (potentiële) meerwaarde ruimschoots opweegt tegen de investeringen. Daarbij realiseren zij zich dat in dit eerste project veel werk is verricht, dat in volgende projecten kan worden hergebruikt.
Organisatie Onder organisatie wordt verstaan: de organisatie, de competenties en het management van partijen (werkvormen)
Vooruitlopend op het digitale systeem vraagt deze aanpak de competentie bij de opdrachtgever om de eisen in output te kunnen formuleren. Daarna is niet veel training nodig om het te gebruiken door zowel de opdrachtgever als opdrachtnemer. Het moeilijkst aan het systeem is het vertalen van de papieren outputspecificaties naar bolletjes en lijntjes, de relaties tussen de bolletjes. Dit vraagt extra competenties van de opdrachtgever. Bij het verificatiemodel is het arbeidsintensief om de juiste eisen toe te bedelen aan de juiste partijen in het consortium. Door het toebedelen van de eisen aan partijen (demarcatie) wordt transparant welke partijen voor welke eisen verantwoordelijk zijn. Er is in dit consortium gekozen voor disciplinematig ontwerpen. Risico aan deze organisatievorm is dat afstemming tussen partijen niet voor de hand ligt bij eisen die voor meer partijen gelden, hetgeen bij outputspecificeren nogal eens voorkomt. Om dit probleem te voorkomen is voor multidisciplinaire eisen gewerkt met werkgroepen die per eis zijn ingericht, echter deze werkwijze brengt het risico met zich mee erg veel te vergaderen. Doordat het werken met het verificatiemodel nog geen common practice is, en de invoering te laat was omdat er geen bronbestand beschikbaar was, werd het systeem tijdens de ontwerpfase nog niet al werkende weg gebruikt om te verifiëren door de partijen in het consortium. Daardoor was er voor het management gedurende het ontwerpproces nog geen informatie beschikbaar over de status van de verificatie. De ervaringen van dit eerste project t.a.v. de kosten en de baten rechtvaardigen de keuze van de deelnemersom hiermee verder te gaan.
Blad /47
13
Procedure Onder procedure wordt verstaan: de manier van werken met het digitale model Het outputspecificatiemodel maakt het mogelijk voor de opdrachtgever dat er een nauwkeurige controle uitgeoefend kan worden op de consistentie van de outputspecificatie. Verkeerde gegevens en interne tegenstrijdigheden worden snel zichtbaar en kunnen aangepast worden, waardoor de kwaliteit van de outputspecificatie toeneemt. Het digitale systeem zorgt ervoor dat informatie overal toegankelijk is en fungeert als naslagwerk voor zowel opdrachtgever als opdrachtnemer. Een belangrijke functie van het systeem is die van een de document management systeem. Hierdoor kan eenvoudig het wijzigingenbeheer op consistente wijze worden gevoerd. De lange contractduur (25 jaar) vraagt om goed bewaarde documentatie. Het systeem zorgt ervoor dat onduidelijke mapstructuren op lokale computers en archieven met mappen overbodig worden. Het verificatiemodel biedt voor de opdrachtgever een ondersteuning in het bepalen of het ontwerp aan de eisen voldoet. Echter, niet bij alle verificaties zijn testrapporten opgenomen waardoor in die gevallen onvoldoende onderbouwd is of aan de eis voldaan wordt. Niet altijd was duidelijk welke eis op welk abstractieniveau in dit (besteks-)stadium geverifieerd moest worden.
Technisch Onder technisch wordt verstaan: de software en hardware van het digitale model (de database + twee templates) Het systeem is gebruiksvriendelijk. Een voorlichtingsmiddag is voldoende training voor de gemiddelde gebruiker om het systeem in het eigen proces te gebruiken. Het modelleren van de outputspecificaties in het systeem is echter complex en vraagt om specifieke competenties met betrekking tot het modelleren van de template en domeinkennis van huisvesting en gebouwen.
4.2
Aanbevelingen
De volgende aanbevelingen zijn verbeteringen voor zowel het systeem zelf als de organisatie rondom het systeem die op korte termijn kunnen worden opgepakt. Het systeem verdient een legitieme positie Om het functioneren van het systeem te optimaliseren moet het een stevige plaats in het proces krijgen, zowel bij opdrachtgever als bij opdrachtnemer. Managers dienen het gebruik van het systeem te verplichten, waardoor het als stuurinstrument bruikbaar wordt. Let wel, dit kan extra training vergen van de gebruiker. Tevens dienen gegevens in het systeem vanuit juridisch perspectief erkend te worden, zodat niet langer met gesigneerde CD’s-ROM of papier gewerkt hoeft te worden.
Richt een bijpassende organisatie in De methodiek die achter een integraal systeem met Outputspecificaties en Verificaties ligt vereist ook meer integraal werken. De theorie van Systems Engineering past daar goed bij. In de praktijk betekent dit dat bij zowel opdrachtgever als opdrachtnemer multidisciplinaire sessies kunnen en moeten worden georganiseerd. Hierbij kan dan iedereen vanuit zijn eigen deskundigheid inbreng geven en tegenstrijdigheden direct worden herkend en eventueel opgelost. Met bijvoorbeeld een beamer kan men in groepen diverse eisen te toetsen. Hierdoor kan de hoeveelheid printwerk en het aantal afstemmingsbilateralen verminderd worden, waardoor transactiekosten verlaagd worden en tevens de totale kwaliteit wordt verhoogd.
Blad /47
14
Voor het consortium is het van belang om te sturen op het gebruik van het systeem. Om niet te vervallen in non-integraal ontwerpen door het zogenaamde opknippen van de eisen kan in het systeem de volgende aanpassing worden gemaakt: Eis: Veiligheid
Hoofdverantwoordelijke Burgers Ergon
Medeverantwoordelijke(n) GTI, Strukton
Hierdoor wordt duidelijk welke partijen met elkaar moeten samenwerken om aan gestelde eisen te kunnen voldoen. Het werken met multidisciplinaire teams kan deze manier van denken versterken in de uitvoering. Verbeteringen in de Outputspecificatie voor de opdrachtnemer Om te kunnen werken met het digitale model is het voor de opdrachtnemer wenselijk om direct over een digitale versie van de outputspecificatie te beschikken. Het model moet in een eenvoudig in te lezen bestandstype zijn opgeslagen. Inmiddels is hiervoor de mogelijkheid geopend voor volgende projecten bij de Rijksgebouwendienst. Verbeteringen in het Verificatiemodel voor de opdrachtgever Voor de opdrachtgever zou het makkelijker doorzoekbaar zijn wanneer er een parallelboom ontwikkeld wordt, waarin alle eisen op basis van door hen gehanteerde thema’s als logistiek en veiligheid wordt ingedeeld. Op deze manier wordt het systeem beter doorzoekbaar tijdens de Verificatiefase. Het systeem kan Systems Engineering beter ondersteunen Het systeem zou de diverse fasen in het proces beter moeten volgen. De volgende fasen worden in ieder geval herkent: Outputspecificatie, Bafo (Best en Final offer), Bestek, Toetsen, Monitoring. Voor elke fase zijn voor Opdrachtgever en Opdrachtnemer andere eisen te vervullen. Daarnaast moet de inhoud van het systeem ook vergelijkingen toestaan tussen diverse stadia. Zo is een Bafo een antwoord op de Outputspecificatie en wordt het Bestek getoetst op basis van de Outputspecificatie en de aanvulling daarop tijdens de ontwerpfase. Systems Engineering is geschikt om deze procesgang te ordenen en eisen en oplossingen systematisch bij elkaar te houden. Het systeem zou dit moeten ondersteunen. Documenten, testrapporten en normen als document opnemen Om ervoor te zorgen dat het systeem ook tijdens en na de verificatie de karakteristieken van het model behoudt, is het noodzakelijk om elk document, testrapporten of norm (platte tekstdocumenten) eenmalig in het systeem op te nemen. Het leggen van de juiste relaties naar deze documenten voorkomt dat dubbelingen in het systeem ontstaan of dat het moeilijk doorzoekbaar wordt.
Blad /47
15
Bijlage A
Screenvoorbeelden
Blad /47
16
Blad /47
17
Blad /47
18
Blad /47
19
Blad /47
20
Blad /47
21
Blad /47
22
Blad /47
23
Blad /47
24
Blad /47
25
Blad /47
26
BIJLAGE B
Vragenlijsten
- Vragenlijst algemeen - Vragenlijst ICT
Blad /47
27
Vragenlijst Algemeen • •
•
•
Met welke aanname met betrekking tot het gebruik van het model is het project begonnen? Hoe ondersteunt het digitale model het verificatieproces? o
In hoeverre draagt het gebruik van digitaalmodel programma's daadwerkelijk bij aan de kwaliteitborging (tov bijv excel lijsten)?
o
Welke voordelen dan wel nadelen hebben digitaal model programma's bij digitale communicatie tijdens aanbestedingen?
Hoe ondersteunt het de opdrachtgever/aanbieder? o Wat is het verschil tussen het digitale model en de traditionele manier van verifiëren? o
Wat betekent het gebruik van digitaal model programma's voor de werkbelasting van het toetsen van oplossingen door de Opdrachtgever?
o
Wat betekent het gebruik van digitaal model programma's voor de werkbelasting van het toetsen van oplossingen door de Opdrachtnemer?
o
Hoe is de samenwerking beïnvloed door het gebruik van het digitale model?
Hoe zou het model verbeterd kunnen worden? o Wat zijn de aanbevelingen voor het inrichten van de digitaal model programma's? (standaard benaming relaties, toepassen familie relaties,...) o o
Wat zijn de aanbevelingen voor verificatie- en validatiemethoden? (welke type eisen/relaties worden geverifieerd dan wel gevalideerd, welke standaard methoden kunnen worden onderscheiden, expliciet maken van fasen (wanneer welke),...)
Blad /47
28
Vragenlijst ICT evaluatie ministerie van Financiën Gebruikersgroep Opdrachtgever 17 april 2007
1. Met welke aanname met betrekking tot het gebruik van het model is het project begonnen? (hoe kregen jullie te horen dat er gewerkt werd met PKM en wat stelde je je erbij voor?) Notitie 2. Hoe ondersteunt het digitale model het verificatieproces? o
In hoeverre draagt het gebruik van digitaalmodel programma's daadwerkelijk bij aan de kwaliteitborging (tov bijv excel lijsten)?
o
Welke voordelen dan wel nadelen hebben digitaal model programma's bij digitale communicatie tijdens aanbestedingen?
3. Hoe ondersteunt het de opdrachtgever/aanbieder? o Wat is het verschil tussen het digitale model en de traditionele manier van verifiëren? o
Wat betekent het gebruik van digitaal model programma's voor de werkbelasting van het toetsen van oplossingen door de Opdrachtgever?
o Hoe is de samenwerking beïnvloed door het gebruik van het digitale model? Wat zijn de aanbevelingen voor verificatie- en validatiemethoden? 4. Hoe zou het model verbeterd kunnen worden? Wat zijn de aanbevelingen voor het inrichten van de digitaal model programma's? 5. Is het eenvoudig om de juiste plaats voor gegevens te bepalen? Is het eenvoudig te voorspellen waar je bepaalde gegevens kunt terugvinden? Welke gegevens zijn makkelijk te traceren, welke het moeilijkst? Notitie 6.
Zijn er eenvoudige zoekfuncties voorhanden? Worden die veelvuldig gebruikt? Zijn die ook hard nodig? Notitie
7. Hoe kan je gestructureerd alles doornemen? Is dat wel eens nodig gebleken, heeft iemand dat wel eens gedaan? En waarom?
Blad /47
29
8. Hoe weet je of de data compleet is? 9. Welke gedeelte van de software werd het meest gewaardeerd, welke het minst? En waarom? 10. Wat vond u het vervelendst? 11. Wat was de leercurve om het systeem en de methodiek te doorgronden? Kan iedereen er mee omgaan? Wie wel , wie minder goed? Waarom? 12. Waren er problemen met rapporten, printen, uitvoer anderszins? 13. Hoe was de reactie snelheid bij problemen? Is er een goed functionerende helpdesk? Heeft u die nooit, weinig, veel, vaak gebeld? 14. Welke training en ondersteuning is noodzakelijk, cq. gewenst voor nieuwe gebruikers? En voor een nieuw project? 15. Welke training hebben de gebruikers nu gehad? Was dat voldoende? Hebben ze veel zelf moeten uitzoeken/uitvinden? 16. Was de PKM tool het juiste gereedschap voor het doel? Zijn er alternatieven? Hoe kan het anders? Is het te ingewikkeld, of sluit het precies aan bij het doel?
Blad /47
30
17. Wat zou eenvoudiger kunnen?
18. Wat zou nog eenvoudig bijgemaakt kunnen worden?
19. Wat zou uw eerste wens zijn bij aanpassing of uitbreiding van het systeem?
Blad /47
31
BIJLAGE C Respondentenlijst
Naam Sietske Bergsma Angelia Zeegers Fred Kater Juriaan v Meel Fred Lohman Marc Mommers Pascal van Bruggen Berjan Arentsen Bernd Karstenberg Ger van de Zwan Emile Boele Ton Wolff Conchita Wolf
Organisatie Min Fin RGD Min Fin Icop PKM Strukton GTI Burgers Ergon Deerns Min FIn RGD Min Fin Min Fin
Blad /47
32
BIJLAGE D Besprekingsverslagen
Blad /47
33
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Opdracht Specificatie en tbv Verificatie
Aanwezig:
Frank Hoekmeijer (Strukton), Kees Robers (PSIB), Jan Kees Pikkaart (PSIB) Mercure Hotel Deventer
Plaats:
Opgesteld: J.K. Pikkaart Datum: 23 maart 2007
Rol van Frank in het PPS contract tbv Ministerie van Financiën is (was): Kwaliteits Coordinator Ontwerp. Daarnaast is Frank vanaf het begin van het maken van de aanbieding betrokken geweest bij het project als PPS deskundige. Vincent van der Sleen is hem opgevolgd nu het project in de “operationele modus” is gekomen. Frank is nu betrokken bij andere PPS contracten van Strukton. Door de opdrachtgever is tbv de aanbesteding van het PPS contract een digitale versie gemaakt van de Outputspecificatie (OS). Deze is aan de aanbieders beschikbaar gesteld door middel van een website (HTML) waarop de specificaties konden worden gelezen. De onderliggende database is niet beschikbaar gesteld. Het Verificatiemodel (VM) is gebaseerd op een kopie van de database van de OS. Daarop is een filtering en ordeningsmodule aangebracht waarmee de OS enerzijds kon worden benaderd vanuit het gezichtspunt van ontwerpdisciplines. Anderzijds werden de Specificaties waar nodig “gedecomponeerd” in meetbare/toetsbare (=verifieerbare) eigenschappen. De ambitie voor het VM begin 2006 bij opdracht was tweeledig en met name intern-Safire gericht: 1. eisen inzichtelijk maken aan de ontwerpgroep 2. afchecken van gerealiseerde eisen De ambitie was niet: het automatiseren van een vergelijking tussen OS en de ontworpen oplossing. Ook was het niet de bedoeling om het te gebruiken voor het aantoonbaar maken van het voldoen aan de specificaties. Dit VM is te laat bruikbaar geworden om vanaf de aanvang van het ontwerp te dienen als uitgangpunt voor het ontwerp. Frank beveelt aan om dit de volgende keer wel te doen. Het ontwerp is achteraf getoetst door het VM te gebruiken. Alle eisen zijn handmatig afgevinkt wanneer in het ontwerp aan de eisen werd voldaan. Deze achteraf check heeft nauwelijks veranderingen in het ontwerp tot gevolg gehad. Maw het ontwerp was goed ondanks dat het VM niet vanaf het begin werd gebruikt. De engineers vonden het wel handig om te verifiëren, maar zouden het geen meerwaarde hebben gevonden tijdens het ontwerpproces. Voor hun gevoel was het extra werk en bracht de digitale versie van de OS niet minderwerk met zich mee. Men moest veel zoeken. In de OS zijn ruimtetypen beschreven met hun specificaties. Dus niet elke ruimte afzonderlijk. In het VM is deze methodiek overgenomen. Het was te veel werk om alle objecten van het ontwerp uniek op te nemen. Onderliggende problematiek is ook dat de juridische status bij zowel Opdrachtgever als Opdrachtnemer van de digitale-OS en het VM niet duidelijk is. Daardoor worden beiden behandeld als “nice to have” en niet als noodzakelijke middelen bij het project. Dit is duidelijk een verbeterpunt.
Blad /47
34
De argumentatie vanuit de opdrachtgever om de OS (digitaal) niet onderdeel te maken van het contract is bij Frank niet bekend. (navragen bij RGD) Het VM zou nu moeten dienen om aan te tonen dat aan de eisen wordt voldaan. Echter het voldoen aan de eisen die gesteld zijn, heeft een tijdsaspect. Volgens Frank is bij het verkrijgen van de opdracht al aan een aantal gestelde eisen voldaan. Daarnaast zal pas tijdens de gebruiksfase aan andere, pas dan verifieerbare, eisen kunnen worden voldaan. Volgens hem is de huidige status dus een momentopname. De wens van de opdrachtgever om in februari 2007 aan te tonen dat aan alle eisen wordt voldaan, kan niet gerealiseerd worden middels het VM. De ontwerpmanager van Strukton (Mark Mommers) en meerdere ontwerpers waren niet op voorhand positief over de digitale OS en het VM. Dit heeft ook tot minder resultaten en gebruik geleid dan mogelijk was geweest. De verificatie bij de opdrachtgever heeft uiteindelijk ook traditioneel plaatsgevonden; mede doordat geen log-in mogelijkheid was meegegeven en de opdrachtgever daar ook niet naar heeft gevraagd. Belangrijkste conclusies van Frank: eerder beginnen met het VM model anders opbouwen met verschillende views: objectenboom (decompositie van het gebouw), verificatieboom (discipline geordend), specificatieboom (eisen) zeer nuttig voor het formaliseren van de (ook interne) eisen ten behoeven van validatie en verificatie. Dit gebeurt dan explicieter. noodzaak aan standaardisatie van relatiedefinities Naast dit gesprek is voor specifieke ICT vragen een vragenlijst uitgereikt. Frank heeft toegezegd deze in te vullen en binnen twee weken te retourneren. De vragenlijst kan ook digitaal van de Projectwebsite worden gehaald. Alleen de “C-vragen” zijn voor hem als gebruiker van belang.
Blad /47
35
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Output Specificatie en tbv Verificatie
Aanwezig:
Sietske Bergsma (Min Fin), Kees Robers (PSIBouw), Serena Scholte (PSIBouw) deels: Fred Kater (Min Fin) Ministerie v Financiën
Plaats:
Opgesteld: S.J. Scholte
Datum: 29 maart 2007
Sietkse geeft aan vooral bij het OS deel betrokken te zijn geweest. Haar rol bij het VM deel is coördinerend. Hoe is men tot de keuze gekomen om te werken met het PKM-model? Het ministerie heeft samen met de Rgd bewust gekozen voor het gebruik van het PKM model om de volgende redenen: minder papier consistentere outputspecificatie (minder fouten) In 2003 is er een traditioneel programma van eisen opgesteld. Het Center for People and Buildings heeft het ministerie de tip gegeven om te gaan praten met PKM Solutions. Zij hebben toen aangetoond aan de hand van het digitaliseren van een deel van de OS dat de kwaliteit van de OS substantieel zou toenemen. De Rgd was betrokken bij de besluitvorming en heeft een positief oordeel uitgesproken over het gebruik van PKM. De Rgd heeft een deel van de kosten van PKM gesubsidieerd. Nog meer voordeel Een ander voordeel van het gebruik van het model blijkt de vindbaarheid van de stukken. Alle rapporten en documenten staan bij elkaar opgeslagen. Dat voorkomt blader- en zoekwerk. Tevens is het model goed toe te passen voor versiebeheer. Testmodel: in de OS staat een testmodel waarin wordt aangegeven hoe toetsing van de eis in een bepaalde fase plaatsvindt. Daarbij is onderscheid gemaakt tussen de volgende fasen: inschrijving BAFO Voorlopige oplevering Exploitatie Einde contract De toetsing van het Uitwerkings- en Realisatieplan (het bestek maakt hiervan onderdeel uit) staat niet in de OS (verbeterpunt). De toetsing zelf wordt niet door het OS-model gefaciliteerd. Safire heeft de beschikking gekregen over het OS-model van Financiën als bronbestand voor het opstellen van hun verificatiemodel. Hoe wordt het model gebruikt voor de verificatie? De verificatie is op traditionele wijze verlopen. Het bestek en de tekeningen zijn uitgeprint en vervolgens beoordeeld. Het zogenaamde ‘vinkjes’ systeem (zoals door Safire ingevuld door de onderaannemers) is niet volledig en geeft niet voldoende inzicht in of en hoe de verificatie heeft plaatsgevonden. Niet alle testrapporten zijn beschikbaar. Een directe link met de eis uit de OS ontbreekt. Vanuit de bestekstoetsing zijn vragen- en opmerkingen lijsten opgesteld. Deze zijn door minfin aan het consortium verstrekt. Deze lijsten worden momenteel besproken. Er is wel een ‘go’ gegeven voor de aanvang van de bouwwerkzaamheden onder voorwaarde dat de vragen en opmerkingen op een juiste manier worden afgehandeld. Het vertrouwen is er dat dit gebeurt. Was het VM ook bedoeld voor Min Fin of alleen voor intern gebruik Safire?
Blad /47
36
Het model is in eerste instantie bedoeld voor intern gebruik Safire. Safire heeft toestemming aan minfin gevraagd om het bestek c.q. uitwerkings- en realisatieplan digitaal aan te leveren. D.w..z in de vorm van het VM-model. Minfin heeft hiermee ingestemd. Daarmee was een afgeleid doel toch ook het ondersteunen van het verificatieproces van minfin. Er zijn hier echter geen verdere afspraken over gemaakt. Hierdoor was het model voor ons (waarschijnlijk) minder gebruiksvriendelijk. (verbeterpunt) Klopt het dat er geen log-ins waren? Nee, dat klopt niet. Er was een lijst van log-ins die door Vincent vd Sleen beschikbaar zijn gesteld. Het systeem werkt nog niet optimaal wat het valideren betreft. Wanneer een aspect (of een oplossing)gevalideerd is (bijvoorbeeld door de beoordeling inschrijving), dan dient het systeem dit te valideren. Nu blijft de eis nog steeds in het systeem aanwezig terwijl de oplossing hiervoor in de plaats is gekomen (systemenginering). Daarnaast bleken logische relaties tussen verschillende onderdelen (de paden die je doorloopt voor verifieren) niet gelegd, waardoor je niet van document naar document kon klikken. Het is verstandig om samen met Deerns, Rgd en minfin-medewerkers (de bestektoetsers) een sessie te organiseren om het gebruik van het PKM model als verificatietool te evalueren. Hoe verliep het invullen in het consortium? Sietske geeft aan dat ze heeft vernomen dat er te weinig aandacht is besteed aan training en opleiding van de partijen in het consortium voor het werken met het systeem. Hierdoor is het onduidelijk of partijen het systeem op eenduidige wijze gehanteerd hebben. Tevens was voor partijen niet duidelijk hoe ze het systeem direct konden gebruiken, waardoor ze eerst traditioneel zijn gaan werken en het vullen van het systeem als extra werk hebben gezien. Wat is nu het grote voordeel van het systeem? Het systeem is eigenlijk een kwaliteitsborgingsysteem dat informatie bij elkaar brengt. Die informatie is op een gemakkelijke manier te ontsluiten. Het systeem heeft veel potentie omdat je eisen en oplossingen aan elkaar kunt koppelen. Hoe zou het systeem verder verbeterd kunnen worden? Het systeem zou eigenlijk een scheiding moeten maken tussen het aanbestedlngsdeel van de OS (het deel waarop je gunt) en een apart domein voor de bouw en exploitatiefase. Hier krijg je de prestatiemetingen. Het ontwerp van het consortium en andere onderdelen van de bieding maken hiervan integraal onderdeel uit. Essentieel wordt hierbij het wijzigingenbeheer: waarom is iets aangepast? En wat zijn de consequenties voor het totale ontwerp? Hier zou systemsengeneering meer tot zijn recht komen. Is de samenwerking beïnvloed door het gebruik van het digitale model? Ja, de samenwerking is vergemakkelijkt. Je kon makkelijk verwijzen naar stukken die eenvoudig vindbaar zijn in 1 systeem. Vooral voor de technische onderhandelingen is een dergelijk systeem een belangrijk hulpmiddel. Maar ook nu in het uitwerkingsproces. Over de werkbelasting bij het toetsen: wat voor invloed heeft het model daarop? De ontwikkeling van het OS model heeft veel tijd gekost. Vooral het invoeren vergt meer inzet. Deze tijd wordt zeker terugverdient wanneer wijzigingen zich voordoen en wanneer informatie gezocht moet worden. Op het toetsen heeft het VM-model niet zoveel invloed gehad. Er is veel uitgeprint en dus eigenlijk traditioneel getoets. In totaal zal er ongeveer 800 uur door het team aan besteed zijn. 5% meer dan normaal Voor het VM zou het goed zijn om te werken in een beamersessie Afgesproken wordt dat Fred een bijeenkomst met de echte gebruikers (Rgd/Deerns) belegt om de ervaringen te evalueren. Sietske merkt tot slot op dat het goed is om ook een evaluatie van de gebruikers aan de Safirekant te houden.
Blad /47
37
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Outputspecificatie en tbv Verificatie
Aanwezig:
Angelia Zeegers (RGD), Kees Robers (PSIBouw), Serena Scholte (PSIBouw) RGD
Plaats:
Opgesteld: S. Scholte Datum: 10 april 2007
Er wordt vastgesteld dat er naast het project KV 7 alweer nieuwe ervaringen worden opgedaan in de PPS-projecten Belastingdienst Doetinchem, Belastingdienst/ InformatieBeheerGroep Groningen en het Detentiecentrum Rotterdam. Deze ervaringen dienen aan de evaluatie toegevoegd te worden. Verificatiemodel KV7: er is vanuit PKM in 2005 een aanbod gedaan om een digitaal verificatiemodel voor de opdrachtgever te maken om het beidingsproces te vereenvoudigen. Van dit aanbod wilde men destijds geen gebruik maken. Er was geen tijd meer en men wilde eerst afwachten hoe het digitale OS-model bij de consortia zou vallen. Digitaal aanleveren van biedingen zou wellicht te veel van het goede zijn. Safire heeft na aanwijzing “Preffered Bidder” zelf het initiatief genomen een verificatiemodel op te stellen voor hun eigen primaire proces. Het verificatiemodel is door ICOP gemaakt voor Safire. In oktober 2006 is het verificatiemodel voor het eerst geperesenteerd en in februari 2007 kon de opdrachtgever middels het verificatiemodel bestek en tekeningen toetsen, voor zover er openstaande punten ter toetsing waren. Angelia is niet direct betrokken bij de toetsgroepen van het verificatieproces na gunning i.v.m. inzet bij andere projecten. Over de beoordeling van het project KV7 voor gunning merkt ze op: veel parpierwerk en veel zoekwerk. De opdrachtgever moet zelf de juiste informatie uit de stukken halen. Door de enorme hoeveelheid aan informatie zijn ook inconsistenties aan de zijde van de consortia geconstateerd dat weer leidde tot clarificatievragen (vertraging). In het project Detentiecentrum Rotterdam worden de biedingen middels een digitaal biedingsmodel aangeleverd (“geupload”). De opdrachtgever bepaald welke informatie hij wil hebben en hoe deze aangeleverd moet worden (format, hoeveelheid etc.)
Wat is de reden om te werken met een digitaal systeem? Wij verwachten van een digitaal biedings- en verificatiemodel efficiency verbetering van het proces en een kwaliteitsverbetering. Daarnaast biedt het duidelijkheid. De consortia weten wat ze aan moeten leveren en kunnen zich focussen op juist die informatie. Voor de toetsteams zal het tijdswinst opleveren (minder zoekwerk) en een betere vergelijking tussen de verschillende biedingen. Beschikbaar stellen van digitale data. Safire heeft aangegeven graag eerder in het proces de beschikking te hebben gehad over de digitale database om hun eigen interne processen beter te structureren. De Rgd heeft zich over deze vraag gebogen en onlangs besloten dat zij strategisch geen bezwaar verwacht indien de data digitaal beschikbaar wordt gesteld ter verbetering van interne processen van de consortia. Het beschikbaar stellen van de digitale data van de Outputspecificatie moet wel in een vorm gebeuren dat de data voor alle partijen te gebruiken is en zij niet gedwongen worden specifieke licenties aan te schaffen. Daarvoor is gekozen voor Excel. Of de data ook daadwerkelijk in de Rgd PPS-projecten ter beschikking wordt gesteld is een beslissing die de betreffende procesmanager moet nemen. De data kan beschikbaar worden gesteld aan consortia ter verbetering van hun interne proces. De uitvraag van de biedingen (wat moet er aan geleverd worden, in welke vorm, hoe gaat de opdrachtgever toetsen etc.) blijft ter bepaling van de opdrachtgever. Hij houdt de regie over het proces (incl. de toetsing). . Hoe kun je de communicatie tussen opdrachtgever en partijen verbeteren?
Blad /47
38
ICT is een hulpmiddel zo moet je het ook gebruiken. Door gebruik te maken van een biedings- en verificatiemodel wordt verwacht dat het voor de consortia duidelijker wordt welke stukken aangeleverd moeten worden en dat het voor de opdrachtgever eenvoudiger wordt de gevraagde stukken te toetsen. Bij het Detentiecentrum Rotterdam is voor het eerst gebruik gemaakt van een biedings- en verificatiemodel. Net als bij de eerste digitale outputspecificatie zullen er bij het eerste biedings- en verificatiemodel vast nog wel wat onvolkomenheden worden geconstateerd. In overleg tussen Opdrachtgever en consortia kan uiteindelijk een goed werkend model ontstaan. Dialoog is belangrijk om te komen tot een optimaal product. Hoe heeft men geleerd te werken met het systeem? ICOP / PKM-Solutions heeft voor de Rgd het Output Specificatie model (OS-model) ontworpen en voor de gebruikers van het model een training gegeven. Op dit moment worden zogenaamde heavy users opgeleid om zelf ook in staat te zijn te programmeren/modelleren in de database. Dit om ongewenste afhankelijkheid van 1 leverancier te voorkomen. Verbeterpunt voor het verificatiemodel van Safire: De bruikbaarheid van het verificatiemodel als toetsinstrument voor de opdrachtgever is sterk afhankelijk van de inrichting van het model. Het verificatiemodel van Safire is voor het eigen interne proces gebruikt en niet ontworpen om de opdrachtgever te helpen. Dit was ook niet de opzet. Kijkend naar het model is de bruikbaarheid voor de opdrachtgever beperkt. Alleen het gebruik van vinkjes zegt de opdrachtgever erg weinig. Het gaat om het proces achter het zetten van het vinkje: gebeurt dat uniform binnen het consortium en waarop is het vinkje gebaseerd? Het ontwikkelen van één model die aan de wensen van de opdrachtgever voldoet alsmede aan de wensen van de consortia is volgens Angelia niet haalbaar. Beide partijen hebben eigen doelstellingen en verwachtingen van een model en die hoeven niet met elkaar op één lijn te liggen.
Blad /47
39
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Opdracht Specificatie en tbv Verificatie
Aanwezig:
Vincent van der Sleen, Kees Robers, Jan Kees Pikkaart, Serena Scholte
Opgesteld: J.K. Pikkaart & Kees Robers
Plaats:
Prinsenhof, ministerie van Financiën
Datum: 17 april 2007
Vincent is in april 2005 tijdens de biedingsfase betrokken bij het project. Hij was toen verantwoordelijk voor het coördineren van alle partijen voor het toeleveren van de gevraagde stukken: het samenstellen van de BAFO (Best And Final Offer). Vanaf juni 2006 was hij samen met Frank Hoekemeijer “kartrekker”voor het PKM systeem. Hij was toen Kwaliteits Coördinator en viel direct onder de Ontwerpmanager van de VOF, Mark Mommers. Het systeem was bedoeld als sturingsysteem voor de ontwerpers. Daarvoor is het echter niet gebruikt. Er is een traditioneel bestek en tekeningen gemaakt. Dit kan te maken hebben gehad met het feit dat de VOF zelf niet het ontwerp maakte, maar dit verdeelde over de alliantiepartners (Strukton, GTI en Burgers Ergon). Deze partners lieten het vervolgens deels ook nog door andere toeleverende specialisten uitvoeren (oa ISS). Het doel dat Vincent nastreefde was (samen met Frank Hoekemeijer) het verdelen van de gestelde eisen in de OS middels samen te stellen verificaties naar een partij van de VOF. De partijen gaven dan de te maken documenten op. Door hier een plandatum aan te koppelen zou het mogelijk zijn om ook de voortgang te registreren. Dit bleek niet het geval doordat “90% van de documenten pas op het laatste moment wordt afgemaakt”. Eisen
Verificaties
Partijen Documenten.
De verificaties zijn pas gedaan nadat het ontwerp gereed was. De praktijk was dat dit gebeurde op basis van het gemaakte document. Het heeft daarmee het ontwerpteam dus niet ondersteund. In Oktober 2006 is aan de Opdrachtgever een presentatie gegeven van de methodiek van verifieren (vinkjes) om aan te toenen hoe Safire borgt te voldoen aan het OS. Daarbij is aangegeven dat een CDrom met deze gegevens aan de Opdrachtgever kon worden beschikbaar gesteld. In werkelijkheid is besloten om direct live toegang te verstrekken in het systeem. Dit had ook tot doel om het aantal te leveren papieren documenten laag te houden. Het Verificatiemodel (VM) is ingedeeld naar ontwerpdisciplines. Het is daarom niet geschikt om vragen van de Opdrachtgever te beantwoorden als: “Voldoet deze ruimte aan alle eisen?” Het is wel het doel van de VOF om het systeem verder te gebruiken,zeker tot aan de oplevering. Om te beoordelen of het systeem ook te gebruiken is als monitor systeem tijdens de exploitatie, heeft de benoemde Exploitatiemanager nu toegang tot het systeem. Belangrijkste conclusies van Vincent: • Sterkste kanten van het VM zijn: o Alle eisen zijn toebedeeld aan een specifieke partij o Alle documenten opgeslagen en beschikbaar • Zwakste kanten van het VM zijn: o Werkt traag en is gebruiksonvriendelijk o Geen voortgangsbewaking o Veel werk om verificaties aan te maken o Een lokaal systeem zou beter werken o Tekeningen uploaden en van metadata voorzien is veel werk
Blad /47
40
Naast dit gesprek is voor specifieke ICT vragen een vragenlijst uitgereikt aan Vincent. Hij heeft toegezegd deze in te vullen en te retourneren. De vragenlijst kan ook digitaal van de Projectwebsite worden gehaald. Voor Vincent zijn de C-vragen van belang.
Blad /47
41
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Opdracht Specificatie en tbv Verificatie
Aanwezig:
Jurriaan van Meel (ICOP) (deels), Fred Lohman (PKM Solutions), Kees Robers, Jan Kees Pikkaart Prinsenhof, ministerie van Financiën
Plaats:
Opgesteld: J.K. Pikkaart & Kees Robers Datum: 04 april 2007
PKM Solutions is de ontwikkelaar van de software bestaande uit een generiek deel met een “semantische database” en daarop een “template”. Zo’n template is een geconfigureerd instrument om met de database te werken. Deze template wordt opgezet door een domeindeskundige, in dit geval voor huisvesting. ICOP is de huisvestingsdeskundige die de template heeft gemaakt. Het startpunt voor het Verificatiemodel (VM) was een bestaand product dat reeds ontwikkeld was en gebruikt bij een ander project. Vanuit Strukton is gevraagd of dit VM ook bruikbaar kon worden gemaakt voor het Ministerie van Financiën. Dit was het startpunt voor het huidige VM. De gegevens die in het VM worden beheerd, zijn gebaseerd op de Output Specificatie (OS). Deze OS is later aangevuld met de wijzigingen en aanvullingen die in de uiteindelijke aanbieding (BAFO) zijn aangeboden. Ook latere wijzigingen van deze OS + BAFO zijn verwerkt in het OS systeem en in het VM. Het invoeren van de gegevens is in eerste instantie door ICOP en PKM gedaan. Het ordenen (modelleren) van de gegevens naar structuren vereist kennis en inzicht. Deze is niet bij iedereen aanwezig. Bij volgende projecten is gebleken dat de meer ervaren mensen van de opdrachtgever wel in staat zijn de gegevens te modelleren als OS in het systeem. Bij deze volgende projecten kon hierdoor wel een “enorme versnelling” plaatsvinden. Het eenvoudig hergebruiken (kopiëren) van eerder gespecificeerde gegevens levert hieraan een belangrijke bijdrage. Het VM is opgezet en was bedoeld om het ontwerpproces te ondersteunen voor Strukton intern. Het is niet opgezet om ook de Opdrachtgever te dienen. Middels velerlei database queries werd gecheckt of gegevens “compleet” waren. Ook werden queries gedraaid om na te gaan of bijvoorbeeld alle eisen wel gekoppeld waren met een ontwerpdiscipline en een bijbehorende bestekstekst. In beperkte mate hebben PKM Solutions en ICOP aan de Opdrachtgever aangegeven dat op basis van het OS ook voor hen een verificatiemodel kon worden opgezet. Hierdoor zou het mogelijk zijn om op basis van de gestelde verificatieprocedures ook daadwerkelijk verificaties uit te voeren middels het model. Tijdens de aanbiedingsfase heeft PKM dit wel aangeboden aan Opdrachtgever om de aanbiedingen te vergelijken met het OS. Achteraf heeft de Opdrachtgever aangegeven dat men dit aanbod beter wel had kunnen accepteren. Bij dit project was het waarschijnlijk niet haalbaar geweest om het ontwerp ook in het systeem te modelleren (mbv bijvoorbeeld een objectenboom). Dit zou een te grote stap voorwaarts zijn geweest voor de betrokkenen. De “organisaties” waren nog niet klaar om in een “centraal systeem” hun gegevens op te slaan en bij te houden. Het printen van delen van of de gehele OS is toe te schrijven aan de technische staat van normaal gebruikte hardware en software: het is voor niemand fijn om op de huidige PC’s te lezen. Veel mensen printen een document van enkele pagina’s uit, ook om bijschriften te kunnen maken. Hier mogen dus geen andere conclusies uit worden getrokken.
Blad /47
42
Op juridisch gebied zijn alle partijen nog aan het zoeken hoe met een dergelijk systeem om te gaan. Alles is nog erg nieuw, er is nog geen “jurisprudentie”. Vastlegging middels een vast medium is nu nog de oplossing: CD-rom of pdf. Het vrijgeven van het bronbestand ligt al veel gevoeliger. Belangrijkste conclusies van Fred en Jurriaan: • Het systeem is de afgelopen jaren gerijpt; op volgende projecten wordt het al veel prominenter toegepast • Ook de software is nu veel “slimmer” en gebruiksvriendelijker • De opdrachtgever had er wijs aan gedaan om ook meerdere VM-en (voor verschillende fasen van het proces) te definiëren • Een aantal juridische aspecten verdient aandacht om meer (met name ook door gebruik bij aanbieders) voordeel uit deze methodiek te verkrijgen. • De volgende stap (na OS en VM) in het gebruik van deze gegevens is het toepassen van het model in de gebruiksfase. Naast dit gesprek is voor specifieke ICT vragen een vragenlijst uitgereikt aan Fred en Jurriaan. Zij hebben toegezegd deze in te vullen en te retourneren. De vragenlijst kan ook digitaal van de Projectwebsite worden gehaald. Voor PKM Solutions zijn alleen de A vragen van belang, voor ICOP de B-vragen.
Blad /47
43
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Opdracht Specificatie en tbv Verificatie
Aanwezig:
Vincent van der Sleen Frank Hoekemeijer Pascal van Bruggen (GTI) Berjan Arentsen (Strukton) (oude) Ministerie van Financién
Plaats:
Opgesteld: S.J. Scholte
Datum: 23 mei 2007
1. Betrokkenheid van de deelnemers bij OS en Verificatiemodel (VM): Het gesprek concentreert zich op de ervaringen van Pascal en Berjan. Frank en Vincent nemen deel om ook gebruikerservaringen te horen. Pascal: electroengineer bij GTI. Heeft het OS gehanteerd als een naslagwerk, maar voornamelijk in het verificatieproces PKM gebruikt als checklist. Hij geeft aan dat hij graag prioriteiten toegekend zou zien in de te verifiëren eisen. Frank Hoekemeijer: heeft de functie van kwaliteitscoördinator vanuit de VOF. Geeft aan dat het systeem ertoe heeft bijgedragen dat verantwoordelijkheden om te voldoen aan bepaalde eisen zichtbaar werden gemaakt door het systeem. (reeds geïnterviewd) Berjan Arentsen: is verantwoordelijk voor de werkvoorbereiding bij Strukton. Vincent van der Sleen: reeds geïnterviewd. 2. Ervaringen -
-
-
-
De CD-Rom van de OS was erg lastig doorzoeken. ‘veel geklik’. Met de verificatie is al gezorgd voor meer ordening. Het OS model is vrij omvangrijk. De noodtelefoon was door GTI over het hoofd gezien in het OS model. Bij de verificaties in het VM model kwam deze eis naar voren. Het ‘in behandeling’ vinkje is niet veel gebruikt, waardoor onduidelijk bleef voor Vincent wat de status van de verificatie was; Het systeem zou optimaal functioneren als beheerstool voor coördinatoren en managers. Hiervoor is het systeem nog niet voldoende toegepast en uitgedragen door de huidige coördinator. Het systeem was te laat klaar om gedegen te kunnen worden gebruikt voor de verificatie. Berjan vraagt zich af of zijn opmerkingen in het VM wel worden gelezen door de opdrachtgever; Berjan vraagt zich ook af of het mogelijk is om eisen waar meer partijen verantwoordelijk voor zijn deze eis toe te bedelen, zodat de noodzakelijke/gewenste communicatie tussen partijen heel zichtbaar wordt. Dit staat op gespannen voet met het idee om 1 partij verantwoordelijk te houden, ondanks dat deze met een andere partij moet samenwerken. Idee is om checkboxes toe te voegen waarin partijen achter een eis kunnen worden aangevinkt en iemand die eindverantwoordelijk wordt gesteld (en dat mogelijkerwijs niet is) deze verantwoordelijkheid kan ‘afstaan’; Het systeem werkt eenvoudig. 1 dag training en “een beetje rondklikken” was voldoende uitleg om te begrijpen hoe het werkt. De verificaties zijn disciplinair ingericht, omdat zo de organisatiestructuur en verantwoordelijkheid is opgebouwd. De verificaties zouden ook per bouwdeel of thema (logistiek, veiligheid) opgebouwd kunnen worden, afhankelijk van de gekozen organisatiestructuur / werkwijze. Berjan geeft aan dat hij stukken uit PKM in PDF heeft gezet en gemaild naar de partijen. Het liefste zou hij een afgeschermd deel in PKM hebben waar partijen zelf toegang tot hebben om de benodigde stukken op te halen/down te loaden;
Blad /47
44
-
-
-
-
Het systeem wordt nu gevuld met rapporten van partijen waarin ze aantonen dat ze aan eisen voldoen. Om te voorkomen dat hetzelfde ontstaat als bij het niet digitale OS (dubbelingen, lastig zoeken) zouden eigenlijk deze rapporten ook in componenten (net als de eisen) moeten worden opgesplitst en in het systeem worden opgenomen. Informatiemanager is een nieuwe rol die noodzakelijk is bij gebruik van dit soort modellen. Terminologie voor onderdelen van het gebouw dient uniform te zijn. Dat bleek nog wel eens een zoektocht. Belangrijk is dat het zichtbaar is bij welke specifieke eis welke verificatie hoort; Over normen: onderdelen die uit normen worden vereist, zouden eveneens als eisen in het systeem moeten worden opgenomen (in plaats van alleen als normverwijzing). Dit om te voorkomen dat er cruciale zaken te laat zichtbaar worden (zoals dikte van de drempel van het archief); Er mag meer druk uitgeoefend worden naar partijen toe om te werken met het PKM systeem, zodat het niet iets ‘erbij’ wordt maar dat men de potentie onderzoekt om het als beheerssysteem te laten functioneren; Hoe nu verder met PKM? De discussie is nu of het gebruikt kan worden voor kwaliteitsborging in de uitvoering. Het PKM systeem wordt in ieder geval doorontwikkeld. Het systeem zou gebruikt kunnen worden om documenten uit te wisselen tussen partijen. Echter de softwear is (momenteel) niet toegespitst om als Document Management Systeem te fungeren.
Met Marc Mommers is op 5 juni een afspraak gemaakt om te evalueren.
Blad /47
45
Besprekingsverslag
Onderwerp:
Ministerie van Financiën, digitaal model tbv Opdracht Specificatie en tbv Verificatie
Aanwezig:
Sietske Bergsma (MvF), Conchita Wolf (MvF), Ton Wolff (MvF), Ger vd Zwan (MvF), Fred Kater (Rgd), Emile Boel (Rgd), Bernd Karstenberg (Deerns), Kees Robers (PSIBouw), Serena Scholte (PSIBouw), Jan Kees Pikkaart (PSIBouw) Peter vd Linden (Rgd) Ministerie van Financién
Afwezig: mk Plaats:
Opgesteld: J.C.B. Robers
Datum: 17 april 2007
1. Betrokkenheid van de deelnemers bij OS en Verificatiemodel (VM): Sietske: Heeft leiding gegeven aan het proces van totstandkoming van OS en de verificatie. Conchita (Fac.Dienst): Heeft mede het PvE gemaakt; is bij de omzetting tot OS betrokken geweest en heeft bij de verificatie een aantal onderwerpen voor haar rekening genomen o.a. als belangrijk punt: de beveiliging. Ton (ICT): Is ook bij de vorming van de OS en de verificatie betrokken geweest. Ziet als belangrijkste probleem: hoe in dit soort processen het voortschrijdend inzicht meegenomen kan worden. Bij de verificatie zijn er al weer nieuwe ideeën en ontwikkelingen. Emiel (constructie): Is bij R’dam en Doetinchem betrokken geweest bij OS/PKM via een collega, die de gegevens invoerde. Voor Groningen heeft hij zelf de gegevens ingevoerd. Bij de verificatie van het MvF heeft hij die kennis als “naslagwerk” gebruikt. De informatie (tekeningen) heeft hij op papier van Fred K. gekregen. Dat is ook niet vanaf scherm te doen. De berekeningen heeft hij wel vanaf het scherm gecontroleerd. Hij doet dit overigens liever vanaf papier; dat is minder vermoeiend. Ger (beveiliging): Heeft de beveiligingshardware getoetst door de bestekken uit te draaien op de plotter. Vindt het lastig de relaties te vinden: bijv, de afmetingen van een tourniquet moeten vanaf de bouwkundige tekening gehaald worden. Bernd: (Installaties): Is bij het opstellen van de OS betrokken geweest; heeft ook koppelingen gelegd. Vond het in die fase moeilijk om een kostenraming te maken (t.b.v. de PPComparitor). Daarvoor is het te ondoorzichtig. Bij de toetsing bleek hem dat veel koppelingen ontbraken. Daarom maar traditioneel beoordeeld. Fred (RGD gebouwbeheer): Heeft Rotterdam intensief doorgewerkt. Nu voor KV7 de verificatie georganiseerd. Ervaart het model vooral als een Doc. Man. systeem.
2. Ervaringen (een samenvatting van de diverse ervaringen in aanvulling op de reeds onder 1 genoemde) - Het verificatiemodel is weliswaar vooral voor Safire-intern gemaakt, maar op grond van de presentatie in oktober en de toelichting begin februari werd de verwachting gewekt dat de Opdrachtgever het ook zou kunnen gebruiken. Dat viel wat tegen. - Handig dat op meerdere werkplekken er in gekeken kan worden (werkplek onafhankelijk) - De codering zou aangevuld moeten worden met een soort tekeningenlijst. (nu zelf gemaakt) - Het systeem levert nu niet zoveel extra’s, maar in potentie zou het veel meer kunnen leveren. - Voordeel is dat je alles digitaal hebt. Dan kun je ook delen uit een tekening lichten en op een A4 afdrukken. - Het heeft de goede beheersing van een doc.man.systeem. (versiebeheer) - Tekeningen beoordelen kan niet op beeldscherm (onvoldoende overzicht). Zou je moeten projecteren. Dan ook goed voor groepssessies. - In het begin was het systeem slecht toegankelijk. Maar dat was een “kinderziekte”.
Blad /47
46
- Bij gebrek aan relaties kon je via de zoekfunctie toch in het ontwerp alles m.b.t. een bepaald onderwerp naast elkaar krijgen en op consistentie beoordelen. (bijv. diameter tourniquets). Echter, het betrof een full text zoekfunctie (letterlijke tekst ipv zoeken op de manier van Google geavanceerd zoeken) waardoor het niet eenvoudig was de wensen uit de OS naast de oplossing te zetten. - tijdbesteding: het leren werken met het systeem kost in het begin wel tijd, maar het bespaart daarna veel tijd doordat je snel iets op kunt zoeken.
Blad /47
47
