Systems Engineering in de praktijk. Een onderzoek naar toepassingsmogelijkheden

Transcriptie

1 Systems Engineering in de praktijk Een onderzoek naar toepassingsmogelijkheden en eigenschappen E. Vink De Bilt, 18 december 2008

2

3 Systems Engineering in de praktijk Een onderzoek naar toepassingsmogelijkheden en eigenschappen Auteur: Eline Vink De Bilt, 18 december 2008 Opdrachtgevers: Technische Universiteit Delft Faculteit Civiele Techniek en Geowetenschappen Studie Civiele Techniek Master Building Engineering Specialisatie Design & Construction Processes Grontmij bv Afdeling Waterbouw Team Projects Afstudeercommissie: Prof. Dr. Ir. H.A.J. de Ridder Dr. Ir. G.A. van Nederveen Dr. Drs. Ir. C.M. Ravesloot Ir. R.J.J. Raaijmakers Ir. N.J.M. Nijenhuis Technische Universiteit Delft Technische Universiteit Delft Avans Hogeschool en Hogeschool Zuyd Grontmij Kondor Wessels Projecten

4

5 Samenvatting Inleiding De GWW-sector is aan het veranderen van een regionaal georiënteerde markt naar een dynamische wereld. Redenen hiervoor zijn een terugtredende overheid en het aanbieden van fullservice door opdrachtnemers. In deze veranderende markt is noodzaak voor een nieuwe ontwerpmethode die voorziet in beheersbaarheid en doelmatigheid van (complexe) projecten en gericht is op efficiëntie en transparantie van het proces en de activiteiten. Deze andere werkwijze is gevonden in Systems Engineering. Een methode die zichzelf al bewezen heeft in talloze andere sectoren. De invoering van Systems Engineering verloopt niet vloeiend. Er zijn veel problemen en onduidelijkheden. In dit onderzoek is de aandacht gevestigd op de onduidelijkheden over het te bewandelen pad, het ontbreken van inzicht in de mogelijk te gebruiken projectbeheersinginstrumenten die aangereikt worden en de afweging die gemaakt kan worden voor elk van deze instrumenten over het waarom en wanneer (niet) gebruiken van deze instrumenten. In dit onderzoek is de volgende doelstelling geformuleerd; Doelstelling: Het doel van het onderzoek is het doen van aanbevelingen en het formuleren van afwegingscriteria voor het gebruik van projectbeheersinginstrumenten die SE biedt, door inzicht te geven in de gebruikte instrumenten bij een casestudie en aan de hand van een enquête op basis van de casestudie een analyse te maken over het waarom en wanneer (niet) gebruiken van deze instrumenten. Om dit doel te halen is besloten om naast een literatuuronderzoek, een casestudie te behandelen en een enquête uit te zetten. De volgende vier onderzoeksvragen worden in dit rapport beantwoord; 1. Wat is er in de theorie bekend over de koppeling tussen Systems Engineering en projectkenmerken? (Deel A) 2. Hoe wordt er binnen het project HVVOS gedacht over en omgegaan met Systems Engineering en haar onderdelen? (Deel B) 3. Welke vragen dienen gesteld te worden in de enquête om conclusies te kunnen trekken over de toepassing van Systems Engineering in relatie tot projectkenmerken? (Deel C) 4. Hoe luiden de afwegingen die op basis van de theorie, interviews en enquête gemaakt kunnen worden? (Deel D) Het onderzoek Allereerst is er in deel A gekeken naar de theorie over Systems Engineering en projectkenmerken. Aan de hand van de projectkenmerken kunnen de uiteindelijk de afwegingen gemaakt worden. Bij projectkenmerken kan bij voorbeeld gedacht worden aan projectgrootte, complexiteit en het aantal disciplines. Deel A besluit met een tabel met afwegingen die vanuit de theorie gemaakt kunnen worden. Daarin staat beschreven onder welke, theoretische, voorwaarden Systems Engineering wel en niet toegepast moet worden en welke eigenschappen daarmee gecreëerd worden, zoals kwaliteit of structuur. In deel B, de casestudie, wordt vanuit de theoretische benadering gekeken naar een project. Dit project, de renovatie van de Haringvliet en Volkerak sluizencomplexen, wordt uitgevoerd met Systems Engineering als ontwerpmethode. Door middel van een aantal interviews is gekeken naar afwegingen die vanuit de casestudie gemaakt kunnen worden. Op basis van de theorie en de interviews binnen de casestudie is een enquête ontworpen. In deel C worden de enquête en de resultaten van de enquête besproken. Hieruit komen wederom afwegingen. In het laatste deel, deel D, worden alle afwegingen en resultaten vanuit de theorie, casestudie en enquête vergeleken in een discussie en worden er conclusies getrokken. De belangrijkste conclusies staan hieronder weergegeven. Conclusies Het complete afwegingsmodel staat in hoofdstuk 12.2 weergegeven, hieronder staan de belangrijkste en meest opvallende conclusies uit deze tabel. Achter elke conclusie staat het hoofdstuk waar deze is terug te vinden. Belangrijk om te weten is dat deze conclusies zijn geformuleerd aan de hand van de theorie en in meerdere mate aan de hand van een zevental interviews en 34 enquêtes. De geïnter- Hoofdstuk: Samenvatting 5

6 viewden en de respondenten zijn vooraf geselecteerde personen, waardoor het geen willekeurige groep is. Om deze twee redenen geven de conclusies geen algemeen geldende mening weer en bieden zij een explorerende kijk op de mening van Systems Engineering in de praktijk. Systems Engineering biedt in de GWW-sector (nog) geen reductie in kosten en tijd en introduceert risico s (11.2, 11.3 & 11.4). Systems Engineering is zinvol om toe te passen bij installatietechnische projecten (11.5). Systems Engineering is zinvol om toe te passen bij renovatieprojecten wanneer het projectteam ervaren is met betrekking tot SE (11.5). Systems Engineering is zinvol om toe te passen bij projecten gekenmerkt door veel keuzevrijheid (11.5). Systems Engineering is zinvol om toe te passen bij projecten gekenmerkt door weinig keuzevrijheid, wanneer er een ervaren projectteam beschikbaar is met betrekking tot SE (11.5). Systems Engineering moet worden toegepast bij projecten met een projectgrootte van de ontwerpfase vanaf , - (9.3.2). Systems Engineering moet worden toegepast vanaf een projectduur van de ontwerpfase vanaf 6 maanden (9.3.2). Alle onderdelen van Systems Engineering moeten altijd toegepast worden bij het gebruik van Systems Engineering. Er mogen geen onderdelen overgeslagen worden (9.3 & 9.4) Systems Engineering zorgt voor beheersbaarheid van het project (bij een ervaren projectteam), structuur, expliciet werken, transparantie en reductie van complexiteit (bij een ervaring projectteam). Daarnaast biedt het een controlemiddel ten behoeve van kwaliteit en een ontwerpcontrole (4, 9.3 & 9.4) Er is na dit onderzoek nog steeds twijfel over het feit of Systems Engineering zorgt voor verrassende en innovatieve oplossingen (11.6). Een algemene conclusie voortkomend uit dit onderzoek: Een praktische handleiding is noodzakelijk bij het introduceren van Systems Engineering in de GWW-sector (12.3). Aanbevelingen Hieronder staan de aanbevelingen weergegeven, die voortkomen uit dit onderzoek. Deze staan verder uitgelegd in hoofdstuk Er dient een opleidingsprogramma ontwikkeld te worden met workshops en een voor iedereen beschikbare praktische handleiding Een complex project moet opgepakt worden door een ervaren projectteam. Dit onderzoek dient, aangepast, te worden voortgezet om zo meer resultaten te verkrijgen en meer algemene conclusies te kunnen trekken. De resultaten die in dit rapport zijn gepresenteerd dienen gebruikt te worden bij de start van nieuwe projecten. Er moet onderzoek gedaan worden naar de voor- en nadelen van Systems Engineering in de Nederlandse GWW-sector. Onderzoeksvragen Binnen dit onderzoek is een aantal vragen onbeantwoord gebleven en is een aantal nieuwe vragen gerezen. Deze vragen kunnen als onderzoeksvragen dienen in verder onderzoek (12.4). Reduceert SE kosten in de GWW? Reduceert SE tijd in de GWW? Reduceert SE onzekerheid in de GWW? Reduceert SE risico s in de GWW? Zijn functionele eisen oplossingsvrij? Zorgt Systems Engineering voor verrassende en innovatieve oplossingen? Hoofdstuk: Samenvatting 6

7 Summary Introduction The public works and water management industry in the Netherlands is rapidly changing from regional orientated to a dynamic industry. The two main reasons for this turn are governmental step back and full-service offer from contractors. In this changing industry there is necessity for a new design approach which anticipates in a controllability and effectiveness of complex projects. This approach should also aim at efficiency and transparency of the process and its activities. Systems Engineering is found as new approach which provides in all these requirements. The method has already proven itself in numerous other industries. The introduction of Systems Engineering brought a lot of problems and vagueness. In this thesis the focus is on the vagueness of the work method, the lack of insight in the possible instruments that can be used and are provided for by the method and the assessment that can be made for each instrument about the why and when (not) using these instruments. Therefore the following objective is formulated; Objective: The objective of this thesis is formulating recommendations and an assessment model for the use of possible instruments and tools that the discipline Systems Engineering provides for, through giving insights in the used instruments in a case study and by analyzing the results of an enquiry, based on the case study, about the why en when (not) using these instruments. To reach this goal there is decided to, besides using a theoretical approach, research a case study and develop an enquiry. The following four research questions were derived and answered in this thesis: 1. What is known in theory about the link between Systems Engineering and project characteristics? (Part A) 2. How is Systems Engineering and her instruments handled in the case study HVVOS? (Part B) 3. Which questions can be asked in the enquiry in order to draw conclusions about the link between the application of Systems Engineering and project characteristics? (Part C) 4. What are the assessments that can be made according to the conclusions from the theoretical approach, case study and enquiry? (Part D) The research Part A is the theoretical part of the research. In this part the subjects Systems Engineering and project characteristics are covered. By means of project characteristics the assessments can be made. As clarification project characteristics can be project size, complexity or number of disciplines. Part A concludes with a table with assessments from the theoretical part. In the table is presented under what, theoretical, circumstances Systems Engineering should be applied and which characteristics are provided for. For instance quality or structure. In part B a case, the renovation of Haringvliet and Volkerak locks, is studied. Systems Engineering is applied as design method in this case. People working on this case are interviewed about using Systems Engineering and assessments are made from the results. By means of the theoretical part and the case study, an enquiry is designed. In part C the enquiry and its results are discussed. This part also concludes with assessments according to the results of the enquiry. In the final part, D, all assessments from theory, the case study and the enquiry will be compared and weighed in order to draw conclusions and final assessments. The most important conclusions are listed below. Conclusions The assessment model is given in chapter Below the most important conclusions from this model are given. The number between brackets refers to the chapter wherein this conclusion is drawn. Important to know is that these conclusions are drawn based on the theory, but for the most part based on seven interviews and 34 enquiries. The interviewees and respondents are preselected, Hoofdstuk: Summary 7

8 therefore it is no arbitrary group of people. Because of these two reasons, the conclusions are not general applicable. The conclusion gives an exploring view on the opinions about Systems Engineering in practice, Systems Engineering in the public works and water management industry does not provide reduction of costs and time and introduces risks (11.2, 11.3 & 11.4). Systems Engineering should be applied on installation technical projects (11.5). Systems Engineering should be applied on renovation projects, under the condition that the project team is experienced in using SE (11.5). Systems Engineering is useful to apply on projects characterized by freedom of choice (11.5). Systems Engineering can be useful to apply on projects characterized by minimal freedom of choice, under the condition that the project team is experienced in using SE (11.5). Systems Engineering should be applied on projects with a minimum size of the design phase of , - (9.3.2). Systems Engineering should be applied on projects with a minimum time span of the design phase of 6 months (9.3.2). When applying Systems Engineering all components of the method should be applied. No component can miss out (4, 9.3 & 9.4). Systems Engineering provides controllability of the project (with experienced project team members), structure, working explicitly, transparency and reduction of complexity (with experiences project team members). SE also provides means to control quality and design (11.6). These is still doubt about the fact that Systems Engineering provides for innovative and surprising solutions (11.6). A more general conclusion from this research: A practical guideline is essential for introducing Systems Engineering in the public works and water management industry (12.3) Recommendations Below recommendations are given. These recommendations are further explained in chapter A education program needs to be developed including workshops and a practical guideline available for everyone A complex project needs to be carried out by an experienced team It is recommended that the enquiry is adjusted and continued in order to gather more results so more general conclusions can be drawn The results that are presented in this thesis should be used at the start of new projects. In order to decide whether Systems Engineering is the right approach Research should be carried out on the advantages and disadvantages of Systems Engineering in the public works and water management industry Research questions Within this thesis a few questions remain unanswered and new questions arised. These questions can be used in further research (12.4). Does SE reduce costs in the public works and water management industry? Does SE reduce time span in the public works and water management industry? Does SE reduce insecurity in the public works and water management industry? Does SE reduce risks in the public works and water management industry? Are functional requirements free of aiming for certain solutions? Does SE lead to surprising and innovative solutions? Hoofdstuk: Summary 8

9 Voorwoord Voor u ligt mijn afstudeerrapport met als onderwerp Systems Engineering in de praktijk; een onderzoek naar toepassingsmogelijkheden en eigenschappen. Ik heb dit onderzoek gedaan ter afronding van mijn master Building Engineering aan de faculteit Civiele Techniek en Geowetenschappen van Technische Universiteit Delft. Systems Engineering is een nieuwe ontwerpmethode die binnen een aantal vakken terugkomt, maar tot de verbeelding blijft spreken. Na me wat meer in de methode verdiept te hebben, bleek dat veel mensen die in de praktijk te maken hebben met deze methode moeite hebben met de toepassing hiervan. Ook is het doel van Systems Engineering niet duidelijk. Voor mij was dit een reden om Systems Engineering in mijn afstudeeronderzoek als onderwerp te kiezen. Dit onderzoek heb ik uitgevoerd met de hulp van een groot aantal mensen die ik hier graag wil bedanken. Allereerst wil ik mijn afstudeercommissie bedanken. Wanneer ik dacht dat ik zou verdrinken in mijn onderzoek hebben zij me leren zwemmen. Daarnaast wil ik Grontmij, afdeling Waterbouw bedanken voor het bieden van een afstudeerplek en alle collega s die me de afgelopen 10 maanden gesteund en geholpen hebben. Zonder geïnterviewden en respondenten van de enquête had ik dit onderzoek nooit tot een goed gevolg kunnen brengen dus iedereen die hier de moeite voor heeft genomen, bedankt! In het bijzonder wil ik Ruud bedanken voor alle tijd die hij de laatste maand heeft vrijgemaakt om me te helpen met het afronden van mijn rapport en Martijn voor de mentale steun die ik zo hard nodig heb gehad. Eline Vink, De Bilt, 2008 Hoofdstuk: Voorwoord 9

10

11 Inhoudsopgave 1 Inleiding 15 2 Onderzoeksontwerp Systems Engineering in de GWW-sector Probleem- en doelstelling Afbakening onderzoekskader Onderzoeksmodel Vraagstelling Leeswijzer 24 Deel A; Theoretische benadering 25 3 Systems Engineering Inleiding Definitie en inhoud Systems Engineering Werkdefinitie Levenscyclus Toepassingsmogelijkheden Systems Engineering Wanneer passen we Systems Engineering toe? Waarom passen we Systems Engineering toe? Terugkoppeling onderzoeksvraag 35 4 Projectkenmerken Inleiding Complexiteit Complexiteit wordt gedefinieerd door functies, onderlinge interactie en dynamiek Projectkenmerken met relatie tot complexiteit Kosten Tijd Projectkenmerken gerelateerd aan de GWW-sector Terugkoppeling onderzoeksvraag 39 5 Afweging op basis van de theoretische benadering 41 Deel B; Casestudy renovatie Haringvliet en Volkerak Sluizencomplexen 43 6 HVVOS Doel Casestudy Het project Projectkenmerken HVVOS Systems Engineering binnen HVVOS Format Interviews Aanleiding en indeling interview Relevante uitkomsten 49 Hoofdstuk: Inhoudsopgave 11

12 6.4 Terugkoppeling onderzoeksvraag 51 7 Afwegingen vanuit de casestudy 53 Deel C; Enquête 55 8 Opzet enquête Doel Opzet enquête Variabelen Vraagstelling en beantwoording Enquête vragen 58 9 Enquête resultaten Doel Algemeen Respondenten Weggevallen vragen Gemiddelden Algemeen Systems Engineering Systeembeschrijving Eisenanalyse Functieanalyse Ontwerpafweging Raakvlakken RAMS analyse Verificatie Afwegingen vanuit de gemiddelden Kruistabellen Onafhankelijke variabelen Afhankelijke variabelen Afwegingen vanuit de kruistabellen Afwegingen vanuit de enquête 87 Deel D; Afwegingen en conclusies Discussie Doel Tijd Risico s Kosten Keuzeruimte Verrassende oplossingen Beheersbaarheid Eisen stellen aan functies/functievervullers Conclusies uit de discussie Conclusies en aanbevelingen 97 Hoofdstuk: Inhoudsopgave 12

13 12.1 Doel Afwegingsmodel Systems Engineering Onderdelen van Systems Engineering Conclusies Aanbevelingen Aanbevelingen Onderzoeksvragen voor verder onderzoek Gebruikte begrippen en afkortingen Begrippenlijst Afkortingen Bronnen Literatuur Publicaties en artikelen 105 Hoofdstuk: Inhoudsopgave 13

14

15 1 Inleiding De GWW-sector was voorheen regionaal georiënteerd maar verandert in een dynamische wereld. Dit is te wijten aan een aantal ontwikkelingen. Eén daarvan is de terugtredende overheid een ander het aanbieden van fullservice door opdrachtnemers. De GWW in Nederland wordt voor het overgrote deel door de overheid gedomineerd. Doordat de overheid meer en meer aan de markt overlaat en steeds minder zelf doet veranderen de rollen van partijen. De relatie tussen opdrachtgever en opdrachtnemer verandert; er wordt meer gestuurd op prijs/kwaliteit verhoudingen, de opdrachtgever legt risico s bij de opdrachtnemer, opdrachtnemers moeten kwaliteitscertificering hebben en er moet transparantie in het proces zijn (ONRI, 2005). De taak van opdrachtgevers concentreert zich voornamelijk op het formuleren van de specifieke eisen waaraan het project en de ontwerpen moeten voldoen en het bewaken hiervan tijdens de ontwerp- en bouwfase (ProRail & Rijkswaterstaat, 2007). Door de terugtredende overheid komt er ruimte voor de marktpartijen. Het invullen van deze ruimte wordt gezien als een uitdaging voor de verschillende partijen. Door het stimuleren van eigen inbreng van de opdrachtnemer om dit in te vullen, wordt getracht de doelmatigheid en efficiëntie van een project te vergroten. Waarbij doelmatigheid staat voor een betere aansluiting van het project aan de klantbehoefte en efficiëntie voor zo veel mogelijk resultaat tegenover zo weinig mogelijk input (ONRI, 2005; Luiten et al., 2005). Het invullen van die ruimte wordt door opdrachtnemers vaak gedaan door samenwerkingsverbanden te sluiten tussen ingenieursbureaus, aannemers en leveranciers om zo de opdrachtgever een fullservice aan te kunnen bieden (ONRI, 2005). Doelmatigheid wordt vergroot doordat een project bekeken wordt vanuit verschillende invalshoeken en over meerdere fasen. Daarnaast kan het proces efficiënter worden ingedeeld, omdat communicatielijnen kort zijn en er veel samengewerkt wordt waardoor activiteiten parallel kunnen lopen (Luiten et al., 2005). Een andere ontwikkeling is de wetgeving gericht op transparantie en daarbij behorend de aandacht voor het beheersbaar houden van complexe en meer onzekere projectvormen (ProRail & Rijkswaterstaat, 2007; ONRI, 2005; Luiten et al., 2005). Dit tweetal ontwikkelingen in de bouwsector vragen om een nieuwe werkwijze die de activiteiten van alle partijen structureert. Een methode die zorgt voor beheersbaarheid en doelmatigheid van (complexe) projecten en gericht is op efficiëntie en transparantie van het proces en de activiteiten. Deze methode is gevonden in Systems Engineering. Systems Engineering is een beproefde methode in onder andere de telefoniesector, lucht- en ruimtevaartindustrie en softwareontwikkeling. De methode is echter niet beperkt tot deze disciplines, of zelfs maar technische disciplines. Systems Engineering is ontwikkeld uit het systeem denken, waar vanuit een holistische visie, complexe problemen en mogelijke oplossingen worden beschouwd (SEATC, 2000; ProRail & Rijkswaterstaat, 2007). Tien jaar geleden is Systems Engineering geïntroduceerd in de grond-, weg- en waterbouw bij het HSL-Zuid project en in 2007 is er door ProRail en Rijkswaterstaat een handleiding uitgebracht over dit onderwerp. Dit onderzoek naar Systems Engineering is uitgevoerd in opdracht van Technische Universiteit Delft en Grontmij, afdeling waterbouw, team projects en dient als afronding van de master Building Engineering, design & Construction processes van de faculteit Civiele Techniek en Geowetenschappen. Hoofdstuk: Inleiding 15

16

17 2 Onderzoeksontwerp 2.1 Systems Engineering in de GWW-sector Systems Engineering is, gedefinieerd door het International Counsel on Systems Engineering (INCO- SE), een interdisciplinaire benadering en middel om de realisatie van succesvolle systemen mogelijk te maken. De focus ligt hierbij op het definiëren van de klantwensen en benodigde functionaliteit vroeg in de ontwikkelingsfase van het project, het documenteren van de eisen, de ontwerpsynthese en de systeem verificatie en validatie, gezien vanuit het complete probleem (INCOSE, 2008). Dit is slechts een van de vele definities die gevonden kan worden in de literatuur. Dit is ook te zien aan de verscheidenheid in praktische toepassingen. Sinds een aantal jaar is Systems Engineering (SE) ook in de Grond-, Weg- en Waterbouw (GWW) een veelgehoorde term. Tien jaar geleden is deze methode geïntroduceerd in de GWW sector bij het HSL zuid project en sindsdien is Systems Engineering niet meer weg te denken in deze sector. Vanuit de toepassing van Systems Engineering bij de HSL is deze methode opgepakt door ProRail en Rijkswaterstaat. Zij hebben getracht SE verder te ontwikkelen voor de GWW-sector. Ook is de methode als onderzoeksvraag opgepakt door kennisinstanties en netwerken. Kennisinstanties als INCOSE, CROW en technische universiteiten zijn ook bezig met het verder ontwikkelen van de methode en focussen zich op de praktische invulling hiervan. Ondanks dat deze methode al een aantal jaren een begrip is in de bouw, heeft men er nog weinig grip op wat Systems Engineering inhoudt en hoe ermee gewerkt moet worden. Dit wordt mede veroorzaakt door de diversiteit aan definities en toepassingen vanuit de literatuur en andere disciplines. Elk artikel en elk boek over het onderwerp Systems Engineering, heeft een eigen definitie van het begrip. De term wordt veel gebruikt zonder dat er een consensus is bereikt over de te hanteren definitie. Het beeld, dat men heeft van SE verschilt van persoon tot persoon. Vaak zijn de definities niet volledig en wordt er slechts een van de vele instrumenten benoemd of een klein onderdeel. In de Leidraad Systems Engineering (ProRail & Rijkswaterstaat, 2007) wordt Systems Engineering beschreven als een geïntegreerde en gestructureerde set methodieken om projecten succesvol te verwezenlijken en te beheren. Kernelementen die daarbij genoemd worden zijn specificeren, ontwerpen, realiseren, beheren, verifiëren, valideren en levenscyclus. In het handboek oplossingsvrij specificeren van het CROW (2007) wordt Systems Engineering beschreven als een werkwijze om allerhande processen systematisch te benaderen. Door de samenhang tussen alle delen van een project systematisch in beeld te brengen kunnen weloverwogen ontwerpbeslissingen worden genomen. De methode is erop gericht om op een gestructureerde en beheersbare wijze tot een beschrijving van het te bouwen of te analyseren systeem te komen. Het handboek oplossingsvrij specificeren gaat in op verschillende onderdelen van het ontwerpproces en focust daarbij op het oplossingsvrij zijn van eisen en functies. Alle eisen en randvoorwaarden die gegeven worden moet dusdanig gesteld worden dat de ontwerper nog vrij is een oplossing te kiezen. In het kader van dit onderzoek wordt Systems Engineering als volgt gedefinieerd: SE is een discipline die een set methodieken aanreikt om het bouwproces in te richten en te beheersen. Met deze methodieken wordt bewerkstelligd dat men denkt vanuit het probleem, kijkt naar de gehele levenscyclus en transparant werkt. 2.2 Probleem- en doelstelling De leidraad opgesteld door Rijkswaterstaat, ProRail, Bouwend Nederland en ONRI (2007) presenteert de inhoud van SE binnen de GWW-sector. Het document is echter zeer theoretisch. Hoe deze methode praktisch moet worden toegepast en welke instrumenten, die worden aangereikt, nu wel en niet gebruikt moet worden bij bepaalde projecten is niet duidelijk. Vanuit allerlei bedrijven en instanties Hoofdstuk: Onderzoeksontwerp 17

18 wordt nu gewerkt aan een praktische handleiding en ook de commissie voor de ontwikkeling van de Leidraad Systems Engineering blijft aanpassingen doen en verder ontwikkelen. CROW, ook bezig met zijn eigen leidraad vanuit het zogenaamde oplossingsvrij specificeren (OVS), formuleert het probleem als volgt (Eelants & Visser, 2007): CROW Kennis van Systems Engineering wordt binnen infrastructurele projecten nauwelijks toegepast omdat deze kennis slecht toegankelijk is voor de GWW-sector. Hierdoor wordt het bestaande begrippenkader en de methoden en technieken van SE, nauwelijks toegepast. De Leidraad Systems Engineering (ProRail, Rijkswaterstaat, 2007) is gepresenteerd op 10 april 2007 en vanaf dat moment werd deze methode voorgeschreven binnen een groot aantal projecten als ontwerpmethode. Aannemers en ingenieursbureaus werden hiermee geconfronteerd en proberen nu praktische invulling te geven aan de methode. De ontwikkeling van de leidraad heeft jaren gekost. In die jaren hebben ProRail en Rijkswaterstaat Systems Engineering verder ontwikkeld voor de GWWsector. Het bedrijfsleven daarentegen, wordt geconfronteerd met een andere werkwijze en wordt geacht zich van het een op het andere moment aan te passen. Dit is dan ook zeer moeilijk gebleken. Dit ligt niet alleen aan de recente invoering van SE, maar ook de weinig praktisch toepasbare handleiding en het ontbreken van inzicht in de discipline. Het eigen maken van een discipline kost nu eenmaal tijd en inzet, deze moet dan ook door de opdrachtgevers geboden worden. Het gebruik van Systems Engineering zou het werk simpeler moeten maken, maar de tendens is dat het er alleen maar complexer van wordt 1. De baten die het gebruik van Systems Engineering moeten echter wel opwegen tegen de toegevoegde complexiteit wil deze methode toegevoegde waarde hebben. Niet alleen bij de opdrachtnemer is de invoering lastig, ook de opdrachtgever kampt met problemen. De opdrachtgever krijgt te maken met onder andere systeemgerichte contractbeheersing. Ook krijgt zij aanbiedingen en ontwerpen binnen, die allesomvattend zijn en zoveel tekst bevatten dat deze niet te beoordelen zijn. De contractbeheerser, meestal opdrachtgever, heeft vaak niet de capaciteit en kennis die nodig is om de geleverde ontwerpen te beoordelen. Vanaf beide kanten zijn er dus opstartproblemen. Hieronder staan een tweetal problemen genoemd, de een meer gericht op toepassing en de ander op inhoud. Dit onderzoek beperkt zich tot het eerste probleem, maar om volledig te zijn wordt het tweede probleem wat hierboven al deels beschreven is, ook genoemd. Geen inzicht in de mate van nuttige toepassing van SE instrumenten Vanuit het beleid van een organisatie kunnen er problemen ontstaan met het toepassen van Systems Engineering, maar ook binnen projecten zijn er een aantal problemen te onderkennen. Binnen een aantal bedrijven (Grontmij, ProRail) wordt onderscheid gemaakt tussen een SE in een lichtere uitvoering (basis, light) en een uitgebreide versie. Bij Grontmij wordt hier wel over gesproken maar wordt nog niet naar de invulling hiervan gekeken. Ook is er nog niet bepaald wanneer welke variant van toepassing is. Op het moment dat er een opdracht binnen komt bij Grontmij wordt vanuit de vraagspecificatie of klantbehoefte heel ad hoc, uit ervaring en intuïtie bepaald hoe het project aangepakt gaat worden. Hierbij wordt geen analyse gemaakt op welk niveau het project zich eigenlijk bevindt. Heeft de opdrachtgever alleen nog maar een probleembeschrijving, of is er al tot een oplossing besloten en is het een complex project? Dit is onder andere van invloed op de te gebruiken instrumenten die SE biedt. Uit gesprekken met werknemers van Grontmij valt af te leiden dat men vaak gefrustreerd is over het gebruik van Systems Engineering, omdat niet duidelijk is waarom dit in sommige situaties toegepast wordt of de eis van de opdrachtgever om Systems Engineering toe te passen geen toegevoegde waarde biedt voor het project. Vaak wordt er nu veel te diep gegaan in de uitwerking met behulp van de instrumenten die Systems Engineering biedt, of er wordt juist veel te licht gedacht over het gebruik van de instrumenten. Ook is het in deze situatie voor een opdrachtgever nog maar afwachten of hij uiteindelijk krijgt wat hij voor ogen had, omdat niet in te schatten is hoe ver er in het project gedoken gaat worden. In een steeds complexer wordende wereld, is het opvallend dat binnen de discipline SE niet gesproken wordt over complexiteit. Het is niet zo dat voor elk project de mate van het toepassen van SE gelijk zou moeten zijn. Er is een aantal kenmerken die de mate van toepassen van Systems Enginee- 1 Gesprekken met werknemers Grontmij Hoofdstuk: Onderzoeksontwerp 18

19 ring zou kunnen bepalen. Getracht wordt in dit onderzoek de mate van het toepassen van SE te bepalen aan de hand van de kenmerken van een project. Er wordt hierbij dan ook niet zozeer op de discipline gefocust, maar op de methodieken die aangereikt worden. Te weinig inzicht in de praktische invulling van instrumenten Het tweede probleem is dat men te weinig inzicht heeft in het gebruik van de instrumenten. De praktische invulling van de methode is zodanig onduidelijk dat er vaak de verkeerde kant op wordt gewerkt. Wanneer de opdrachtgever al een oplossing voor ogen heeft, maar er nog geen functionele analyse is gedaan, moet men toch vaak, op verzoek van de opdrachtgever, terugwerken naar een functionele specificatie en feitelijk een hoger niveau. In principe stelt de opdrachtgever eisen aan wat hij hebben wil, zonder daarbij van een bepaalde oplossing uit te gaan. Van daaruit wordt er, binnen Systems Engineering, een functieanalyse opgesteld. Wanneer alle functies duidelijk zijn, kunnen bij deze functies functievervullers worden gegenereerd. Functievervullers zijn tastbare objecten. En door al deze functievervullers te koppelen ontstaat er een ontwerp. Wanneer de opdrachtgever al zover is dat hij het ontwerp in gedachten heeft, zijn deze stappen wellicht weinig zinvol. Het kan betekenen dat er uiteindelijk toch weer eenzelfde oplossing uitkomt. Er kan ook doorgevraagd worden naar het waarom van de ontwerpkeuzes om zo te achterhalen waarom de opdrachtgever deze oplossing in gedachten had. Zo kan een functionele specificatie worden opgesteld waar niet per se de oplossing uitkomt die de opdrachtgever voor ogen had, maar een betere, goedkopere of mooiere oplossing. Het is dus niet altijd verkeerd om toch die analyse te maken, maar de vraag is of het zinvol is wanneer de opdrachtgever al precies weet wat hij wil. Het doorlopen van de stappen kost tijd en geld en de vraag is of dat het waard is. Het hoeft de doelmatigheid niet te bevorderen, aangezien de opdrachtgever in zijn eigen oplossing ook alles krijgt wat hij hebben wil. Probleemstelling: Binnen projecten, waar SE als discipline is voorgeschreven, bestaat nog veel onduidelijkheid over het te bewandelen pad, door het ontbreken van inzicht in de mogelijk te gebruiken projectbeheersinginstrumenten die aangereikt worden en de afweging die gemaakt kan worden voor elke van deze instrumenten over het waarom en wanneer (niet) gebruiken ervan. Binnen Grontmij worden veel projecten uitgevoerd waarbij Systems Engineering is voorgeschreven als ontwerp- en projectbeheersingmethode. Omdat deze discipline relatief nieuw is, is het belangrijk om in kaart te brengen welk beeld Grontmij nu precies heeft bij de geboden instrumenten en hoe deze toegepast kunnen worden binnen projecten. Het verder ontwikkelen van de methode SE voert te ver voor dit afstudeerrapport en lost niet alle problemen op. Om in kaart te brengen welke instrumenten er gebruikt worden en wat het nut van deze instrumenten is, wordt een explorerende casestudie uitgevoerd. De conclusies van dit onderzoek kunnen als leidraad dienen voor volgende projecten. De resultaten zijn wel projectafhankelijk, maar de afwegingen die gemaakt zijn, kunnen verhelderend werken bij het opzetten van een volgend project. Doelstelling: Het doel van het onderzoek is het doen van aanbevelingen en het formuleren van afwegingscriteria voor het gebruik van projectbeheersinginstrumenten die SE biedt, door inzicht te geven in de gebruikte instrumenten bij een casestudie en aan de hand van een enquête op basis van de casestudie een analyse te maken over het waarom en wanneer (niet) gebruiken van deze instrumenten. 2.3 Afbakening onderzoekskader Dit onderzoek met het onderwerp Systems Engineering, beperkt zich tot de GWW-sector. De leidraad van Rijkswaterstaat en ProRail spreekt over de grond-, weg- en waterbouw sector. Maar in de praktijk wordt Systems Engineering ingezet in allerlei bouwgerelateerde projecten. Bij de renovatie van een sluizencomplex bijvoorbeeld, wat een civiel technisch werk is wat onder grond-, weg- en waterbouw valt, maar waar ook installatietechniek bij komt kijken. Hoofdstuk: Onderzoeksontwerp 19

20 Daarnaast focust Systems Engineering zich voornamelijk op technische processen binnen het integrale projectmanagement (ProRail, Rijkswaterstaat, 2007). Vandaar dat in het kader van dit onderzoek ook alleen naar deze processen wordt gekeken. Binnen de technische processen wordt ingezoomd op het ontwerp. Figuur 2.1: afbakening onderzoekskader (ProRail & Rijkswaterstaat, 2007; Blanchard & Fabrycky, 1998) Figuur 2.2: focus technisch proces (ProRail & Rijkswaterstaat, 2007) Zoals in figuur 2.1 staat aangegeven ligt de focus op het ontwerpproces. Binnen het ontwerpproces zitten ook de andere onderdelen van het engineeringproces verwerkt. Door de opdrachtgever worden al eisen en functies geformuleerd, maar op hoog niveau. Binnen de ontwerpen worden deze eisen en functies doorvertaald en naar lagere niveaus gedecomponeerd. Met decomponeren wordt in dit rapport bedoeld het ontleden van een op hoger niveau staand systeem. Hoofdstuk: Onderzoeksontwerp 20

21 Binnen deze afbakening wordt dit explorerende onderzoek uitgevoerd. Dat wil zeggen dat er ook literatuur gezocht wordt binnen deze afbakening. Een aantal bronnen is reeds genoemd in dit rapport zoals INCOSE, CROW, ProRail en Rijkswaterstaat. Verder wordt er gezocht in verschillende databases om te achterhalen wat er in eerder onderzoek is geconcludeerd (zie bijlage 1). 2.4 Onderzoeksmodel Onderstaand onderzoeksmodel, figuur 2.3, is ontworpen aan de hand van methode Verschuren en Doorewaard (2005). In het model wordt door middel van kleur, verschil gemaakt tussen theorie (donkerblauw), empirie (lichtblauw) en resultaten (rood). Theorie Empirie Systems Engineering A. Theoretische benadering onderzoekskader Resultaat Projectkenmerken Casestudie HVVOS Interviews B. Huidig begrip en omgang met Systems Engineering (bij HVVOS) C. Enquête optimalisering Systems Engineering in relatie tot projectkenmerken Deskundigen D. Afwegingsmodel toepassing Systems Engineering Figuur 2.3: Onderzoeksmodel (Verschuren & Doorewaard, 2005) Bovenstaand model wordt van rechts naar links ontworpen, te beginnen bij de doelstelling van het onderzoek kort weergegeven in vak 4. Vanuit de doelstelling, kan naar rechts toewerkend, gevraagd worden wat ervoor nodig is om dit te bereiken. De benodigde ingrediënten bevinden zich links in de figuur en worden verkregen uit de theorie of de empirie. Onderdelen die bestudeerd moeten worden om tot dit model te komen zijn Systems Engineering, projectkenmerken en de projectcase HVVOS. Systems Engineering Projectkenmerken Figuur 2.4: deel A A. Theoretische benadering onderzoekskader Door een beschrijving te geven van de methode SE, wordt gekeken wat in theorie de bedoeling is van de methode, wat de voor- en nadelen zijn en waar het toegepast wordt. Daarnaast wordt gekeken naar projectkenmerken en naar de koppeling tussen beide begrippen. Aan de hand van de projectkenmerken kunnen uiteindelijk de afwegingen gemaakt worden. Wellicht is in de theorie al een verband zichtbaar tussen de toepassing van SE en de kenmerken die een project heeft. Hoofdstuk: Onderzoeksontwerp 21

22 Casestudie HVVOS Interviews B. Huidig begrip en omgang met Systems Engineering (bij HVVOS) Naast het theoretisch kader wordt gekeken naar een case renovatie Haringvliet en Volkerak sluizencomplexen (HV- VOS). Binnen dit project wordt SE toegepast in de ruimste zin van het woord. Binnen de projectorganisatie worden een aantal interviews gehouden. Hieruit volgt het huidige begrip en de omgang met Systems Engineering. Dit perspectief ontstaat vanuit het project HVVOS. Figuur 2.5: deel B A. B. Theoretische benadering onderzoekskader Huidig begrip en omgang met Systems Engineering (bij HVVOS) C. Enquête optimalisering Systems Engineering in relatie tot projectkenmerken Het theoretisch kader en het huidige begrip en omgang met Systems Engineering, vormen de input van een enquête. Deze enquête is erop gericht om te achterhalen of de theorie begrepen is en de meningen over SE binnen HVVOS nu algemeen geldend zijn. Daarnaast wordt de koppeling gemaakt met projectkenmerken. Vanuit de theorie kunnen een aantal vragen beantwoord worden, maar dat wil niet zeggen dat het in de praktijk ook geldt. Er wordt daarom ook gekeken naar de verschillen hiertussen. Figuur 2.6: deel C C. Enquête optimalisering Systems Engineering in relatie tot projectkenmerken D. Afwegingsmodel toepassing Systems Engineering De enquête wordt ingevuld door deskundigen, mensen die te maken hebben of hebben gehad met Systems Engineering. Uit de resultaten komt een afwegingsmodel, waarin staat waarop gelet moet en kan worden bij het toepassen van Systems Engineering. Deskundigen Figuur 2.7: deel D Hoofdstuk: Onderzoeksontwerp 22

23 2.5 Vraagstelling In dit hoofdstuk worden centrale en deelvragen opgesteld die in het hoofdrapport beantwoord worden. Met het beantwoorden van alle hoofdvragen, door allereerst alle deelvragen te beantwoorden, kan het doel gehaald worden. In dit onderzoek gaat het om het ontwikkelen prescriptieve kennis. Deze kennis geeft voorschriften over de wijze waarop een situatie moet worden veranderd. Dit komt overeen met de doelstelling, waarin eigenlijk gevraagd wordt om een structurering van projecten te maken en de daarbij toepasbare mate van Systems Engineering. Een die nog niet gemaakt wordt. Elke centrale vraag is ook weer terug te voeren naar de verschillende kolommen en onderdelen in het onderzoeksmodel. Centrale vraag 1: theoretische benadering onderzoekskader Wat is er in de theorie bekend over de koppeling tussen Systems Engineering en projectkenmerken? a. Wat wordt verstaan onder Systems Engineering? b. Welke onderdelen van Systems Engineering kunnen onderscheiden worden? c. Welke verschillende projectkenmerken kunnen onderscheiden worden? Centrale vraag 2: huidige begrip en omgang met Systems Engineering bij HVVOS Hoe wordt er binnen het project HVVOS gedacht over en omgegaan met Systems Engineering en haar onderdelen? a. Wat behelst het project HVVOS? b. Welke onderdelen van Systems Engineering worden onderscheiden in dit project? c. Welke projectkenmerken heeft dit project? d. Welke interviewvragen dienen gesteld te worden om het huidige begrip en de omgang met SE binnen het project te onderzoeken? Centrale vraag 3: enquête optimalisering Systems Engineering in relatie tot projectkenmerken Welke vragen dienen gesteld te worden in de enquête om conclusies te kunnen trekken over de toepassing van Systems Engineering in relatie tot projectkenmerken? Centrale vraag 4: afwegingsmodel toepassing Systems Engineering Hoe luiden de afwegingen die op basis van de theorie, interviews en enquête gemaakt kunnen worden? a. Welke relaties tussen projectkenmerken en (onderdelen van) Systems Engineering zijn er uit de theorie af te leiden? b. Welke relaties tussen projectkenmerken en (onderdelen van) Systems Engineering zijn er uit de interviews af te leiden? c. Welke relaties tussen projectkenmerken en (onderdelen van) Systems Engineering zijn er uit de enquête af te leiden? d. Welke afwegingen volgen uit a, b en c. Hoofdstuk: Onderzoeksontwerp 23

24 2.6 Leeswijzer Het rapport is ingedeeld is een aantal delen. Allereerst heeft u nu de inleiding en de opzet van het onderzoek gelezen. Hierna volgen vier afzonderlijke delen, waarin het onderzoek wordt uitgevoerd. In deel A is de theoretische benadering te vinden. Hierin wordt onderzoeksvraag 1 en 4a beantwoord. Dit deel bestaat uit een drietal hoofdstukken; H3 Systems Engineering H4 Projectkenmerken H5 Afwegingen vanuit de theorie In deel B wordt er gekeken naar de casestudie renovatie Haringvliet en Volkerak sluizencomplexen. Hiervan wordt bepaald hoe er met SE is gewerkt en wat men ervan vond, door middel van interviews. In dit hoofdstuk wordt onderzoeksvraag 2 en 4b beantwoord. Dit deel bestaat uit twee hoofdstukken, te weten; H6 Casestudie HVVOS H7 Afwegingen vanuit de casestudie In het derde deel, C, wordt een uitgezette enquête besproken. Deze enquête is uitgezet om te kijken of de afwegingen en conclusies die getrokken kunnen worden uit de theorie en de casestudie ook algemeen gelden. De theorie en de casestudie zijn als input gebruikt voor het opstellen van de enquête. In dit deel wordt onderzoeksvraag 3 en 4c beantwoord. Dit deel bestaat uit een drietal hoofdstukken; H8 Opzet enquête H9 Resultaten enquête H10 Afwegingen vanuit de enquête In het laatste deel, D, komen de drie voorgaande delen samen. Er is zoveel mogelijk voor gezorgd dat de delen A, B en C los van elkaar staan, zodat ze in deel d kunnen worden vergeleken. In dit hoofdstuk wordt onderzoeksvraag 4 beantwoord. Dit deel bestaat uit twee hoofdstukken; H11 Discussie H12 Conclusies en aanbevelingen Hoofdstuk 13 bevat een begrippen- en afkortingenlijst, waarin de meeste begrippen zijn opgenomen. In het rapport wordt verwezen naar literatuur door middel van een auteursnaam en een jaartal. In hoofdstuk 14, bronnen, kan de volledige titel gevonden worden van desbetreffend artikel of boek. Er is ook gebruik gemaakt van voetnoten, wanneer het een verwijzing betreft naar iets wat een persoon gezegd heeft. Deze bron is niet opgenomen in de bronnenlijst in hoofdstuk 14. Naast dit rapport is er een aparte bundel met bijlagen. Hoofdstuk: Onderzoeksontwerp 24

25 Deel A; Theoretische benadering

26

27 3 Systems Engineering 3.1 Inleiding In dit hoofdstuk wordt Systems Engineering gedefinieerd ten behoeve van dit onderzoek. Daarbij wordt aandacht besteed aan: De inhoud van SE in de GWW-sector De methodieken die SE aanreikt In welke situaties Systems Engineering wordt toegepast Waarom Systems Engineering wordt toegepast Het hoofdstuk wordt afgesloten met de beantwoording van de onderzoeksvragen 1a en 1b; Wat wordt verstaan onder Systems Engineering in dit onderzoek? Welke onderdelen van Systems Engineering kunnen onderscheiden worden? 3.2 Definitie en inhoud Systems Engineering Werkdefinitie In het vorige hoofdstuk is een werkdefinitie van SE gegeven, welke gebruikt wordt in dit onderzoek; SE is een discipline welke een set methodieken aanreikt om het bouwproces in te richten en te beheersen. Met deze methodieken wordt bewerkstelligd dat men denkt vanuit het probleem, kijkt naar de gehele levenscyclus en transparant werkt. Deze werkdefinitie is een combinatie van verschillende definities gegeven door INCOSE (2007), Pro- Rail & Rijkswaterstaat (2007) en CROW (2007). Ingezoomd op deze werkdefinitie, wordt duidelijk wat de speerpunten van de discipline SE zijn; probleemgericht denken, een levenscyclusbenadering en transparant werken. Dit zijn eigenschappen van de discipline. Daarnaast ligt de nadruk van dit onderzoek op het bouwproces en is het doel van het onderzoek om afwegingen weer te geven met betrekken tot de set methodieken die aangereikt worden. De vetgedrukte begrippen uit de werkdefinitie worden hieronder verder uitgelegd. Discipline SE zou eenvoudig te implementeren zijn wanneer het slechts het volgen van een stappenplan zou behelzen. Juist doordat veel mensen op die manier denken, komt de discipline SE ook niet verder dan het volgen van een stappenplan en wordt de discipline ervaren als veel (onnodig) werk, ondoorzichtig en omslachtig. SE wordt binnen dit onderzoek gedefinieerd als discipline omdat het een andere manier van denken van mensen vraagt; het denken in systemen, het probleemgericht werken en het beschouwen van de gehele levenscyclus. Wanneer er iets moet veranderen aan de manier van denken en werken van mensen, dan vraagt dit oefening en tijd. Het is een discipline omdat men het onder de knie moet krijgen, moet oefenen en leren. Het hele denk- en werkproces wordt ondersteund door een gereedschapskist, maar SE is meer dan deze instrumenten alleen (Gesprekken Grontmij, 2008). Set methodieken Zoals bij discipline al aangegeven, biedt Systems Engineering een gereedschapskist om de denk- en werkwijze van mensen te sturen en te structureren. Hierbij kan gedacht worden aan het functioneel specificeren en het functiedenken, het opzetten van een work-breakdown structuren en het maken Hoofdstuk: Systems Engineering 27

28 van een verificatie en validatie plan. Al deze onderdelen worden in paragraaf verder onderscheiden (ProRail & Rijkswaterstaat, 2007). Bouwproces Dit onderzoek beperkt zich tot de GWW-sector, daarom wordt hier ook het bouwproces binnen de GWW-sector bedoeld. In dit rapport worden utiliteitsbouw en woningbouwprojecten niet betrokken. Overigens is de Leidraad Systems Engineering van ProRail en Rijkswaterstaat (2007) ook voor de GWW-sector opgesteld. Met proces wordt hier bedoeld een aaneenschakeling van activiteiten, in een bedoelde volgorde en met een beoogd resultaat. Processen kunnen worden weergegeven in een context diagram (INCOSE, 2007). Daarin staat de input, output, proces besturing (controls) en proces mechanismen (enablers) weergegeven. Figuur: 3.1: context diagram (INCOSE, 2007) Probleem Van nature wordt er veel te snel gedacht in oplossingen. Wanneer er alleen oplossingsgericht wordt gewerkt, wordt het hele proces van het uiteenrafelen van het probleem overgeslagen. Door naar het probleem te kijken en dit volledig uit te werken in eisen en functies, kunnen alternatieven gegenereerd worden die wellicht innovatiever, efficiënter of goedkoper zijn. Door te achterhalen wat de achterliggende redenen zijn van de opdrachtgever om het project een bepaalde eis mee te geven, kan tot nieuwe inzichten gekomen worden. Het kan ook zo zijn dat er exact dezelfde oplossing uitkomt doordat SE transparanter is en de keuzes aantoonbaar zijn (ProRail & Rijkswaterstaat, 2007). Een probleem wordt in het kader van dit onderzoek gezien als een waarschijnlijke, maar niet wenselijke toekomst (de Ridder & Ravesloot, 2007). Levenscyclus De volgende levenscyclus fasen worden onderscheiden; concept, ontwikkeling, realisatie, gebruik, beheer & onderhoud en sloop (ProRail & Rijkswaterstaat, 2007). Als voorbeeld kan gedacht worden aan het ontwerpen van straatverlichting. De goedkoopste optie voor een aannemer is om gloeilampen toe te passen. Dit zorgt voor lage initiële kosten, maar vraagt veel onderhoud dus de onderhoudskosten zijn hoog. Een alternatief is LEDverlichting of spaarlampen. Initieel zijn de kosten een stuk hoger, maar deze lampen hoeven niet zo vaak vervangen te worden, zijn energiezuinig en leveren een hogere lichtsterkte. De onderhoudskosten zijn dus lager. Bekeken vanuit de gehele levenscyclus zijn LED-verlichting of spaarlampen wellicht een goedkoper alternatief. In de ontwerpfase worden volgens de methodiek van SE niet alleen de eisen ten behoeve van het functioneren van het te realiseren object ingevuld, maar ook aan diverse aspecteisen zoals bijvoorbeeld onderhoudbaarheid en veiligheid van het te realiseren object. Transparantie De totstandkoming van het ontwerp en de bijbehorende keuzes worden binnen Systems Engineering nadrukkelijk vastgelegd (ProRail & Rijkswaterstaat, 2007). Andere begrippen die binnen Systems Engineering veel gebruikt worden zijn expliciet en gestructureerd werken. Dit hangt samen met transparantie. Om transparant te kunnen werken zal het hele proces gestructureerd moeten zijn en alles expliciet vastgelegd moeten worden. Dit om zo min mogelijk onzekerheden en onduidelijkheden te krijgen (ProRail & Rijkswaterstaat, 2007) Hoofdstuk: Systems Engineering 28

29 3.2.2 Levenscyclus Systems Engineering gaat uit van de gehele levenscyclus. Hieronder is het V-model weergegeven met de zes basisfasen erin. Binnen het V-model worden de technische processen doorlopen, maar daarnaast bevinden zich de projectprocessen. Deze worden parallel doorlopen. Figuur 3.2: V-Model (aangepast van ProRail & Rijkswaterstaat, 2007) Fasen van de levenscyclus Definitie Ontwerp Realisatie Gebruik, beheer en onderhoud Renovatie Sloop Tabel 3.1: Fasen van de levenscyclus (aangepast van ISO 15288) Doel Probleemherkenning en beschrijving Identificeren van de behoefte van belanghebbenden Realiseren van het systeem Verifiëren en valideren In werking zijn van het systeem waarmee aan de behoefte van de gebruikers wordt beantwoord Moderniseren van een bestaand systeem zodat het weer aan de eisen en de behoefte van de gebruiker voldoet Verwijderen van het systeem Het V-model zoals weergegeven in figuur 3.2, geeft voornamelijk de technische processen weer. Parallel aan het V-model lopen de projectprocessen. Projectprocessen worden gedefinieerd met het context diagram in figuur 3.1. Voorbeelden van projectprocessen zijn risicomanagement, wijzigingen management en planning. Deze vallen buiten de scope van dit onderzoek en zijn niet toegepast. De technische processen worden gebruikt om: de systeemeisen te formuleren de systeemeisen om te zetten in objecten de objecten te gebruiken om de functies te vervullen het vervullen van deze functies door het object in stand te houden het object te slopen Kortweg beschrijven de technische processen de gehele levenscyclus van een object (of project). In de technische processen worden de activiteiten geformuleerd waarmee de voordelen van technische besluiten en handelingen kunnen worden geoptimaliseerd de uit technische besluiten en handelingen voortkomende risico s kunnen worden verminderd. (INCOSE, 2007). Hoofdstuk: Systems Engineering 29

30 De discipline Systems Engineering valt uiteen in een aantal onderdelen. Deze worden hieronder beschreven. Requirements Onder requirements wordt verstaan eisen, wensen, randvoorwaarden en uitgangspunten. Deze Engelse term wordt in het Nederlands vaak vertaald naar eisen, maar dit dekt de lading niet. Vandaar dat er hier voor gekozen is om de Engelse term te gebruiken. Eisen beschrijven een ondergrens waaraan het ontwerp minimaal moet voldoen en komen altijd van de opdrachtgever. Er wordt ook wel gesproken over een resultaatsverplichting. Randvoorwaarden worden bepaald door de omgeving en komen van buitenaf. De naam zegt het al, het is een voorwaarde. Vaak worden randvoorwaarden afgedekt door een lijst van bindende documenten die geformuleerd zijn in het programma van eisen. Randvoorwaarden beschrijven een bovengrens. Wensen beschrijven de kwaliteit die de opdrachtgever graag in het ontwerp terug zou zien, maar dit is geen breekpunt. Een wens is een zogenaamde inspanningsverplichting. Uitgangspunten kunnen zowel van binnenuit als van buitenaf komen. In figuur 3.3 is te zien hoe bovenstaande beschrijving van eisen, randvoorwaarden en uitgangspunten eruit kan zien. Een mogelijke oplossing of ontwerp zit tussen de eisen en randvoorwaarden, aangezien eisen de ondergrens aangeven en randvoorwaarden de bovengrens. Hierbinnen kunnen van binnen of buiten nog uitgangspunten en wensen gesteld worden. Wanneer de oplossing of het ontwerp gekozen is, dan staat de prestatie vast die deze oplossing heeft. Om alles wat te verduidelijken staat hieronder een voorbeeld van een weg; Figuur 3.3: eisen, randvoorwaarden en uitgangpunten (de Ridder & Ravesloot, 2007) Een eis vanuit de opdrachtgever is dat er minimaal auto s per dag over een nieuw te ontwerpen weg moeten kunnen, als uitgangspunt kan het ontwerpteam met het oog op groeiend autogebruik ervoor kiezen om auto s aan te houden. Als randvoorwaarde met het oog op milieuverontreiniging mogen er niet meer dan auto s per dag over dit wegdeel. Om te voorkomen dat dit aantal overschreden wordt, wordt als uitgangspunt maximaal ontworpen voor auto s. Na uiteindelijk ontworpen te hebben kan geconcludeerd worden dat de prestatie van de weg auto s per dag wordt. Bij de casestudie in deel B wordt wederom alleen gesproken over eisen, maar hiermee worden ook randvoorwaarden, uitgangspunten en wensen bedoeld. Functies De relaties die het systeem heeft met zijn omgeving en onderling met andere systemen, kunnen omgezet worden naar functies. Functies zijn de basis voor het opsporen, afbakenen en ontwikkelen van de juiste oplossingen/objecten. Om de werking van een systeem te begrijpen is inzicht nodig in de samenhang en samenstelling van de functies (CROW, 2007; In t Veld, 1998). Systemen en objecten Een bouwwerk kan gezien worden als één of meerdere systemen. Deze systemen worden bij elke ontwerpstap verder opgedeeld naar objecten, vervolgens componenten en daarna elementen. Alle materie in de wereld bestaat uit (scheikundige) elementen, een samenstelling van elementen vormt een component, een samenstelling van componenten een object en een samenstelling van objecten een systeem. Binnen een beschrijving van het systeem wordt de aandacht gevestigd op het beschrijven van het bouwwerk vanuit het geheel. Er wordt gekeken naar het doel van het systeem en van daaruit kunnen Hoofdstuk: Systems Engineering 30

31 later de functies bepaald worden. Daarnaast is het belangrijk te beschrijven wat de huidige en gewenste situatie is en wat de relaties van de systemen onderling en met de projectomgeving is (CROW, 2007; In t Veld, 1998). In het systeem zijn objecten tastbaar en vormen samenhangend het systeem. Om tot het juiste object te komen wordt er gekeken naar de eisen en de functie die het object moet vervullen. Vandaar dat deze ook weleens functievervuller genoemd wordt. Er zijn vaak meerdere objecten die passen binnen de eisen en de functie vervullen. Om tot het best passende alternatief te komen wordt er gebruik gemaakt van afwegingsmethoden zoals MCA (Multi-criteria analyse) of trade-off matrices (CROW, 2007) Raakvlakken Door middel van raakvlakken wordt de onderlinge samenhang tussen componenten of objecten in beeld gebracht. Dit kan zowel binnen hetzelfde systeem, intern, als de samenhang met andere systemen, extern, zijn. Dit is nodig om eventuele afstemmingsproblemen te voorkomen (CROW, 2007). Een raakvlak beschrijft een relatie tussen een aantal componenten of objecten. Een relatie wil zeggen dat het ene onderdeel van andere afhankelijk is, het beschrijft afhankelijkheid. Het nadrukkelijk opschrijven en erkennen van deze raakvlakken is essentieel om een systeem naar behoren te laten functioneren. Als voorbeeld kan gedacht worden aan het systeem een provinciale weg van A naar B. Binnen dit systeem bevinden zich een aantal kunstwerken, waaronder een brug. Deze brug als object kan op zichzelf voldoen aan alle gestelde eisen en randvoorwaarden, maar als de brug niet aansluit op, het object, het wegdeel dan voldoet het totale systeem niet aan de eisen en functioneert het systeem niet naar behoren. Verificatie Na elke vertaalslag wordt het ontwerp getoetst door middel van verificatie. Onder verificatie wordt verstaan een proces van evaluatie van een systeem om te bepalen of het systeem ontworpen in de ontwerpfase voldoet aan de requirements gesteld aan het begin van die fase (IEEE , 1990). Alle eisen worden vergeleken met het uiteindelijke ontwerp en er wordt dan gevraagd: Bouw ik het juist?. Er wordt ook nog onderscheid gemaakt met validatie. Onder validatie wordt verstaan het proces van evaluatie van een systeem om te controleren of het systeem aan de behoeftes van de belanghebbenden beantwoordt wanneer het systeem in gebruikt is in de vooraf bedoelde omgeving, kortweg of het gebouwde systeem valide is (IEEE , 1990). De vraag die voor de validatie gesteld kan worden is Bouw ik het juiste?. Validatie valt echter niet binnen de scope van het onderzoek. Daarnaast is er nog een toets op beschikbaarheid en betrouwbaarheid wat RAMS analyse genoemd wordt (Reliability, Availability, Maintainability & Safety). Hierin staan faalkansen verwerkt (ProRail, Rijkswaterstaat, 2007). De definitie van de vier termen die samen de afkorting RAMS vormen, staat hieronder weergegeven en komt uit de NEN-EN Reliability, betrouwbaarheid, wat wordt beschreven door mean time between failure. Het betreft de absolute (aaneengesloten) tijd dat het systeem werkt zonder falen. Availability, beschikbaarheid, wat wordt beschreven door = ( ) Het percentage van de tijd dat het systeem werkt en beschikbaar is. Maintainability, onderhoudbaarheid, wat wordt beschreven door correctieve en preventieve onderhoudbaarheid. Correctieve onderhoudbaarheid wordt beschreven door mean time to repair, de gemiddelde tijd die nodig is om het systeem te repareren. Safety, veiligheid, wat wordt beschreven door tolerable hazard rate, de toelaatbare mate van gevaar. 3.3 Toepassingsmogelijkheden Systems Engineering Wat Systems Engineering behelst binnen de GWW-sector is te vinden in een aantal bronnen, maar voornamelijk in de Leidraad Systems Engineering van ProRail en Rijkswaterstaat (2007). Waarom deze partijen voor Systems Engineering als nieuwe ontwerpmethode hebben gekozen staat zeer summier in deze bron en wordt niet onderbouwd met literatuur. Door het systematisch doorzoeken van verschillende databases en het raadplegen van verschillende naslagwerken (zie bijlage 1) is getracht literatuur en eerdere onderzoeken te vinden die aangeven wanneer en waarom Systems Engineering wordt toegepast en in de GWW-sector zou moeten worden toegepast. Hoofdstuk: Systems Engineering 31

32 Voor- en nadelen van Systems Engineering zijn zeer lastig te vinden en literatuur wat Systems Engineering in verband brengt met de GWW is onvindbaar. In bijlage 1 is een lijst te vinden met geraadpleegde databases en naslagwerken. De volgende twee paragrafen en geven weer wat er bekend is over het wanneer en waarom toepassen van Systems Engineering in andere sectoren, om zo een idee te geven wat de mogelijke toepassingsmogelijkheden en voor- en nadelen van Systems Engineering in de GWW-sector kunnen zijn. Er is echter geen verband aangetoond. De sectoren waarvoor wel literatuur en onderzoek is gevonden, zijn voornamelijk ICT, software, productie en militaire sectoren. Het ontbreken van relevante literatuur en eerder onderzoek geeft aan dat men in het duister tast over de toepassingsmogelijkheden en de eigenschappen van de discipline Systems Engineering. In dit explorerende onderzoek wordt de eerste stap gezet om deze toepassingsmogelijkheden en eigenschappen te beschrijven Wanneer passen we Systems Engineering toe? In deze paragraaf wordt er gekeken naar wanneer Systems Engineering toegepast kan worden. Het SE proces kan worden toegepast bij een project om de volgende redenen (Martin, 1997): Het project is complex In de GWW-sector bestaan er bijna geen simpele projecten. Afgaand op deze reden op SE toe te passen, zou Systems Engineering een geschikte discipline zijn voor de GWW-sector. In paragraaf 4.2 wordt dieper ingegaan op complexiteit als projectkenmerk. Het project is uniek en de oplossing is nog niet beschikbaar Veel projecten binnen de GWW zijn uniek, vandaar ook dat de meeste projecten complex zijn. De oplossing als geheel is vaak niet beschikbaar, maar voor deelproblemen en deelsystemen zijn vaak wel oplossingen beschikbaar. Projecten zijn veelal uniek om de omgevingsfactoren; bijvoorbeeld andere ondergrond, randvoorwaarden met betrekking tot het milieu en een andere opdrachtgever. Het systeem wat gebouwd moet worden op zichzelf is vaak niet uniek. Afgaand op deze reden om SE toe te passen, kan SE toegepast worden op veel GWW-projecten. Renovatieprojecten vallen hier in eerste instantie niet onder, aangezien hiervoor de oplossing al beschikbaar is. Het project vraagt om speciaal materiaalgebruik, speciale service, nieuwe technieken voor de ontwikkeling, speciale uitvoeringsmethodieken etc. Bovenstaande reden gaat alleen op voor GWW-projecten in bepaalde situaties. Het kan zijn dat de omgeving vraagt om speciaal materiaal gebruik. Aan een boorplatform in zee, of een kade van een haven worden speciale eisen gesteld voor materiaalgebruik, omdat men hier te maken heeft met zware omstandigheden waar niet elk materiaal tegen kan. Ook kunnen speciale eisen gesteld worden uit milieu oogpunt of esthetica. GWW-projecten vallen niet per definitie onder deze reden om SE toe te passen, dit moet per geval bekeken worden. Het project doet in de ontwikkelfase beroep op meerdere disciplines. GWW-projecten zijn veelal multidisciplinair. Afgaand op deze reden zou SE toegepast kunnen worden binnen GWW-projecten. Hoofdstuk: Systems Engineering 32

33 Balans in technologie, proces en mensen Balans in technologie, proces en mensen zorgt voor een efficiënt gebruik van Systems engineering, mits deze drie kernpunten gelijkwaardig ontwikkeld zijn (FHA, 2007). Deze drie punten bepalen in grote mate de kosten, planning en kwaliteit van het geleverde product. In dit onderzoek wordt de nadruk gelegd op het verbeteren van het proces. Er wordt niet ingegaan op het praktisch omgaan met de technologie/tools of het opleiden van mensen, maar alle drie kernpunten moeten gelijkmatig ontwikkeld worden om een goed resultaat te bereiken. Het ontwikkelen van nieuwe technologieën en tools, heeft geen zin als daarbij geen mensen worden opgeleid die ermee kunnen werken en het proces niet zodanig aangepast wordt dat deze nieuwe technologie of tool hierbinnen gebruikt kan worden. Een projectorganisatie, bestaand uit mensen, technologie en proces, is immers zo zwak als haar zwakste schakel Waarom passen we Systems Engineering toe? Het antwoord op wanneer SE toegepast kan worden, geeft geen antwoord op waarom men Systems Engineering zou willen toepassen. In deze paragraaf worden een aantal redenen besproken waarom Systems Engineering meerwaarde kan hebben binnen een project. Voordelen die Systems Engineering oplevert in de GWW-sector, zijn nog niet duidelijk geformuleerd. Wel worden de theoretische voordelen vaak aangekaart in andere sectoren. Theorie over Systems Engineering voordelen in de GWW-sector zijn niet gevonden (zie bijlage 1). Aanwijzingen kunnen worden gevonden in literatuur uit andere sectoren. De redenen voor toepassen zijn verdeeld in drie categorieën; kosten, tijd en risico s. Kosten Uit een onderzoek uitgevoerd door Eric Honour (Honour, 2004), namens INCOSE, komt het verband in figuur 3.4. Er zijn data verzameld van ruim 40 projecten over de kosten, tijd, kwaliteit en planning. In onderstaand figuur is de Systems Engineering Effort (SEE) uitgezet tegen de ratio van actuele en geplande kosten. SEE bestaat uit de kwaliteit van de uitgevoerde Systems engineering en het percentage project kosten wat besteed is aan Systems Engineering. Er is te zien dat het vergroten van SEE leidt tot een optimalisering van de kosten van een project. Figuur 3.4: Systems Engineering Effort versus Kosten (Honour, 2004) Dit is een opvallende conclusie wanneer het merendeel van de onderzochte projecten niet meer dan 10% van hun budget hadden gereserveerd voor SE. Het optimum volgens het onderzoek ligt tussen de 15-20% SEE (Honour, 2004). Dat wil grofweg zeggen dat 15-20% van het totale budget uitgegeven zou moeten worden aan Systems Engineering. Figuur 3.4 representeert alleen niet de GWW-sector, maar productie. De data is verzameld vanuit NASA en diverse technology product development teams (Honour, 2004). Hier gaat het om producten die eenmaal ontworpen worden en daarna in (massa) productie genomen worden. Ontwerpkosten zijn hier in verhouding tot 1 product vele malen groter dan bij een bouwproject. GWW-projecten zijn allemaal uniek er vragen voor elk product of systeem een nieuw ontwerptraject. Bij bouwprojecten wordt naar schatting gemiddeld 10% van de totale kosten uitgetrokken voor het ontwerptraject. Dit ligt ruim onder het optimum dat door Honour geconcludeerd is. Dat neemt niet weg dat bovenstaand verband ook kan gelden binnen de bouwsector, maar of dit daadwerkelijk het geval is moet nog blijken uit verder onderzoek. Met de toepassing van Systems Engineering worden vaak in het begin meer kosten gemaakt, door bijvoorbeeld het werken met een nieuwe methode en software die daarbij nodig is. Deze kosten en Hoofdstuk: Systems Engineering 33

34 moeite kunnen de kosten in latere fasen van het project echter significant verlagen, bijvoorbeeld bij het definitief ontwerp en de ontwikkelfase. Wanneer alles expliciet en transparant verwerkt is en het goed vastligt, zijn er in theorie geen discussies en wijzigingen meer nodig. Alles is bekeken vanuit het geheel en, wanneer goed uitgevoerd, zijn er geen onderdelen overgeslagen. Concluderend kan het besteden van meer tijd en geld aan Systems Engineering in het begin van een project, leiden tot kostenbesparingen verderop in de uitvoering, de gebruiksfase en de sloop van het gebouw. Dit levert 40% reductie van de constructiekosten in de productiesector op (Blanchard & Fabrycky, 1998; Martin, 1997). Tijd Reductie van benodigde tijd kan gehaald worden door het vroegtijdig in het ontwerpproces onderzoeken van meerdere haalbare opties (met het gebruik van de nodige software tools). Hierdoor kan het beste alternatief ook vroegtijdig gekozen worden. Het uiteindelijk ontwerp kan dan beter uitgewerkt en ontwikkeld worden doordat daar meer tijd voor is. Ook kunnen wijzigingen en veranderingen in een eerder stadium gedetecteerd en geïmplementeerd worden in het ontwerp. Door deze tijdsbesparing in een vroegtijdig stadium van het ontwerpproces kunnen ook veel kosten bespaard worden. Door deze werkwijze te hanteren kan uiteindelijk ook tijd gewonnen worden bij het verifiëren en valideren van het ontwerp. In de productiesector levert dit een reductie op tot 60 % van de constructietijd. Tot 75 % kan gereduceerd worden in de benodigde tijd voor herontwerp en het verwerken van wijzigingen en tot 50 % in het aantal wijzigingen (Martin, 1997). Wat tot gevolg heeft dat het totale product meer competitief is en meegaat met de verwachtingen en eisen van de externe klant, opdrachtgever of gebruiker. Dit betrekkend op de GWW-sector lijken deze percentages aan de hoge kant. Constructietijd in de GWW-sector wordt vaak bepaald door het uitharden van materiaal zoals beton en de zettingstijd van de ondergrond en niet zozeer door het ontwerp of het proces. De percentages voor reductie van benodigde tijd voor het verwerken van wijzigingen en het aantal benodigde wijzigingen lijken realistischer met betrekking tot de GWW-sector. Figuur 3.5: Systems Engineering Effort versus tijd (Honour, 2004) SEE, zoals besproken in de paragraaf Kosten, heeft ook invloed op de ratio tussen actuele en geplande tijdsbesteding. Rond 18% SEE levert het meest optimale resultaten qua planning. Wanneer ongeveer 18 % van het totale budget aan Systems Engineering wordt besteed kan de actuele tijdsbesteding teruggebracht worden tot minder dan de geplande tijdsbesteding. Dit geldt wederom voor de projecten welke Honour s heeft onderzocht; projecten van NASA en diverse technology product development teams. Risico s In de vorige paragrafen werd aangekaart dat er voldoende budget aanwezig moet zijn voor de implementatie van Systems Engineering in het ontwerpproces, om te zorgen voor een reductie in tijd en geld. Wanneer er echter teveel geld en tijd besteed wordt aan Systems Engineering, dan wordt het risico op overschrijding van het budget en de planning groter. Helm (1996) beschrijft risico als kans maal gevolg, maar waarschuwt hierbij wel dat een simpel product van kans maal gevolg risico nooit volledig kan beschrijven. Maar hij geeft wel aan dat dit een adequate basis is voorvergelijking in beslisprocessen. Voor dit rapport volstaat de definitie van risico als: = In figuur 3.6 zijn deze twee verbanden te zien; het verkleinen van de risico s op kosten- en tijdsoverschrijding door meer SE toe te passen en de kostentoename bij het vergroten van de mate van toepassen van SE. Wanneer beide verbanden tegen elkaar uitgezet worden, is er een optimum te bepalen (INCOSE, 2007; FHA, 2007). Hoofdstuk: Systems Engineering 34

35 . Figuur 3.6: tailoring op risico s (Aangepast van INCOSE, 2007; FHA, 2007) Volgens Dean, Bentz & Terry Bahill (1997) en Martin (1997) zorgt Systems Engineering ook voor het vroegtijdig lokaliseren van ontwerpfouten en tegenstrijdigheden, zoals bij paragraaf Tijd al is vermeld. Naast het reduceren van benodigde tijd, zorgt het vroegtijdig lokaliseren van ontwerpfouten ook voor het reduceren van ontwerprisico s. 3.4 Terugkoppeling onderzoeksvraag In de inleiding van dit hoofdstuk is onderstaande onderzoeksvraag al vermeld en in de paragrafen daarna is getracht deze vraag te beantwoorden. In deze paragraaf is het antwoord beknopt weergegeven. Onderzoeksvraag: Wat wordt verstaan onder Systems Engineering in dit onderzoek? SE is een discipline welke een set methodieken aanreikt om het bouwproces in te richten en te beheersen. Met deze methodieken wordt bewerkstelligd dat men denkt vanuit het probleem, kijkt naar de gehele levenscyclus en transparant werkt (3.2.1). Deze methode kan worden toegepast om de volgende redenen (3.3.1); 1. Het project is complex 2. Het project is uniek en de oplossing is nog niet beschikbaar 3. Het project vraagt om speciaal materiaalgebruik, speciale service, nieuwe technieken voor de ontwikkeling, speciale uitvoeringsmethodieken etc. 4. Het project doet in de ontwikkelfase beroep op meerdere disciplines. En onder de voorwaarde dat er balans is tussen technologie, proces en mensen. Systems Engineering kan daarbij zorgen voor reductie van (3.3.2) Kosten Tijd Risico s Deze reductie is onderzocht in de productie en ICT sector en niet in de GWW-sector. De hypothese is dat deze verbanden ook gelden in de GWW-sector. Welke onderdelen van Systems Engineering kunnen onderscheiden worden? De volgende onderdelen kunnen onderscheiden worden (3.2.2): Hoofdstuk: Systems Engineering 35

36 Requirements Systemen en objecten Functies Raakvlakken Verificatie Hoofdstuk: Systems Engineering 36

37 4 Projectkenmerken 4.1 Inleiding Er is een keuze gemaakt van een aantal projectkenmerken die terug komen in de enquête in deel C. In dit hoofdstuk worden deze kenmerken besproken. Hierin komen de kenmerken kosten, tijd en risico s van het deel A terug. Onder complexiteit vallen een aantal projectkenmerken, daarnaast zijn kosten en tijd projectkenmerken en zijn er nog een aantal projectkenmerken die gerelateerd zijn aan de GWW-sector. Het hoofdstuk wordt afgesloten met de beantwoording van onderzoeksvraag 1c; Welke projectkenmerken kunnen onderscheiden worden? 4.2 Complexiteit Complexiteit wordt gedefinieerd door functies, onderlinge interactie en dynamiek Of iets als complex ervaren wordt heeft te maken met het niveau van kennis en ervaring. Het ervaren van complexiteit verschilt van persoon tot persoon en heeft te maken met het niet kunnen overzien, doorzien of bevatten van een situatie. Het ervaren van complexiteit kan echter ook afhangen van de beschrijving van het object. Volgens Alkemade (1992) is complexiteit uiteindelijk terug te brengen naar twee hoofdkenmerken; het aantal functies van het systeem en de onderlinge interactie tussen de functies. Ook noemt Alkemade complexiteit een relatief en subjectief begrip. In het ontwerpproces heeft complexiteit zowel betrekking op de ontwerper als de conceptoplossing. Voor de ontwerper is complexiteit subjectief, want iedereen kijkt immers op een andere manier naar de opgave en complexiteit is relatief omdat het wordt bepaald door ervaring, kennis en kunde van de persoon die ermee werkt. Brussaard en Thiadens (1993) voegen daar nog aan toe dat een systeem complex is wanneer het aan verandering onderhevig is, dus dynamisch is. Kortweg zeggen Alkemade (1992) en Brussaard & Thiadens (1993); Een systeem is complex wanneer het systeem meerdere functies moet vervullen en binnen het systeem of tussen de verschillende (sub)systemen onderlinge interactie plaatsvindt. Daarnaast is een systeem complex wanneer het onderhevig is aan verandering (dynamisch) Projectkenmerken met relatie tot complexiteit Aantal disciplines Wanneer slechts één of enkele disciplines samenkomen binnen het project, is het proces ontwerp minder omvattend. Er moet goed gekeken worden naar alle onderdelen van het systeem, de relatie en de onderlinge interactie tussen deze onderdelen. Wanneer het project multidisciplinair is, moet veel meer gefocust worden op het procesontwerp, en de raakvlakken zowel intern als extern (FHA,2007). Wanneer er meerdere disciplines betrokken zijn heeft het systeem meerdere functies te vervullen. Afhankelijkheid Een deelbaar project bestaat uit verschillende, onafhankelijk van elkaar functionerende objecten of deelprojecten. Een ondeelbaar project bestaat uit één functioneel geheel dat niet meer kan functioneren als er een onderdeel uit is weggehaald. In ondeelbare objecten of deelprojecten is dus veel onderlinge interactie (Van Gigch, 1991). Deelbare projecten kenmerken zich door activiteiten die parallel Hoofdstuk: Projectkenmerken 37

38 kunnen plaatsvinden, waardoor er minder tijd nodig is en kostenoverschrijdingen verminderd kunnen worden. Wanneer activiteiten opeenvolgend zijn, leidt vertraging bij een onderdeel vaak voor vertraging in het gehele project. Ook kunnen deelprojecten geïsoleerd worden en besloten worden een van de deelprojecten te annuleren zonder dat dat invloed heeft op de andere projecten. Wanneer het project deelbaar is, biedt dat meer zekerheid en beheersbaarheid (Van Gigch, 1991; Rijkswaterstaat, 2006). Binnen de GWW-sector zijn er zelden delen totaal onafhankelijk van elkaar, maar er kan wel degelijk verschil gemaakt worden op basis van afhankelijkheid. Belangen en belanghebbenden Het gaat hierbij niet alleen maar om het aantal belanghebbenden. Ook een klein aantal belanghebbenden kan veel belangen hebben die in meer of mindere mate tegenstrijdig zijn. Deze tegenstrijdigheid is echter wel belangrijk, want een groot aantal belanghebbenden met dezelfde belangen, maakt een project of systeem niet complex. Wanneer er veel belanghebbenden zijn of veel tegenstrijdigheid in de belangen is, moet er veel gecommuniceerd worden met deze belanghebbenden. Dit kenmerk zorgt zowel voor onzekerheid als risico en dus voor complexiteit. Het is dan belangrijk om transparant en expliciet te zijn in je werkwijze. Iets waar Systems Engineering in voorziet (FHA, 2007). Innovatie Het gebruik van bewezen techniek of het ontwerpen van een standaardsysteem kent meer zekerheden dan het gebruik van innovatieve techniek of het doen van een uniek, innovatief project. Het project is beter beheersbaar en minder complex, maar er wordt wel ingeleverd op innovatiepotentieel en dus op inhoudelijke verrijking (Rijkswaterstaat, 2006). Door het toepassen van Systems Engineering wordt er ruimte aan de opdrachtnemer gegeven om met innovatieve alternatieven te komen (DoD, 2001) zonder daarmee veel onzekerheden te introduceren. Meer creativiteit en innovatie in een bouwproject kan leiden tot doelmatigere en efficiëntere bouwprojecten (ONRI, 2005). In de interviews en de enquête, deel B en C, wordt daarom gekeken of Systems Engineering daadwerkelijk op dit moment ruimte biedt voor innovatie en de deze ruimte ook gebruikt wordt. Kennis en ervaring Het slagen van het gebruik van Systems Engineering, staat en valt met de kennis en ervaring van de mensen die met de discipline werken (FHA, 2007). Dat SE een discipline is wil zeggen dat het niet een stappenplan is wat je kunt gebruiken, maar een methode die je eigen moet maken. Wanneer projectmedewerkers weinig ervaring hebben met Systems Engineering is het belangrijk mensen in te schakelen die hier wel ervaring mee hebben om te assisteren en te adviseren en het overzicht te bewaren (FHA, 2007). Het ervaren van iets als complex alles te maken met kennis en ervaring van de persoon (4.2.1) 4.3 Kosten In de literatuur wordt er nauwelijks verschil gemaakt in toe te passen mate van Systems Engineering bij verschillende projectomvang (in ), maar er is simpelweg bij kleinere projecten geen geld beschikbaar om alles op een formele manier te doen. Natuurlijk kunnen er niet zomaar stappen overgeslagen worden, maar de onderdelen kunnen wel op een minder formele manier uitgevoerd worden (FHA, 2007). Het toepassen van een nieuwe ontwerpmethode kost nu eenmaal tijd en geld en dat is niet altijd voor handen. Er zal een bepaalde minimale projectomvang (in ) zijn waarbij het toepassen van Systems Engineering wenselijk is. Wanneer er minder budget is, zal het niet opwegen. In de interviews en de enquête wordt aandacht besteed aan deze minimaal benodigde projectomvang vanaf wanneer het wenselijk is Systems Engineering toe te passen. 4.4 Tijd Er is al een aantal punten behandeld waaruit blijkt dat de methode Systems Engineering omvattend is en niet zomaar toegepast kan worden. De planning van projecten kan gevolgen hebben voor de toepassing van Systems Engineering. Wanneer het een klein project betreft moet men zich afvragen of Hoofdstuk: Projectkenmerken 38

39 de moeite en tijd die de toepassing van Systems Engineering vraagt, opweegt tegen de voordelen die het kan bieden. Bij grotere projecten, waar de projectmedewerkers geen ervaring hebben met Systems Engineering, zal men zich wederom af moeten vragen of de moeite en tijd die de toepassing van Systems Engineering vraagt, opweegt tegen de voordelen die het kan bieden. Er moeten dan onder andere extra mensen ingeschakeld worden die ervaring hebben met de methode (INCOSE, 2007; Martin, 1997; FHA, 2007). 4.5 Projectkenmerken gerelateerd aan de GWW-sector Fase in het V-model Er kan onderscheid gemaakt worden tussen projecten in verschillende fasen van de levenscyclus. Dan gaat het bijvoorbeeld om nieuwbouwprojecten en renovatieprojecten. Het feit of het gaat om nieuwbouw of renovatie is in theorie niet bepalend voor de invulling van Systems Engineering binnen het project, aangezien SE gedurende de gehele levenscyclus toegepast kan worden, maar wellicht wel voor het nut hiervan. Bij nieuwbouwprojecten is er meestal meer vrijheid binnen het ontwerp. Renovatieprojecten zijn daarentegen redelijk vastomlijnd. De projectgrenzen liggen vast en vaak moeten bepaalde functievervullers vervangen worden om zo weer aan de prestatie-eisen van het systeem te voldoen. Doordat er minder vrijheid in de ontwerpfase is, kan het zijn dat bepaalde onderdelen van Systems Engineering niet zo zinvol zijn. Een renovatieproject is daarentegen minder risicovol omdat er veel gegevens over beschikbaar zijn en duidelijk is aan welke functies en eisen niet voldaan wordt. Bij nieuwbouwprojecten is er meestal weinig informatie beschikbaar en moet er veel zelf uitgezocht worden en veel aannames gedaan worden (FHA, 2007). Soort project De leidraad is geschreven voor grond-, weg- en waterbouw projecten (ProRail & Rijkswaterstaat, 2007), maar in dit document wordt niet duidelijk of Systems Engineering zich beperkt tot deze projecten of de methode ook bij andersoortige projecten toepasbaar is. In de enquête wordt een aantal keer aandacht geschonken aan de toepassing van Systems Engineering bij andersoortige projecten dan GWW-projecten. Dit mede doordat opdrachtgevers bij andersoortige projecten, zoals installatietechnische projecten, ook Systems Engineering vereisen. 4.6 Terugkoppeling onderzoeksvraag In deze paragraaf staat beknopt het antwoord op onderstaande onderzoeksvraag weergegeven. Welke projectkenmerken kunnen onderscheiden worden? In dit hoofdstuk worden onderstaande projectkenmerken onderscheiden: Complexiteit Aantal disciplines Afhankelijkheid Belangen en belanghebbenden Innovatie Kennis en ervaring Kosten Tijd Fase in het V-model Soort project Hoofdstuk: Projectkenmerken 39

40

41 5 Afweging op basis van de theoretische benadering Zoals in de leeswijzer al is weergegeven, is ervoor gekozen om de afzonderlijke onderdelen van dit onderzoek strikt gescheiden te behandelen. Vandaar dat in het laatste hoofdstuk van deel a: theoretische benadering, onderzoeksvraag 1 wordt beantwoord; Wat is er in de theorie bekend over de koppeling tussen Systems Engineering en projectkenmerken? Onderdeel Wel bij Niet bij Zorgt voor Zorgt niet voor Twijfel bij Systems Engineering Voldoende SE budget (3.3.2) Afhankelijkheid van projectonderdelen / onderlinge relaties (4.2.2) Veel belanghebbenden / tegenstrijdige belangen (4.2.2) Vodoende keuzeruimte (4.5) Balans; mens, technologie & proces (3.3.1) Voldoende kennis en ervaring aanwezig (4.2.2) Tabel 5.1: afwegingen vanuit de theorie Deze tabel kan als volgt gelezen worden: Reductie kosten Reductie tijd Reductie risico's Zekerheid Beheersbaarheid Transparantie Expliciet werken Structuur Het onderdeel uit kolom 1, in dit geval Systems Engineering,: Kan wel toegepast worden bij alle voorwaarden in kolom 2. Kan niet toegepast worden bij alle voorwaarden in kolom 3 Zorgt voor alle eigenschappen in kolom 4 Zorgt niet voor alle eigenschappen in kolom 5 Kolom 6, twijfel bij, wil zeggen dat er sterke twijfel bestaat over het nut van het toepassen van het onderdeel (kolom 1) bij de voorwaarden of eigenschappen in kolom 6 genoemd. Nu staat er niets in deze kolom, maar als daar reductie kosten zou staan, dan is er sterke twijfel of Systems Engineering als discipline zorgt voor kostenreductie. Veel afwegingen betreffen het toepassen van Systems Engineering. Wanneer wel en niet, zijn in de theorie nog niet terug te vinden. Wel staat er veel als, dan informatie in. Een aantal voorbeelden hiervan zijn: Als er voldoende budget wordt gereserveerd voor Systems Engineering binnen de projectbegroting, dan kan dit reductie in kosten, tijd, onzekerheid en risico s tot gevolg hebben. Als het project multidisciplinair is, moet er meer nadruk gelegd worden op het procesontwerp en de interne en externe raakvlakken. Deze voorbeelden kunnen niet meteen als afweging neergezet worden, maar wellicht is deze informatie in combinatie met andere afwegingen zinvol. De tabel dient als volgt gelezen te worden: Systems Engineering kan worden toegepast bij voldoende budget voor SE. Met voldoende budget zorgt SE voor reductie van kosten, tijd en risico s. Hoofdstuk: Afweging op basis van de theoretische benadering 41

42 Vanuit de theorie komen geen duidelijke kenmerken of eigenschappen naar voren waarbij Systems Engineering een negatief effect heeft. Uitspraken gericht op de onderdelen van Systems Engineering, zoals in paragraaf opgesomd, zijn niet gevonden. Hoofdstuk: Afweging op basis van de theoretische benadering 42

43 Deel B; Casestudy renovatie Haringvliet en Volkerak Sluizencomplexen

44

45 6 HVVOS 6.1 Doel In deel A, is de koppeling tussen de theorie van Systems Engineering en projectkenmerken besproken. Vervolgens wordt in dit hoofdstuk gekeken naar een project; renovatie van de Haringvliet en Volkerak sluizencomplexen (HVVOS). Dit project wordt opgepakt met Systems Engineering als ontwerpmethode. Dit project is geanalyseerd en er is daarbij gekeken naar wat de ervaring is met SE en hoe het precies in het ontwerpproces verweven zit. In dit hoofdstuk wordt antwoord gegeven op onderzoeksvraag 2 met bijbehorende deelvragen; Hoe wordt er binnen het project HVVOS gedacht over en omgegaan met Systems Engineering en haar onderdelen? a. Wat behelst het project HVVOS? b. Welke onderdelen van Systems Engineering worden onderscheiden in dit project? c. Welke projectkenmerken heeft dit project? d. Welke interviewvragen dienen gesteld te worden om het huidige begrip en de omgang met SE binnen het project te onderzoeken? 6.2 Casestudy Het project Homij Technische Installaties is, als hoofdaannemer, betrokken bij de renovatie van de Haringvliet en Volkerak sluizencomplexen, afgekort HVVOS. Het betreft hier een design, construct & maintain contract, een contract waarbij Homij verantwoordelijk is voor het ontwerp, de realisatie en het onderhoud van deze aansprekende onderdelen van de deltawerken. Het renovatiewerk duurt tot 2010 en Homij blijft tot 2025 verantwoordelijk voor het onderhoud. Homij werkt hierbij samen met ABB, Grontmij, Hycom en Hollestelle. Na veertig jaar is een groot deel van de elektronische installaties en het verouderde bedienings- en besturingssysteem op de complexen aan het einde van de technische levensduur. Hierdoor neemt de kans op storingen toe en de veiligheid af. Deze systemen zijn toe aan vervanging en groot onderhoud. Ook worden de sluisdeuren gerenoveerd. Met de renovatie van de Haringvlietsluizen werkt Rijkswaterstaat, de opdrachtgever, ook toe naar een nieuw waterbeheer in het Haringvliet. Het is de bedoeling dat bij vloed de sluizen tot 10% open komen te staan, zodat er een grotere biologische rijkdom wordt gecreëerd in het Westelijk deel van het Haringvliet, trekvissen veel beter kunnen passeren en de kraamkamerfunctie weer hersteld wordt. Grontmij ondersteunt Homij met een team en zo is Grontmij mede verantwoordelijk voor het opstellen van het voorontwerp en het definitief ontwerp. Dit verloopt geheel volgens de principes van Systems Engineering en Life Cycle Management. Daarnaast heeft Grontmij een belangrijke rol in het omgevingsmanagement voor externe communicatie en het verkrijgen van alle vergunningen. Ook het opstellen van de berekeningen voor het aantonen van de geëiste betrouwbaarheid en beschikbaarheid en ondersteuning tijdens het realisatieproces behoren tot de taken van Grontmij Projectkenmerken HVVOS Fase in het V-model; renovatie Het project betreft de renovatie van de Haringvliet en Volkerak sluizencomplexen. Dat wil zeggen dat het systeem al bestaat en niet meer naar behoren functioneert, niet aan de wensen voldoet of in de nabije toekomst niet meer voldoet. Binnen dit project is er wel een aantal verschillende soorten werk te onderscheiden. Het betreft onderhoud, renovatie en nieuwbouw. Het energiesysteem wordt volledig verwijderd en opnieuw ontworpen en gerealiseerd. Het hydraulisch systeem moet gerenoveerd worden en in het bouwkunde systeem zit wat onderhoud en wat nieuwbouw. Deze nieuwbouw is echter wel aan veel eisen gebonden. Het moet passen binnen het huidige systeem. Dat wil zeggen dat er Hoofdstuk: HVVOS 45

46 weinig keuzeruimte is. Dit is tevens het kenmerk van een renovatieproject. Vandaar dat ik het kopje renovatie wordt genoemd en niet de nieuwbouw en het onderhoud. Soort project; installatietechniek Het project valt uiteen in een aantal onderdelen; elektrotechniek, hydrauliek, bediening- en besturingssysteem en bouwkunde. Drie van deze onderdelen betreffen installatietechnische en werktuigbouwkundige zaken. Dit is een totaal andere insteek dan bouwkunde. Binnen de Leidraad Systems Engineering, wordt de focus ook voornamelijk gelegd op de GWW sector. Natuurlijk komen daar wel installatietechnische zaken bij kijken, maar dat is niet de insteek van de methode en de leidraad. Het is mogelijk dat de discipline Systems Engineering niet voldoende mogelijkheden biedt voor installatietechnische projecten. Daarom is dit een belangrijk projectkenmerk om mee te nemen in dit onderzoek. Aantal disciplines Binnen het project komt een aantal disciplines samen; onder andere elektrotechniek, hydrauliek, bediening- en besturing en bouw. Kosten De totale projectomvang zoals op de aanbestedingskalender is gepubliceerd is Daarvan is ongeveer 6% 2 begroot voor het voorlopig en definitief ontwerp. Projectgrootte Vanuit Grontmij, Homij en ABB waren hier ruim 30 mensen parttime of fulltime mee bezig. Tijd Het project HVVOS is op 29 augustus 2007 gegund aan HOMIJ Technische installaties. Vanaf dat moment tot 1 augustus 2008 is er gewerkt aan het voorlopig en definitief ontwerp (de focus van dit onderzoek). Op het moment is men bezig met het uitvoeringsontwerp. Complexiteit HVVOS bestaat uit een groot aantal functies en ontelbaar veel onderlinge relaties. Dit bepaalt de complexiteit (H4) en dus kan HVVOS als complex project worden gezien Systems Engineering binnen HVVOS Het moge duidelijk zijn dat vanuit de Opdrachtgever Rijkswaterstaat Systems Engineering wordt vereist als project aanpak. Binnen de vraagspecificatie deel 2 van dit project wordt daar het volgende over gezegd 2 : De markt tenzij Conform de beleidsdoelstelling de markt tenzij beoogt de Opdrachtgever de Opdrachtnemer zoveel mogelijk in te schakelen voor het uitvoeren van projectopdrachten Samenvattend heeft de Opdrachtgever behoefte aan een expliciete project aanpak door de Opdrachtnemer op basis van bijpassende methoden en technieken waarmee; - helderheid, transparantie, overzicht en consistentie in de diverse processen wordt geborgd, - kan worden aangetoond dat de opdracht goed wordt begrepen, - de Opdrachtgever en overige betrokken partijen op de juiste manier worden betrokken, - expliciet kan worden aangetoond dat ontwerpen/producten aan de eisen voldoen, - kan worden aangetoond dat de Opdrachtnemer zijn eigen werk controleert, - Wijzigingen en (ontwerp)beslissingen steeds traceerbaar zijn, - kan worden aangetoond dat risico s worden beheerst. Met Systems Engineering als methodisch fundament voor een expliciete project aanpak, kan in de behoeften van de Opdrachtgever worden voorzien. Binnen de vraagspecificaties van dit project wordt elke keer weer teruggegrepen naar Systems Engineering, breakdown structures en het V-model. Ook zijn alle activiteiten en resultaten beschreven in deze documenten. 2 Documentatie HVVOS Hoofdstuk: HVVOS 46

47 6.2.4 Format Door adviseurs van de afdeling Projects binnen Grontmij is uit alle aangeleverde informatie door Rijkswaterstaat een format gemaakt. Dit format is bedoeld voor alle ontwerpdocumenten. Hierin staat beschreven welke activiteiten er ontplooid moeten worden, hoe deze uitgevoerd moeten worden, in welke volgorde en hoe deze opgeschreven moeten worden. De format kent een aantal uitvoeringen; er is een uitgeklede versie voor fases waarin niet alle activiteiten nodig zijn en een uitgebreide versie wanneer dit wel het geval is. In figuur 6.1 op de volgende pagina is te zien hoe het proces in elkaar zat voor het voorlopig en definitief ontwerp. Op hoofdlijnen bevat het format de volgende onderdelen. Systeembeschrijving Binnen de systeembeschrijving wordt een scheiding gemaakt tussen het huidige en gewenste systeem. Daarnaast wordt er beschreven welke functie het (sub)systeem, waar het document betrekking op heeft, vervult binnen het geheel. Eisenanalyse Beschrijving van de eisen en randvoorwaarden die bepalend zijn voor het ontwerp van het subsysteem, inclusief (indien van toepassing) de in andere en voorgaande documenten afgeleide eisen. Functieanalyse Beschrijving van de functionaliteit van het subsysteem, inclusief de gebruikersinterface en toestandsdiagrammen. Ontwerpafweging Bepaling van de meest optimale alternatieven om de functies van het subsysteem te kunnen vervullen. Elk alternatief wordt allereerst beoordeeld aan de hand van een aantal selectiecriteria. Deze criteria bevatten randvoorwaarden waaraan het alternatief zeker moet voldoen wil het een serieus te overwegen optie zijn. Daarna worden de overgebleven alternatieven in een trade-off matrix beoordeeld op verschillende criteria zoals kosten, risico s, beschikbaarheid en betrouwbaarheid. Ontwerp Uitwerking van het ontwerp van het (sub)systeem, middels een oplossingsgerichte decompositie. De eisendecompositie op (sub)systeemniveau gegeven in de eisenanalyse, wordt naar het onderliggende niveau doorvertaald. Daarnaast worden hier de interne en externe raakvlakken bepaald. Ook worden make-or-buy beslissingen genomen. Wanneer onderdelen ingekocht gaan worden is het namelijk niet zinvol om deze verder te detailleren in een volgende fase. Verificatie Hierin wordt geverifieerd of het (sub)systeem aan de in de eisenanalyse en het ontwerp gestelde eisen voldoet. RAMS analyse Naast alle onderdelen van de format loopt de RAMS-analyse. Dit is niet een apart onderdeel van de format en wordt alleen kort genoemd in het hoofdstuk ontwerpafweging. De beschrijving van RAMS staat weergegeven in paragraaf Hoofdstuk: HVVOS 47

48 Figuur 6.1: procesgang HVVOS Hoofdstuk: HVVOS 48

49 6.3 Interviews Aanleiding en indeling interview Het uiteindelijke doel van het onderzoek is: het doen van aanbevelingen en het formuleren van afwegingscriteria voor het gebruik van projectbeheersinginstrumenten die SE biedt, door inzicht te geven in de gebruikte instrumenten bij een casestudie(s) en aan de hand daarvan een analyse te maken over het waarom en wanneer (niet) gebruiken van deze instrumenten. De afwegingen komen onder andere uit de literatuur, besproken in deel A, maar ook uit de praktijk. Theorie beschrijft hoe het zou moeten zijn en zou moeten gaan, maar wanneer de theorie niet goed beheerst wordt, mensen liever hun eigen gang gaan of een project niet volgens het boekje verloopt, gaan dingen vaak anders en loopt men tegen veel problemen aan. Om in de enquête, behandeld in deel C, de goede vragen te stellen, is het belangrijk om te weten waar de pijnpunten zitten en wat nu bepaald dat Systems Engineering handig of nuttig is om te gebruiken. Om meer gevoel hierbij te krijgen en ook een beter beeld te krijgen wat het project nu precies behelst, is een aantal mensen geïnterviewd. Deze mensen zijn allen projectmedewerkers betrokken bij HVVOS. Het betreft zowel mensen werkzaam bij Rijkswaterstaat, Homij, ABB en Grontmij om een meer volledig beeld te krijgen. De indeling van het interview is grotendeels gelijk aan het format wat opgesteld is (paragraaf 6.2.4). Allereerst zijn er wat algemene vragen gesteld om erachter te komen wat de achtergrond is van de geïnterviewde en wat zijn begrip is van het onderwerp Systems Engineering. Daarnaast zijn er wat vragen gesteld over het project HVVOS. Zonder de geïnterviewde in een bepaalde richting te sturen wordt gevraagd naar welke onderdelen nuttig waren en waarom. Hierna is de format besproken. De format is per onderdeel doorlopen. Door gericht vragen te stellen maar ook de geïnterviewde te laten praten, kon een beeld gevormd worden van de pijnpunten en de frustraties. Er was dus geen sprake van een vastomlijnde vragenlijst, maar meer een oriënterend gesprek met wat onderwerpen die aan bod kwamen en waarover vragen werden gesteld. De onderdelen die besproken zijn: Algemeen Systems Engineering HVVOS Specifiek Systeembeschrijving Eisenanalyse Functieanalyse Ontwerpafweging Ontwerp Raakvlakken RAMS (reliability, availability, maintainability & safety) Verificatie Relevante uitkomsten De resultaten van de interviews zijn kort en bondig weergegeven in bijlage 2. Hieronder worden een aantal interessante uitspraken en conclusies vanuit de interviews opgesomd die input leveren voor de enquête. Algemeen; Systems Engineering Wanneer de opdrachtgever al een oplossing in zijn hoofd heeft, dan is het niet zinvol om het project functioneel te beschrijven. De opdrachtgever kan dan beter opschrijven wat hij precies Hoofdstuk: HVVOS 49

50 wil hebben in plaats van proberen de functies en eisen zo te formuleren dat eruit komt wat hij in zijn hoofd had zitten. Met het risico dat dat er toch niet precies uitkomt. Installatietechniek bepaalt een groot gedeelte van het project HVVOS. Een kenmerk hiervan is dat er voor veel problemen standaard oplossingen zijn. Systems Engineering is daarom niet zinvol. Ook heeft het te renoveren systeem zoveel functies dat het gebruik van Systems Engineering het ontwerpproces te omvattend en complex maakt. De meerwaarde van Systems Engineering zit in de beheersbaarheid van een project en niet in de specifieke werkwijze. Het toepassen van Systems Engineering kost veel tijd en geld. Voor kleinere bedrijven is dit moeilijk vrij te maken. Algemeen; HVVOS Er is allereerst een aanbieding gedaan om het project HVVOS gegund te krijgen. Binnen deze aanbieding is een ontwerp gemaakt en hiervoor zijn keuzes gemaakt. Op basis daarvan wordt het project wel of niet gegund aan de aanbiedende partij. Deze keuzes staan echter niet goed op papier, waardoor de afwegingen opnieuw gemaakt moeten worden. Dit is dubbel werk. Specifiek; systeembeschrijving In de systeembeschrijving moet de huidige en gewenste situatie besproken worden. Het verschil hiertussen bepaalt je projectkader. Deze onderdelen moeten dan ook duidelijk verwoord worden. Hierbij moet men zich niet beperken tot de informatie aangeleverd door de opdrachtgever, maar de informatie moet aangevuld worden. Het is daarbij belangrijk dat men kennis krijgt van het te renoveren systeem en inziet wat er allemaal moet gebeuren. Specifiek; eisenanalyse In een eisenanalyse moeten niet alleen maar de eisen van de opdrachtgever herhaald worden. Er moet gekeken worden naar het niveau, herkomst en de formulering van de eis. Is het dan een eis aan het gehele systeem of aan een klein onderdeel en is het dan een randvoorwaarde, prestatie-eis of eigenlijk een wens van de opdrachtgever of de belanghebbenden? Een eis aan een systeem beschrijft wat het systeem moet kunnen en waar het aan moet voldoen. Wanneer de eisen te gedetailleerd zijn en op een laag niveau zijn, beschrijven ze al een oplossingsrichting. Eisen kunnen je dan beïnvloeden in het denken in een bepaalde richting. Specifiek; functieanalyse Ongeacht de projectkenmerken, een functieanalyse is altijd zinvol en is altijd nodig. Dit omdat de functievervullers of objecten direct verband houden met de functies die een systeem moet vervullen. Met een vage omschrijving van het te bouwen of renoveren systeem is er veel ruimte voor een ontwerpteam. Wanneer eisen, wensen en randvoorwaarden duidelijk en precies geformuleerd worden, is de kans groter dat de opdrachtgever krijgt wat hij voor ogen had. Volgens de theorie worden eisen aan functies gesteld, maar in de praktijk is het makkelijker om eisen aan de functievervullers te stellen. Daaraan zijn ze ook gekoppeld. Eisen zeggen iets over objecten. Specifiek; ontwerpafweging Wanneer er door de opdrachtgever veel eisen, wensen en randvoorwaarden worden gesteld en daarnaast nog eisen aan de procesgang zijn geformuleerd, blijft er weinig keuzeruimte over in de ontwerpafweging. Weinig alternatieven voldoen aan alle eisen. Afwegingen zijn dan beperkt zinvol. Er komen sporadisch verrassende oplossingen uit de ontwerpafweging (met gebruik van de methode Systems Engineering). Ontwerpers met veel ervaring weten welke oplossingen werken en bepaalde problemen oplossen. Door een andere benadering worden deze oplossingen niet anders. Hoofdstuk: HVVOS 50

51 De methode Systems Engineering levert een aantal voordelen op, maar kost daarnaast ook erg veel tijd. Voorlopig wegen de voordelen die het biedt niet op tegen de tijd die het kost om deze methode te hanteren. Specifiek; RAMS Doordat een ontwerp moet voldoen aan een bepaalde beschikbaarheid en betrouwbaarheid, is het belangrijk het juiste alternatief te kiezen wat deze criteria betreft. Daarnaast zijn er nog vele andere criteria, maar de beschikbaarheid en betrouwbaarheid bepalen vaker dat er gekozen moet worden voor een ander alternatief. Dit zijn keiharde eisen terwijl andere criteria meestal wat ruimer zijn. Specifiek; raakvlakken Raakvlakken kunnen verdeeld worden in externe en interne raakvlakken. Wanneer men als team bezig is aan een ontwerp van een bepaald systeem, dan is het expliciet formuleren van interne raakvlakken onzinnig. Men werkt samen en draagt verantwoordelijkheid voor het voldoen aan de eisen en functioneren van het te ontwerpen systeem, deze raakvlakken worden dus al bekeken. 6.4 Terugkoppeling onderzoeksvraag In dit hoofdstuk is antwoord gegeven op onderzoeksvraag 2. In deze paragraaf is het antwoord nogmaals weergegeven. Bij deelvraag a en de hoofdvraag was het niet mogelijk om een goed beknopt antwoord te geven en is er verwezen naar een paragraaf in het hoofdstuk. Onderzoeksvraag: Hoe wordt er binnen het project HVVOS gedacht over en omgegaan met Systems Engineering en haar onderdelen? Zie hiervoor paragraaf en bijlage 1. a. Wat behelst het project HVVOS? HVVOS is een renovatieproject van de Haringvliet en Volkerak sluizencomplexen. Voor verdere beschrijving wordt verwezen naar paragraaf b. Welke onderdelen van Systems Engineering worden onderscheiden in dit project? De volgende onderdelen van Systems Engineering worden in dit rapport onderscheiden: Eisenanalyse Functieanalyse Ontwerpafweging Ontwerp RAMS Raakvlakken Verificatie c. Welke projectkenmerken heeft dit project? De volgende projectkenmerken worden in dit rapport onderscheiden: Fase in het V-model; renovatie Soort project; installatietechniek Aantal disciplines Kosten Projectgrootte Tijd Complexiteit Hoofdstuk: HVVOS 51

52 d. Welke interviewvragen dienen gesteld te worden om het huidige begrip en de omgang met SE binnen het project te onderzoeken? Er zijn geen specifieke interviewvragen gesteld, maar er is een algemene opzet gemaakt voor de gesprekken; Algemeen Systems Engineering HVVOS Specifiek Systeembeschrijving Eisenanalyse Functieanalyse Ontwerpafweging Ontwerp Raakvlakken RAMS Verificatie Hoofdstuk: HVVOS 52

53 7 Afwegingen vanuit de casestudy In dit laatste hoofdstuk van deel B; casestudie renovatie Haringvliet en Volkerak sluizencomplexen wordt onderzoeksvraag 4b beantwoord. Dit gebeurt op basis van de voorgaande hoofdstukken in dit deel. Onderzoeksvraag 4b: Welke relaties tussen projectkenmerken en (onderdelen van) Systems Engineering zijn er uit de interviews af te leiden? Onderdeel Wel bij Niet bij Zorgt voor Zorgt niet voor Twijfel bij Systems Engineering Keuzevrijheid Vaste oplossingen Beheersbaarheid Installatietechniek Risico's Kleinere bedrijven Afwegingen bij routineklussen Kleine projecten Functieanalyse Altijd Renovatie - vervangen functievervullers Randvoorwaarden Ontwerpafweging RAMSanalyse Tabel 7.1: afwegingen vanuit de casestudie Verrassende oplossingen Transparantie Voordelen die opwegen tegen tijd en geld Overtuiging Deze tabel kan als volgt gelezen worden: Het onderdeel uit kolom 1, bijvoorbeeld Systems Engineering,: Kan wel toegepast worden bij alle voorwaarden in kolom 2. Kan niet toegepast worden bij alle voorwaarden in kolom 3 Zorgt voor alle eigenschappen in kolom 4 Zorgt niet voor alle eigenschappen in kolom 5 Kolom 6, twijfel bij, wil zeggen dat er sterke twijfel bestaat over het nut van het toepassen van het onderdeel (kolom 1) bij de voorwaarden of eigenschappen in kolom 6 genoemd. Nu staat er niets in deze kolom, maar als daar beheersbaarheid zou staan, dan is er sterke twijfel of Systems Engineering als discipline zorgt voor beheersbaarheid. In de interviews is ontzettend veel informatie gegeven over het functioneren van Systems Engineering binnen het project HVVOS. Helaas is een groot gedeelte niet van toepassing op dit onderzoek, maar het kan wel input leveren voor verder onderzoek. Wat uit bovenstaande tabel, 7.1, valt af te lezen is dat men overwegend negatief was over de methode Systems Engineering en haar onderdelen. Ook zitten er tegenstrijdigheden in de tabel. Een functieanalyse moet altijd gedaan worden, maar moet niet gedaan worden wanneer het gaat om een renovatieproject en/of het vervangen van functievervullers. Deze resultaten en tegenstrijdigheden worden in de enquête (deel C) uitgevraagd om duidelijkheid te krijgen over de toepassingsmogelijkheden en eigenschappen van Systems Engineering en haar onderdelen. Hoofdstuk: Afwegingen vanuit de casestudy 53

54

55 Deel C; Enquête

56

57 8 Opzet enquête 8.1 Doel In deel A is de theorie besproken, vervolgens is in deel B gekeken naar een project HVVOS om erachter te komen hoe daar omgegaan werd en gedacht werd over Systems Engineering. Beide delen leveren informatie wat verwerkt wordt in een enquête. Deze enquête wordt uitgezet op internet en een ieder die ervaring heeft met Systems Engineering kan deze invullen. Dit hoofdstuk gaat over de opzet van de enquête. Hierin wordt onderzoeksvraag 3 beantwoord; Welke vragen dienen gesteld te worden in de enquête om conclusies te kunnen trekken over de toepassing van Systems Engineering in relatie tot projectkenmerken? Dit hoofdstuk wordt niet afgesloten met een terugkoppeling naar de onderzoeksvraag, aangezien het antwoord niet beknopt weer te geven is. 8.2 Opzet enquête Variabelen De enquête bestaat uit 153 stellingen en vragen. Deze stellingen zijn onderverdeeld in een aantal onderwerpen. Deze onderwerpen worden beschreven, volgens de statistiek (Moore & McCabe, 2005) als variabelen. Er wordt onderscheid gemaakt in typen variabelen. Er zijn zogenaamde onafhankelijke variabelen en afhankelijke variabelen. Onafhankelijke variabelen zijn variabelen die worden gebruikt om afhankelijke variabelen te voorspellen. Het zijn min of meer vaste kenmerken zoals opleiding, organisatie waar men werkzaam is en Systems Engineering ervaring. Binnen de enquête vallen de vragen die betrekking hebben op onafhankelijke variabelen onder algemene vragen. Daar tegenover hebben afhankelijke variabelen waarden die van deze onafhankelijke variabelen afhankelijk kunnen zijn. Door afhankelijke variabelen met onafhankelijke variabelen te vergelijken kan wellicht een causaal verband worden blootgelegd. (Moore & McCabe, 2005). Binnen de enquête gaat het om de volgende variabelen: Onafhankelijke variabele Organisatie Opleidingsniveau Werkervaring Projectervaring Soort projecten Omvang projecten SE ervaring Projecten naast elkaar HVVOS Tabel 8.1: variabelen Afhankelijke variabele Mening over: Systems Engineering (21 deelvragen) Systeembeschrijving (16 deelvragen) Eisenanalyse (16 deelvragen) Functieanalyse (23 deelvragen) Ontwerpafweging (12 deelvragen) Ontwerp (3 deelvragen) Raakvlakken (15 deelvragen) RAMS (15 deelvragen) Verificatie (15 deelvragen) Vraagstelling en beantwoording De enquête is opgesteld met stellingen. Deze stellingen kunnen beantwoord worden met 1 = helemaal mee oneens, 2 = mee oneens, 3 = neutraal, 4 = mee eens en 5 = helemaal mee eens. Bij elke vraag is bewust gekozen voor een 5-puntsschaal. Het betreft hier een kwalitatieve enquête. Er zitten slechts een klein aantal kwantitatieve vragen bij. Bij stellingen die vragen naar iemands mening is het niet zinvol om meer keuzeruimte te geven dan deze 5 mogelijkheden. Buiten dat is het verschil tussen helemaal mee eens en mee eens ook kwalitatief en niet met een waarde aan te geven. Wanneer een Hoofdstuk: Opzet enquête 57

58 7-puntsschaal zou worden gebruikt, is het nog lastiger om alle antwoorden te vergelijken omdat het ook persoonsafhankelijk is of men in uitersten of gemiddelden antwoordt. Een tweede reden voor het gebruiken van een 5-puntsschaal is de uniformiteit. Alle vragen kunnen beantwoord worden met dezelfde opzet, dit zorgt ervoor dat de respondenten de enquête relatief snel kunnen doorlopen. Er hoeft niet elke keer opgelet te worden op de beantwoording van de vragen omdat deze bij (bijna) elke vraag hetzelfde is Enquête vragen In deze paragraaf worden de enquêtevragen besproken. Een aantal vragen komen terug bij elk onderdeel, andere zijn geformuleerd omdat deze punten omhoog kwamen bij de interviews, gesprekken of literatuur. Bij elk nieuw onderdeel is wordt ook een korte definitie of omschrijving gegeven. De gehele enquête is te vinden in bijlage 3, de verantwoording van de gestelde vragen in bijlage 4. Algemeen De algemene vragen zijn gesteld om causaal verband aan te kunnen tonen mocht het nodig zijn. In principe is het voldoende om de gemiddelden van de resultaten te weten. Wanneer alle respondenten binnen een redelijke spreiding van het gemiddelde zitten dan kan geconcludeerd worden dat het gemiddelde de algemeen geldende mening is. Dan is het niet nodig om een splitsing te maken tussen bijvoorbeeld of men bij de aannemer werkt of bij de opdrachtgever. De antwoorden zullen dan niet verschillen. Voor vragen en stellingen waarbij de spreiding zo groot is dat het gemiddelde niet als algemeen geldende mening kan worden gezien, wordt een vergelijking gemaakt met een aantal onafhankelijke variabelen om toch nog een conclusie te kunnen trekken. Er is een vraag binnen de algemene vragen die niet vanzelfsprekend is; Hoeveel projecten heeft u doorgaans naast elkaar lopen waarbij Systems Engineering wordt ingezet? Deze vraag komt uit de interviews. Door een geïnterviewde werd aangevoerd dat wanneer men meerdere projecten naast elkaar had lopen, er minder tijd aan lastige en complexe projecten wordt besteed. Het is dan immers makkelijk om je eigen prioriteiten te stellen en daardoor je aandacht te vestigen op makkelijkere of leukere taken. Wanneer men dan tegen problemen aanloopt binnen een project, bijvoorbeeld met de relatief nieuwe methode Systems Engineering, dan kan men geneigd zijn hier minder tijd in te steken. Ook heeft men met minder projecten naast elkaar meer tijd om zich te verdiepen in het groter geheel en de problemen die er spelen. Onderdelen Een aantal stellingen wordt bij meerdere onderdelen gesteld. Deze worden hier besproken. De systeembeschrijving wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Vaak wordt door de opdrachtgever in de vraagspecificatie omschreven welke resultaten zij willen zien en ook hoe zij deze gepresenteerd willen hebben en welke werkwijze hierbij hoort. Veel onderdelen worden dus specifiek vereist. Wat dan interessant is om te onderzoeken, is of deze onderdelen slechts uitgevoerd worden omdat dit gevraagd is of ook omdat men hier meerwaarde in ziet. Het is nodig om deze stap expliciet op te schrijven Ondanks dat de invulling van een bepaald onderdeel meerwaarde kan hebben, wil dit niet zeggen dat het altijd nodig is om deze stap expliciet op te schrijven en uit te werken. Soms kan wellicht volstaan worden met een beknopte samenvatting van de uitkomsten. Een systeembeschrijving moet gegeven worden ongeacht de complexiteit Ook bij weinig complexe projecten is een systeembeschrijving zinvol Een systeembeschrijving moet gegeven worden ongeacht de projectomvang Een systeembeschrijving moet gegeven worden ongeacht de planning Een systeembeschrijving moet gegeven worden ongeacht het aantal disciplines Hoofdstuk: Opzet enquête 58

59 Ook bij monodisciplinaire projecten is een systeembeschrijving zinvol Bovenstaande stellingen gaan over vier projectkenmerken (complexiteit, projectomvang, tijd en aantal disciplines), daarnaast staan er twee controlevragen in. Zoals in het hoofdstuk projectkenmerken (H4) al besproken is, kunnen deze kenmerken invloed hebben op in te vullen Systems Engineering onderdelen. Er wordt een aantal stellingen weergegeven in de enquête die ingaan op verschillende projectkenmerken. Onder andere tijd, kosten, complexiteit, soort project, afhankelijkheid, belanghebbenden, aantal disciplines, fase in het V-model en innovatie. Een aantal van deze stellingen komt ook mede voort uit de resultaten van de interviews, waar ook ingegaan is op de projectkenmerken. Deze resultaten worden niet per onderdeel besproken. Alleen de vragen die niet op basis van de projectkenmerken hierboven genoemd, gesteld zijn worden kort genoemd. De andere vragen zijn te vinden in bijlage 2 en 3. Systems Engineering Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: SE biedt structuur SE biedt een controlemiddel ten behoeve van kwaliteit SE zorgt voor verrassende oplossingen Deze stellingen komen voort uit de resultaten van de interviews (H6). Daarnaast bevinden zich in dit onderdeel nog een drietal vragen die niet beantwoord kunnen worden met helemaal mee oneens tot helemaal mee eens, zij hebben vijf keuzemogelijkheden die hieronder zijn weergegeven bij de vragen. SE moet toegepast worden voor een projectgrootte in de ontwerpfase vanaf o <1.000, , , , > SE moet toegepast worden vanaf een projectomvang van o <10 medewerkers, 15, 20, 25, >30 medewerkers SE moet toegepast worden bij een projectduur in de ontwerpfase vanaf o <1 week, 1 maand, 6 maanden, 1 jaar, >1,5 jaar De vragen komen voort uit de projectkenmerken en voor de antwoorden is beroep gedaan op de kennis van de afstudeercommissie 3. Systeembeschrijving Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: De verschillen tussen de huidige en gewenste situatie moeten duidelijk in beeld komen Een systeembeschrijving geeft aan wat er moet veranderen Deze stellingen komen voort uit de resultaten van de interviews (H6). Een systeembeschrijving geeft een beeld van het project Een systeembeschrijving geeft aan welke functies een complex heeft Een systeembeschrijving geeft relaties weer Deze stellingen komen voort uit de theorie (In t Veld, 1998) Een systeembeschrijving beschrijft de functies van een project Deze stelling komt voort uit gesprekken 3 3 Mondelinge communicatie met de afstudeercommissie Hoofdstuk: Opzet enquête 59

60 Eisenanalyse Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: Een eisenanalyse bevooroordeelt je in het denken in een bepaalde oplossingsrichting en moet dus na de ontwerpafweging gedaan worden Een opsomming van de eisen van Rijkswaterstaat is voldoende, er hoeft geen analyse gedaan te worden Eisen stellen zonder te sturen op een oplossingsrichting is onmogelijk Deze stellingen komen voort uit de resultaten van de interviews (H6). Hoe meer eisen er geformuleerd worden, des te minder ontwerpvrijheid heb je Hoe meer eisen je formuleert, des te kleiner is de kans dat je krijgt wat je verwacht Elke eis heeft een topeis Deze stellingen komen voort uit de resultaten van de interviews en gesprekken 4 Functieanalyse Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: Functioneel beschrijven is niet altijd beter. Hoe preciezer je dingen formuleert, hoe groter de kans dat je krijgt wat je hebben wilt. Als je weet wat je wilt hebben, moet je het niet functioneel beschrijven, maar gewoon met eisen en wensen. Een functieanalyse is niet zinvol als er al functievervullers zijn, die alleen niet meer voldoen Een functie die niet goed meer vervuld wordt door zijn functievervuller, moet opnieuw vervuld worden. Daarbij fungeren de andere al vervulde of nog te vervullen functies als randvoorwaarden Een functieanalyse kan niet gemaakt worden zonder dat het ontwerp voor handen is Eisen worden aan functievervullers gesteld Deze stellingen komen voort uit de resultaten van de interviews (H6). Een functieanalyse wordt gedaan om innovatieve oplossingen in de hand te werken Eisen worden aan functies gesteld Functionele eisen zijn oplossingsvrij Een functionele eis beschrijft de prestatie van een functie Deze stellingen komen voort uit de theorie en gesprekken 4. Een functieanalyse wordt gedaan om ervoor te zorgen dat er geen gaten vallen in het eisenpakket Deze stelling komt voort uit de kenmerken van het project HVVOS. Ontwerpafweging Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft Ontwerpafwegingen van specifieke installatietechnische oplossingen zijn niet zinvol Er wordt door Rijkswaterstaat zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn 4 Mondeling gesprekken met de afstudeercommissie Hoofdstuk: Opzet enquête 60

61 Het gaat slechts sporadisch om verassende oplossingen Deze stellingen komen voort uit de resultaten van de interviews en de theorie over projectkenmerken. De voordelen die de ontwerpafwegingen opleveren, wegen niet op tegen de tijd die het kost Keuzes zijn al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om het hier nog een keer te doen 80% van de ontwerpen in de installatietechniek zijn nu hetzelfde als 10 jaar geleden De 20% die verschilt in de ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen Deze stellingen komen voort uit de resultaten van de interviews (H6). Ontwerp Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: Op basis van een objectenboom kan gebouwd worden Een objectenboom formuleren is gelijk aan ontwerpen Deze stellingen komen voort uit gesprekken 5 Voor ontwerpers is het net zo makkelijk om in plaats van alleen maar het object ook een specificatie op te schrijven, het zit toch in het hoofd. Deze stelling komt voort uit de resultaten van de interviews (H6). Raakvlakken Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: Raakvlakken moeten afgestemd worden tussen de verschillende systemen en disciplines, alleen opschrijven per systeem is zinloos Interne raakvlakken zijn onzinnig, want deze zitten binnen een ontwerp waar je als team mee bezig bent en verantwoordelijk voor bent Raakvlakken moeten weergegeven worden in een tekening Deze stelling komt voort uit de resultaten van de interviews (H6). Het formuleren van raakvlakken gebeurt op basis van een objecten structuur Het formuleren van raakvlakken gebeurt op basis van een ontwerp Deze stellingen komen voort uit gesprekken 5. RAMS Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: RAMS bepaalt vaker dat er andere alternatieven gezocht en gekozen moeten worden dan de selectiecriteria in de ontwerpafweging RAMS is weinig overtuigend want het is slechts statistiek RA(MS) is onnodig duur Voor een goede RA(MS) analyse is een volledige systeembeschrijving nodig Deze stelling komt voort uit de resultaten van de interviews (H6). 5 Mondelinge communicatie met de afstudeercommissie Hoofdstuk: Opzet enquête 61

62 Als RA(MS) gecheckt is en voldoet dan ben ik volledig Deze stelling komt voort uit gesprekken 6. Verificatie Naast de stellingen die voortkomen uit de projectkenmerken en de vragen die in elk onderdeel worden gesteld, zoals hierboven is weergegeven, worden de volgende stellingen in de enquête verwerkt: Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan Verificatie is, in de huidige vorm, maar beperkt zinvol. Het is nog steeds lastig grijpbaar of ontwerpen nu echt aan de eisen voldoen Deze stelling komt voort uit de resultaten van de interviews (H6). Verificatie is de ontwerpcontrole De opdrachtgever is verantwoordelijk voor het juist formuleren van de topeis Deze stelling komt voort uit gesprekken 6. 6 Mondelinge communicatie en de afstudeercommissie Hoofdstuk: Opzet enquête 62

63 9 Enquête resultaten 9.1 Doel In het vorige hoofdstuk is de enquête besproken met alle onderdelen die daarin zitten. Daarnaast is uitgelegd wat het doel is van de enquête. In dit hoofdstuk worden de verkregen resultaten besproken. Belangrijk gegeven is hierbij dat het gaat om de resultaten van slechts 34 respondenten. Dit zijn te weinig respondenten om te kunnen concluderen dat de conclusies algemeen geldend zijn, daarnaast zijn de resultaten beperkt statistisch getoetst. De conclusies hebben veelal betrekking op interpretaties van de grafieken en gemiddelde waarden. Omdat het gaat om 153 vragen en stellingen zijn er enorm veel resultaten. Niet alles wordt in dit hoofdstuk besproken. Alleen de opvallende resultaten worden behandeld. Voor meer resultaten wordt verwezen naar bijlage 5, 6 en 7. De eerste paragraaf (9.1) bespreekt algemene zaken over het uitvoeren van de enquête. Daarna worden de resultaten besproken. De resultaten zijn op twee manieren verwerkt; met gemiddelden en kruistabellen. Deze manieren worden in onderstaande paragrafen besproken. Allereerst worden in 9.2 de gemiddelde resultaten gegeven. Alle respondenten zijn hier als één groep genomen en van de resultaten van deze groep zijn figuren gemaakt met gemiddelde waarden. De resultaten worden besproken per vraag of onderwerp. Hieruit komt al veel informatie zoals de mening over bepaalde System Engineering onderdelen, maar ook algemenere dingen als werkervaring, opleidingsniveau en ervaring met Systems Engineering. Alle gemiddelde waarden staan weergegeven in bijlage 6. Door alleen te kijken naar gemiddelden, blijft er veel informatie besloten in de uitkomsten. Op een aantal vragen wordt verschillend geantwoord. Mensen zijn het niet met elkaar eens bij bepaalde stellingen. Het is interessant om dan te kijken of dat bijvoorbeeld verband heeft met organisatie waarin de respondent werkt of de mate van ervaring met Systems Engineering die hij heeft. Hiervoor worden kruistabellen gebruikt. Hierin worden onafhankelijke en afhankelijke variabelen vergeleken en gekeken of deze verband met elkaar hebben (9.3). Meer resultaten staan weergegeven in bijlage 7. In de laatste paragraaf (9.4) worden de conclusies vergeleken en opgesomd. De conclusies berusten alleen op de resultaten van de enquête. Theorie en de interviewresultaten worden in latere hoofdstukken betrokken. In dit hoofdstuk wordt antwoord gegeven op onderzoeksvraag 4c; Welke relaties tussen projectkenmerken en (onderdelen van) Systems Engineering zijn er uit de enquête af te leiden? In hoofdstuk 10 is het antwoord op deze vraag beknopt weergegeven als conclusie van dit hoofdstuk. 9.2 Algemeen Respondenten Mogelijke respondenten zijn per benaderd en zijn dus niet volledig willekeurig gekozen. Tevens zijn de projectmedewerkers van HVVOS benaderd om de enquête in te vullen. In totaal hebben 42 respondenten de enquête ingevuld. Door bovengenoemde redenen zijn de personen die de enquête hebben ingevuld, gekleurd in hun mening. De resultaten binnen dit onderzoek zijn daardoor waarschijnlijk niet algemeen geldend. Ook speelt het aantal bruikbare enquêtes hierin mee. Van de 42 enquêtes zijn er 34 bruikbaar. Om de hieronder beschreven redenen. Een groot aantal enquêtes is niet volledig ingevuld. De webapplicatie slaat enquêtes die gestart zijn automatisch op. Het is voorgekomen dat men de enquête niet af heeft gemaakt. De gegevens van niet voltooide enquêtes zijn niet verwerkt. Hoofdstuk: Enquête resultaten 63

64 Een klein aantal enquêtes is niet serieus ingevuld. Er wordt door de respondenten bijvoorbeeld geen antwoord gegeven op de open vraag; Systems Engineering is voor mij? Ook is er meerdere malen achter elkaar bij verschillende onderdelen het antwoord neutraal gegeven. Dit duidt erop dat men geen tijd of zin meer had om de enquête serieus in te vullen, maar deze wel af wilde maken. Het kan ook zijn dat deze respondent weinig tot geen ervaring heeft met Systems Engineering en de onderdelen, maar dit niet kenbaar heeft willen maken in de vragen naar ervaring. Een klein aantal respondenten spreekt zichzelf tegen in de antwoorden. Er zijn een 13-tal controlevragen gesteld. Dit wil zeggen dat meerdere malen eenzelfde soort vraag is gesteld in andere bewoording om te controleren of de antwoorden betrouwbaar zijn. Met tegenspreken wordt hier bedoeld een verschil in antwoorden met interval 2. Bijvoorbeeld mee eens tegenover mee oneens en niet helemaal mee oneens tegenover mee oneens (interval 1). Wanneer het verschil 1 stap is, kan dat te maken hebben met het gevoel dat een vraag bij een respondent oproept, wat ervoor zorgt dat men er toch helemaal mee (on)eens is in plaats van mee (on)eens. Het tegenspreken kan grofweg een gevolg zijn van per ongeluk verkeerd invullen of geen verstand van zaken hebben. Binnen deze definitie is het acceptabel dat men zichzelf één keer tegenspreekt (8% van de controlevragen). Een viertal respondenten spreken zich 2 maal tegen. Twee van deze respondenten doen dat bij een bepaald onderdeel, wat erop wijst dat ze daar (te) weinig verstand van hebben. Daarom is ook besloten deze twee respondenten binnen het onderzoek te laten vallen, alleen deze onderdelen te schrappen. De twee andere respondenten, die zichzelf tegenspraken bij verschillende onderdelen, zijn als onbruikbaar aangemerkt. Een tweetal respondenten gaf aan dat ze geen ervaring met Systems Engineering heeft. Daarmee wordt de enquête direct afgesloten Weggevallen vragen Bij welk soort projecten bent u voornamelijk betrokken? Bij deze vraag is een aantal keuzemogelijkheden gegeven, maar daarnaast ook een invuloptie gegeven wanneer het goede antwoord er niet bij staat. Deze invuloptie is door bijna iedereen gebruikt om alle mogelijke soorten projecten in op te schrijven. Dit zorgt ervoor dat er geen conclusie uit te trekken is en ook geen verbanden mee gelegd kunnen worden. Achteraf gezien had deze vraag beter uit een beperkt aantal soorten projecten kunnen bestaan en een optie anders, zonder invuloptie. [Onderdeel] wordt ingevuld omdat het vereist is Het gemiddelde van de antwoorden op deze vragen is slechts sporadisch betrouwbaar. Met een onbetrouwbaar gemiddelde wordt in dit hoofdstuk bedoeld, dat het gemiddelde niet de werkelijkheid beschrijft. De antwoorden zijn te divers om het gemiddelde hiervan als conclusie te gebruiken. Reacties die op deze vraag gekomen zijn, geven aan dat de respondenten deze vraag lastig te beantwoorden vonden. De meeste onderdelen zijn wel vereist maar worden ook ingevuld omdat deze meerwaarde hebben. Dan kan je de vraag op twee manieren beantwoorden, wat ook vaak gebeurde; helemaal mee eens, want het is inderdaad vereist of helemaal mee oneens want het biedt meerwaarde dus het werd niet alleen maar ingevuld omdat het vereist was. Hoeveel jaren projectervaring heeft u? Hierop wordt hetzelfde geantwoord als op de vraag hoeveel jaren werkervaring heeft u?. Werkervaring en projectervaring zijn dus uitwisselbaar. Hoofdstuk: Enquête resultaten 64

65 Het gehele onderdeel Ontwerp Er zijn drie vragen gesteld in dit onderwerp, maar het onderwerp staat niet ter discussie in de afwegingen. Het ontwerp is het doel van de ontwerpprocessen en documenten. Deze vragen dragen daarom niet bij aan het onderzoek en zijn uit de resultaten geschrapt. 9.3 Gemiddelden Bij het berekenen van de gemiddelden worden alle respondenten als een groep benaderd. Er wordt hier nog geen verschil gemaakt tussen bijvoorbeeld bij welke organisatie men werkt en of men veel of weinig Systems Engineering ervaring heeft. De gemiddelden zeggen iets over de mening die men heeft over bepaalde onderwerpen. Naast de gemiddelden wordt ook gekeken naar de spreiding van de antwoorden. Wanneer op een stelling gemiddeld genomen neutraal wordt geantwoord, kan dit betekenen dat veel respondenten neutraal als antwoord hebben gegeven, maar het kan ook zijn dat er gemiddeld genomen evenveel mensen er wel als niet mee eens zijn. Het gemiddelde zegt dus niet per definitie iets over de algemeen geldende mening. Wanneer de spreiding groot is van de antwoorden en het gemiddelde dan dicht bij 3 (neutraal) uitkomt, duidt dit erop dat men niet eensgezind was. Dit is dus een belangrijk gegeven om in de gaten te houden. In de figuren zijn af en toe rode balken te zien. Deze staan voor resultaten die niet betrouwbaar worden geacht. Dit zijn resultaten waarbij de spreiding van de antwoorden groter is dan 1 en het gemiddelde een zodanige waarde heeft, dat er niet geconcludeerd kan worden dat een overduidelijke meerderheid het gemiddelde representeert. Voor een meer uitgebreide uitleg wordt verwezen naar paragraaf 9.4. Uitspraken over gemiddelden die niet betrouwbaar worden geacht zijn aangegeven met een sterretje (*) en worden nader bekeken in paragraaf 9.4. In deze paragraaf worden overigens niet alle resultaten besproken, maar alleen de relevante uitkomsten voor dit onderzoek. De resultaten per vraag en de gemiddelden zijn weergegeven in bijlage 4 en Algemeen Van alle algemene vragen wordt er hier voornamelijk gekeken naar vier; In welke organisatie bent u werkzaam? Wat is uw hoogst genoten opleiding? Hoeveel ervaring heeft u met Systems Engineering? Hoe lang bent u betrokken geweest bij HVVOS? Van alle respondenten is 9 % werkzaam bij de aannemer, 62 % bij een ingenieursbureau, 15 % bij een opdrachtgever en 15% bij een consultant. Respondenten worden gezien als vertegenwoordigers van hun organisatie. Ondanks dat er vanuit de aannemer maar 3 bruikbare enquêtes zijn ingevuld, worden de antwoorden wel als representatief vanuit de aannemer gezien. Figuur 9.1: organisatie Figuur 9.2: opleiding In opleidingsniveau verschillende respondenten niet zoveel, iedereen is hoger opgeleid. 38 % heeft een afgeronde HBO opleiding, 59 % een WO opleiding en 3 % zelfs WO+. Hoofdstuk: Enquête resultaten 65

66 Figuur 9.3: Systems Engineering De ervaring met Systems Engineering varieert sterk. Ondanks dat de Leidraad SE (Rijkswaterstaat, ProRail, 2007) pas in april 2007 is geïntroduceerd, heeft 56% van de respondenten al meer dan 2 jaar ervaring met de methode. In deze figuur staan ook 2 respondenten met geen Systems Engineering ervaring. Tot deze vraag hebben zij de enquête ingevuld, hierna is voor hen de enquête afgesloten. Figuur 9.4: HVVOS De interviews zijn gehouden met projectmedewerkers van het project Renovatie Haringvliet en Volkerak Sluizencomplexen. Om te kijken of dit duidelijk invloed heeft op de resultaten, is deze vraag opgenomen. Nu kan bij vragen met een onbetrouwbaar gemiddelde gekeken worden of er een verband bestaat tussen die stelling en het wel of niet betrokken zijn bij het project HV- VOS. Hoofdstuk: Enquête resultaten 66

67 9.3.2 Systems Engineering Onderstaand figuur, 9.5, geeft alle stellingen weer over Systems Engineering die te beantwoorden waren met helemaal mee oneens (1) tot helemaal mee eens (5). Te zien is dat er niet veel stellingen heel positief of negatief uitkomen. Dit vertelt al dat het een lastig onderwerp is en de meningen vaak niet heel uitgesproken zijn. De met rood aangegeven balken zijn stellingen waarbij de spreiding van de antwoorden zodanig groot is, dat het gemiddelde niet als betrouwbaar kan worden aangemerkt. Deze stellingen worden in de paragraaf kruistabellen verder behandeld. Figuur 9.5: gemiddelden Systems Engineering Hoofdstuk: Enquête resultaten, Gemiddelden, Systems Engineering 67

68 Binnen dit onderdeel is ook een drietal vragen gesteld met kwantitatieve antwoord mogelijkheden. Ongeveer 63% van de respondenten vindt dat Systems Engineering moet worden toegepast voor een projectgrootte in de ontwerpfase vanaf euro. Figuur 9.6: aantallen projectgrootte Meer dan 50% van de respondenten vindt dat Systems Engineering moet worden toegepast vanaf een projectomvang van minder dan 10 projectmedewerkers. Het aantal projectmedewerkers is kennelijk minder relevant voor het wel of niet toepassen van Systems Engineering dan projectgrootte of projectduur. Figuur 9.7: aantallen projectomvang Figuur 9.8: aantallen projectduur 44% van de respondenten vindt dat Systems Engineering al moet worden toegepast bij een projectduur (in de ontwerpfase) van 1 maand of korter. 80% van de respondenten vindt dit bij 6 maanden. De volgende conclusies kunnen uit deze figuren en resultaten getrokken worden: Systems Engineering is volgens de respondenten zinvol om toe te passen bij nieuwbouwprojecten, maar over het nut bij renovatie projecten zijn de resultaten onbetrouwbaar.* Systems Engineering moet volgens de respondenten toegepast worden wanneer projecten multidisciplinair zijn, veel belanghebbenden betrokken zijn of er veel tegenstrijdige belangen zijn, projectonderdelen afhankelijk van elkaar zijn, het installatietechnische en/of grond-, wegen waterbouw projecten betreft. Systems Engineering komt volgens de respondenten de kwaliteit van eindproduct ten goede. Systems Engineering reduceert op dit moment niet de benodigde tijd. Het gemiddelde antwoord is 2.53 dat wil zeggen tussen mee oneens en neutraal in. Dit suggereert dat het gebruik van Systems Engineering ook niet veel meer tijd vergt. Daarnaast is het antwoord op de stelling of Systems Engineering beheersbaarheid in tijd en geld biedt niet betrouwbaar.* Systems Engineering maakt het werk niet eenvoudiger. Met wederom een score van 2.53 wordt gesuggereerd dat het er ook niet complexer van wordt. Bij de stelling Systems Engineering reduceert complexiteit is men het er niet over eens of dit nu het geval is. Deze twee resultaten spreken elkaar dus tegen.* Hoofdstuk: Enquête resultaten, Gemiddelden, Systems Engineering 68

69 Systems Engineering zorgt volgens de respondenten niet tot nauwelijks voor verrassende oplossingen (2.78) Systems Engineering biedt voornamelijk een controlemiddel ten behoeve van kwaliteit en biedt structuur. Volgens (meer dan) 50% van de respondenten moet Systems Engineering toegepast worden in de ontwerpfase bij een projectgrootte vanaf euro en een projectduur vanaf 6 maanden. Hoofdstuk: Enquête resultaten, Gemiddelden, Systems Engineering 69

70 9.3.3 Systeembeschrijving Figuur 9.9: gemiddelden systeembeschrijving De volgende conclusie kan uit figuur 9.9 getrokken worden: Een systeembeschrijving moet gegeven worden ongeacht de complexiteit, projectomvang, planning en aantal disciplines van een project. Dit wordt bevestigd door de controle vragen over de toepassing van een systeembeschrijving bij weinig complexe en monodisciplinaire projecten. Hoofdstuk: Enquête resultaten, Gemiddelden, Systeembeschrijving 70

71 9.3.4 Eisenanalyse Figuur 9.10: gemiddelden eisenanalyse De volgende conclusies kunnen hieruit getrokken worden: De eisenanalyse moet altijd gegeven worden, omdat deze meerwaarde heeft, ongeacht de complexiteit, planning, projectomvang en aantal disciplines. Daarnaast moet het ook altijd expliciet opgeschreven worden. De eisenanalyse bevooroordeelt je niet in het denken in een bepaalde oplossingsrichting. Hoe meer eisen er geformuleerd worden, hoe minder ontwerpvrijheid je hebt. De respondenten zijn het niet eens met de stelling hoe meer eisen je stelt, des te kleiner is de kans dat je krijgt wat je verwacht. Eisen kunnen gesteld worden zonder te sturen in oplossingsrichting. Hoofdstuk: Enquête resultaten, Gemiddelden, Eisenanalyse 71

72 9.3.5 Functieanalyse Figuur 9.11: gemiddelden functieanalyse De volgende conclusies kunnen hieruit getrokken worden: De functieanalyse moet uitgevoerd worden ongeacht het aantal disciplines, maar bij de uitvoering ongeacht de complexiteit, projectomvang en planning zijn de resultaten onbetrouwbaar*. Ook al is er geen eenduidig antwoord gegeven op het geven van een functieanalyse ongeacht de complexiteit, er kan wel geconcludeerd worden dat ook bij weinig complexe projecten deze analyse zinvol is om uit te voeren (3.46) Hoofdstuk: Enquête resultaten, Gemiddelden, Functieanalyse 72

73 De antwoorden op de stelling een functieanalyse moet altijd uitgevoerd worden, zijn niet eenduidig en daardoor niet betrouwbaar.* De functieanalyse werkt in meer of mindere mate innovatieve oplossingen in de hand. Als de opdrachtgever weet wat hij of zij wil hebben, dan moet dat met eisen en wensen omschreven worden en geen functieanalyse geëist worden. Het gemiddelde van de antwoorden is in mindere mate negatief bij de stelling een functieanalyse is niet zinvol als er al functievervullers zijn die niet meer aan de eisen voldoen. Een functieanalyse wordt in dit geval dus als wel zinvol beschouwd. Een functieanalyse kan gemaakt worden zonder ontwerp. Eisen worden aan functievervullers gesteld. Ook het gemiddelde van de stelling eisen worden aan functies gesteld is positief, dit is opmerkelijk, want je kunt geen eisen stellen aan functies en objecten. Het gemiddelde van de resultaten op de stelling eisen worden aan functies gesteld is echter niet betrouwbaar door de grote spreiding van de antwoorden.* Een functionele eis beschrijft de prestatie van een functie. Hoofdstuk: Enquête resultaten, Gemiddelden, Functieanalyse 73

74 9.3.6 Ontwerpafweging Figuur 9.12: gemiddelden ontwerpafweging De volgende conclusies kunnen hieruit getrokken worden: Het gemiddelde van de antwoorden op de stelling ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft is lichtelijk positief. Deze antwoorden zijn alleen niet betrouwbaar, omdat de spreiding van de antwoorden te groot is.* Ontwerpafwegingen van specifieke installatietechnische oplossingen zijn zinvol. Meningen verschillen ook sterk over de stelling er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerp afwegingen zonde van de tijd zijn.* De respondenten zijn neutraal over de stelling het gaat sporadisch om verrassende oplossingen De voordelen die ontwerpafwegingen bieden, wegen wel op tegen de tijd die het kost. Op de installatietechnische vragen wordt neutraal gereageerd, dit kan erop wijzen dat weinig mensen hier een mening over of ervaring mee hebben.* Hoofdstuk: Enquête resultaten, Gemiddelden, Ontwerpafweging 74

75 9.3.7 Raakvlakken Figuur 9.13: gemiddelden raakvlakken De volgende conclusies kunnen hieruit getrokken worden: Raakvlakken dienen te worden ingevuld ongeacht de complexiteit, planning, projectomvang en aantal disciplines van het project. Raakvlakken moeten afgestemd worden tussen verschillende systemen en disciplines. Alleen interne raakvlakken formuleren is zinloos. Interne raakvlakken zijn niet onzinnig. Het formuleren van raakvlakken gaat aan de hand van een objectenstructuur en in mindere mate ook aan de hand van het ontwerp. Of raakvlakken in een tekening weergegeven moet worden, wordt neutraal beantwoord, maar de antwoorden hebben echter een zodanige spreiding dat het gemiddelde niet betrouwbaar is.* Hoofdstuk: Enquête resultaten, Gemiddelden, Raakvlakken 75

76 9.3.8 RAMS analyse Figuur 9.14: gemiddelden RAMS De volgende conclusies kunnen hieruit getrokken worden: Betrouwbaarheid van de gemiddelden van de antwoorden op de stellingen een RAMS analyse moet gedaan worden ongeacht de complexiteit, projectomvang en planning is onvoldoende.* Op de stelling een RAMS analyse moet gedaan worden ongeacht het aantal disciplines neigt men naar positieve beantwoording. Er wordt lichtelijk positief geantwoord op de stelling RAMS bepaalt vaker dat er anderen alternatieven gezocht en gekozen moeten worden dan de selectiecriteria in de ontwerpafweging. RAMS analyse is overtuigend en niet slechts statistiek. RAMS is niet onnodig duur. Voor een goede RAMS analyse is een volledige systeembeschrijving nodig. Hoofdstuk: Enquête resultaten, Gemiddelden, RAMS analyse 76

77 9.3.9 Verificatie Figuur 9.15: gemiddelden verificatie De volgende conclusies kunnen hieruit getrokken worden: Verificatie moet uitgevoerd worden ongeacht de complexiteit, planning, projectomvang en aantal disciplines van het project. De verificatie moet altijd uitgevoerd worden. Of de verificatie door een onafhankelijk persoon moet worden gedaan, daarover verschillende de meningen te veel om op basis van het gemiddelde een conclusie te geven.* Er wordt lichtelijk negatief geantwoord op de stelling Verificatie is, in de huidige vorm, maar beperkt zinvol. Het is nog steeds lastig grijpbaar of ontwerpen nu echt aan de eisen voldoen. Verificatie wordt dus als wel zinvol gezien. Verificatie is ontwerpcontrole Hoofdstuk: Enquête resultaten, Gemiddelden, Verificatie 77

78 Afwegingen vanuit de gemiddelden In tabel 9.1 staan toepassingsmogelijkheden en eigenschappen van Systems Engineering die volgens de respondenten van de enquête gelden. Zoals ik paragraaf reeds vermeld zijn de conclusies die getrokken kunnen worden aan de hand van de enquête waarschijnlijk niet algemeen geldend, doordat het gaat om een vooraf geselecteerde en gekleurde groep respondenten. Daarnaast bestaat deze groep respondenten uit 34 mensen. Onderdeel Wel bij Niet bij Zorgt voor Zorgt niet voor Twijfel bij Systems Engineering Nieuwbouwprojecten Kwaliteit Reductie tijd Renovatieprojecten Multidisciplinaire projecten Controlemiddel tbv Verrassende oplossingen Beheersbaarheid in tijd en geld Veel belanghebbenden kwaliteit Veel tegenstrijdige belangen Structuur Reductie complexiteit afhankelijke projectonderdelen Installatietechnische projecten GWW projecten Projectgrootte ontwerpfase > euro Projectduur ontwerpfase vanaf 6 maanden Systeembeschrijving Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Eisenanalyse Projecten ongeacht Denken/sturen in Complexiteit Projectomvang bepaalde oplossingsrichting Planning Aantal disciplines Functieanalyse Projecten ongeacht Duidelijk beeld van OG Innovatieve oplossingen Aantal disciplines wat hij wil hebben Weinig complexe projecten Functievervullers die niet meer aan eisen Ontwerpafweging weinig tijd en geld (voordelen wegen op) Raakvlakken RAMSanalyse Verificatie Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Externe raakvlakken Interne raakvlakken Projecten ongeacht Aantal disciplines Volledige systeembeschrijving Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Tabel 9.1: afwegingen vanuit gemiddelden Deze tabel kan als volgt gelezen worden: Specifieke installatietechnische oplossingen het zoeken naar andere alternatieven (vaker dan dat selectiecriteria dat doen) Overtuiging Controle van ontwerp op eisen Het onderdeel uit kolom 1, in dit geval Systems Engineering,: Kan wel toegepast worden bij alle voorwaarden in kolom 2. Kan niet toegepast worden bij alle voorwaarden in kolom 3 Zorgt voor alle eigenschappen in kolom 4 Zorgt niet voor alle eigenschappen in kolom 5 Onnodige kosten Mate van complexiteit Projectomvang Planning Wel of niet altijd uitvoeren Afweging alleen zinvol wanneer het geen standaardsituaties betreft Weinig keuzeruimte maakt afweging zonde van tijd Het gaat sporadisch om verrassende oplossingen Weergave in tekening Ongeacht de complexiteit Ongeacht de projectomvang Ongeacht de planning Controle door onafhankelijk persoon Kolom 6, twijfel bij, wil zeggen dat er sterke twijfel bestaat over het nut van het toepassen van het onderdeel (kolom 1) bij de voorwaarden of eigenschappen in kolom 6 genoemd. In dit geval is er sterke twijfel of Systems Engineering zinvol is om toe te passen bij renovatieprojecten. Uit de gemiddelden komt naar voren dat Systems Engineering bijna altijd zinvol is. Er is twijfel bij de toepassing bij renovatieprojecten en of het zorgt voor reductie van complexiteit en beheersbaarheid in tijd en geld. Daarnaast zorgt Systems Engineering volgens de respondenten niet voor reductie van tijd en verrassende oplossingen. Hoofdstuk: Enquête resultaten, Gemiddelden, Afwegingen vanuit de gemiddelden 78

79 Ook over de onderdelen zijn de respondenten overwegend positief. De functieanalyse is beperkt zinvol wanneer de opdrachtgever een duidelijk beeld voor ogen heeft wat hij wil hebben en ontwerpafwegingen zijn niet nuttig bij specifieke installatietechnische oplossingen. De opmerkingen die in de kolom twijfel bij staan, worden verder onderzocht in paragraaf 9.4. Hoofdstuk: Enquête resultaten, Gemiddelden, Afwegingen vanuit de gemiddelden 79

80

81 9.4 Kruistabellen Door alleen naar de gemiddelden te kijken, worden veel resultaten verkregen maar blijven ook nog veel vragen open staan. Gemiddelden zijn alleen zinvol wanneer deze waarden ook betrouwbaar zijn, dus de spreiding van de antwoorden laag is. Van alle stellingen is het gemiddelde (M) de standaarddeviatie (s) bepaald. De standaarddeviatie zegt iets over de spreiding van de antwoorden. Het gebied tussen het gemiddelde min eenmaal de stan- daarddeviatie en het gemiddelde plus eenmaal de standaarddeviatie is 68,2 procent van alle antwoor- den. (M + s) (M s) = 68,2 % Figuur 9.16: normale verdeling (Moore & McCabe, 2006) De antwoordmogelijkheden van de stellingen zijn helemaal mee oneens (1) tot helemaal mee eens (5). Wanneer de standaarddeviatie 1 is, betekent ent dit dat 68,2% van de antwoorden tussen M-1 en M+1 zit. In een maximaal mogelijke spreiding van 4 is deze waarde van de standaarddeviatie te groot om betrouwbaar genoemd te worden, tenzij het gemiddelde heel positief of heel negatief is. Wanneer de spreiding groot is, maar het merendeel van de antwoorden positief (of negatief) is, dan wordt het gemiddelde betrouwbaar geacht. Het gaat binnen dit onderzoek immers om het beamen of ontkennen van de stellingen en niet de mate waarin dit gebeurt. Figuur 9.19 hieronder, geeft de geschetste situa- tie weer. Betrouwbaar positief resultaat Antwoordmogelijkheden Onbetrouwbaar resultaat Figuur 9.17: betrouwbaar en onbetrouwbaar resultaat met standaarddeviatie 1 In onderstaande voorbeelden wordt bovenstaande situatie nog iets verder uitgelegd. Stelling: Een eisenanalyse bevooroordeeld je in het denken in een bepaalde oplossingsrichting en moet dus na de ontwerpafweging gedaan worden Gemiddelde: 2,07 (mee oneens) Hoofdstuk: Enquête resultaten, Kruistabellen 81

82 Standaarddeviatie: 1,334 Antwoorden: 1. Helemaal mee oneens Mee oneens Neutraal Mee eens Helemaal mee eens - 2 Het overgrote deel van de antwoorden is negatief. Het gemiddelde van 2,07 kan dus als een betrouwbare uitkomst worden beschouwd. Het benadert de algemeen geldende mening van de respondenten. Wanneer de standaarddeviatie groter is dan 1 en het gemiddelde ligt rond het midden (3), dan duidt dit er veelal op dat er even vaak positief als negatief is gereageerd op een bepaalde stelling Stelling Eisen worden aan functies gesteld Gemiddelde: 3,00 (neutraal) Standaarddeviatie: 1,233 Antwoorden: 1. Helemaal mee oneens Mee oneens Neutraal Mee eens Helemaal mee eens - 2. Ondanks dat de meeste antwoorden positief uitvallen is het verschil heel klein. 9 respondenten antwoorden negatief waarvan 4 helemaal mee oneens. 11 respondenten beantwoorden de stelling positief waarvan (slechts) 2 helemaal mee eens. Dit gemiddelde wordt als onbetrouwbaar beschouwd. Er wordt in deze paragraaf gekeken of er een reden is voor deze diverse antwoorden. Het negatief of positief beantwoorden van een vraag kan afhankelijk zijn van werkervaring, Systems Engineering ervaring, organisatie waar diegene werkt en in het geval van mijn onderzoek soms ook het wel of niet betrokken zijn geweest bij het project HVVOS. Niet alle stellingen die in de vorige paragraaf rood zijn gemarkeerd in de figuren worden hieronder behandeld. Alle relevante kruistabellen kunnen gevonden worden in Bijlage 6. Daarnaast worden de afhankelijke variabelen, rood gekleurde stellingen, alleen vergeleken met de onafhankelijke variabelen; organisatie, SE ervaring en HVVOS. Alleen de vergelijkingen die iets toevoegen aan het onderzoek worden in deze paragraaf behandeld. Allereerst zijn er ook wat kruistabellen gemaakt met onafhankelijke variabelen om te kijken of daar verbanden in zijn te vinden Onafhankelijke variabelen Hoofdstuk: Enquête resultaten, Kruistabellen 82

83 Figuur 9.18: organisatie versus opleiding Duidelijk is te zien dat van onder naar boven gelezen het aandeel hoger opgeleiden daalt en het aandeel academici stijgt. Van nature is ons onderwijssysteem erop gericht in het hoger onderwijs zich meer op de praktijk te richten en in het academisch onderwijs meer op de theorie. De namen zeggen het al Hoger Beroeps Onderwijs en Wetenschappelijk Onderwijs. Vanuit deze gedachte wordt aangenomen dat dit onderscheid zich ook bij de respondenten bevindt. Verderop in het onderzoek kan af en toe de link worden gelegd tussen het geven van de antwoorden en het hebben van een meer theoretische of praktische achtergrond. Figuur 9.19: Organisatie versus SE ervaring De ervaring met SE is heel verschillend. Opvallend hierbij is wel dat de respondenten die de vragenlijst namens de opdrachtgever invulden niet de mensen zijn met de meeste ervaring met Systems Engineering. Relatief gezien zitten de meest ervaren mensen in de consultancy wereld. Daarna volgt de opdrachtgever en daarna de aannemer. Het ingenieursbureau is slecht te plaatsen in deze lijst, omdat hier respondenten zitten met ervaring van Systems Engineering van meer dan 4 jaar tot helemaal geen. Hoofdstuk: Enquête resultaten, Kruistabellen 83

84 Figuur 9.20: opleiding versus SE ervaring In kruistabel 9.20 is te zien dat hoe hoger men is opgeleid hoe meer ervaring men heeft met Systems Engineering. Wellicht valt dit te wijten aan de voorlopig voornamelijk theoretische invulling van Systems Engineering. En de meer theoretische achtergrond van academici Afhankelijke variabelen Alle afhankelijke variabelen worden vergeleken, in kruistabellen, met drie onafhankelijke variabelen. Te weten de organisatie waarin men werkzaam is, de Systems Engineering ervaring en de betrokkenheid bij het project HVVOS. Opleidingsniveau wordt niet meegenomen, aangezien reeds is aangetoond in dat organisatie en opleiding verband met elkaar hebben. Uitgebreide resultaten zijn te vinden in bijlage 7. Stellingen zonder duidelijk verband met onafhankelijke variabelen Hieronder staan alle stellingen opgesomd waarbij geen verband te onderscheiden was tussen de uitkomsten op de stelling en de onafhankelijke variabelen. De reden van de grote spreiding is niet te verklaren met de in de enquête gestelde vragen. De gemiddelde waarden die bij deze stellingen horen zijn aangenomen als resultaat. Waarbij 1 staat voor helemaal mee oneens, 2 voor mee oneens, 3 voor neutraal, 4 voor mee eens en 5 voor helemaal mee eens. Een systeembeschrijving geeft aan wat er moet veranderen (3,16) Een systeembeschrijving geeft relaties weer (3,31) Elke eis heeft een topeis (3,71) Een functieanalyse moet gegeven worden ongeacht de complexiteit (3,35) Een functieanalyse moet gegeven worden ongeacht de projectomvang (3,35) Een functieanalyse moet gegeven worden ongeacht de planning (3,42) Een functieanalyse moet altijd worden gedaan (3,23) Functionele eisen zijn oplossingsvrij (3,58) Keuzes zijn vaak al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om dat nog een keer te doen (2,93) De 20% die verschilt in ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen (2,92) Raakvlakken moeten weergegeven worden in een tekening (2,97) RAMS analyse moet gedaan worden ongeacht de complexiteit (3,38) RAMS analyse moet gedaan worden ongeacht de projectomvang (3,42) RAMS analyse moet gedaan worden ongeacht de planning (3,46) Stellingen met duidelijk verband met onafhankelijke variabelen De andere stellingen waarbij het resultaat, gezien de spreiding, onbetrouwbaar werd geacht, vertonen wel verband met een of meerdere onafhankelijke variabelen. SE biedt beheersbaarheid van het project in tijd en geld (3,09) Hoofdstuk: Enquête resultaten, Kruistabellen 84

85 Gekeken naar organisatie en SE ervaring, kan geconcludeerd worden dat SE beheersbaarheid biedt in tijd en geldt wanneer projectmedewerkers een aantal jaren ervaring hebben met SE of werken bij een opdrachtgever of consultancy. Wanneer men weinig ervaring met Systems Engineering heeft en voornamelijk praktisch bezig is, biedt het dit niet. SE reduceert complexiteit (2,84) Alleen respondenten met meer dan vier jaar SE ervaring of werkend bij de opdrachtgever of consultancy reageren positief op de stelling SE reduceert complexiteit. Het ingenieursbureau en de aannemer die binnen het ontwerptraject het meest met SE geconfronteerd worden, zijn het hier niet mee eens. SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt gegeven (3,12) SE heeft weinig nut bij projecten waarbinnen weinig vrijheid wordt gegeven volgens de aannemer, ingenieursbureau en consultancy. Alleen wanneer betrokkenen veel Systems Engineering ervaring hebben kan het nut hebben dit toe te passen op een dergelijk project. Volgens de opdrachtgever heeft het toepassen van SE bij weinig vrijheid echter wel nut. SE moet toegepast worden bij renovatieprojecten (3,12) Alleen de opdrachtgever en mensen met veel Systems Engineering ervaring zien nut in het toepassen van Systems Engineering bij renovatieprojecten. Eisen worden aan functies gesteld (3,00) Door de aannemer en respondenten die weinig ervaring met Systems Engineering hebben en betrokkenen bij HVVOS wordt instemmend gereageerd op de stelling. Ontwerpafwegingen zijn alleen zinvol wanneer het geen standaardsituaties betreft (3,11) In de praktijk is het niet zinvol om afwegingen te maken wanneer het standaardsituaties betreft. Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn (2,64) Alleen de aannemer en respondenten met weinig Systems Engineering ervaring vinden dat de afwegingen zonde van de tijd zijn wanneer er te weinig keuzeruimte geboden wordt. Als RAMS gecheckt is en voldoet, ben ik volledig (2,29) Opvallend is dat de opdrachtgever de enige organisatie is die het eens is met de stelling dat als RAMS gecheckt is en voldoet men volledig is. De andere organisaties niet. Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan (3,00) De opdrachtgever en aannemer zijn het redelijk eens dat dit door een onafhankelijke partij moet gebeuren. Volgens het ingenieursbureau en de consultancy moet dit echter niet door een onafhankelijk persoon gebeuren. Hoofdstuk: Enquête resultaten, Kruistabellen 85

86 9.4.3 Afwegingen vanuit de kruistabellen Bij deze afwegingen is gekeken vanuit de kant van het ingenieursbureau, aangezien Grontmij het bedrijf is waarbij dit onderzoek heeft plaatsgevonden en de resultaten voor haar nuttig moet zijn. Onderdeel Stelling Wel bij Niet bij Systems Engineering Beheersbaarheid in tijd en geld Veel SE ervaring Weinig SE ervaring Theorie Praktijk Reduceert complexiteit Veel SE ervaring Weinig SE ervaring Theorie Praktijk Nut bij projecten met weinig vrijheid Meer dan 4 jaar ervaring met SE Minder ervaring met SE Renovatieprojecten Veel ervaring met SE Minder ervaring met SE Functieanalyse Ongeacht complexiteit Altijd x Ongeacht projectomvang Altijd x Ongeacht planning Altijd x Altijd Altijd x Ontwerpafweging In standaardsituaties Theorie Praktijk Weinig keuzeruimte Ingenieursbureau Aannemer Meer SE ervaring Weinig SE ervaring RAMSanalyse Ongeacht complexiteit Altijd x Ongeacht projectomvang Altijd x Ongeacht planning Altijd x Gechecked = volledig x Geldt nooit Tabel 9.2: afwegingen vanuit de kruistabellen Niet alle stellingen waarvan de gemiddelden onbetrouwbaar waren zijn in deze tabel verwerkt, alleen degenen die bijdragen aan de afweging. De tabel ziet er iets anders uit dan de vorige tabellen. In deze tabel is gespecificeerd naar stelling en vervolgens vermeld in welke situaties deze stelling wel en niet geldt. Hoofdstuk: Enquête resultaten, Kruistabellen 86

87 10 Afwegingen vanuit de enquête Afwegingstabellen 9.1 en 9.2 zijn gecombineerd tot onderstaande tabel Hierbij is wederom rekening gehouden met de opdrachtgever Grontmij. De tabel is het antwoord op onderzoeksvraag 4c; Welke relaties tussen projectkenmerken en (onderdelen van) Systems Engineering zijn er uit de enquête af te leiden? Onderdeel Stelling Wel bij Niet bij Zorgt voor Zorgt niet voor Twijfel bij Systems Nieuwbouwprojecten Kwaliteit Reductie tijd Engineering Multidisciplinaire projecten Controlemiddel tbv Verrassende Veel belanghebbenden kwaliteit oplossingen Veel tegenstrijdige belangen Structuur afhankelijke projectonderdelen Installatietechnische projecten GWW projecten Projectgrootte ontwerpfase > Projectduur ontwerpfase vanaf 6 maanden Ontwerpafweging Systeembeschrijving Eisenanalyse Functieanalyse Raakvlakken RAMSanalyse Verificatie Beheersbaarheid in tijd en geld Reduceert complexiteit Nut bij projecten met weinig vrijheid Renovatieprojecten In standaardsituaties Weinig keuzeruimte Veel ervaring met SE Projecten ongeacht Projecten ongeacht Projecten ongeacht Theorie Ingenieursbureau Meer SE ervaring Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Complexiteit Projectomvang Planning Aantal disciplines Complexiteit Projectomvang Planning Aantal disciplines Altijd Weinig complexe projecten Functievervullers die niet meer aan eisen voldoen Weinig tijd en geld (voordelen wegen op) Complexiteit Projectomvang Planning Aantal disciplines Externe raakvlakken Interne raakvlakken Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Volledige systeembeschrijving Projecten ongeacht Tabel 10.1: afwegingen vanuit de enquête Veel SE ervaring Theorie Veel SE ervaring Theorie Meer dan 4 jaar ervaring met SE Complexiteit Projectomvang Planning Aantal disciplines Weinig SE ervaring Praktijk Weinig SE ervaring Praktijk Minder ervaring met SE Minder ervaring met SE Duidelijk beeld van OG wat hij wil hebben Specifieke installatietechnische oplossingen Praktijk Aannemer Weinig SE ervaring Innovatieve oplossingen het zoeken naar andere alternatieven (vaker dan dat selectiecriteria dat doen) Overtuiging Controle van ontwerp op eisen Denken/sturen in bepaalde oplossingsrichting Onnodige kosten Als je RAMS gechecked hebt, ben je nog niet volledig Het gaat sporadisch om verrassende oplossingen Weergave in tekening Controle door onafhankelijk persoon Hoofdstuk: Afwegingen vanuit de enquête 87

88 Deze tabel kan als volgt gelezen worden: Het onderdeel uit kolom 1, in dit geval Systems Engineering,: Kan wel toegepast worden bij alle voorwaarden in kolom 2. Kan niet toegepast worden bij alle voorwaarden in kolom 3 Zorgt voor alle eigenschappen in kolom 4 Zorgt niet voor alle eigenschappen in kolom 5 Kolom 6, twijfel bij, wil zeggen dat er sterke twijfel bestaat over het nut van het toepassen van het onderdeel (kolom 1) bij de voorwaarden of eigenschappen in kolom 6 genoemd. In dit geval is er sterke twijfel of Systems Engineering zorgt voor verrassende en innovatieve oplossingen. Er staan in deze tabel nog een aantal tegenstellingen, deze worden samen met de opmerkelijke resultaten en tegenstellingen met de tabellen vanuit de theorie en de casestudie besproken in deel D. Vervolgens wordt in hoofdstuk 12 het afwegingsmodel gepresenteerd. Hoofdstuk: Afwegingen vanuit de enquête 88

89 Deel D; Afwegingen en conclusies

90

91 11 Discussie 11.1 Doel Elk deel in het rapport heeft zijn eigen conclusies. Deze zijn verwoord in hoofdstukken 5, 7 en 10. Deze conclusies beantwoorden aan het onderzoeksdoel om afwegingen weer te geven voor het gebruik van Systems Engineering. De conclusies die uit de theorie kunnen worden getrokken, zijn niet altijd hetzelfde als de conclusies uit de enquête of de interviews. Dit hoofdstuk bespreekt een aantal tegenstrijdige conclusies. Niet alleen tussen de delen (theorie, interviews en enquête) bestaan tegenstrijdige conclusies maar ook binnen deze delen zijn er tegenstrijdigheden. Elke paragraaf begint met een hypothese vanuit de theorie, daarna worden resultaten uit de interviews en de enquête omtrent dat onderwerp besproken. Als laatste wordt besproken waarom deze resultaten eruit komen, voor zover dit bekend en te herleiden is. De conclusies kunnen echter niet als algemeen geldend worden bestempeld, het gaat immers om de resultaten van 7 interviews en 34 enquêtes, waaraan de conclusies zijn verbonden Tijd In hoofdstuk 3, in het onderdeel theoretische benadering, komt naar voren dat Systems Engineering in verschillende sectoren de benodigde tijd voor het gehele project kan reduceren. Het gaat voornamelijk om gegevens vanuit NASA en diverse technology product development teams. Gegevens die dit ondersteunen voor de GWW-sector zijn echter niet gevonden. Hypothese: Systems Engineering zorgt voor een reductie van de benodigde tijd in de GWWsector Bij de resultaten van de enquête komen een aantal gerelateerde zaken aan de orde, die tot nu toe de hypothese niet bevestigt. Systems Engineering zorgt volgens de respondenten niet tot reductie in benodigde tijd. Het levert in de praktijk ook geen beheersbaarheid in tijd en geld op. Er kan vanuit de praktijk geconcludeerd worden dat Systems Engineering in de GWW-sector, op dit moment, de benodigde tijd niet reduceert. Er kan een aantal redenen aangedragen worden waarom deze hypothese verworpen wordt. De GWW-sector heeft binnen projecten te maken met omgevingsfactoren, iets waar productie minder mee te maken heeft. Er zijn veel partijen betrokken en daarnaast zijn er veel belangen en belanghebbenden in het spel. Een project wordt vaak niet ontworpen, uitgevoerd, beheert en onderhouden door dezelfde partij. Er is dus behalve transparantie en expliciet werken meer nodig om een project soepel te laten verlopen en tijdwinst te pakken. Daarnaast is er in de GWW-sector ook sprake van unieke projecten die eenmalig worden uitgevoerd. In de productiesector wordt de ontwerpfase doorlopen om vervolgens een product of systeem in productie te nemen. Het gaat dan vaak om massaproductie. Hier wordt dan tijdwinst gepakt doordat in de ontwerpfase het proces geoptimaliseerd is. In de GWW-sector zorgt Systems Engineering (nog) niet voor reductie van de tijdsbesteding, redenen hiervoor kunnen zijn de betrokkenheid van veel partijen, omgevingsfactoren en veel belangen die meespelen en het uniek zijn van de projecten Risico s In de theorie komt naar voren dat Systems Engineering kan zorgen voor een reductie van de risico s. Hypothese: Systems Engineering zorgt voor een reductie van de risico s in de GWW-sector Uit de interviews komt echter naar voren dat Systems Engineering juist risico s introduceert. Systems Engineering is in de Leidraad SE (ProRail & Rijkswaterstaat, 2007) geïntroduceerd als een transpa- Hoofdstuk: Discussie 91

92 rante en expliciete werkmethode. Er worden allerlei onderdelen en instrumenten aangeboden die kunnen helpen met het toepassen van de methode SE. Dit alles suggereert een feilloze methode. Men moet echter goed beseffen wat men doet en waarom. Door blindelings alle onderdelen uit te voeren, is men niet volledig en kunnen alsnog dingen over het hoofd gezien worden, aldus een van de geïnterviewden. In de enquête is hier geen aandacht aan besteed, aangezien de focus niet ligt op risicomanagement. Concluderend uit de interviews wordt de hypothese verworpen en daaraan toegevoegd dat Systems Engineering risico s introduceert Kosten In de theorie wordt veel gesproken over kosten en reductie van de kosten. Wederom gaat het om theorie vanuit andere sectoren dan de GWW- of bouwsector; voornamelijk productie en ICT. In de enquête kwam een aantal op kosten gerelateerde onderwerpen terug. Hypothese: Systems Engineering zorgt voor een reductie van de kosten in de GWW-sector Nergens komt in de interviews of enquête naar voren dat kostenreductie bewerkstelligd kan worden met deze discipline. Er is dan ook geen reden om aan te nemen dat de theorie betreffende andere sectoren, overeenkomt met de GWW-sector. Redenen hiervoor kunnen zijn dat het gaat om unieke projecten, waarbij het ontwerpproces eenmaal doorlopen wordt voor een eenmalig project. In de productiesector kunnen kosten bespaard worden door het productieproces zo efficiënt mogelijk in te richten en zo weinig mogelijk afval materiaal te produceren. Het productieproces kan ook meerdere malen geoptimaliseerd worden, omdat het om massaproductie gaat en een langlopend proces is. De reden dat er nu nog geen reductie van de kosten bereikt wordt, kan zijn dat Systems Engineering nog niet lang wordt toegepast binnen de GWW-sector en het introduceren en leren werken met een nieuwe discipline kost veel tijd en ook geld. Wat verder over kosten naar voren komt zijn de volgende punten: Volgens de meerderheid van de respondenten van de enquête, moet Systems Engineering toegepast worden vanaf een projectomvang van ,- in de ontwerpfase. Ondanks dat in de interviews aangegeven werd dat RAMS onnodig duur is en voor extra kosten zorgt, vinden de respondenten van de enquête dit niet. RAMS zorgt niet voor onnodige kosten. Systems Engineering zorgt nog niet voor kostenreductie in de GWW-sector, doordat projecten uniek zijn en nieuwe methodes in de eerste gebruiksperiode vaak tijd en geld kosten Keuzeruimte Er zijn twee uiterste situaties denkbaar; één waarbij de opdrachtgever totaal niet weet hoe de oplossing van zijn probleem eruit moet zien en één waarbij de opdrachtgever vastomlijnde ideeën heeft over de oplossing die gerealiseerd dient te worden. Uit de theorie komt naar voren dat Systems Engineering alleen zinvol is bij voldoende keuzeruimte geboden door de opdrachtgever. Systems Engineering kan toegepast worden wanneer de oplossing nog niet beschikbaar is, Martin (1997) Hypothese: Systems Engineering is alleen zinvol in projecten waar voldoende keuzeruimte wordt geboden Uit de interviews komt naar voren dat men het hier mee eens is. Systems Engineering moet alleen toegepast worden bij voldoende vrijheid en keuzeruimte. Systems Engineering moet niet toegepast worden wanneer het gaat om standaardsituaties of routineklussen met vaste oplossingen. IN de ogen van de geïnterviewden betekent dit dat Systems Engineering niet toegepast dient te worden bij specifieke installatietechnische projecten. Binnen de installatietechniek is er namelijk weinig keuzeruimte. Veel problemen hebben standaard oplossingen. Naast weinig keuzeruimte wordt ook binnen de inter- Hoofdstuk: Discussie 92

93 views aangekaart dat installatietechniek meer functies heeft dan GWW-objecten en het proces daarmee te complex wordt. Uit de enquête komt echter naar voren dat ontwerpafwegingen, als onderdeel van Systems Engineering, wel toegepast dienen te worden bij specifieke installatietechnische oplossingen. Ook zijn de respondenten van mening dat Systems Engineering moet worden toegepast bij installatietechnische projecten. Er wordt meer gewicht toegekend aan de resultaten van de enquête, omdat het hier meerdere respondenten betreft en deze de vragen hebben beantwoord vanuit verschillende achtergronden, ervaring en organisaties. De mening bij de stelling of Systems Engineering toegepast moet worden bij projecten met weinig keuzeruimte is wat meer genuanceerd. Respondenten met meer dan 4 jaar SE ervaring zijn van mening dat ook hier Systems Engineering moet worden toegepast. Respondenten met minder ervaring zijn het hier niet mee eens. Reden voor deze resultaten kan zijn dat binnen Systems Engineering meerdere onderdelen (functieanalyse, ontwerpafwegingen) gericht zijn op het genereren van verschillende alternatieven en het kiezen van het beste alternatief. Wanneer er dan geen keuzeruimte is, lijken deze onderdelen niet zinvol. Systems Engineering bevat echter nog meer onderdelen en wordt ook om diverse redenen toegepast naast het genereren van alternatieven en het kiezen van de beste. De conclusie dat bij weinig tot geen keuzeruimte Systems Engineering niet zou moeten worden toegepast, is dan wellicht te stellig, want er zijn meer redenen om de methode toe te passen. Indirect zegt Martin (1997) ook dat Systems Engineering niet toegepast dient te worden bij renovatieprojecten, want daar is de oplossing immers al beschikbaar, aangenomen dat het bestaande installaties zijn die gerenoveerd moeten worden. Vanuit het V-model, het model wat gebruikt wordt bij Systems Engineering in de GWW-sector, wordt deze conclusie niet bevestigd. Want Systems Engineering kan worden toegepast gedurende alle fasen van het V-model en renovatie is daar één van. Uit de interviews komt echter dat bij renovatie projecten Systems Engineering niet moet worden toegepast. Vanuit de enquête zijn de resultaten wat betreft het toepassen van SE bij nieuwbouw en renovatieprojecten wat meer genuanceerd. Bij nieuwbouwprojecten moet Systems Engineering worden toegepast maar bij renovatieprojecten alleen als de projectmedewerkers veel ervaring hebben met Systems Engineering. De ontbrekende keuzeruimte binnen renovatieprojecten is hier waarschijnlijk de reden voor deze conclusie. Systems Engineering kan echter toegepast worden om meerdere redenen, dus of de conclusie getrokken kan worden dat SE binnen renovatieprojecten minder zinvol is, is niet eenduidig. Als resultaat van het onderzoek kan geconcludeerd worden dat bij weinig tot geen keuzeruimte geen Systems Engineering moet worden toegepast, tenzij projectmedewerkers veel (4 jaar of meer) ervaring hebben met Systems Engineering. Hieruit komt naar voren dat Systems Engineering ook niet moet worden toegepast bij renovatieprojecten, standaardoplossingen en routineklussen mits er niet voldoende ervaring in het projectteam aanwezig is. Bij installatietechnische projecten moet Systems Engineering wel worden toegepast ongeacht de ervaring van projectmedewerkers Verrassende oplossingen Een onderdeel van Systems Engineering is het vanuit functies genereren van alternatieven om zo tot een efficiënte oplossing te komen. Omdat dit gebeurt vanuit het functie-denken, wordt er in dit proces geen oplossingsrichting aangegeven en zou dit kunnen zorgen voor verrassende en innovatieve oplossingen. Hypothese: Systems Engineering zorgt voor verrassende oplossingen Uit de interviews komt echter dat er weinig tot geen verrassende oplossingen uitkomen. De respondenten van de enquête beamen dit. Systems Engineering zorgt volgens de respondenten niet voor verrassende oplossingen. Het gebruik van een functieanalyse kan echter wel zorgen voor innovatieve oplossingen volgens dezelfde respondenten. Of de ontwerpafweging verrassende oplossingen oplevert is twijfelachtig door onbetrouwbare resultaten. Deze drie conclusies spreken elkaar tegen, wat niet tot een eenduidige conclusie leidt. De reden dat men twijfelt over het feit of de ontwerpafweging verrassende oplossingen oplevert, kan zijn dat projectmedewerkers, door ervaring, vaak kunnen inschatten wat de beste oplossing moet zijn en dit is veelal ook het resultaat van het ontwerpproces. Dat een functieanalyse wel voor verrassende Hoofdstuk: Discussie 93

94 of innovatieve oplossingen kan zorgen, kan liggen aan het in functies omschrijven van het gewenste systeem. Hiermee geeft men geen oplossingsrichting aan en wordt er vaak op hoger of abstracter niveau gedacht. Wanneer men na gaat denken over welke objecten deze functie kunnen vervullen en daarbij out-of-the-box denken kunnen er verrassende ideeën uitkomen. Dat vervolgens Systems Engineering niet tot verrassende oplossingen leidt, kan liggen aan het niet goed uitvoeren van de functieanalyse en het te snel in oplossingen denken. Ondanks al deze mogelijke verklaringen voor de uitkomsten, geven de resultaten van de interviews en de enquête geen eenduidig antwoord op de hypothese Beheersbaarheid Naast dat Systems Engineering volgens de theorie transparantie, expliciet werken en structuur met zich mee brengt, is beheersbaarheid van een project ook een van de speerpunten. Hypothese: Systems Engineering zorgt voor beheersbaarheid van een project In de interviews wordt deze hypothese beaamd en is men het ermee eens dat Systems Engineering beheersbaarheid in tijd en geld biedt. De respondenten van de enquête vinden dit echter niet. Alleen als er veel ervaring met SE in het projectteam aanwezig is, kan Systems Engineering dit bieden. De reden hiervoor kan zijn dat om beheersbaarheid te creëren, men de instrumenten geboden door SE op een juiste manier moet kunnen toepassen. In theorie zorgt SE voor de juiste instrumenten en condities, maar in de praktijk is het een relatief nieuwe discipline voor de GWW-sector. Dat wil zeggen dat men het nog niet volledig kan overzien en de discipline dan ook niet voor beheersbaarheid zorgt. Systems Engineering biedt hulpmiddelen om die beheersbaarheid te creëren, maar met het alleen maar toepassen van de methode is dit nog niet gegarandeerd. Kijkend naar de resultaten van de interviews en de enquête, met daarbij de mogelijke verklaring voor de antwoorden, kan geconcludeerd worden dat Systems Engineering wel beheersbaarheid van het project kan verzorgen, maar alleen wanneer men voldoende ervaring heeft met de methode Eisen stellen aan functies/functievervullers In theorie horen eisen aan de functies gesteld te worden, uit deze functies en bijbehorende eisen komen functievervullers, oftewel objecten (ProRail & Rijkswaterstaat, 2007). Hypothese: eisen worden aan functies gesteld Uit de interviews komt de uitspraak, dat dit in theorie wel het geval is, maar in de praktijk het veel makkelijker is om eisen aan functievervullers te stellen. Eisen zeggen immers iets over de functievervullers. De reden voor dit resultaat kan zijn dat het ook eenvoudiger is om eisen te stellen aan het object brug dan aan de functie het vervoeren van auto s per dag van punt a naar b. Wanneer de eis aan de functie wordt gesteld, is nog open gelaten of het een brug, tunnel of veerpont wordt. Wanneer je echter eisen stelt aan de functievervullers, geef je vaak al een oplossingsrichting aan en dit is nu juist wat de methode Systems Engineering wil voorkomen. Uit de enquête komt overigens naar voren dat eisen stellen zonder te sturen op een oplossingsrichting mogelijk is en functionele eisen oplossingsvrij zijn. Respondenten van de enquête zijn ook van mening dat eisen aan functievervullers gesteld dienen te worden. De stelling of eisen aan functies gesteld dienen te worden, wordt verdeeld beantwoord. De aannemer en opdrachtgever zijn lichtelijk positief, de consultancy en het ingenieursbureau zijn lichtelijk negatief. Het positief beantwoorden van beide stellingen is tegenstrijdig, want eisen stellen aan zowel functies als functievervullers levert een ongestructureerd en onlogisch geheel van eisen op. Aan de hand van de resultaten kan geconcludeerd worden dat eisen sowieso aan functievervullers gesteld moeten worden. Wanneer dit echter in de praktijk gebeurt, moet men zich afvragen welk nut Hoofdstuk: Discussie 94

95 de functieanalyse nog heeft. Er wordt door de eisen al op een bepaalde oplossing gestuurd. Naast het oplossingsvrij houden van de specificatie zorgt de functieanalyse ook voor overzicht en randvoorwaarden. De vraag wordt dan of de voordelen die deze andere functies bieden, opwegen tegen de moeite die het opstellen van een functieanalyse kost. Bekeken dat dit onderzoek in opdracht van Grontmij, een ingenieursbureau, is uitgevoerd kan geconcludeerd worden dat eisen niet aan functies gesteld dienen te worden Conclusies uit de discussie In deze paragraaf worden alle conclusies die getrokken zijn in dit hoofdstuk nogmaals opgesomd. Hierbij wordt gekeken naar de antwoorden vanuit de theorie, interviews en enquête, wordt rekening gehouden met de opdrachtgever, Grontmij en met mogelijke redenen voor de resultaten. In de GWW-sector zorgt Systems Engineering (nog) niet voor reductie van de benodigde tijd, redenen hiervoor kunnen zijn de betrokkenheid van veel partijen, omgevingsfactoren, belangen die meespelen en het uniek zijn van projecten. Systems Engineering introduceert risico s. Systems Engineering zorgt (nog) niet voor kostenreductie in de GWW-sector, doordat projecten uniek zijn en nieuwe ontwerpmethodes na introductie vaak eerst tijd en geld kosten voordat het iets oplevert. Bij weinig tot geen keuzeruimte dient geen Systems Engineering te worden toegepast, tenzij projectmedewerkers veel (4 jaar of meer) ervaring hebben met de discipline. Systems Engineering moet daarom ook niet toegepast worden bij renovatieprojecten, standaardoplossingen en routineklussen mits er niet voldoende ervaring in het projectteam aanwezig is. Systems Engineering moet wel toegepast worden bij installatietechnische projecten. Of Systems Engineering verrassende en innovatieve oplossingen oplevert is na dit onderzoek nog onduidelijk. Systems Engineering biedt beheersbaarheid in tijd en geld, mits het projectteam ervaren is met de discipline. Eisen moeten aan functievervullers gesteld worden. Hoofdstuk: Discussie 95

96

97 12 Conclusies en aanbevelingen 12.1 Doel In dit hoofdstuk staan 2 tabellen weergegeven waarin de resultaten vanuit de theorie, interviews en enquête worden beschreven. Alle tegenstrijdigheden die nog wel in de hoofdstukken 5, 7 en 10 zijn te lezen zijn grotendeels besproken in hoofdstuk 11 en niet meer in tabellen 12.1 en 12.2 te vinden. Het wordt een afwegingsmodel genoemd omdat deze tabel aangeeft wanneer Systems Engineering kan worden toegepast en wat het wel en niet oplevert. Men kan voor zichzelf nu de afweging maken of Systems Engineering als ontwerpmethode toepasbaar is op bepaalde projecten. In dit hoofdstuk wordt antwoord gegeven op onderzoeksvraag 4: Hoe luiden de afwegingen die op basis van de theorie, interviews en enquête gemaakt kunnen worden? Het afwegingsmodel (H 12.2) bevat conclusies van het onderzoek, maar naast dit model is er nog een conclusie te trekken, deze is weergegeven in paragraaf Als laatste worden in dit hoofdstuk aanbevelingen gegeven in paragraaf Ondanks dat de conclusies hier stellig staan gegeven, zijn het waarschijnlijk algemeen geldende conclusies. De conclusies berusten op een zevental interviews en 34 enquêtes. De interviews zijn afgenomen bij projectmedewerkers van het project HVVOS, een project waar men met Systems Engineering werkt en waar veel problemen zijn geweest met de implementatie van SE. De enquête is uitgevraagd aan een vooraf geselecteerde groep mensen, waaronder wederom projectmedewerkers betrokken bij HVVOS. Het betreft dus geen willekeurige groep mensen en daardoor kunnen de conclusies beïnvloed zijn. Het betreft hier een explorerende kijk op de mening van deze groep mensen op Systems Engineering in de praktijk. Hoofdstuk: Conclusies en aanbevelingen 97

98 12.2 Afwegingsmodel Deze paragraaf bevat het antwoord op de onderzoeksvraag die vraag naar afwegingen die op basis van de theorie, interviews en enquête kunnen worden gemaakt. De afwegingen zijn opgesplitst in twee tabellen (12.1 & 12.2). De eerste tabel kijkt alleen naar Systems Engineering in het geheel en geeft de toepassingsmogelijkheden en eigenschappen weer Systems Engineering Onderdeel Kenmerk Wel (bij) Niet bij Zorgt voor Zorgt niet voor Systems Engineering Algemeen Beheersbaarheid van het project bij ervaring team mbt SE (9.4 & 11.7) Controlemiddel tbv kwaliteit (3 & 9.3.2) Structuur (3 & 9.3.2) Expliciet werken (3 & 9.3.2) Twijfel bij Aantal disciplines Afhankelijkheid Belangen en belanghebbenden Complexiteit Innovatie Ongeacht het aantal disciplines (9.3.2) Afhankelijke projectonderdelen (4 & 9.3.2) Veel belanghebbenden (4 & 9.3.2) Veel tegenstrijdige belangen (4 & 9.3.2) Ongeacht de complexiteit (9.3.2) Transparantie (3) Reductie van complexiteit bij ervaren team mbt SE ( 4 jaar) (4 & 9.4) Risico-reductie (9.4 & 11.3) Zorgen voor verrassende en innovatieve oplossingen (9.3.2, 9.4 & 11.7) Kosten Tijd Fase V-model Soort project Projectgrootte in de ontwerpfase vanaf ,- (9.3.2) Projectduur in de ontwerpfase vanaf 6 maanden (9.3.2) Nieuwbouw (9.3.2) Renovatieproject met ervaren team mbt SE ( 4 jaar) (9.4 & 11.5) GWW-projecten (9.3.2) Renovatieproject met weinig ervaren team mbt SE (9.4 & 11.5) Kostenreductie (9.4 & 11.4) Tijdreductie (9.4 & 11.2) Keuzeruimte Installatietechnische projecten (9.4 & 11.5) Keuzevrijheid (11.5) Weinig keuzevrijheid met ervaren team mbt SE ( 4 jaar) (11.5) Tabel 12.1: afwegingen Systems Engineering Weinig keuzevrijheid (11.5) Standaardoplossin gen (11.5) Deze tabel en onderstaande tabel kan als volgt gelezen worden: Het onderdeel uit kolom 1, in dit geval Systems Engineering,: Kan wel toegepast worden bij alle voorwaarden in kolom 2. Kan niet toegepast worden bij alle voorwaarden in kolom 3 Zorgt voor alle eigenschappen in kolom 4 Zorgt niet voor alle eigenschappen in kolom 5 Hoofdstuk: Conclusies en aanbevelingen 98

99 Kolom 6, twijfel bij, wil zeggen dat er sterke twijfel bestaat over het nut van het toepassen van het onderdeel (kolom 1) bij de voorwaarden of eigenschappen in kolom 6 genoemd. In dit geval is er sterke twijfel of Systems Engineering zinvol is om toe te passen bij renovatieprojecten. Bovenstaande tabel, 12.1, bevat gegevens uit de theorie, interviews en enquête met betrekking tot Systems Engineering. In de tweede kolom staan een aantal projectkenmerken gegeven, zodat de tabel overzichtelijk is en snel te lezen is. Achter elke toepassingsmogelijkheid of eigenschap staat een nummer, deze verwijst naar het hoofdstuk of de paragraaf waar deze conclusie getrokken is Onderdelen van Systems Engineering In onderstaande tabel (12.2) staan alle onderdelen van Systems Engineering weergegeven. Ook hier zijn de geconcludeerde toepassingsmogelijkheden en eigenschappen weergegeven met daarachter het hoofdstuk of de paragraaf waar deze conclusie getrokken is. Onderdeel Wel (bij) Niet bij Zorgt voor Zorgt niet voor Twijfel bij Systeem-beschrijving Ongeacht (9.3.3) Complexiteit Projectomvang Planning Aantal disciplines Eisenanalyse (9.3.4) Functieanalyse Ontwerpafweging Ongeacht Complexiteit Altijd (9.4) Projectomvang Planning Aantal disciplines Weinig tijd en geld, voordelen wegen op (9.3.5) Standaardoplossingen (met ervaren team mbt SE) (9.4) Weinig keuzeruimte (met ervaren team mbt SE) (9.4) Specifieke installatietechnische oplossingen (11) Randvoorwaarden (6) Sturen in een bepaalde oplossingsrichting Zorgen voor verrassende oplossingen (9.3.5, 9.4 & 11.6) Raakvlakken (9.3.7) RAMS Verificatie (9.3.9) Ongeacht Complexiteit Projectomvang Planning Aantal disciplines Ongeacht (9.4) Complexiteit Projectomvang Planning Aantal disciplines Overtuiging (9.3.8) Ongeacht Complexiteit Projectomvang Planning Tabel 12.2: afwegingen SE onderdelen Aantal disciplines Onvolledige systeembeschrijving (9.3.8) Het zoeken naar andere alternatieven (9.3.8) Ontwerpcontrole Volledigheid (9.4) Wanneer er een verwijzing staat bij het onderdeel, geldt dit voor alle toepassingsmogelijkheden en eigenschappen die daarachter genoemd zijn. Hoofdstuk: Conclusies en aanbevelingen 99

100 12.3 Conclusies Het antwoord op onderzoeksvraag 4, het afwegingsmodel, is in paragraaf 12.2 gegeven, maar uit het onderzoek is ook een algemene conclusie te trekken. Deze staat hieronder weergegeven; Over Systems Engineering is veel theorie te vinden, maar dit is voornamelijk gericht op andere sectoren. Systems Engineering in de Nederlandse GWW-sector is nieuw en nog weinig onderzocht. Na het verwerken van alle onderzoeksresultaten kan de volgende conclusie getrokken worden met betrekking tot de theorie en de theoretische benadering in dit rapport: Een praktische handleiding is noodzakelijk bij het introduceren van Systems Engineering in de GWW-sector De theorie van Systems Engineering blijft heel abstract. Ondanks dat Rijkswaterstaat, ProRail, ONRI en Bouwens Nederland een leidraad specifiek voor de GWW-sector hebben geschreven, draagt dit niet bij aan de praktische invulling van Systems Engineering. Een praktische handleiding ontbreekt Aanbevelingen In deze paragraaf staat een aantal aanbevelingen die gebaseerd zijn op de conclusies. Ook is er een aantal mogelijke onderzoeksvragen geformuleerd die voort komen uit de stellingen waar onbetrouwbare gemiddelden uitkwamen en die geen aantoonbaar verband vertoonden met de onafhankelijke variabelen (H 9.4.2) Aanbevelingen Er dient een opleidingsprogramma ontwikkeld te worden met workshops en een voor iedereen beschikbare praktische handleiding Het is belangrijk om een praktische handleiding te ontwikkelen voor het gebruik van Systems Engineering. Dit wordt al door diverse bedrijven gedaan, maar veelal alleen voor intern gebruik. Omdat ProRail en Rijkswaterstaat, als grote opdrachtgevers, beiden bij veel projecten Systems Engineering vereisen, is het ontwikkelen van een eenduidige en voor iedereen beschikbare praktische handleiding aan te raden. Een voor iedereen beschikbare praktische handleiding is niet alleen voor de opdrachtnemer noodzakelijk, ook de opdrachtgever heeft hier profijt van. Elke marktpartij hanteert dan dezelfde handleiding, waardoor de aanbiedingen en ontwerpdocumenten eenvoudiger te controleren zijn door eenzelfde opzet. Het gebruikt van de praktische handleiding moet echter wel vooraf gegaan worden door een workshop, waarin projectmedewerkers met weinig ervaring met SE uitgelegd krijgen door middel van interactieve opdrachten hoe Systems Engineering is elkaar zit, wat er van hen verwacht wordt en waarom de methode op die manier ingestoken wordt. Het is belangrijker om te snappen wat de achterliggende gedachte is van de methode dan precies stap voor stap te weten wat er moet gebeuren. Vandaar dat met een praktische handleiding hier geen stappenplan wordt bedoeld, maar meer een dictaat waarin staat uitgelegd wat de bedoeling is van de methode, welke onderdelen hierbinnen gedefinieerd worden en welke vragen je jezelf kunt stellen om tot een goed resultaat te komen. Het dient meer als geheugensteun. Een complex project moet opgepakt worden door een ervaren projectteam. Een aanbeveling die direct uit de casestudie voortvloeit, is dat een dergelijk complex project waarbij Systems Engineering wordt toegepast, opgepakt dient te worden met een ervaren projectteam met betrekking tot Systems Engineering. Als dit niet het geval is, heeft het toepassen van Systems Engineering meer nadelen dan voordelen. Bij minder complexe projecten kunnen onervaren mensen ingezet worden om hen de mogelijkheid te bieden om ervaring op te doen met Systems Engineering. In die Hoofdstuk: Conclusies en aanbevelingen 10 0

101 projecten kunnen mensen opgeleid worden, bij complexere projecten dienen mensen al opgeleid te zijn binnen andere projecten of door middel van het eerder aanbevolen opleidingsprogramma Dit onderzoek dient, aangepast, te worden voortgezet om zo meer resultaten te verkrijgen en meer algemene conclusies te kunnen trekken. Aangezien het een explorerend onderzoek betreft kon volstaan worden met minimaal 30 respondenten. Om daadwerkelijk algemeen geldende conclusies te kunnen trekken, dienen er meer respondenten te zijn. Daarnaast kan aan de hand van dit onderzoek de enquête aangepast worden zodat de resultaten bruikbaarder worden. Er is in paragraaf al een aantal vragen aangegeven die weggevallen zijn door een ongelukkige vraagstelling en er zijn aan de hand van de conclusies vragen te bedenken die toegevoegd kunnen worden aan de enquête. De resultaten die in dit rapport zijn gepresenteerd dienen gebruikt te worden bij de start van nieuwe projecten. In de tabellen (12.1 & 12.2) kan opgezocht worden wat Systems Engineering kan brengen en wat niet. Als voorbeeld kan een van de speerpunten van het project bijvoorbeeld zijn het zoveel mogelijk reduceren van de kosten en de benodigde tijd. In tabel 12.1 is dan af te lezen dat Systems Engineering in de GWW-sector hier (nog) niet voor zorgt. Andere maatregelen moeten dan genomen worden om dit te bewerkstelligen. Er moet onderzoek gedaan worden naar de voor- en nadelen van Systems Engineering in de Nederlandse GWW-sector. Binnen andere sectoren waar Systems Engineering wordt toegepast is reeds onderzoek gedaan naar de voordelen die het kan bieden. Er zijn meerdere projecten bekeken en aan de hand daarvan is bekeken onder welke voorwaarden Systems Engineering kan zorgen voor reductie van kosten, tijd, onzekerheid en risico s. Iets soortgelijks moet gedaan worden voor projecten binnen de GWW-sector waarbij Systems Engineering is toegepast. Hiervoor zijn echter wel afgeronde projecten nodig en die zijn er nog niet zoveel. Dit zal dus nog een lange tijd duren voordat soortgelijke database gecreëerd is Onderzoeksvragen voor verder onderzoek Hieronder staan onderzoeksvragen opgesomd die gesteld kunnen worden in verder onderzoek Reduceert SE kosten in de GWW? Reduceert SE tijd in de GWW? Reduceert SE onzekerheid in de GWW? Reduceert SE risico s in de GWW? De theorie over andere sectoren geeft de reductie van kosten, tijd, onzekerheid en risico s aan als voordeel, maar dit is niet bevestigd in dit onderzoek. Er is zelfs gesproken over het introduceren van risico s door het blindelings volgen van de methode SE. Zijn functionele eisen oplossingsvrij? Direct hiermee samenhangend zijn de stellingen eisen worden aan functies gesteld en eisen worden aan functievervullers gesteld. Op beide stellingen wordt positief gereageerd, wat tegenstrijdig is. Om deze onderzoeksvraag te beantwoorden moet dan ook antwoord gegeven worden op de vraag waar eisen aan gesteld worden; functies of functievervullers?. En wat betekent in dit hele verhaal oplossingsvrij? Zorgt Systems Engineering voor verrassende en innovatieve oplossingen? Hoofdstuk: Conclusies en aanbevelingen 10 1

102 Zowel in de enquête als de casestudie wordt hier verschillend op gereageerd. Het zorgen voor verrassende en innovatieve oplossingen wordt in de documentatie wel gebruikt als reden om SE toe te passen, maar het is niet aangetoond dat het die mogelijkheid ook biedt. Hoofdstuk: Conclusies en aanbevelingen 10 2

103 13 Gebruikte begrippen en afkortingen 13.1 Begrippenlijst Begrip Beschikbaarheid Beschrijving = ( ) (NEN-EN 50126) Het betreft de absolute (aaneengesloten) tijd dat het systeem werkt zonder falen. Betrouwbaarheid mean time between failure (NEN-EN 50126) Het percentage van de tijd dat het systeem werkt en beschikbaar is. Complexiteit Een systeem is complex wanneer het systeem meerdere functies moet vervullen en binnen het systeem of tussen de verschillende (sub)systemen onderlinge interactie plaatsvindt. Daarnaast is een systeem complex wanneer het onderhevig is aan verandering (dynamisch). (Alkemade, 1992; Brussaard & Thiadens, 1993) Decomponeren het ontleden van een op hoger niveau staand systeem Raakvlakken De functionele en fysieke eigenschappen die dienen te bestaan voor het in samenhang functioneren van delen op een gemeenschappelijke grens (ProRail & Rijkswaterstaat, 2007) Risico s Kans x gevolg (Helm, 1996) Systems Engineering SE is een discipline die een set methodieken aanreikt om het bouwproces in te richten en te beheersen. Met deze methodieken wordt bewerkstelligd dat men denkt vanuit het probleem, kijkt naar de gehele levenscyclus en transparant werkt. Systems Engineering Effort SEE bestaat uit de kwaliteit van de uitgevoerde Systems engineering en het percentage project kosten wat besteed is aan Systems Engineering. (Honour, 2004) 13.2 Afkortingen Afkorting GWW HBO HSL HVVOS ICT MCA RAMS SE SEE WO Begrip Grond-, weg en waterbouw Hoger Beroeps Onderwijs Hoge snelheidslijn Renovatie Haringvliet en Volkerak sluizencomplexen Informatie en Communicatie Technologie Multi-criteria analyse Reliability, Availibility, Maintainibility, Safety (beschikbaarheid, betrouwbaarheid, onderhoudbaarheid en veiligheid) Systems Engineering Systems Engineering Effort Wetenschappelijk Onderwijs Hoofdstuk: Gebruikte begrippen en afkortingen 10 3

104

105 14 Bronnen 14.1 Literatuur Alkemade, drs. M.J.A. (1992) Inspelen op complexiteit; mens, techniek, informatie en organisatie s Gravenhage: Stichting toekomstbeeld der techniek. Blanchard, Benjamin S. & Fabrycky, Wolter J. (1998) Systems Engineering and Analysis; third edition New Jersey: Prentice Hall Inc. Gigch, J.P. van (1991) System Design Modeling and Metamodeling Kluwer Academic Pub. Martin, James N. (1997) Systems Engineering Guidebook; a process for developing systems and products Florida: CRC Press. Moore, D.S. & McCabe, G.P. (2005) Introduction in the practice of statistics, fifth edition Freeman & Co ltd. Veld, ir. J. in t (1998) Analyse van organisatieproblemen; een toepassing van denken in systemen en processen Blaricum: EPN, zevende druk. Verschuren, P. & Doorewaard, H. (2005) Het ontwerpen van een onderzoek Utrecht: Lemma, derde druk Publicaties en artikelen Bonnema, Maarten G. (2008) Funkey Architecture; an integrated approach to systems architecting using functions, key drivers and system budgets Proefschrift, Universiteit Twente. Brussaard, B.K. & Thiadens, T.J.G. (1993) How to deal with complex information systems? Delft University of Technology. California department of transportation, division of research and innovation (2007) Systems Engineering Guidebook for ITS Caltrans. CROW (2007) Handboek oplossingsvrij specificeren CROW. Dean, F.F., Bentz, B. & Terry Bahill, A. (1997) A road map for implementing Systems Engineering SANDIA National Laboratories. Hoofdstuk: Bronnen 10 5

106 Department of Defense (2001) Systems Engineering Fundamentals Virginia Defense acquisition press. Eelants, J.P. & Visser, A. (2007) Programmaplan; CROW-kennisprogramma Systems Engineering CROW. Helm, P (1996) Integrated risk management for natural and technological disasters Tephra, 15(1): Honour, Eric (2008) Systems Engineering and Complexity INCOSE Insight, vol 11 Issue 1. Honour, Eric (2004) Understanding the value of Systems Engineering INCOSE, 2004 INCOSE (2007) Systems Engineering Handbook; a guide for system life cycle processes and activities INCOSE. INCOSE (2008) INCOSE. Institute of Electrical and Electronics Engineers (1990) IEEE STD ; IEEE Standard Glossary of Software Engineering Terminology IEEE ISO/IEC 15288: 2002 (NL) Leijten, Martijn & Bruijn, Hans de ( ) Algemene kenmerken van grote infrastructuur projecten Tweede Kamer, vergaderjaar , , nr.10 Luiten, G.J. et al. (2005) Vraagspecificatie als katalysator voor vernieuwing PSIB. Nederlands Normalisatie Instituut (1999) NEN-EN 50126: Spoorwegen en soortgelijke geleid vervoer - De specificatie en het bewijs van de bruikbaarheid, beschikbaarheid, onderhoudbaarheid en veiligheid - Deel 1: Basiseisen NNI ONRI (2005) Posities en rollen van advies- en ingenieursbureaus in een dynamische markt ONRI. Prorail, Rijkswaterstaat, ONRI & Bouwend Nederland (2007) Leidraad voor Systems Engineering binnen de GWW-sector ProRail &Rijkswaterstaat. Ridder, H.A.J. de & Ravesloot, C.M. (2007) Systems Engineering ontwerpproject 3 Technische Universiteit Delft, faculteit Civiele Techniek en Geowetenschappen Hoofdstuk: Bronnen 10 6

107 Rijkswaterstaat (2006) Werkwijzer Marktconsultatie Rijkswaterstaat. Systems Engineering applications technical committee (2000) Systems Engineering applications profiles, version 3.0 INCOSE. US Department of transportation, Federal highway administration & Federal transit administration (2007) Systems Engineering for intelligent transportation systems; an introduction for transportation professionals FHA. Hoofdstuk: Bronnen 10 7

108 Bijlagen Systems Engineering in de praktijk Een onderzoek naar toepassingsmogelijkheden en eigenschappen E. Vink De Bilt, 18 december 2008

109

110 Bijlagen Systems Engineering in de praktijk Een onderzoek naar toepassingsmogelijkheden en eigenschappen Auteur: Eline Vink De Bilt, 18 december 2008 Opdrachtgevers: Technische Universiteit Delft Faculteit Civiele Techniek en Geowetenschappen Studie Civiele Techniek Master Building Engineering Specialisatie Design & Construction Processes Grontmij bv Afdeling Waterbouw Team Projects Afstudeercommissie: Prof. Dr. Ir. H.A.J. de Ridder Dr. Ir. G.A. van Nederveen Dr. Drs. Ir. C.M. Ravesloot Ir. R.J.J. Raaijmakers Ir. N.J.M. Nijenhuis Technische Universiteit Delft Technische Universiteit Delft Avans Hogeschool en Hogeschool Zuyd Grontmij Kondor Wessels Projecten

111

112 Inhoudsopgave Bijlage 1 Literatuuronderzoek... 7 Bijlage 2 uitwerking interviews... 9 Bijlage 3 enquête Bijlage 4 verantwoording enquête Bijlage 5 enquête resultaten losse vragen Bijlage 6 enquête resultaten gemiddelden Bijlage 7 kruistabellen Hoofdstuk: Inhoudsopgave 5

113

114 Bijlage 1 Literatuuronderzoek Zoals ik het hoofdrapport is weergegeven is getracht literatuur en eerder onderzoek te vinden over Systems Engineering in de GWW-sector. In de bronnenlijst van het hoofdrapport zijn een aantal bronnen gegeven waarin gegevens staan over SE in de GWW, te weten: CROW (2007) Handboek oplossingsvrij specificeren CROW. Eelants, J.P. & Visser, A. (2007) Programmaplan; CROW-kennisprogramma Systems Engineering CROW. Prorail, Rijkswaterstaat, ONRI & Bouwend Nederland (2007) Leidraad voor Systems Engineering binnen de GWW-sector ProRail &Rijkswaterstaat. Voor literatuur en eerder onderzoek is gezocht in de volgende media en databases: Universiteitsbibliotheek Delft Enschede Utrecht Databases ACS full text Civil Engineering database Compendex DAREnet Google Scholar icivilengineer IEEE/IET Electronic library NARCIS NOD Nederlandse Onderzoeks Database PiCarta SAGE journals online ScienceDirect Scopus Web of Science Wiley Interscience Kennisinstanties INCOSE CROW Rijkswaterstaat ProRail Ook zijn literatuurlijsten van afstudeerrapporten over het onderwerp Systems Engineering in de GWWsector bekeken om hieruit de goede literatuur te halen. Onder andere afstudeerrapporten van: Erwin Uil Boj Dimmendaal Hoofdstuk: Literatuuronderzoek 7

115

116 Bijlage 2 uitwerking interviews In de interviews zijn een groot aantal uitspraken gedaan. Ze zijn niet allemaal relevant voor het onderzoek en niet alle uitspraken zijn in deze bijlage weergegeven. De geïnterviewde partijen zijn Grontmij, Homij, Rijkswaterstaat en ABB. 2.1 Algemeen SE De invulling en uitwerking van een project met Systems Engineering is niet eenduidig Als je al weet wat je moet hebben, dan ga je dat niet cryptisch omschrijven Systems Engineering past niet binnen installatietechniek Alle componenten van een project moeten in de opbouw zitten, ongeacht of je er nu iets mee doet of niet De meerwaarde van Systems Engineering zit in de beheersbaarheid van een project en niet in de specifieke werkwijze Kleinere bedrijven hebben geen tijd en geld om Systems Engineering toe te passen Systems Engineering verdient zichzelf niet terug in kleine projecten Binnen Systems Engineering moet je beginnen met het totale systeem om vervolgens naar deelsystemen en componenten toe te werken. Je kunt niet beginnen met een deelsysteem Systems Engineering is een oude methode in een nieuw jasje Systems Engineering introduceert risico s. Er wordt gesuggereerd dat het overzicht er is, danwel via de methode danwel via software. Het systeem borgt echter niet alle invalshoeken en beschikt niet over een consistency check. Systems Engineering ligt over 10 jaar weer in de prullenbak Systems Engineering is weinig praktisch invulling en veel theorie 2.2 Algemeen HVVOS Je kunt niet om een definitief ontwerp van een systeem vragen wanneer daar geen voorlopig ontwerp van gemaakt is De eerste ontwerpstap, hier het voorlopig ontwerp, kan maar bestaan uit één document waarin alles verwerkt zit. Van daaruit moet naar beneden gewerkt worden. De naamgeving van de documenten (voorlopig ontwerp, definitief ontwerp, uitvoeringsontwerp) is verwarrend. Er werd ontworpen in niveaus, elke keer weer een slag dieper. De indeling had anders moeten zijn; Hoofdstuk: uitwerking interviews 9

117 Het kennisniveau van de HVVOS complexen was te licht Het format was te theoretisch Bij de invulling van het project met Systems Engineering moet gekeken worden naar de partijen die verder moeten met de documenten en wat zij nodig hebben. Documenten zijn inhoudelijk weinig praktisch en zinvol Documenten zijn niet leesbaar In de documenten had meer visueel gedaan moeten worden en minder tekstueel Er is veel werk verzet maar op de oude manier waren we nu veel verder geweest Afwegingen maken is niet nuttig wanneer het gaat om alledaagse dingen en routineklussen Tussen de opdrachtgever en opdrachtnemer moet meer afgestemd worden wat de verwachtingen zijn Het gaat ons om wat we moeten bouwen, dat het niet duurder is en of het aan de eisen voldoet. De rest van de informatie is vereist door Rijkswaterstaat. Het aanbiedingsontwerp zou beter op papier moeten staan zodat niet opnieuw keuzes moeten worden gemaakt en moet worden afgeleid Het abstractieniveau van documenten van Rijkswaterstaat is te hoog. Je kunt niet verwachten dat iedereen dat snapt Installatietechniek heeft tegenover civiele techniek veel meer systemen en functies, wat het hele proces van Systems engineering omvangrijk maakt Wij hebben onze verwachtingen niet goed vastgelegd Het kennisniveau van Rijkswaterstaat neemt snel af wanneer het gedetailleerder wordt, wat ons vrijheid geeft, maar waardoor ook rare voorschriften zijn gemaakt aangaande de indeling van de fases. Rijkswaterstaat vraagt om een merkwaardige opbouw, met weinig voorlopige ontwerpen, wat meer definieve ontwerpen en overal een uitvoerings ontwerp van. In het contract hebben we teveel gekeken op eisniveau en de functies niet goed onderkend Het is nog zoeken naar een simpele manier van toepassen, doelmatig toepassen en niet het middel het doel laten worden Wanneer er geen oude ontwerpen beschikbaar zijn, zoals bij HVVOS, moet je je afvragen of Systems Engineering het goede mechanisme is We hadden het doel en de gewenste resultaten moeten beschrijven in plaats van de werkwijze Er is weinig leereffect, doordat we geen vrijheid hebben geboden in de methode Men weet niet waarom bepaalde dingen gedaan worden Hoofdstuk: uitwerking interviews 10

118 Opgeleverde documenten zijn niet voor iedereen helder Documenten verschillen heel erg qua invulling De opdrachtgever en opdrachtnemer moeten hun verwachtingen afstemmen en vastleggen In het aanbiedingsontwerp is de invulling en de prijs al bepaald. Daarna ga je volgens Systems engineering alles opnieuw bepalen en naar het aanbiedingsontwerp toewerken. o Er zou meteen Systems engineering toegepast moeten worden in de aanbiedingsfase OF o Nieuwe afwegingen moeten nagecalculeerd worden 2.3 Systeembeschrijving In de systeembeschrijving moet meer visueel en meer schematisch worden neergezet Beschikbaarheid en betrouwbaarheid moeten verwerkt zitten in de systeembeschrijving De verschillen tussen de huidige en gewenste situatie moeten duidelijk verwoord worden Er is te weinig beschreven in de systeembeschrijving De informatie moet worden aangevuld, in plaats van alleen maar van Rijkswaterstaat te kopiëren Er is alleen informatie van Rijkswaterstaat gekopieerd 2.4 Eisenanalyse Eisen zijn niet gestructureerd Het is hier geen analyse, maar een herhaling van de eisen van Rijkswaterstaat Door de eisen hier te formuleren ben je bevooroordeeld in het denken in een bepaalde oplossingsrichting We hebben geen niveaus aangegeven bij de eisen wat suggereerde dat alle eisen zich op hetzelfde niveau bevinden. Het is geen analyse maar een opsomming van de al eerder door Rijkswaterstaat geformuleerde eisen De eigenlijke analyse moet na de functieanalyse komen, omdat er dan toegevoegde eisen bijkomen om de functies goed te beschrijven 2.5 Functieanalyse Moet onbevooroordeeld uitgevoerd worden Er moet ook wat mee gedaan worden anders is het tijdverdrijf. Een functieanalyse is altijd nodig Hoe preciezer je dingen formuleert, hoe groter de kans dat je ook krijgt wat je wilt hebben. Functioneel omschrijven is dus niet altijd beter De functieanalyse was hier niet zinvol, omdat functievervullers niet meer voldeden en vervangen moesten worden. De functievervullers waren er dus al en hoefden niet meer bepaald te worden Eisen zijn direct gekoppeld aan de functievervullers in plaats van de functies. Een functie wordt niet goed vervuld door de functievervuller en bij het renoveren van deze functievervuller zijn alle andere functies van het complex de randvoorwaarden Eisen zijn aan functievervullers (objecten) gekoppeld in plaats van aan functies. Dat komt doordat wij het zo gevraagd hebben, maar ook door gebrek aan ervaring van de andere kant Hier is teveel aandacht aan besteed in de aanbieding. Omdat het een bestaand systeem is, zijn alle functies al bekend. 2.6 Ontwerpafweging Er zijn niet zoveel reële oplossingsmogelijkheden voor handen Door de detaillering van de eisen van Rijkswaterstaat is er weinig keuzeruimte Gemaakte keuzes zijn niet transparant Sporadisch verrassende oplossingen 80 % van de afwegingen zijn niet zinnig Hoofdstuk: uitwerking interviews 11

119 Tijd die in de methode is gestoken weegt niet op tegen de voordelen die het biedt Keuzes zijn al gemaakt in de aanbiedingsfase maar niet opgeschreven Niet alle beslissingen zijn verwerkt in de documenten Voor veel onderdelen zijn geen keuzes gemaakt 80% van de installatietechnische ontwerpen zijn hetzelfde als 10 jaar geleden. De 20% veranderingen ligt aan de nieuwe ontwikkelingen en niet aan een afwegingsmodel. Systemen hebben bepaalde standaard oplossingen, vragen om alternatieven is werkverschaffing, want de standaard oplossing zal de trade-off winnen Afwegingen zijn gemaakt omdat we het gevraagd hebben, maar oplossingen zaten al in de hoofden. Het is dus werkverschaffing Er wordt ook gekeken naar uniformiteit en onderhoudbaarheid. Ook al is de conclusie dat een van de 10 componenten anders moet worden ingevuld volgens de trade-off, zullen er toch 10 dezelfde componenten worden toegepast. Oplossingen worden al bepaald in de aanbiedingsfase Alternatieven kunnen moeilijk gegenereerd worden omdat wij niet iets van een ander merk voorschrijven. Voor onze eigen producten hebben we richtlijnen waarin staat in welke situaties deze toegepast kunnen worden. Deze richtlijnen bepalen de afweging al, alternatieven zijn dan al afgevallen. Om deze alsnog te verwoorden is onzin. 2.7 Ontwerp De koppeling tussen de systemen HV-1, HV-2 en VOS mist De stap van het gehele complex naar de systemen mist door het lage niveau van het VO Er is nog steeds niet duidelijk wat er gaat komen, de vertaalslag moet nog steeds gemaakt worden Erg veel papier Ik ben niet overtuigd van de meerwaarde van de extra definitief ontwerpen, maar men roept dat binnen Systems Engineering deze definitieve ontwerpen niet kunnen en mogen ontbreken 2.8 RAMS Leveranciers weten niet wat de beschikbaarheid en betrouwbaarheid van hun eigen producten is Beschikbaarheid en betrouwbaarheidsberekeningen hebben weinig overtuiging omdat het statistisch is RAMS bepaald vaker dat er andere alternatieven gezocht en gekozen moeten worden dan de methode van ontwerpafwegingen en selectiecriteria De berekeningen zijn te conservatief. In de praktijk blijken de systemen beter te werken dan dat we geëist hebben 2.9 Raakvlakken Afstemming van de raakvlakken is niet te vinden Raakvlakken matrices horen niet in het rapport Het overzicht is niet handig gegroepeerd Raakvlakken werden met lijsten afgestemd omdat face-2-face teveel tijd kostte Raakvlakken moeten op hetzelfde niveau benoemd worden Er was weinig samenspraak Het werd gezien als verplicht nummer Er moet meer rekening gehouden worden met elkaars systeem Interne raakvlakken benoemen is een beetje onzinnig, want je bent als team bezig en verantwoordelijk voor een ontwerp Verificatie Moet meer visueel Geen eenduidige uitleg over wanneer je nu voldaan hebt Hoofdstuk: uitwerking interviews 12

120 Systems Engineering schiet hierin te kort Verificatie kan alleen goed gaan, wanneer het vanaf het begin goed is ingevuld Verificatie moet altijd in iemands achterhoofd zitten Verificatie gebeurd alleen binnen documenten en grijpt nu niet terug naar hogere niveaus De controle of de ontwerpen aan de eisen voldoen, is lastig grijpbaar Onderdelen doorschuiven naar het uitvoerings ontwerp kan natuurlijk niet in de verificatie Het had een kwalitatief slechte invulling Er is geen objecties koppeling te vinden. Je wilt per object alle eisen hebben. Dat levert veel papier, maar dan is alles wel traceerbaar Smarteam Als niemand de uitdraaien leest, waarom zouden we ze dan maken Smarteam zou niet op papier moeten verschijnen Smarteam gaf bij foutmeldingen aan dat er 5000 pagina s eisen waren Toegankelijkheid van smarteam is slecht. Binnen het programma weet ik het niet, maar op papier is het heel beperkt De indeling van smarteam uitdraaien was nooit hetzelfde en ook nooit goed. Er stonden veel overbodige coderingen en verschillende lettergroottes in Hoofdstuk: uitwerking interviews 13

121

122 Bijlage 3 enquête Hoofdstuk: enquête 15

123 Hoofdstuk: enquête 16

124 Systems Engineering SE is een discipline die een set methodieken aanreikt om het bouwproces in te richten en te beheersen. Met deze methodieken wordt bewerkstelligd dat men denkt vanuit functies, kijkt naar de gehele levenscyclus, transparant werkt en aantoonbare keuzes maakt. (werkdefinitie gebaseerd op Leidraad SE van Rijkswaterstaat, ProRail, Bouwend Nederland en ONRI (2007) en het INCOSE handboek (2007)) Sinds april 2007 wordt het zowel door ProRail als Rijkswaterstaat vereist als ontwerpmethode bij projecten, zo ook bij onder andere het project renovatie Haringvliet en Volkerak sluizencomplexen. Hieronder staan een aantal stellingen die gericht zijn op waarom SE er is en wanneer het toegepast wordt. Hoofdstuk: enquête 17

125 Systeembeschrijving Een systeembeschrijving is het vanuit het geheel benaderen van het project in plaats van vanuit de elementen. Er wordt gekeken naar het doel van het systeem; waarvoor dient het systeem. Van daaruit worden de functies bepaald die vervuld moeten worden binnen het systeem om dat doel te realiseren. Het vervullen van zo een functie is dan op zijn beurt weer het doel van een subsysteem, waarvoor binnen dat subsysteem vaak weer verscheidene functies nodig zijn, enz. Het is hierbij ook belangrijk te ontdekken welke subsystemen het meeste invloed uitoefenen op het functioneren van het gehele systeem (J. in t Veld, 2002) Hoofdstuk: enquête 18

126 Hoofdstuk: enquête 19

127 Eisenanalyse Onder een eisenanalyse wordt verstaan het categoriseren van eisen naar verschillende detailniveaus, het redigeren en passend formuleren (SMART) en het afleiden van eisen (CROW, 2007) Hoofdstuk: enquête 20

128 Functieanalyse De functie van een element (object of systeem) is datgene wat door dat element wordt teweeggebracht waaraan het grotere geheel behoefte heeft. Kortweg: de gewenste bijdrage van een deel aan een groter geheel waarvan het deel uitmaakt (J. in 't Veld, 2002) Een functieanalyse is daarbij een methode om een duidelijk en volledig beeld te vormen van het functioneren van een bouwwerk, om vervolgens een principeoplossing te vinden voor het ontwerpprobleem. Om de werking van een systeem te begrijpen is inzicht nodig in de samenhang en samenstelling van de functies (CROW, 2007). Hoofdstuk: enquête 21

129 Hoofdstuk: enquête 22

130 Ontwerpafweging De ontwerpafweging heeft als doel het afwegen van alternatieven in het ontwerp om zo aantoonbaar te maken dat het best passende alternatief gekozen is. Hoofdstuk: enquête 23

131 Hoofdstuk: enquête 24

132 Ontwerp Raakvlakken Als (sub)systemen en objecten zijn afgebakend, volgt een nadere analyse waarin per (sub)systeem de componenten en hun onderlinge samenhang in kaart worden gebracht. Bij verdergaande decompositieslagen worden ook de relaties met andere objecten steeds gedetailleerder vastgelegd. Dit is noodzakelijk omdat juist bij de raakvlakken vaak afstemmingsproblemen ontstaan die de kwaliteit van het project onder druk zetten. Raakvlakken vormen het gemeenschappelijke gebied waar afstemming over het ontwerp moet plaatsvinden (CROW, 2007) Hoofdstuk: enquête 25

133 Hoofdstuk: enquête 26

134 RAMS Reliability, availability(, maintainability, safety). De essentie is het expliciet maken van het prestatieniveau met als einddoel het verhogen van de kwaliteit. RA(MS) leidt onder andere tot emotieonafhankelijke en rationele beslissingen. Hoofdstuk: enquête 27

135 Verificatie Verificatie dient om aan te tonen dat bij elk ontwerp wordt voldaan aan de voorgeschreven specificatie. Samen te vatten in de vraag: bouw ik het juist? (o.a. CROW, 2007) Hoofdstuk: enquête 28

136 Bijlage 4 verantwoording enquête 4.1 Systems Engineering Systeembeschrijving Eisenanalyse Functieanalyse Ontwerpafweging Ontwerp RAMS Verificatie Systems Engineering Stellingen Herkomst Opmerkingen SE biedt structuur Theorie Eens SE biedt een controlemiddel ten behoeve van kwaliteit Insteek HOMIJ vanwege A73 project Eens, er moet bewezen worden dat HOMIJ wel kwaliteit kan SE zorgt voor verrassende oplossingen Interviews SE biedt beheersbaarheid van het Interviews project in tijd en geld SE reduceert de benodigde tijd Theorie Controlevraag SE maakt alle beslissingen expliciet Theorie Eens SE reduceert complexiteit Theorie Eens SE maakt het werk eenvoudiger Theorie Controlevraag SE is zinvol om toe te passen bij grond-, weg- en waterbouwprojecten SE is zinvol om toe te passen bij Installatietechnische projecten SE moet toegepast worden wanneer de projectonderdelen afhankelijk van elkaar zijn SE moet toegepast worden bij projecten waar veel partijen belangen in hebben of er veel tegenstrijdige belangen zijn SE heeft geen nut bij projectcases waarbinnen weinig vrijheid wordt gegeven SE moet toegepast worden wanneer het project multidisciplinair is SE moet toegepast worden voor een projectgrootte in de ontwerpfase vanaf (bedragen in euro s) SE moet toegepast worden vanaf een projectomvang van (aantal medewerkers) SE moet toegepast worden bij een Theorie Interviews Theorie, projectkenmerken Theorie, projectkenmerken Interviews Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken leveren. Niet binnen HVVOS, want er was geen keuzeruimte geboden door de Opdrachtgever Daarin zit de meerwaarde van Systems Engineering. Eens (Leidraad SE) Oneens, installatietechniek heeft veel meer systemen dan GWW wat het complex maakt. Ook zijn er voor veel situaties al oplossingen, dus afwegingen zijn niet altijd zinvol. Eens (ProRail) Eens (ProRail) Neutraal, afwegingen zijn dan niet nuttig en er is weinig leereffect, maar SE zorgt wel voor beheersbaarheid en structuur. ProRail ProRail Hoofdstuk: verantwoording enquête 29

137 projectduur in de ontwerpfase vanaf (tijdsduur in maanden) SE moet toegepast worden in nieuwbouw projecten SE moet toegepast worden in renovatieprojecten Theorie Theorie Interviews Leidraad Systems Engineering Eens Oneens, want alles ligt al vast dus heeft SE geen meerwaarde meer. 4.2 Systeembeschrijving Stellingen Herkomst Opmerkingen De systeembeschrijving wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Het is nodig om deze stap expliciet op te schrijven Een systeembeschrijving moet gegeven worden ongeacht de complexiteit Ook bij weinig complexe projecten is een systeembeschrijving zinvol Een systeembeschrijving moet gegeven worden ongeacht de projectomvang Een systeembeschrijving moet gegeven worden ongeacht de planning Een systeembeschrijving moet gegeven worden ongeacht het aantal disciplines Ook bij monodisciplinaire projecten is een systeembeschrijving zinvol De verschillen tussen de huidige en gewenste situatie moeten duidelijk in beeld komen Een systeembeschrijving geeft een beeld van het project Een systeembeschrijving geeft aan wat er moet veranderen Een systeembeschrijving geeft aan welke functies een complex heeft Een systeembeschrijving geeft relaties weer Een systeembeschrijving beschrijft de functies van een project 4.3 Eisenanalyse Interviews Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Interviews Theorie Interviews Theorie Theorie 1 Gesprekken met afstudeercommissie Gesprekken 1 Draagt bij aan het doel van het onderzoek Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Controlevraag Controlevraag Jan in t Veld Dat werd bij HVVOS als gemis gezien. Hoofdstuk: verantwoording enquête 30

138 Stellingen Herkomst Opmerkingen De eisenanalyse wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Het is nodig om deze stap expliciet op te schrijven Een eisenanalyse moet gegeven worden ongeacht de complexiteit Ook bij weinig complexe projecten is een eisenanalyse zinvol Een eisenanalyse moet gegeven worden ongeacht de projectomvang Een eisenanalyse moet gegeven worden ongeacht de planning Een eisenanalyse moet gegeven worden ongeacht het aantal disciplines Ook bij monodisciplinaire projecten is een eisenanalyse zinvol Een eisenanalyse bevooroordeeld je in het denken in een bepaalde oplossingsrichting en moet dus na de ontwerpafweging gedaan worden Een opsomming van de eisen van Rijkswaterstaat is voldoende, er hoeft geen analyse gedaan te worden Hoe meer eisen er geformuleerd worden, des te minder ontwerpvrijheid heb je Hoe meer eisen je formuleert, des te kleiner is de kans dat je krijgt wat je verwacht Interviews Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Interviews Interviews Interviews, gesprekken 2 Interviews, gesprekken 2 Draagt bij aan het doel van het onderzoek Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Controlevraag Controlevraag Elke eis heeft een topeis Gesprekken 2 Oneens Eisen stellen zonder te sturen op een oplossingsrichting is onmogelijk Interviews 4.4 Functieanalyse Hierbij werd verondersteld dat eisen aan objecten en niet aan functies kunnen worden gesteld. Eisen beschrijven dan al gedeeltelijk het object en laten je niet vrij in het ontwerpen. De eisenanalyse van HVVOS werd als opsomming gezien. Stellingen Herkomst Opmerkingen De functieanalyse wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Draagt bij aan het doel van het onderzoek 2 Gesprekken met afstudeercommissie Hoofdstuk: verantwoording enquête 31

139 Het is nodig om deze stap expliciet op te schrijven Een functieanalyse moet gegeven worden ongeacht de complexiteit Ook bij weinig complexe projecten is een functieanalyse zinvol Een functieanalyse moet gegeven worden ongeacht de projectomvang Een functieanalyse moet gegeven worden ongeacht de planning Een functieanalyse moet gegeven worden ongeacht het aantal disciplines Ook bij monodisciplinaire projecten is een functieanalyse zinvol Een functieanalyse moet altijd worden gedaan Een functieanalyse wordt gedaan om innovatieve oplossingen in de hand te werken Een functieanalyse wordt gedaan om ervoor te zorgen dat er geen gaten vallen in het eisenpakket Functioneel beschrijven is niet altijd beter. Hoe preciezer je dingen formuleert, hoe groter de kans dat je krijgt wat je hebben wilt. Als je weet wat je wilt hebben, moet je het niet functioneel beschrijven, maar gewoon met eisen en wensen. Een functieanalyse is niet zinvol als er al functievervullers zijn, die alleen niet meer voldoen Een functie die niet goed meer vervuld wordt door zijn functievervuller, moet opnieuw vervuld worden. Daarbij fungeren de andere al vervulde of nog te vervullen functies als randvoorwaarden Een functieanalyse kan niet gemaakt worden zonder dat het ontwerp voor handen is Interviews Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Gesprekken 3 HVVOS 3 Gesprekken met afstudeercommissie Interviews Interviews Interviews Interviews Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Controlevraag Controlevraag Eerst werden de eisen geformuleerd en daarna de functieanalyse gedaan. Dan wordt duidelijk of alle eisen gesteld zijn en kunnen gaten opgevuld worden. Dat wordt ook als functie van de functieanalyse gezien. Waarom een pomp functioneel beschrijven, wanneer je er gewoon een nieuwe in kunt zetten? Andere functies moeten vervuld blijven en mogen niet te leiden hebben onder het opnieuw invullen van een andere functie. Hoofdstuk: verantwoording enquête 32

140 Eisen worden aan functies gesteld Eisen worden aan functievervullers gesteld Functionele eisen zijn oplossingsvrij Een functionele eis beschrijft de prestatie van een functie 4.5 Ontwerpafweging Theorie Interviews Theorie Theorie, gesprekken 4 Controlevraag CROW Stellingen Herkomst Opmerkingen De ontwerpafweging wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Het is nodig om deze stap expliciet op te schrijven Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betref Ontwerpafwegingen van specifieke installatietechnische oplossingen zijn niet zinvol Er wordt door Rijkswaterstaat zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn Het gaat slechts sporadisch om verassende oplossingen De voordelen die de ontwerpafwegingen opleveren, wegen niet op tegen de tijd die het kost Keuzes zijn al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om het hier nog een keer te doen 80% van de ontwerpen in de installatietechniek zijn nu hetzelfde als 10 jaar geleden De 20% die verschilt in de ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen 4.6 Ontwerp Interviews Interviews Interviews Interviews Interviews Interviews Interviews Interviews Interviews Draagt bij aan het doel van het onderzoek Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Voor standaardsituaties zijn standaardoplossingen Voor specifieke installatietechnische problemen zijn al specifieke oplossingen. Gegenereerde alternatieven voldoen niet aan de criteria (bijvoorbeeld budget) omdat bij het formuleren van die criteria al uit is gegaan van een bepaalde oplossing Stellingen Herkomst Opmerkingen Op basis van een objectenboom kan gebouwd worden Gesprekken 4 Oneens, maar het maken van bestekstekeningen wordt uitgesteld. Een objectenboom formuleren Gesprekken 4 4 Gesprekken met afstudeercommissie Hoofdstuk: verantwoording enquête 33

141 is gelijk aan ontwerpen Voor ontwerpers is het net zo makkelijk om in plaats van alleen maar het object ook een specificatie op te schrijven, het zit toch in het hoofd. Interviews Raakvlakken Stellingen Herkomst Opmerkingen De raakvlakken worden ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Het is nodig om deze stap expliciet op te schrijven De beschrijving van de raakvlakken moet gegeven worden ongeacht de complexiteit Ook bij weinig complexe projecten is een raakvlakanalyse zinvol De beschrijving van de raakvlakken moet gegeven worden ongeacht de projectomvang De beschrijving van de raakvlakken moet gegeven worden ongeacht de planning De beschrijving van de raakvlakken moet gegeven worden ongeacht het aantal disciplines Ook bij monodisciplinaire projecten is een raakvlakanalyse zinvol Raakvlakken moeten afgestemd worden tussen de verschillende systemen en disciplines, alleen opschrijven per systeem is zinloos Interne raakvlakken zijn onzinnig, want deze zitten binnen een ontwerp waar je als team mee bezig bent en verantwoordelijk voor bent Het formuleren van raakvlakken gebeurt op basis van een objecten structuur Het formuleren van raakvlakken gebeurt op basis van een ontwerp Raakvlakken moeten weergegeven worden in een tekening 5 Gesprekken met afstudeercommissie Interviews Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Interviews Interviews Gesprekken 5 Gesprekken 5 Interviews Draagt bij aan het doel van het onderzoek Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Controlevraag Controlevraag Raakvlakken kunnen ook visueel worden uitgebeeld, en plaatjes zeggen meer dan Hoofdstuk: verantwoording enquête 34

142 woorden. 4.7 RAMS Stellingen Herkomst Opmerkingen De RA(MS) analyse wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Het is nodig om deze stap expliciet op te schrijven Een RAMSanalyse moet gedaan worden ongeacht de complexiteit Ook bij weinig complexe projecten is een RAMSanalyse zinvol Een RAMSanalyse moet gedaan worden ongeacht de projectomvang Een RAMSanalyse moet gedaan worden ongeacht de planning Een RAMSanalyse moet gedaan worden ongeacht het aantal disciplines Ook bij monodisciplinaire projecten is een RAMSanalyse zinvol RAMS bepaalt vaker dat er andere alternatieven gezocht en gekozen moeten worden dan de selectiecriteria in de ontwerpafweging RAMS is weinig overtuigend want het is slechts statistiek Als RA(MS) gecheckt is en voldoet dan ben ik volledig RA(MS) is onnodig duur Voor een goede RA(MS) analyse is een volledige systeembeschrijving nodig 4.8 Verificatie Interviews Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Interviews Interviews Gesprekken 6 Interviews Interviews Draagt bij aan het doel van het onderzoek Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Controlevraag Controlevraag Stellingen Herkomst Opmerkingen De verificatie wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Interviews Het is nodig om deze stap expliciet op te schrijven 6 Gesprekken met afstudeercommissie Interviews RAMS voorwaarden zijn meer bindend dan de selectiecriteria. Hier valt niet over te onderhandelen. Het is gebaseerd op theoretische waarden. Oneens. Als het complex beschikbaar, betrouwbaar, veilig en onderhoudbaar is, dan voldoet het. Er wordt dan geen rekening gehouden met kosten, planning etc. Draagt bij aan het doel van het onderzoek Systems Engineering betekent veel papierwerk en Hoofdstuk: verantwoording enquête 35

143 Een verificatie moet uitgevoerd worden ongeacht de complexiteit Ook bij weinig complexe projecten is een verificatie zinvol Een verificatie moet uitgevoerd worden ongeacht de projectomvang Een verificatie moet uitgevoerd worden ongeacht de planning Een verificatie moet uitgevoerd worden ongeacht het aantal disciplines Ook bij monodisciplinaire projecten is een verificatie zinvol Een verificatie moet altijd uitgevoerd worden Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Theorie, projectkenmerken Interviews Verificatie is, in de huidige Interviews vorm, maar beperkt zinvol. Het is nog steeds lastig grijpbaar of ontwerpen nu echt aan de eisen voldoen Verificatie is de ontwerpcontrole Gesprekken 7 De opdrachtgever is Gesprekken 7 verantwoordelijk voor het juist formuleren van de topeis administratie, is dat allemaal nodig? Controlevraag Controlevraag Het wordt nu vaak ingevuld zonder terug te kijken naar documenten, maar op geheugen. 7 Gesprekken met afstudeercommissie Hoofdstuk: verantwoording enquête 36

144 Bijlage 5 enquête resultaten losse vragen 5.1 Algemeen Systems Engineering Systeembeschrijving Eisenanalyse Functieanalyse Ontwerpafweging Ontwerp Raakvlakken RAMS Verificatie Algemeen In welke soort organisatie bent u werkzaam? Valid Frequency Percent Percent Percent Valid Aannemer 3 8,8 8,8 8,8 Ingenieursbureau 21 61,8 61,8 70,6 Opdrachtgever 5 14,7 14,7 85,3 Consultancy 5 14,7 14,7 100,0 Wat is uw hoogst genoten opleiding? Frequency Percent Valid Percent Percent Valid HBO 13 38,2 38,2 38,2 WO 20 58,8 58,8 97,1 WO+ 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 37

145 Wat is uw hoogst genoten opleiding? Frequency Percent Valid Percent Percent Valid HBO 13 38,2 38,2 38,2 WO 20 58,8 58,8 97,1 WO+ 1 2,9 2,9 100,0 Hoeveel jaren werkervaring heeft u? Frequency Percent Valid Percent Percent Valid 1-4 jaar 10 29,4 29,4 29, jaar 4 11,8 11,8 41,2 meer dan 10 jaar 20 58,8 58,8 100,0 Hoofdstuk: enquête resultaten losse vragen 38

146 Hoeveel jaren projectervaring heeft u? Frequency Percent Valid Percent Percent Valid 1-4 jaar 12 35,3 35,3 35, jaar 3 8,8 8,8 44,1 meer dan 10 jaar 19 55,9 55,9 100,0 Wat is de gemiddelde omvang van de projecten waar u bij betrokken bent? Frequency Percent Valid Percent Percent Valid klein 1 2,9 2,9 2,9 middel 14 41,2 41,2 44,1 groot 19 55,9 55,9 100,0 Hoofdstuk: enquête resultaten losse vragen 39

147 Hoeveel ervaring heeft u met Systems Engineering? Frequency Percent Valid Percent Percent Valid geen 2 5,9 5,9 5,9 minder dan 2 jaar 13 38,2 38,2 44,1 2-4 jaar 12 35,3 35,3 79,4 meer dan 4 jaar 7 20,6 20,6 100,0 Hoeveel projecten heeft u doorgaans naast elkaar lopen waarbij Systems Engineering wordt ingezet? Frequency Percent Valid Percent Percent Valid ,4 32,4 32, ,1 47,1 79,4 meer dan ,7 14,7 94,1 weggevallen 2 5,9 5,9 100,0 Hoofdstuk: enquête resultaten losse vragen 40

148 Hoelang bent u betroken geweest bij HVVOS Frequency Percent Valid Percent Percent Valid vanaf de initiatie 8 23,5 23,5 23,5 vanaf de aanbieding 2 5,9 5,9 29,4 vanaf de gunning 2 5,9 5,9 35,3 n.v.t ,8 61,8 97,1 weggevallen 1 2,9 2,9 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 3 8,8 8,8 14,7 Hoofdstuk: enquête resultaten losse vragen 41

149 neutraal 4 11,8 11,8 26,5 mee eens 17 50,0 50,0 76,5 helemaal mee eens 8 23,5 23,5 100,0 Systems Engineering is voor mij? Een hoop administratie een methode die alleen goed bruikbaar is bij het ontwerp van nieuwe projecten in combinatie met de juiste tools. Een hulpmiddel om gestructureerd te ontwerpen. Een formeel systeemontwikkelingtraject onder een gestructureerde manier van werken. Een vehikel wat voor complexe installatietechniek zich nog niet heeft bewezen. Een methodiek om op een expliciete wijze te komen van een idee tot een oplossing In theorie een goede methode om (alle mogelijke) verschillende afwegingen te maken. In praktijk een omslachtige en tijdrovende werkmethode... een noodzakelijk middel om werkelijke projectbeheersing te kunnen doen, n.l. projectbeheersing via de inhoud Een methode waarbij inzichtelijk zou moeten zijn of de juiste ontwerpafwegingen, etc zijn gekozen. een dagtaak binnen een project Nu nog voorgeschreven hulpmiddel, maar ik zie het voordeel ontstaan Een methodiek om gestructureerd (complexe) systemen in te richten en in stand te houden die (aantoonbaar) optimaal aan de gebruikerswensen voldoen. In theorie een manier om het ontwerpproces gestructureerd te laten verlopen, in de praktijk door ON aantonen van de door OG gestelde eisen. Een manier om structuur aan te brengen in projecten. Een beheers tool De ontwerpdiscipline waarmee complexe systemen worden ontworpen, gerealiseerd en geëxploiteerd. Daarnaast is SE voor mij het theoretisch kader om het gedrag van complexe systemen te begrijpen. Systematisch + expliciet werken en vastleggen van ontwerpuitgangspunten. Een holistisch ontwikkelproces dat, indien het volledig (uitgaande levenscyclus) en correct doorlopen wordt, voor borgt dat de opdrachtgever iets krijgt waarmee zijn probleem opgelost wordt. Het bewust vast laten leggen van stappen, zoals eigenlijk ook volgens de ISO zou moeten Denken op abstract niveau en details vergeten. Een goed stuk gereedschap, mits op de goede wijze gebruikt. Expliciet werken. Een middel om het doel (succesvol project) te verwezenlijken een methode om controle te krijgen over de scope, stakeholders en het proces Een goede manier van efficiënt en effectief te werken om binnen complexe projecten tot Hoofdstuk: enquête resultaten losse vragen 42

150 acceptabel resultaat te komen. een methodiek om middels voorgeschreven werkwijze een project uit te voeren Het gestructureerd doorlopen van de levenscyclus van een systeem, zodanig dat het systeem bij oplevering, en gedurende de gehele gebruiks- en onderhoudsfase op aantoonbare wijze voldoet aan de gestelde stakeholders- en systeemeisen. Een middel om de kwaliteit te borgen, maar indien fout toegepast een hoop administratie Een papieren tijger een gestructureerde en transparante werkwijze voor bestaande projecten (renovatie)niet zinvol. Voor nieuwbouw zou het eventueel kunnen. Het verzandt al snel in een enorme papierwinkel, waarbij zelfs de meest gangbare zaken onbegrijpelijk worden;) 5.2 Systems Engineering SE biedt structuur Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 2 5,9 5,9 14,7 mee eens 15 44,1 44,1 58,8 helemaal mee eens 14 41,2 41,2 100,0 SE biedt een controlemiddel ten behoeve van kwaliteit Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 43

151 helemaal mee oneens 1 2,9 2,9 8,8 mee oneens 2 5,9 5,9 14,7 neutraal 6 17,6 17,6 32,4 mee eens 15 44,1 44,1 76,5 helemaal mee eens 8 23,5 23,5 100,0 SE zorgt voor verrassende oplossingen Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 2 5,9 5,9 11,8 mee oneens 11 32,4 32,4 44,1 neutraal 11 32,4 32,4 76,5 mee eens 8 23,5 23,5 100,0 Hoofdstuk: enquête resultaten losse vragen 44

152 SE biedt beheersbaarheid van het project in tijd en geld Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 2 5,9 5,9 11,8 mee oneens 9 26,5 26,5 38,2 neutraal 8 23,5 23,5 61,8 mee eens 10 29,4 29,4 91,2 helemaal mee eens 3 8,8 8,8 100,0 SE maakt alle beslissingen expliciet Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 45

153 mee oneens 4 11,8 11,8 17,6 neutraal 9 26,5 26,5 44,1 mee eens 13 38,2 38,2 82,4 helemaal mee eens 6 17,6 17,6 100,0 SE maakt het werk eenvoudiger Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 5 14,7 14,7 20,6 mee oneens 12 35,3 35,3 55,9 neutraal 8 23,5 23,5 79,4 mee eens 7 20,6 20,6 100,0 Hoofdstuk: enquête resultaten losse vragen 46

154 SE reduceert de benodigde tijd Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 4 11,8 11,8 17,6 mee oneens 13 38,2 38,2 55,9 neutraal 9 26,5 26,5 82,4 mee eens 6 17,6 17,6 100,0 SE reduceert complexiteit Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 4 11,8 11,8 17,6 mee oneens 9 26,5 26,5 44,1 neutraal 8 23,5 23,5 67,6 mee eens 10 29,4 29,4 97,1 helemaal mee eens 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 47

155 Het gebruik van SE komt de kwaliteit van het eindproduct niet ten goede Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 6 17,6 17,6 23,5 mee oneens 13 38,2 38,2 61,8 neutraal 10 29,4 29,4 91,2 mee eens 3 8,8 8,8 100,0 SE is zinvol om toe te passen bij grond, weg- en waterbouwprojecten Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 neutraal 14 41,2 41,2 47,1 Hoofdstuk: enquête resultaten losse vragen 48

156 mee eens 14 41,2 41,2 88,2 helemaal mee eens 4 11,8 11,8 100,0 SE is zinvol om toe te passen bij Installatietechnische projecten Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 2 5,9 5,9 11,8 neutraal 12 35,3 35,3 47,1 mee eens 7 20,6 20,6 67,6 helemaal mee eens 11 32,4 32,4 100,0 SE moet toegepast worden wanneer de projectonderdelen afhankelijk van elkaar zijn Hoofdstuk: enquête resultaten losse vragen 49

157 Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 2 5,9 5,9 11,8 neutraal 10 29,4 29,4 41,2 mee eens 15 44,1 44,1 85,3 helemaal mee eens 5 14,7 14,7 100,0 SE moet toegepast worden bij projecten waar veel partijen belangen in hebben of er veel tegenstrijdige belangen zijn Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 neutraal 12 35,3 35,3 41,2 mee eens 15 44,1 44,1 85,3 helemaal mee eens 5 14,7 14,7 100,0 Hoofdstuk: enquête resultaten losse vragen 50

158 SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt gegeven Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 3 8,8 8,8 14,7 mee oneens 10 29,4 29,4 44,1 neutraal 4 11,8 11,8 55,9 mee eens 10 29,4 29,4 85,3 helemaal mee eens 5 14,7 14,7 100,0 SE moet toegepast worde wanneer het project multidisciplinair is Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 51

159 mee oneens 1 2,9 2,9 8,8 neutraal 7 20,6 20,6 29,4 mee eens 17 50,0 50,0 79,4 helemaal mee eens 7 20,6 20,6 100,0 SE moet toegepast worden voor een projectgrootte in de ontwerpfase vanaf Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 < 1000 euro 4 11,8 11,8 17, euro 6 17,6 17,6 35, euro 10 29,4 29,4 64, euro 7 20,6 20,6 85,3 > ,7 14,7 100,0 Hoofdstuk: enquête resultaten losse vragen 52

160 SE moet toegepast worden vanaf een projectomvang van Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 < 10 projectmedewerkers 17 50,0 50,0 55,9 15 projectmedewerkers 9 26,5 26,5 82,4 20 projectmedewerkers 2 5,9 5,9 88,2 25 projectmedewerkers 1 2,9 2,9 91,2 > 25 projectmedewerkers 3 8,8 8,8 100,0 SE moet toegepast worden bij een projectduur in de ontwerpfase vanaf Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 53

161 < 1 week 5 14,7 14,7 20,6 1 maand 9 26,5 26,5 47,1 6 maanden 12 35,3 35,3 82,4 1 jaar 2 5,9 5,9 88,2 > 1,5 jaar 4 11,8 11,8 100,0 SE moet toegepast worden in nieuwbouw projecten Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 3 8,8 8,8 17,6 mee eens 19 55,9 55,9 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 54

162 SE moet toegepast worden in renovatie projecten Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 3 8,8 8,8 14,7 mee oneens 8 23,5 23,5 38,2 neutraal 6 17,6 17,6 55,9 mee eens 12 35,3 35,3 91,2 helemaal mee eens 3 8,8 8,8 100,0 5.3 Systeembeschrijving Ik heb ervaring met het begrip systeembeschrijving Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 55

163 Valid Ja 32 94,1 94,1 94,1 Nee 2 5,9 5,9 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 2 5,9 5,9 14,7 mee eens 22 64,7 64,7 79,4 helemaal mee eens 7 20,6 20,6 100,0 De systeembeschrijving wordt ingevuld omdat het meerwaarde heeft Hoofdstuk: enquête resultaten losse vragen 56

164 Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 1 2,9 2,9 11,8 mee eens 21 61,8 61,8 73,5 helemaal mee eens 9 26,5 26,5 100,0 Het is nodig om de systeembeschrijving expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 neutraal 3 8,8 8,8 14,7 mee eens 16 47,1 47,1 61,8 helemaal mee eens 13 38,2 38,2 100,0 Hoofdstuk: enquête resultaten losse vragen 57

165 De systeembeschrijving wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 3 8,8 8,8 14,7 mee oneens 7 20,6 20,6 35,3 neutraal 11 32,4 32,4 67,6 mee eens 9 26,5 26,5 94,1 helemaal mee eens 2 5,9 5,9 100,0 Een systeembeschrijving moet gegeven worden ongeacht de complexiteit Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 58

166 mee oneens 2 5,9 5,9 11,8 neutraal 2 5,9 5,9 17,6 mee eens 16 47,1 47,1 64,7 helemaal mee eens 12 35,3 35,3 100,0 Een systeembeschrijving moet gegeven worden ongeacht de projectomvang Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 2 5,9 5,9 11,8 neutraal 3 8,8 8,8 20,6 mee eens 15 44,1 44,1 64,7 helemaal mee eens 12 35,3 35,3 100,0 Hoofdstuk: enquête resultaten losse vragen 59

167 Een systeembeschrijving moet gegeven worden ongeacht de planning Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 5 14,7 14,7 23,5 mee eens 14 41,2 41,2 64,7 helemaal mee eens 12 35,3 35,3 100,0 Een systeembeschrijving moet gegeven worden ongeacht het aantal disciplines Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 3 8,8 8,8 17,6 mee eens 16 47,1 47,1 64,7 helemaal mee eens 12 35,3 35,3 100,0 Hoofdstuk: enquête resultaten losse vragen 60

168 De verschillen tussen de huidige en gewenste situatie moeten duidelijk in beeld komen Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 1 2,9 2,9 8,8 neutraal 2 5,9 5,9 14,7 mee eens 15 44,1 44,1 58,8 helemaal mee eens 14 41,2 41,2 100,0 Ook bij weinig complexe projecten is een systeembeschrijving zinvol Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 61

169 neutraal 5 14,7 14,7 20,6 mee eens 13 38,2 38,2 58,8 helemaal mee eens 14 41,2 41,2 100,0 Ook bij monodisciplinaire projecten is een systeembeschrijving zinvol Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 neutraal 5 14,7 14,7 20,6 mee eens 14 41,2 41,2 61,8 helemaal mee eens 13 38,2 38,2 100,0 Een systeembeschrijving geeft een beeld van het project Hoofdstuk: enquête resultaten losse vragen 62

170 Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 1 2,9 2,9 8,8 mee oneens 2 5,9 5,9 14,7 neutraal 4 11,8 11,8 26,5 mee eens 16 47,1 47,1 73,5 helemaal mee eens 9 26,5 26,5 100,0 Een systeembeschrijving geeft aan wat er moet veranderen Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 3 8,8 8,8 14,7 mee oneens 7 20,6 20,6 35,3 neutraal 8 23,5 23,5 58,8 mee eens 10 29,4 29,4 88,2 helemaal mee eens 4 11,8 11,8 100,0 Hoofdstuk: enquête resultaten losse vragen 63

171 Een systeembeschrijving geeft aan welke functies een complex heeft Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 5 14,7 14,7 20,6 neutraal 3 8,8 8,8 29,4 mee eens 16 47,1 47,1 76,5 helemaal mee eens 8 23,5 23,5 100,0 Een systeembeschrijving geeft relaties weer Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 1 2,9 2,9 8,8 Hoofdstuk: enquête resultaten losse vragen 64

172 mee oneens 8 23,5 23,5 32,4 neutraal 8 23,5 23,5 55,9 mee eens 10 29,4 29,4 85,3 helemaal mee eens 5 14,7 14,7 100,0 Een systeembeschrijving beschrijft de functies van het project Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 mee oneens 6 17,6 17,6 23,5 neutraal 4 11,8 11,8 35,3 mee eens 13 38,2 38,2 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 65

173 5.4 Eisenanalyse Ik heb ervaring met het begrip eisenanalyse Frequency Percent Valid Percent Percent Valid Ja 30 88,2 88,2 88,2 Nee 4 11,8 11,8 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 mee oneens 2 5,9 5,9 17,6 neutraal 4 11,8 11,8 29,4 mee eens 19 55,9 55,9 85,3 helemaal mee eens 5 14,7 14,7 100,0 Hoofdstuk: enquête resultaten losse vragen 66

174 De eisenanalyse wordt ingevuld omdat het meerwaarde heeft Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 mee oneens 2 5,9 5,9 17,6 neutraal 5 14,7 14,7 32,4 mee eens 15 44,1 44,1 76,5 helemaal mee eens 8 23,5 23,5 100,0 Het is nodig om de eisenanalyse expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 mee oneens 2 5,9 5,9 17,6 Hoofdstuk: enquête resultaten losse vragen 67

175 neutraal 5 14,7 14,7 32,4 mee eens 14 41,2 41,2 73,5 helemaal mee eens 9 26,5 26,5 100,0 De eisenanalyse wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 helemaal mee oneens 3 8,8 8,8 20,6 mee oneens 5 14,7 14,7 35,3 neutraal 8 23,5 23,5 58,8 mee eens 9 26,5 26,5 85,3 helemaal mee eens 5 14,7 14,7 100,0 Hoofdstuk: enquête resultaten losse vragen 68

176 Een eisenanalyse moet gegeven worden ongeacht de complexiteit Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 mee oneens 3 8,8 8,8 20,6 neutraal 5 14,7 14,7 35,3 mee eens 13 38,2 38,2 73,5 helemaal mee eens 9 26,5 26,5 100,0 Een eisenanalyse moet gegeven worden ongeacht de projectomvang Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 mee oneens 5 14,7 14,7 26,5 neutraal 4 11,8 11,8 38,2 mee eens 12 35,3 35,3 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 69

177 Een eisenanalyse moet gegeven worden ongeacht de planning Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 helemaal mee oneens 1 2,9 2,9 14,7 mee oneens 3 8,8 8,8 23,5 neutraal 5 14,7 14,7 38,2 mee eens 12 35,3 35,3 73,5 helemaal mee eens 9 26,5 26,5 100,0 Een eisenanalyse moet gegeven worden ongeacht het aantal disciplines Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 Hoofdstuk: enquête resultaten losse vragen 70

178 mee oneens 4 11,8 11,8 23,5 neutraal 6 17,6 17,6 41,2 mee eens 11 32,4 32,4 73,5 helemaal mee eens 9 26,5 26,5 100,0 Een eisenanalyse bevooroordeeld je in het denken in een bepaalde oplossingsrichting en moet dus na de ontwerpafweging gedaan worden Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 14 41,2 41,2 55,9 mee oneens 7 20,6 20,6 76,5 neutraal 2 5,9 5,9 82,4 mee eens 4 11,8 11,8 94,1 helemaal mee eens 2 5,9 5,9 100,0 Hoofdstuk: enquête resultaten losse vragen 71

179 Ook bij weinig complexe projecten is een eisenanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 helemaal mee oneens 1 2,9 2,9 14,7 mee oneens 2 5,9 5,9 20,6 neutraal 6 17,6 17,6 38,2 mee eens 15 44,1 44,1 82,4 helemaal mee eens 6 17,6 17,6 100,0 Ook bij monodisciplinaire projecten is een eisenanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 4 11,8 11,8 11,8 Hoofdstuk: enquête resultaten losse vragen 72

180 mee oneens 2 5,9 5,9 17,6 neutraal 7 20,6 20,6 38,2 mee eens 14 41,2 41,2 79,4 helemaal mee eens 7 20,6 20,6 100,0 Een opsomming van de eisen van Rijkswaterstaat is voldoende, er hoeft geen analyse gedaan te worden Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 12 35,3 35,3 50,0 mee oneens 13 38,2 38,2 88,2 neutraal 4 11,8 11,8 100,0 Hoofdstuk: enquête resultaten losse vragen 73

181 Hoe meer eisen er geformuleerd worden, des te minder ontwerpvrijheid heb je Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 2 5,9 5,9 20,6 mee oneens 4 11,8 11,8 32,4 neutraal 8 23,5 23,5 55,9 mee eens 9 26,5 26,5 82,4 helemaal mee eens 6 17,6 17,6 100,0 Hoe meer eisen je formuleert, des te kleiner is de kans dat je krijgt wat je verwacht Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 4 11,8 11,8 26,5 mee oneens 14 41,2 41,2 67,6 neutraal 9 26,5 26,5 94,1 mee eens 1 2,9 2,9 97,1 helemaal mee eens 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 74

182 Elke eis heeft een topeis Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 mee oneens 6 17,6 17,6 32,4 neutraal 5 14,7 14,7 47,1 mee eens 9 26,5 26,5 73,5 helemaal mee eens 9 26,5 26,5 100,0 Eisen stellen zonder te sturen op een oplossingsrichting is onmogelijk Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 8 23,5 23,5 38,2 Hoofdstuk: enquête resultaten losse vragen 75

183 mee oneens 10 29,4 29,4 67,6 neutraal 4 11,8 11,8 79,4 mee eens 3 8,8 8,8 88,2 helemaal mee eens 4 11,8 11,8 100,0 5.5 Functieanalyse Ik heb ervaring met het begrip functieanalyse Frequency Percent Valid Percent Percent Valid Ja 26 76,5 76,5 76,5 Nee 8 23,5 23,5 100,0 De definitie van functie die hierboven gegeven is juist Hoofdstuk: enquête resultaten losse vragen 76

184 Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 mee oneens 1 2,9 2,9 26,5 neutraal 7 20,6 20,6 47,1 mee eens 12 35,3 35,3 82,4 helemaal mee eens 6 17,6 17,6 100,0 De definitie van functieanalyse die hierboven gegeven is juist Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 2 5,9 5,9 32,4 neutraal 6 17,6 17,6 50,0 mee eens 11 32,4 32,4 82,4 helemaal mee eens 6 17,6 17,6 100,0 Hoofdstuk: enquête resultaten losse vragen 77

185 De functieanalyse wordt ingevuld omdat het meerwaarde heeft Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 2 5,9 5,9 32,4 neutraal 6 17,6 17,6 50,0 mee eens 11 32,4 32,4 82,4 helemaal mee eens 6 17,6 17,6 100,0 Het is nodig om de functieanalyse expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 Hoofdstuk: enquête resultaten losse vragen 78

186 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 1 2,9 2,9 29,4 neutraal 5 14,7 14,7 44,1 mee eens 11 32,4 32,4 76,5 helemaal mee eens 8 23,5 23,5 100,0 De functieanalyse wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 7 20,6 20,6 50,0 neutraal 6 17,6 17,6 67,6 mee eens 8 23,5 23,5 91,2 helemaal mee eens 3 8,8 8,8 100,0 Hoofdstuk: enquête resultaten losse vragen 79

187 Een functieanalyse moet gegeven worden ongeacht de complexiteit Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 6 17,6 17,6 47,1 neutraal 5 14,7 14,7 61,8 mee eens 7 20,6 20,6 82,4 helemaal mee eens 6 17,6 17,6 100,0 Een functieanalyse moet gegeven worden ongeacht de projectomvang Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 Hoofdstuk: enquête resultaten losse vragen 80

188 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 6 17,6 17,6 47,1 neutraal 5 14,7 14,7 61,8 mee eens 7 20,6 20,6 82,4 helemaal mee eens 6 17,6 17,6 100,0 Een functieanalyse moet gegeven worden ongeacht de planning Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 5 14,7 14,7 44,1 neutraal 6 17,6 17,6 61,8 mee eens 6 17,6 17,6 79,4 helemaal mee eens 7 20,6 20,6 100,0 Hoofdstuk: enquête resultaten losse vragen 81

189 Een functieanalyse moet gegeven worden ongeacht het aantal disciplines Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 4 11,8 11,8 41,2 neutraal 4 11,8 11,8 52,9 mee eens 10 29,4 29,4 82,4 helemaal mee eens 6 17,6 17,6 100,0 Een functieanalyse moet altijd worden gedaan Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 Hoofdstuk: enquête resultaten losse vragen 82

190 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 6 17,6 17,6 47,1 neutraal 8 23,5 23,5 70,6 mee eens 4 11,8 11,8 82,4 helemaal mee eens 6 17,6 17,6 100,0 Een functieanalyse wordt gedaan om innovatieve oplossingen in de hand te werken Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 5 14,7 14,7 41,2 neutraal 5 14,7 14,7 55,9 mee eens 11 32,4 32,4 88,2 helemaal mee eens 4 11,8 11,8 100,0 Hoofdstuk: enquête resultaten losse vragen 83

191 Een functieanalyse wordt gedaan om ervoor te zorgen dat er geen gaten vallen in het eisenpakket Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 5 14,7 14,7 44,1 neutraal 4 11,8 11,8 55,9 mee eens 10 29,4 29,4 85,3 helemaal mee eens 5 14,7 14,7 100,0 Ook bij weinig complexe projecten is een functieanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 Hoofdstuk: enquête resultaten losse vragen 84

192 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 2 5,9 5,9 35,3 neutraal 8 23,5 23,5 58,8 mee eens 10 29,4 29,4 88,2 helemaal mee eens 4 11,8 11,8 100,0 Ook bij monodisciplinaire projecten is een functieanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 1 2,9 2,9 32,4 neutraal 8 23,5 23,5 55,9 mee eens 11 32,4 32,4 88,2 helemaal mee eens 4 11,8 11,8 100,0 Hoofdstuk: enquête resultaten losse vragen 85

193 Functioneel beschrijven is niet altijd beter. Hoe preciezer je dingen formuleert, hoe groter de kans dat je krijgt wat je hebben wilt. Als je weet wat je wil hebben, moet je het niet functioneel beschrijven, maar gewoon met eisen en wensen. Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 2 5,9 5,9 29,4 mee oneens 1 2,9 2,9 32,4 neutraal 3 8,8 8,8 41,2 mee eens 13 38,2 38,2 79,4 helemaal mee eens 7 20,6 20,6 100,0 Een functieanalyse is niet zinvol als er al functievervullers zijn, die alleen niet meer voldoen. Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 86

194 Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 3 8,8 8,8 32,4 mee oneens 10 29,4 29,4 61,8 neutraal 9 26,5 26,5 88,2 mee eens 3 8,8 8,8 97,1 helemaal mee eens 1 2,9 2,9 100,0 Een functie die niet goed meer vervuld wordt door zijn functievervuller, moet opnieuw vervuld worden. Daarbij fungeren de andere reeds vervulde of nog te vervullen functies als randvoorwaarden. Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 mee oneens 3 8,8 8,8 32,4 neutraal 7 20,6 20,6 52,9 mee eens 12 35,3 35,3 88,2 helemaal mee eens 4 11,8 11,8 100,0 Hoofdstuk: enquête resultaten losse vragen 87

195 Een functieanalyse kan niet gemaakt worden zonder dat het ontwerp voor handen is Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 8 23,5 23,5 47,1 mee oneens 12 35,3 35,3 82,4 neutraal 5 14,7 14,7 97,1 mee eens 1 2,9 2,9 100,0 Een functie wordt beschreven door een werkwoord en een zelfstandig naamwoord Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 mee oneens 2 5,9 5,9 32,4 Hoofdstuk: enquête resultaten losse vragen 88

196 neutraal 5 14,7 14,7 47,1 mee eens 10 29,4 29,4 76,5 helemaal mee eens 8 23,5 23,5 100,0 Eisen worden aan functies gesteld Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 4 11,8 11,8 35,3 mee oneens 5 14,7 14,7 50,0 neutraal 6 17,6 17,6 67,6 mee eens 9 26,5 26,5 94,1 helemaal mee eens 2 5,9 5,9 100,0 Hoofdstuk: enquête resultaten losse vragen 89

197 Eisen worden aan functievervullers gesteld Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 mee oneens 1 2,9 2,9 26,5 neutraal 5 14,7 14,7 41,2 mee eens 13 38,2 38,2 79,4 helemaal mee eens 7 20,6 20,6 100,0 Functionele eisen zijn oplossingsvrij Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 mee oneens 6 17,6 17,6 41,2 neutraal 5 14,7 14,7 55,9 mee eens 9 26,5 26,5 82,4 helemaal mee eens 6 17,6 17,6 100,0 Hoofdstuk: enquête resultaten losse vragen 90

198 Een functionele eis beschrijft de prestatie van een functie Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 4 11,8 11,8 38,2 neutraal 4 11,8 11,8 50,0 mee eens 10 29,4 29,4 79,4 helemaal mee eens 7 20,6 20,6 100,0 5.6 Ontwerpafweging Ik heb ervaring met het begrip ontwerpafweging Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 91

199 Valid Ja 28 82,4 82,4 82,4 Nee 6 17,6 17,6 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 neutraal 4 11,8 11,8 29,4 mee eens 16 47,1 47,1 76,5 helemaal mee eens 8 23,5 23,5 100,0 De ontwerpafweging wordt ingevuld omdat het meerwaarde heeft Hoofdstuk: enquête resultaten losse vragen 92

200 Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 neutraal 3 8,8 8,8 26,5 mee eens 18 52,9 52,9 79,4 helemaal mee eens 7 20,6 20,6 100,0 Het is nodig om de ontwerpafweging expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 7 20,6 20,6 20,6 mee oneens 1 2,9 2,9 23,5 neutraal 3 8,8 8,8 32,4 mee eens 14 41,2 41,2 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 93

201 De ontwerpafweging wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 2 5,9 5,9 23,5 mee oneens 6 17,6 17,6 41,2 neutraal 6 17,6 17,6 58,8 mee eens 11 32,4 32,4 91,2 helemaal mee eens 3 8,8 8,8 100,0 Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 Hoofdstuk: enquête resultaten losse vragen 94

202 helemaal mee oneens 3 8,8 8,8 26,5 mee oneens 8 23,5 23,5 50,0 neutraal 4 11,8 11,8 61,8 mee eens 9 26,5 26,5 88,2 helemaal mee eens 4 11,8 11,8 100,0 Ontwerpafweging van specifieke installatietechnische oplossingen zijn niet zinvol Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 6 17,6 17,6 35,3 mee oneens 13 38,2 38,2 73,5 neutraal 5 14,7 14,7 88,2 mee eens 2 5,9 5,9 94,1 helemaal mee eens 2 5,9 5,9 100,0 Hoofdstuk: enquête resultaten losse vragen 95

203 Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 5 14,7 14,7 32,4 mee oneens 8 23,5 23,5 55,9 neutraal 8 23,5 23,5 79,4 mee eens 6 17,6 17,6 97,1 helemaal mee eens 1 2,9 2,9 100,0 Het gaat slechts sporadisch om verassende oplossingen Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 96

204 Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 1 2,9 2,9 20,6 mee oneens 8 23,5 23,5 44,1 neutraal 5 14,7 14,7 58,8 mee eens 12 35,3 35,3 94,1 helemaal mee eens 2 5,9 5,9 100,0 De voordelen die de ontwerpafwegingen opleveren, wegen niet op tegen de tijd die het kost Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 2 5,9 5,9 23,5 mee oneens 15 44,1 44,1 67,6 neutraal 10 29,4 29,4 97,1 mee eens 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 97

205 Keuzes zijn vaak al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om het hier nog een keer te doen. Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 1 2,9 2,9 20,6 mee oneens 12 35,3 35,3 55,9 neutraal 4 11,8 11,8 67,6 mee eens 10 29,4 29,4 97,1 helemaal mee eens 1 2,9 2,9 100,0 80% van de ontwerpen in de installatietechniek zijn nu hetzelfde als 10 jaar geleden Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 98

206 Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 10 29,4 29,4 55,9 neutraal 10 29,4 29,4 85,3 mee eens 5 14,7 14,7 100,0 De 20% die verschilt in de ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen Frequency Percent Valid Percent Percent Valid weggevallen 8 23,5 23,5 23,5 helemaal mee oneens 1 2,9 2,9 26,5 mee oneens 8 23,5 23,5 50,0 neutraal 9 26,5 26,5 76,5 mee eens 8 23,5 23,5 100,0 Hoofdstuk: enquête resultaten losse vragen 99

207 5.7 Ontwerp Op basis van een objectenboom kan gebouwd worden Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 4 11,8 11,8 17,6 mee oneens 13 38,2 38,2 55,9 neutraal 6 17,6 17,6 73,5 mee eens 7 20,6 20,6 94,1 helemaal mee eens 2 5,9 5,9 100,0 Een objectenboom formuleren is gelijk aan ontwerpen Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 Hoofdstuk: enquête resultaten losse vragen 100

208 helemaal mee oneens 3 8,8 8,8 14,7 mee oneens 14 41,2 41,2 55,9 neutraal 5 14,7 14,7 70,6 mee eens 6 17,6 17,6 88,2 helemaal mee eens 4 11,8 11,8 100,0 Voor ontwerpers is het net zo makkelijk om in plaats van alleen maar het object ook een specificatie op te schrijven, het zit toch in het hoofd. Frequency Percent Valid Percent Percent Valid weggevallen 2 5,9 5,9 5,9 helemaal mee oneens 2 5,9 5,9 11,8 mee oneens 13 38,2 38,2 50,0 neutraal 7 20,6 20,6 70,6 mee eens 8 23,5 23,5 94,1 helemaal mee eens 2 5,9 5,9 100,0 Hoofdstuk: enquête resultaten losse vragen 101

209 5.8 Raakvlakken Ik heb ervaring met het begrip raakvlakken Frequency Percent Valid Percent Percent Valid Ja 29 85,3 85,3 85,3 Nee 5 14,7 14,7 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 mee oneens 2 5,9 5,9 20,6 neutraal 1 2,9 2,9 23,5 mee eens 16 47,1 47,1 70,6 Hoofdstuk: enquête resultaten losse vragen 102

210 helemaal mee eens 10 29,4 29,4 100,0 De raakvlakken worden ingevuld omdat het meerwaarde heeft Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 neutraal 2 5,9 5,9 20,6 mee eens 16 47,1 47,1 67,6 helemaal mee eens 11 32,4 32,4 100,0 Het is nodig om de raakvlakken expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 Hoofdstuk: enquête resultaten losse vragen 103

211 neutraal 3 8,8 8,8 23,5 mee eens 12 35,3 35,3 58,8 helemaal mee eens 14 41,2 41,2 100,0 De raakvlakken wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 4 11,8 11,8 26,5 mee oneens 7 20,6 20,6 47,1 neutraal 6 17,6 17,6 64,7 mee eens 9 26,5 26,5 91,2 helemaal mee eens 3 8,8 8,8 100,0 Hoofdstuk: enquête resultaten losse vragen 104

212 De beschrijving van de raakvlakken moet gegeven worden ongeacht de complexiteit Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 mee oneens 1 2,9 2,9 17,6 neutraal 8 23,5 23,5 41,2 mee eens 11 32,4 32,4 73,5 helemaal mee eens 9 26,5 26,5 100,0 De beschrijving van de raakvlakken moet gegeven worden ongeacht de projectomvang Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 mee oneens 2 5,9 5,9 20,6 neutraal 8 23,5 23,5 44,1 mee eens 10 29,4 29,4 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 105

213 De beschrijving van de raakvlakken moet gegeven worden ongeacht de planning Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 mee oneens 3 8,8 8,8 23,5 neutraal 8 23,5 23,5 47,1 mee eens 9 26,5 26,5 73,5 helemaal mee eens 9 26,5 26,5 100,0 De beschrijving van de raakvlakken moet gegeven worden ongeacht het aantal disciplines Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 mee oneens 4 11,8 11,8 26,5 Hoofdstuk: enquête resultaten losse vragen 106

214 neutraal 5 14,7 14,7 41,2 mee eens 9 26,5 26,5 67,6 helemaal mee eens 11 32,4 32,4 100,0 Ook bij weinig complexe projecten is een raakvlakanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 1 2,9 2,9 17,6 neutraal 6 17,6 17,6 35,3 mee eens 14 41,2 41,2 76,5 helemaal mee eens 8 23,5 23,5 100,0 Hoofdstuk: enquête resultaten losse vragen 107

215 Ook bij monodisciplinaire projecten is een raakvlakanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 2 5,9 5,9 20,6 mee oneens 2 5,9 5,9 26,5 neutraal 6 17,6 17,6 44,1 mee eens 12 35,3 35,3 79,4 helemaal mee eens 7 20,6 20,6 100,0 Raakvlakken moeten afgestemd worden tussen de verschillende systemen en disciplines, alleen interne raakvlakken (per systeem) opschrijven is zinloos. Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 3 8,8 8,8 23,5 mee oneens 2 5,9 5,9 29,4 neutraal 2 5,9 5,9 35,3 mee eens 16 47,1 47,1 82,4 helemaal mee eens 6 17,6 17,6 100,0 Hoofdstuk: enquête resultaten losse vragen 108

216 Interne raakvlakken zijn onzinnig, want deze zitten binnen een ontwerp waar je als team mee bezig bent en verantwoordelijk voor bent. Frequency Percent Valid Percent Percent Valid weggevallen 6 17,6 17,6 17,6 helemaal mee oneens 15 44,1 44,1 61,8 mee oneens 6 17,6 17,6 79,4 neutraal 5 14,7 14,7 94,1 mee eens 2 5,9 5,9 100,0 Het formuleren van raakvlakken gebeurt op basis van een objecten structuur Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 Hoofdstuk: enquête resultaten losse vragen 109

217 mee oneens 2 5,9 5,9 20,6 neutraal 7 20,6 20,6 41,2 mee eens 16 47,1 47,1 88,2 helemaal mee eens 4 11,8 11,8 100,0 Het formuleren van raakvlakken gebeurt op basis van een ontwerp Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 2 5,9 5,9 20,6 mee oneens 7 20,6 20,6 41,2 neutraal 4 11,8 11,8 52,9 mee eens 15 44,1 44,1 97,1 helemaal mee eens 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 110

218 Raakvlakken moeten weergegeven worden in een tekening Frequency Percent Valid Percent Percent Valid weggevallen 5 14,7 14,7 14,7 helemaal mee oneens 2 5,9 5,9 20,6 mee oneens 5 14,7 14,7 35,3 neutraal 15 44,1 44,1 79,4 mee eens 6 17,6 17,6 97,1 helemaal mee eens 1 2,9 2,9 100,0 5.9 RAMS Ik heb ervaring met het begrip RAMS Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 111

219 Valid 0 1 2,9 2,9 2,9 Ja 24 70,6 70,6 73,5 Nee 9 26,5 26,5 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 1 2,9 2,9 32,4 mee oneens 3 8,8 8,8 41,2 neutraal 7 20,6 20,6 61,8 mee eens 10 29,4 29,4 91,2 helemaal mee eens 3 8,8 8,8 100,0 Hoofdstuk: enquête resultaten losse vragen 112

220 De RA(MS) analyse wordt ingevuld omdat het meerwaarde heeft Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 1 2,9 2,9 32,4 mee oneens 2 5,9 5,9 38,2 neutraal 2 5,9 5,9 44,1 mee eens 14 41,2 41,2 85,3 helemaal mee eens 5 14,7 14,7 100,0 Het is nodig om de ramsanalyse expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 neutraal 4 11,8 11,8 41,2 mee eens 11 32,4 32,4 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 113

221 De ramsanalyse wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 2 5,9 5,9 35,3 mee oneens 4 11,8 11,8 47,1 neutraal 6 17,6 17,6 64,7 mee eens 10 29,4 29,4 94,1 helemaal mee eens 2 5,9 5,9 100,0 Een ramsanalyse moet gedaan worden ongeacht de complexiteit Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 Hoofdstuk: enquête resultaten losse vragen 114

222 helemaal mee oneens 2 5,9 5,9 35,3 mee oneens 5 14,7 14,7 50,0 neutraal 4 11,8 11,8 61,8 mee eens 8 23,5 23,5 85,3 helemaal mee eens 5 14,7 14,7 100,0 Een ramsanalyse moet gedaan worden ongeacht de projectomvang Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 3 8,8 8,8 38,2 mee oneens 2 5,9 5,9 44,1 neutraal 6 17,6 17,6 61,8 mee eens 8 23,5 23,5 85,3 helemaal mee eens 5 14,7 14,7 100,0 Hoofdstuk: enquête resultaten losse vragen 115

223 Een ramsanalyse moet gedaan worden ongeacht de planning Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 3 8,8 8,8 38,2 mee oneens 2 5,9 5,9 44,1 neutraal 5 14,7 14,7 58,8 mee eens 9 26,5 26,5 85,3 helemaal mee eens 5 14,7 14,7 100,0 Een ramsanalyse moet gedaan worden ongeacht het aantal disciplines Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 Hoofdstuk: enquête resultaten losse vragen 116

224 helemaal mee oneens 3 8,8 8,8 38,2 mee oneens 2 5,9 5,9 44,1 neutraal 5 14,7 14,7 58,8 mee eens 9 26,5 26,5 85,3 helemaal mee eens 5 14,7 14,7 100,0 Ook bij weinig complexe projecten is een ramsanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 2 5,9 5,9 35,3 mee oneens 4 11,8 11,8 47,1 neutraal 6 17,6 17,6 64,7 mee eens 8 23,5 23,5 88,2 helemaal mee eens 4 11,8 11,8 100,0 Hoofdstuk: enquête resultaten losse vragen 117

225 Ook bij monodisciplinaire projecten is een ramsanalyse zinvol Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 2 5,9 5,9 35,3 mee oneens 2 5,9 5,9 41,2 neutraal 5 14,7 14,7 55,9 mee eens 11 32,4 32,4 88,2 helemaal mee eens 4 11,8 11,8 100,0 RAMS bepaalt vaker dat er andere alternatieven gezocht en gekozen moeten worden dan de selectiecriteria in de ontwerpafweging Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 118

226 Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 2 5,9 5,9 35,3 mee oneens 5 14,7 14,7 50,0 neutraal 5 14,7 14,7 64,7 mee eens 10 29,4 29,4 94,1 helemaal mee eens 2 5,9 5,9 100,0 RAMS is weinig overtuigend want het is slechts statistiek Frequency Percent Valid Percent Percent Valid weggevallen 11 32,4 32,4 32,4 helemaal mee oneens 8 23,5 23,5 55,9 mee oneens 9 26,5 26,5 82,4 neutraal 4 11,8 11,8 94,1 mee eens 1 2,9 2,9 97,1 helemaal mee eens 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 119

227 Als RA(MS) gechecked is en voldoet dan ben ik volledig Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 helemaal mee oneens 6 17,6 17,6 47,1 mee oneens 10 29,4 29,4 76,5 neutraal 3 8,8 8,8 85,3 mee eens 5 14,7 14,7 100,0 RA(MS) is onnodig duur Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 Hoofdstuk: enquête resultaten losse vragen 120

228 helemaal mee oneens 2 5,9 5,9 35,3 mee oneens 15 44,1 44,1 79,4 neutraal 3 8,8 8,8 88,2 mee eens 4 11,8 11,8 100,0 Voor een goede RA(MS) analyse is een volledige systeembeschrijving nodig Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 mee oneens 4 11,8 11,8 41,2 neutraal 2 5,9 5,9 47,1 mee eens 10 29,4 29,4 76,5 helemaal mee eens 8 23,5 23,5 100,0 Hoofdstuk: enquête resultaten losse vragen 121

229 5.10 Verificatie Ik heb ervaring met het begrip verificatie Frequency Percent Valid Percent Percent Valid Ja 25 73,5 73,5 73,5 Nee 9 26,5 26,5 100,0 De definitie die hierboven gegeven is is juist Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 mee oneens 4 11,8 11,8 38,2 neutraal 2 5,9 5,9 44,1 mee eens 12 35,3 35,3 79,4 helemaal mee eens 7 20,6 20,6 100,0 Hoofdstuk: enquête resultaten losse vragen 122

230 De verificatie wordt ingevuld omdat het meerwaarde heeft Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 4 11,8 11,8 38,2 mee eens 13 38,2 38,2 76,5 helemaal mee eens 8 23,5 23,5 100,0 Het is nodig om de verificatie expliciet op te schrijven Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 5 14,7 14,7 41,2 mee eens 10 29,4 29,4 70,6 Hoofdstuk: enquête resultaten losse vragen 123

231 helemaal mee eens 10 29,4 29,4 100,0 De verificatie wordt ingevuld omdat het vereist is Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 helemaal mee oneens 2 5,9 5,9 32,4 mee oneens 4 11,8 11,8 44,1 neutraal 3 8,8 8,8 52,9 mee eens 11 32,4 32,4 85,3 helemaal mee eens 5 14,7 14,7 100,0 Een verificatie moet uitgevoerd worden ongeacht de complexiteit Hoofdstuk: enquête resultaten losse vragen 124

232 Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 3 8,8 8,8 35,3 mee eens 12 35,3 35,3 70,6 helemaal mee eens 10 29,4 29,4 100,0 Een verificatie moet uitgevoerd worden ongeacht de projectomvang Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 2 5,9 5,9 32,4 mee eens 13 38,2 38,2 70,6 helemaal mee eens 10 29,4 29,4 100,0 Hoofdstuk: enquête resultaten losse vragen 125

233 Een verificatie moet uitgevoerd worden ongeacht de planning Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 3 8,8 8,8 35,3 mee eens 11 32,4 32,4 67,6 helemaal mee eens 11 32,4 32,4 100,0 Een verificatie moet uitgevoerd worden ongeacht het aantal disciplines Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 3 8,8 8,8 35,3 mee eens 12 35,3 35,3 70,6 Hoofdstuk: enquête resultaten losse vragen 126

234 helemaal mee eens 10 29,4 29,4 100,0 Een verificatie moet altijd uitgevoerd worden Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 mee oneens 2 5,9 5,9 32,4 neutraal 4 11,8 11,8 44,1 mee eens 9 26,5 26,5 70,6 helemaal mee eens 10 29,4 29,4 100,0 Ook bij weinig complexe projecten is een verificatie zinvol Hoofdstuk: enquête resultaten losse vragen 127

235 Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 4 11,8 11,8 38,2 mee eens 11 32,4 32,4 70,6 helemaal mee eens 10 29,4 29,4 100,0 Ook bij monodisciplinaire projecten is een verificatie zinvol Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 neutraal 5 14,7 14,7 41,2 mee eens 10 29,4 29,4 70,6 helemaal mee eens 10 29,4 29,4 100,0 Hoofdstuk: enquête resultaten losse vragen 128

236 Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 helemaal mee oneens 2 5,9 5,9 32,4 mee oneens 6 17,6 17,6 50,0 neutraal 8 23,5 23,5 73,5 mee eens 8 23,5 23,5 97,1 helemaal mee eens 1 2,9 2,9 100,0 Verificatie is, in de huidige vorm, maar beperkt zinvol. Het is nog steeds lastig grijpbaar of ontwerpen nu echt aan de eisen voldoen. Frequency Percent Valid Percent Percent Hoofdstuk: enquête resultaten losse vragen 129

237 Valid weggevallen 9 26,5 26,5 26,5 helemaal mee oneens 3 8,8 8,8 35,3 mee oneens 11 32,4 32,4 67,6 neutraal 5 14,7 14,7 82,4 mee eens 5 14,7 14,7 97,1 helemaal mee eens 1 2,9 2,9 100,0 Verificatie is de ontwerpcontrole Frequency Percent Valid Percent Percent Valid weggevallen 10 29,4 29,4 29,4 mee oneens 5 14,7 14,7 44,1 neutraal 3 8,8 8,8 52,9 mee eens 15 44,1 44,1 97,1 helemaal mee eens 1 2,9 2,9 100,0 Hoofdstuk: enquête resultaten losse vragen 130

238 De opdrachtgever is verantwoordelijk voor het juist formuleren van de top eis Frequency Percent Valid Percent Percent Valid weggevallen 9 26,5 26,5 26,5 mee oneens 3 8,8 8,8 35,3 neutraal 4 11,8 11,8 47,1 mee eens 9 26,5 26,5 73,5 helemaal mee eens 9 26,5 26,5 100,0 Hoofdstuk: enquête resultaten losse vragen 131

239

240 Bijlage 6 enquête resultaten gemiddelden 6.1 Systems Engineering Systeembeschrijving Eisenanalyse Functieanalyse Ontwerpafweging Ontwerp Raakvlakken RAMS Verificatie Systems Engineering Statistics N Valid Missing Mean Std. Deviation Variance SE biedt structuur ,31,738,544 SE biedt een controlemiddel ten ,84,987,975 behoeve van kwaliteit SE zorgt voor verrassende 32 oplossingen 2 2,78,906,822 SE biedt beheersbaarheid van het project in tijd en ,09 1,118 1,249 geld SE maakt alle beslissingen 32 expliciet 2 3,66,937,878 SE maakt het werk eenvoudiger ,53 1,016 1,031 SE reduceert de benodigde tijd ,53,950,902 SE reduceert complexiteit ,84 1,110 1,233 Het gebruik van SE komt de kwaliteit van het ,31,896,802 eindproduct niet ten goede SE is zinvol om toe te passen bij grond-, weg- en ,69,693,480 waterbouwprojecten SE is zinvol om toe te passen bij Installatietechnische projecten ,84,987,975 Hoofdstuk: enquête resultaten gemiddelden 133

241 SE moet toegepast worden wanneer de projectonderdelen ,72,813,660 afhankelijk van elkaar zijn SE moet toegepast worden bij projecten waar veel partijen belangen in hebben of er veel ,78,706,499 tegenstrijdige belangen zijn SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt ,12 1,289 1,661 gegeven SE moet toegepast worde wanneer het project ,94,759,577 multidisciplinair is SE moet toegepast worden 32 in nieuwbouw projecten 2 4,12,707,500 SE moet toegepast worden 32 in renovatie projecten 2 3,12 1,185 1,403 Hoofdstuk: enquête resultaten gemiddelden 134

242 Hoofdstuk: enquête resultaten gemiddelden 135

243 6.2 Systeembeschrijving Statistics N Valid Missing Mean Std. Deviation Variance De systeembeschrijving wordt ingevuld omdat het ,19,644,415 meerwaarde heeft Het is nodig om de systeembeschrijving ,31,644,415 expliciet op te schrijven De systeembeschrijving wordt ingevuld omdat het ,00 1,078 1,161 vereist is Een systeembeschrijving moet gegeven worden ,19,821,673 ongeacht de complexiteit Een systeembeschrijving moet gegeven worden ,16,847,717 ongeacht de projectomvang Een systeembeschrijving moet gegeven worden ,16,808,652 ongeacht de planning Een systeembeschrijving moet gegeven worden ongeacht het aantal ,22,751,564 disciplines De verschillen tussen de huidige en gewenste situatie moeten duidelijk in ,31,738,544 beeld komen Ook bij weinig complexe projecten is een ,28,729,531 systeembeschrijving zinvol Ook bij monodisciplinaire projecten is een ,25,718,516 systeembeschrijving zinvol Een systeembeschrijving geeft een beeld van het project ,94,982,964 Hoofdstuk: enquête resultaten gemiddelden 136

244 Een systeembeschrijving geeft aan wat er moet veranderen Een systeembeschrijving geeft aan welke functies een complex heeft Een systeembeschrijving geeft relaties weer Een systeembeschrijving beschrijft de functies van het project ,16 1,194 1, ,84,987, ,31 1,120 1, ,78 1,070 1,144 Hoofdstuk: enquête resultaten gemiddelden 137

245 Hoofdstuk: enquête resultaten gemiddelden 138

246 6.3 Eisenanalyse Statistics N Valid Missing Mean Std. Deviation Variance De eisenanalyse wordt ingevuld omdat het ,97,850,723 meerwaarde heeft Het is nodig om de eisenanalyse expliciet op ,00,871,759 te schrijven De eisenanalyse wordt ingevuld omdat het vereist ,27 1,230 1,513 is Een eisenanalyse moet gegeven worden ongeacht ,93,944,892 de complexiteit Een eisenanalyse moet gegeven worden ongeacht ,83 1,053 1,109 de projectomvang Een eisenanalyse moet gegeven worden ongeacht ,83 1,085 1,178 de planning Een eisenanalyse moet gegeven worden ongeacht ,83 1,020 1,040 het aantal disciplines Een eisenanalyse bevooroordeeld je in het denken in een bepaalde oplossingsrichting en moet ,07 1,334 1,781 dus na de ontwerpafweging gedaan worden Ook bij weinig complexe projecten is een ,77,971,944 eisenanalyse zinvol Ook bij monodisciplinaire projecten is een eisenanalyse zinvol ,87,860,740 Hoofdstuk: enquête resultaten gemiddelden 139

247 Een opsomming van de eisen van Rijkswaterstaat is voldoende, er hoeft ,72,702,493 geen analyse gedaan te worden Hoe meer eisen er geformuleerd worden, des 29 te minder ontwerpvrijheid 5 3,45 1,183 1,399 heb je Hoe meer eisen je formuleert, des te kleiner 29 is de kans dat je krijgt wat 5 2,34,897,805 je verwacht Elke eis heeft een topeis ,72 1,131 1,278 Eisen stellen zonder te sturen op een oplossingsrichting is onmogelijk ,48 1,379 1,901 Hoofdstuk: enquête resultaten gemiddelden 140

248 Hoofdstuk: enquête resultaten gemiddelden 141

249 6.4 Functieanalyse Statistics N Valid Missing Mean Std. Deviation Variance De functieanalyse wordt ingevuld omdat het ,73 1,041 1,085 meerwaarde heeft Het is nodig om de functieanalyse expliciet op te ,92 1,017 1,034 schrijven De functieanalyse wordt ingevuld omdat het vereist is ,12 1,177 1,386 Een functieanalyse moet gegeven worden ongeacht de ,35 1,294 1,675 complexiteit Een functieanalyse moet gegeven worden ongeacht de ,35 1,294 1,675 projectomvang Een functieanalyse moet gegeven worden ongeacht de ,42 1,301 1,694 planning Een functieanalyse moet gegeven worden ongeacht ,54 1,240 1,538 het aantal disciplines Een functieanalyse moet altijd 26 worden gedaan 8 3,23 1,275 1,625 Een functieanalyse wordt gedaan om innovatieve oplossingen in de hand te ,46 1,104 1,218 werken Een functieanalyse wordt gedaan om ervoor te zorgen dat er geen gaten vallen in ,42 1,238 1,534 het eisenpakket Ook bij weinig complexe projecten is een functieanalyse zinvol ,46 1,104 1,218 Hoofdstuk: enquête resultaten gemiddelden 142

250 Ook bij monodisciplinaire projecten is een ,54 1,067 1,138 functieanalyse zinvol Functioneel beschrijven is niet altijd beter. Hoe preciezer je dingen formuleert, hoe groter de kans dat je krijgt wat je hebben wilt. Als je ,85 1,120 1,255 weet wat je wil hebben, moet je het niet functioneel beschrijven, maar gewoon met eisen en wensen. Een functieanalyse is niet zinvol als er al functievervullers zijn, die ,58,987,974 alleen niet meer voldoen. Een functie die niet goed meer vervuld wordt door zijn functievervuller, moet opnieuw vervuld worden. Daarbij fungeren de andere ,65,892,795 reeds vervulde of nog te vervullen functies als randvoorwaarden. Een functieanalyse kan niet gemaakt worden zonder dat ,96,824,678 het ontwerp voor handen is Een functie wordt beschreven door een werkwoord en een ,96,935,873 zelfstandig naamwoord Eisen worden aan functies gesteld ,00 1,233 1,520 Eisen worden aan functievervullers gesteld ,00,800,640 Functionele eisen zijn oplossingsvrij ,58 1,102 1,214 Een functionele eis beschrijft de prestatie van een functie ,69 1,158 1,342 Hoofdstuk: enquête resultaten gemiddelden 143

251 Hoofdstuk: enquête resultaten gemiddelden 144

252 6.5 Ontwerpafweging Statistics N Valid Missing Mean Std. Deviation Variance De ontwerpafweging wordt ingevuld omdat het ,14,591,349 meerwaarde heeft Het is nodig om de ontwerpafweging expliciet ,15,770,593 op te schrijven De ontwerpafweging wordt ingevuld omdat het vereist ,25 1,143 1,306 is Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties ,11 1,286 1,655 betreft Ontwerpafweging van specifieke installatietechnische ,32 1,124 1,263 oplossingen zijn niet zinvol Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ,64 1,129 1,275 ontwerpafwegingen zonde van de tijd zijn Het gaat slechts sporadisch om verassende ,21 1,067 1,138 oplossingen De voordelen die de ontwerpafwegingen opleveren, wegen niet op ,36,678,460 tegen de tijd die het kost Keuzes zijn vaak al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om het hier nog een keer te doen ,93 1,052 1,106 Hoofdstuk: enquête resultaten gemiddelden 145

253 80% van de ontwerpen in de installatietechniek zijn nu hetzelfde als 10 jaar geleden De 20% die verschilt in de ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen ,73,827, ,92,891,794 Hoofdstuk: enquête resultaten gemiddelden 146

254 6.6 Ontwerp Statistics N Valid Missing Mean Std. Deviation Variance Op basis van een objectenboom kan ,69 1,148 1,319 gebouwd worden Een objectenboom formuleren is gelijk aan ,81 1,230 1,512 ontwerpen Voor ontwerpers is het net zo makkelijk om in plaats van alleen maar het object ook een specificatie op te schrijven, het zit toch in het hoofd ,84 1,081 1,168 Hoofdstuk: enquête resultaten gemiddelden 147

255 6.7 Raakvlakken Statistics N Valid Missing Mean Std. Deviation Variance De raakvlakken worden ingevuld omdat het meerwaarde heeft Het is nodig om de raakvlakken expliciet op te schrijven De raakvlakken wordt ingevuld omdat het vereist is De beschrijving van de raakvlakken moet gegeven worden ongeacht de complexiteit De beschrijving van de raakvlakken moet gegeven worden ongeacht de projectomvang De beschrijving van de raakvlakken moet gegeven worden ongeacht de planning De beschrijving van de raakvlakken moet gegeven worden ongeacht het aantal disciplines Ook bij weinig complexe projecten is een raakvlakanalyse zinvol Ook bij monodisciplinaire projecten is een raakvlakanalyse zinvol ,31,604, ,38,677, ,00 1,254 1, ,97,865, ,90,939, ,83 1,002 1, ,93 1,067 1, ,97,906, ,69 1,137 1,293 Hoofdstuk: enquête resultaten gemiddelden 148

256 Raakvlakken moeten afgestemd worden tussen de verschillende systemen en disciplines, alleen interne ,69 1,198 1,436 raakvlakken (per systeem) opschrijven is zinloos. Interne raakvlakken zijn onzinnig, want deze zitten binnen een ontwerp waar je ,79,995,989 als team mee bezig bent en verantwoordelijk voor bent. Het formuleren van raakvlakken gebeurt op basis ,76,786,618 van een objecten structuur Het formuleren van raakvlakken gebeurt op basis ,21 1,082 1,170 van een ontwerp Raakvlakken moeten weergegeven worden in een ,97,906,820 tekening Hoofdstuk: enquête resultaten gemiddelden 149

257 Hoofdstuk: enquête resultaten gemiddelden 150

258 6.8 RAMS Statistics N Valid Missing Mean Std. Deviation Variance De RA(MS) analyse wordt ingevuld omdat het ,83 1,007 1,014 meerwaarde heeft Het is nodig om de ramsanalyse expliciet op te ,21,721,520 schrijven De ramsanalyse wordt 24 ingevuld omdat het vereist is 10 3,25 1,113 1,239 Een ramsanalyse moet gedaan worden ongeacht de ,38 1,279 1,636 complexiteit Een ramsanalyse moet gedaan worden ongeacht de ,42 1,283 1,645 projectomvang Een ramsanalyse moet gedaan worden ongeacht de ,46 1,285 1,650 planning Een ramsanalyse moet gedaan worden ongeacht ,46 1,285 1,650 het aantal disciplines Ook bij weinig complexe projecten is een ,33 1,204 1,449 ramsanalyse zinvol Ook bij monodisciplinaire projecten is een ,54 1,141 1,303 ramsanalyse zinvol RAMS bepaalt vaker dat er andere alternatieven gezocht en gekozen moeten 24 worden dan de 10 3,21 1,141 1,303 selectiecriteria in de ontwerpafweging RAMS is weinig overtuigend want het is slechts statistiek ,04 1,065 1,134 Hoofdstuk: enquête resultaten gemiddelden 151

259 Als RA(MS) gechecked is en voldoet dan ben ik ,29 1,083 1,172 volledig RA(MS) is onnodig duur ,38,875,766 Voor een goede RA(MS) analyse is een volledige systeembeschrijving nodig ,92 1,060 1,123 Hoofdstuk: enquête resultaten gemiddelden 152

260 6.9 Verificatie Statistics N Valid Missing Mean Std. Deviation Variance De verificatie wordt ingevuld 25 omdat het meerwaarde heeft 9 4,16,688,473 Het is nodig om de verificatie 25 expliciet op te schrijven 9 4,20,764,583 De verificatie wordt ingevuld omdat het vereist is ,52 1,229 1,510 Een verificatie moet uitgevoerd worden ongeacht ,28,678,460 de complexiteit Een verificatie moet uitgevoerd worden ongeacht ,32,627,393 de projectomvang Een verificatie moet uitgevoerd worden ongeacht ,32,690,477 de planning Een verificatie moet uitgevoerd worden ongeacht ,28,678,460 het aantal disciplines Een verificatie moet altijd uitgevoerd worden ,08,954,910 Ook bij weinig complexe projecten is een verificatie ,24,723,523 zinvol Ook bij monodisciplinaire projecten is een verificatie ,20,764,583 zinvol Verificatie moet eigenlijk door een onafhankelijk ,00 1,041 1,083 persoon worden gedaan Verificatie is, in de huidige vorm, maar beperkt zinvol. Het is nog steeds lastig grijpbaar of ontwerpen nu echt aan de eisen voldoen ,60 1,080 1,167 Hoofdstuk: enquête resultaten gemiddelden 153

261 Verificatie is de ontwerpcontrole De opdrachtgever is verantwoordelijk voor het juist formuleren van de top eis ,50,885, ,96 1,020 1,040 Hoofdstuk: enquête resultaten gemiddelden 154

262 Bijlage 7 kruistabellen 7.1 Onafhankelijke variabelen Vergelijking afhankelijke variabelen met onafhankelijke variabelen Onafhankelijke variabelen In welke soort organisatie bent u werkzaam? * SE reduceert complexiteit Hoofdstuk: kruistabellen 155

263 In welke soort organisatie bent u werkzaam? * SE heeft geen nut bij projecten waarbinnen weinig vrijh eid wordt gegeven Hoofdstuk: kruistabellen 156

264 Hoofdstuk: kruistabellen 157