Systems Engineering in de praktijk. Een onderzoek naar toepassingsmogelijkheden

Systems Engineering in de praktijk Een onderzoek naar toepassingsmogelijkheden en eigenschappen

E. Vink De Bilt, 18 december 2008


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

Systems Engineering in de praktijk

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)

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

Het onderzoek

5


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 €100.000, - (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 12.4. • 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.

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

Onderzoeksvragen

6


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)

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 12.2. 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

The research

7


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 €100.000, - (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 12.4. • 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

Hoofdstuk: Summary

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?

8


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.

Hoofdstuk: Voorwoord

Eline Vink, De Bilt, 2008

9


Inhoudsopgave 1

Inleiding _______________________________________________________15

2

Onderzoeksontwerp _____________________________________________17 2.1

Systems Engineering in de GWW-sector ______________________________ 17

2.2

Probleem- en doelstelling___________________________________________ 17

2.3

Afbakening onderzoekskader _______________________________________ 19

2.4

Onderzoeksmodel _________________________________________________ 21

2.5

Vraagstelling _____________________________________________________ 23

2.6

Leeswijzer _______________________________________________________ 24

Deel A; Theoretische benadering _____________________________________25 3

Systems Engineering ____________________________________________27 3.1

Inleiding _________________________________________________________ 27

3.2

Definitie en inhoud Systems Engineering _____________________________ 27

3.2.1 3.2.2

3.3

Toepassingsmogelijkheden Systems Engineering ______________________ 31

3.3.1 3.3.2

3.4

4

Wanneer passen we Systems Engineering toe? ______________________________ 32 Waarom passen we Systems Engineering toe? ______________________________ 33

Terugkoppeling onderzoeksvraag ____________________________________ 35

Projectkenmerken ______________________________________________37 4.1

Inleiding _________________________________________________________ 37

4.2

Complexiteit ______________________________________________________ 37

4.2.1 4.2.2

5

Werkdefinitie _________________________________________________________ 27 Levenscyclus _________________________________________________________ 29

Complexiteit wordt gedefinieerd door functies, onderlinge interactie en dynamiek ___ 37 Projectkenmerken met relatie tot complexiteit ________________________________ 37

4.3

Kosten __________________________________________________________ 38

4.4

Tijd _____________________________________________________________ 38

4.5

Projectkenmerken gerelateerd aan de GWW-sector _____________________ 39

4.6


Afweging op basis van de theoretische benadering ___________________41

Deel B; Casestudy renovatie Haringvliet en Volkerak Sluizencomplexen_____43 HVVOS ________________________________________________________45 6.1

Doel ____________________________________________________________ 45

6.2

Casestudy _______________________________________________________ 45

6.2.1 6.2.2 6.2.3 6.2.4

6.3

Het project ___________________________________________________________ Projectkenmerken HVVOS ______________________________________________ Systems Engineering binnen HVVOS ______________________________________ Format ______________________________________________________________

45 45 46 47

Interviews ________________________________________________________ 49

6.3.1 6.3.2

Aanleiding en indeling interview __________________________________________ 49 Relevante uitkomsten __________________________________________________ 49

Hoofdstuk: Inhoudsopgave

6

11


6.4

7


Afwegingen vanuit de casestudy __________________________________53

Deel C; Enquête ___________________________________________________55 8

Opzet enquête __________________________________________________57 8.1

Doel ____________________________________________________________ 57

8.2

Opzet enquête ____________________________________________________ 57

8.2.1 8.2.2 8.2.3

9

Variabelen ___________________________________________________________ 57 Vraagstelling en beantwoording __________________________________________ 57 Enquête vragen _______________________________________________________ 58

Enquête resultaten ______________________________________________63 9.1

Doel ____________________________________________________________ 63

9.2

Algemeen ________________________________________________________ 63

9.2.1 9.2.2

9.3

Gemiddelden _____________________________________________________ 65

9.3.1 9.3.2 9.3.3 9.3.4 9.3.5 9.3.6 9.3.7 9.3.8 9.3.9 9.3.10

9.4

Algemeen ____________________________________________________________ Systems Engineering ___________________________________________________ Systeembeschrijving ___________________________________________________ Eisenanalyse _________________________________________________________ Functieanalyse ________________________________________________________ Ontwerpafweging ______________________________________________________ Raakvlakken _________________________________________________________ RAMS analyse ________________________________________________________ Verificatie ____________________________________________________________ Afwegingen vanuit de gemiddelden ________________________________________

65 67 70 71 72 74 75 76 77 78

Kruistabellen _____________________________________________________ 81

9.4.1 9.4.2 9.4.3

10

Respondenten ________________________________________________________ 63 Weggevallen vragen ___________________________________________________ 64

Onafhankelijke variabelen _______________________________________________ 82 Afhankelijke variabelen _________________________________________________ 84 Afwegingen vanuit de kruistabellen ________________________________________ 86

Afwegingen vanuit de enquête ___________________________________87

Deel D; Afwegingen en conclusies ____________________________________89 Discussie ____________________________________________________91

11.1

Doel ___________________________________________________________ 91

11.2

Tijd ____________________________________________________________ 91

11.3

Risico’s ________________________________________________________ 91

11.4

Kosten _________________________________________________________ 92

11.5

Keuzeruimte ____________________________________________________ 92

11.6

Verrassende oplossingen _________________________________________ 93

11.7

Beheersbaarheid ________________________________________________ 94

11.8

Eisen stellen aan functies/functievervullers __________________________ 94

11.9

Conclusies uit de discussie _______________________________________ 95

12

Conclusies en aanbevelingen ___________________________________97


11

12


12.1

Doel ___________________________________________________________ 97

12.2

Afwegingsmodel ________________________________________________ 98

12.2.1 12.2.2

Systems Engineering ___________________________________________________ 98 Onderdelen van Systems Engineering _____________________________________ 99

12.3

Conclusies ____________________________________________________ 100

12.4

Aanbevelingen _________________________________________________ 100

12.4.1 12.4.2

Gebruikte begrippen en afkortingen _____________________________103

13.1

Begrippenlijst __________________________________________________ 103

13.2

Afkortingen ____________________________________________________ 103

14

Bronnen ____________________________________________________105

14.1

Literatuur _____________________________________________________ 105

14.2

Publicaties en artikelen __________________________________________ 105


13

Aanbevelingen _______________________________________________________ 100 Onderzoeksvragen voor verder onderzoek _________________________________ 101

13


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 ontwerpen 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-, wegen waterbouw bij het HSL-Zuid project en in 2007 is er door ProRail en Rijkswaterstaat een handleiding uitgebracht over dit onderwerp.

Hoofdstuk: Inleiding

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.

15


2

Onderzoeksontwerp

2.1

Systems Engineering in de GWW-sector

Systems Engineering is, gedefinieerd door het International Counsel on Systems Engineering (INCOSE), 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.

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

In het kader van dit onderzoek wordt Systems Engineering als volgt gedefinieerd:

17


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 1 van wordt . 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.

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 Enginee1

Gesprekken met werknemers Grontmij


Geen inzicht in de mate van nuttige toepassing van SE instrumenten

18


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 ontwerpen 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.

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-, wegen 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-, wegen waterbouw valt, maar waar ook installatietechniek bij komt kijken.


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.

19


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.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.


Figuur 2.1: afbakening onderzoekskader (ProRail & Rijkswaterstaat, 2007; Blanchard & Fabrycky, 1998)

20


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 Resultaat

Systems Engineering

A.

Theoretische benadering onderzoekskader

Projectkenmerken C.

Casestudie HVVOS B.

Interviews

Huidig begrip en omgang met Systems Engineering (bij HVVOS)

Enquête optimalisering Systems Engineering in relatie tot projectkenmerken D.

Afwegingsmodel toepassing Systems Engineering

Deskundigen

Figuur 2.3: Onderzoeksmodel (Verschuren & Doorewaard, 2005)

Systems Engineering

Projectkenmerken

Figuur 2.4: deel A

A.


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.


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.

21



Casestudie HVVOS B.

Interviews

Naast het theoretisch kader wordt gekeken naar een case renovatie Haringvliet en Volkerak sluizencomplexen (HVVOS). 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.


C.

B.


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

22


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 gemaakt kunnen worEngineering zijn er uit Engineering zijn er uit Engineering zijn er uit


Hoe luiden de afwegingen die op basis van de theorie, interviews en enquête den? a. Welke relaties tussen projectkenmerken en (onderdelen van) Systems de theorie af te leiden? b. Welke relaties tussen projectkenmerken en (onderdelen van) Systems de interviews af te leiden? c. Welke relaties tussen projectkenmerken en (onderdelen van) Systems de enquête af te leiden? d. Welke afwegingen volgen uit a, b en c.

23


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.

24

Deel A; Theoretische benadering


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

3.2.1

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), ProRail & 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.

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 denken 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 denken 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

Discipline

27


van een verificatie en validatie plan. Al deze onderdelen worden in paragraaf 3.2.2 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

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)


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.

28


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

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

Tabel 3.1: Fasen van de levenscyclus (aangepast van ISO 15288)

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).


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.

29


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 10.000 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 15.000 auto’s aan te houden. Als randvoorwaarde met het oog op milieuverontreiniging mogen er niet meer dan 20.000 auto’s per dag over dit wegdeel. Om te voorkomen dat dit aantal overschreden wordt, wordt als uitgangspunt maximaal ontworpen voor 18.000 auto’s. Na uiteindelijk ontworpen te hebben kan geconcludeerd worden dat de prestatie van de weg 17.000 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.

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


Functies

30


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-610.12, 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-610.12, 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 50126 • 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 ௠௘௔௡ ௧௜௠௘ ௕௘௧௪௘௘௡ ௙௔௜௟௨௥௘ ‫=ܣ‬ • •

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.


(௠௘௔௡ ௧௜௠௘ ௧௢ ௥௘௣௔௜௥ା௠௘௔௡ ௧௜௠௘ ௕௘௧௪௘௘௡ ௙௔௜௟௨௥௘)

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.

31


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 3.3.1 en 3.3.2 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.

3.3.1

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.

•

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.


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.

32


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.

3.3.2

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)

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


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.

33


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. SEE, zoals besproken in de paragraaf Kosten, heeft ook invloed op de ratio tussen actuele en geplande tijdsbesteding. Rond 18% SEE levert het meest Figuur 3.5: Systems Engineering Effort versus tijd (Honour, 2004)

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.

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).


Risico’s

34


.

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).

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):


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.

35


Requirements Systemen en objecten Functies Raakvlakken Verificatie


• • • • •

36


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

4.2.1

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).

4.2.2

Projectkenmerken met relatie tot complexiteit

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

Aantal disciplines

37


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)

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


4.3

38


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-, wegen 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


In deze paragraaf staat beknopt het antwoord op onderstaande onderzoeksvraag weergegeven.

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


Welke projectkenmerken kunnen onderscheiden worden?

39


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

Systems Engineering

Voldoende SE budget (3.3.2)

Afhankelijkheid van projectonderdelen / onderlinge relaties (4.2.2) Veel belanghebbenden / tegenstrijdige belangen (4.2.2)

Niet bij

Zorgt voor

Zorgt niet voor

Twijfel bij

Reductie kosten Reductie tijd Reductie risico's Zekerheid Beheersbaarheid Transparantie Expliciet werken Structuur

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:

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

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

41


Hoofdstuk: Afweging op basis van de theoretische benadering

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 3.2.2 opgesomd, zijn niet gevonden.

42

Deel B; Casestudy renovatie Haringvliet en Volkerak Sluizencomplexen


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

6.2.1

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.

6.2.2

Projectkenmerken HVVOS

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

Fase in het V-model; renovatie

45


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 2

De totale projectomvang zoals op de aanbestedingskalender is gepubliceerd is € 60.619.103 . Daar2 van is ongeveer 6% 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.

6.2.3

Systems Engineering binnen HVVOS

“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

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 2 over gezegd :

46


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

Hoofdstuk: HVVOS

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 3.2.2.

47

Figuur 6.1: procesgang HVVOS

Hoofdstuk: HVVOS


48


6.3

Interviews

6.3.1

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

6.3.2

49


•

• •

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.

•

•

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

Specifiek; ontwerpafweging

50

Systems Engineering in de praktijk •

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 •

6.4

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.


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 6.3.2 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 6.2.1 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

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

c. Welke projectkenmerken heeft dit project?

51


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;

Hoofdstuk: HVVOS

Algemeen • Systems Engineering • HVVOS Specifiek • Systeembeschrijving • Eisenanalyse • Functieanalyse • Ontwerpafweging • Ontwerp • Raakvlakken • RAMS • Verificatie

52


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 Systems Engineering

Functieanalyse

Wel bij Keuzevrijheid

Altijd

Niet bij Vaste oplossingen Installatietechniek Kleinere bedrijven Afwegingen bij routineklussen Kleine projecten

Zorgt voor Beheersbaarheid

Renovatie - vervangen functievervullers

Randvoorwaarden

Ontwerpafweging

Zorgt niet voor

Twijfel bij

Risico's

Verrassende oplossingen Transparantie Voordelen die opwegen tegen tijd en geld

RAMSanalyse

Overtuiging

Tabel 7.1: afwegingen vanuit de casestudie

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

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

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.

53

Deel C; Enquête


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

8.2.1

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

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)

Tabel 8.1: variabelen

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

8.2.2

57


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.

8.2.3

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

• • • • •

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


•

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.

58


•

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, 10.000, 100.000, 1.000.000, >10.000.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 ken3 nis van de afstudeercommissie .

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

• • •

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 3

Deze stelling komt voort uit gesprekken

3

Mondelinge communicatie met de afstudeercommissie


Deze stellingen komen voort uit de resultaten van de interviews (H6).

59


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


• • •

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 4

Deze stellingen komen voort uit de resultaten van de interviews en gesprekken

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


• • • •

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 4

Deze stellingen komen voort uit de theorie en gesprekken .

•

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.

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:

• • •

4

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

Mondeling gesprekken met de afstudeercommissie


Ontwerpafweging

60


•

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


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 5

Deze stellingen komen voort uit gesprekken

•

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


• •

Het formuleren van raakvlakken gebeurt op basis van een objecten structuur Het formuleren van raakvlakken gebeurt op basis van een ontwerp 5

Deze stellingen komen voort uit gesprekken .

RAMS

• • •

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


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:

61


•

Als RA(MS) gecheckt is en voldoet dan ben ik volledig 6

Deze stelling komt voort uit gesprekken .

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


• •

Verificatie is de ontwerpcontrole De opdrachtgever is verantwoordelijk voor het juist formuleren van de topeis 6

6

Mondelinge communicatie en de afstudeercommissie


Deze stelling komt voort uit gesprekken .

62


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?

9.2

Algemeen

9.2.1

Respondenten

Mogelijke respondenten zijn per e-mail 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

In hoofdstuk 10 is het antwoord op deze vraag beknopt weergegeven als conclusie van dit hoofdstuk.

63


• 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.

9.2.2

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.


•

64

Systems Engineering in de praktijk • 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 5.

9.3.1

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.

In opleidingsniveau verschillende respondenten niet zoveel, iedereen is hoger opgeleid. 38 % heeft een afgeronde HBO opleiding, 59 % een WO opleiding en 3 % zelfs WO+.

Figuur 9.2: opleiding


Figuur 9.1: organisatie

65


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.3: Systems Engineering

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 HVVOS.


Figuur 9.4: HVVOS

66


9.3.2

Systems Engineering

Figuur 9.5: gemiddelden Systems Engineering

Hoofdstuk: Enquête resultaten, Gemiddelden, 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.

67


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 100.000 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.

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.

Figuur 9.8: aantallen projectduur

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.*


Figuur 9.7: aantallen projectomvang

68


• •

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 100.000 euro en een projectduur vanaf 6 maanden.


•

69


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

9.3.3

70


9.3.4

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

Figuur 9.10: gemiddelden eisenanalyse

71


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

9.3.5

72


• • • • •

•

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


9.3.6

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

Figuur 9.12: gemiddelden ontwerpafweging

74


9.3.7

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

Figuur 9.13: gemiddelden raakvlakken

75


9.3.8

RAMS analyse

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

Figuur 9.14: gemiddelden RAMS

76


9.3.9

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

Figuur 9.15: gemiddelden verificatie

77


9.3.10 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 9.2.1 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.

Ontwerpafweging

Wel bij Nieuwbouwprojecten Multidisciplinaire projecten Veel belanghebbenden Veel tegenstrijdige belangen afhankelijke projectonderdelen Installatietechnische projecten GWW projecten Projectgrootte ontwerpfase > 100.000 euro Projectduur ontwerpfase vanaf 6 maanden Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines Projecten ongeacht Aantal disciplines Weinig complexe projecten Functievervullers die niet meer aan eisen weinig tijd en geld (voordelen wegen op)

Raakvlakken

Projecten ongeacht

Systeembeschrijving

Eisenanalyse

Functieanalyse

Niet bij

Zorgt voor Kwaliteit Controlemiddel tbv kwaliteit Structuur

Zorgt niet voor Twijfel bij Reductie tijd Renovatieprojecten Verrassende oplossingen Beheersbaarheid in tijd en geld Reductie complexiteit

Denken/sturen in bepaalde oplossingsrichting

Innovatieve oplossingen

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

Aantal disciplines Volledige systeembeschrijving

het zoeken naar andere Onnodige kosten alternatieven (vaker dan dat selectiecriteria dat doen)

Ongeacht de complexiteit Ongeacht de projectomvang Ongeacht de planning

Projecten ongeacht

Overtuiging Controle van ontwerp op eisen

Duidelijk beeld van OG wat hij wil hebben

Specifieke installatietechnische oplossingen

Complexiteit Projectomvang Planning Aantal disciplines

RAMSanalyse

Verificatie

Externe raakvlakken Interne raakvlakken Projecten ongeacht


Controle door onafhankelijk persoon

Tabel 9.1: afwegingen vanuit gemiddelden

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 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

Onderdeel Systems Engineering

78


Hoofdstuk: Enquête resultaten, Gemiddelden, Afwegingen vanuit de gemiddelden

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.

79


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, zijn dus de spreiding van de antwoorden laag is. 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 stansta daarddeviatie en het gemiddelde plus eenmaal de standaarddeviatie is 68,2 68,2 procent van alle antwoorantwoo 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 M 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. is Wanneer de spreiding iding 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, hieronder, geeft de geschetste situasitu tie weer. Betrouwbaar positief resultaat

Antwoordmogelijkheden

2

3

4

5

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 analyse 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

1

81


Standaarddeviatie: 1,334 Antwoorden: 1. Helemaal mee oneens 2. Mee oneens 3. Neutraal 4. Mee eens 5. Helemaal mee eens

-

14 7 2 4 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 4 2. Mee oneens 5 3. Neutraal 6 4. Mee eens 9 5. 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.

9.4.1

Onafhankelijke variabelen


Allereerst zijn er ook wat kruistabellen gemaakt met onafhankelijke variabelen om te kijken of daar verbanden in zijn te vinden.

82


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.

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.


Figuur 9.19: Organisatie versus SE ervaring

83


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.

9.4.2

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 9.4.1 dat organisatie en opleiding verband met elkaar hebben. Uitgebreide resultaten zijn te vinden in bijlage 7.

Stellingen zonder duidelijk verband met onafhankelijke variabelen

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)


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.

84


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.

85


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 Systems Engineering

Stelling Beheersbaarheid in tijd en geld Reduceert complexiteit

Wel bij Veel SE ervaring Theorie Veel SE ervaring Theorie

Niet bij Weinig SE ervaring Praktijk Weinig SE ervaring Praktijk

Meer dan 4 jaar ervaring met SE Veel ervaring met SE Altijd Altijd Altijd Altijd Theorie Ingenieursbureau Meer SE ervaring Altijd Altijd Altijd x

Minder ervaring met SE Minder ervaring met SE x x x x Praktijk Aannemer Weinig SE ervaring x x x Geldt nooit

Nut bij projecten met weinig vrijheid

Functieanalyse

Ontwerpafweging

RAMSanalyse

Renovatieprojecten Ongeacht complexiteit Ongeacht projectomvang Ongeacht planning Altijd In standaardsituaties Weinig keuzeruimte Ongeacht complexiteit Ongeacht projectomvang Ongeacht planning Gechecked = volledig

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.

86


10

Afwegingen vanuit de enquête

Afwegingstabellen 9.1 en 9.2 zijn gecombineerd tot onderstaande tabel 10.1. 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 Systems Engineering

Stelling

Wel bij Nieuwbouwprojecten Multidisciplinaire projecten Veel belanghebbenden Veel tegenstrijdige belangen afhankelijke projectonderdelen Installatietechnische projecten GWW projecten Projectgrootte ontwerpfase > 100.000 Projectduur ontwerpfase vanaf 6 maanden Beheersbaarheid in tijd Veel SE ervaring Theorie en geld Reduceert complexiteit Veel SE ervaring Theorie Nut bij projecten met Meer dan 4 jaar ervaring met SE weinig vrijheid Renovatieprojecten Veel ervaring met SE

Niet bij

Zorgt voor Kwaliteit Controlemiddel tbv kwaliteit Structuur

Zorgt niet voor Reductie tijd Verrassende oplossingen

Twijfel bij

Weinig SE ervaring Praktijk Weinig SE ervaring Praktijk Minder ervaring met SE

Minder ervaring met SE Systeembeschrijving

Projecten ongeacht

Eisenanalyse

Projecten ongeacht

Complexiteit Projectomvang Planning Aantal disciplines Denken/sturen in bepaalde oplossingsrichting

Complexiteit Projectomvang Planning Aantal disciplines Projecten ongeacht

Functieanalyse

Complexiteit Projectomvang Planning Aantal disciplines Altijd Weinig complexe projecten Functievervullers die niet meer aan eisen voldoen Weinig tijd en geld (voordelen wegen op)

Ontwerpafweging In standaardsituaties Weinig keuzeruimte Raakvlakken

Theorie Ingenieursbureau Meer SE ervaring Projecten ongeacht

Duidelijk beeld van OG Innovatieve wat hij wil hebben oplossingen

Het gaat sporadisch om verrassende oplossingen

Specifieke installatietechnische oplossingen Praktijk Aannemer Weinig SE ervaring

Weergave in tekening

RAMSanalyse

Externe raakvlakken Interne raakvlakken Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines

het zoeken naar andere alternatieven (vaker dan dat selectiecriteria dat doen)

Onnodige kosten Als je RAMS gechecked hebt, ben je nog niet volledig

Volledige systeembeschrijving

Overtuiging Verificatie

Projecten ongeacht Complexiteit Projectomvang Planning Aantal disciplines

Tabel 10.1: afwegingen vanuit de enquête

Controle van ontwerp op eisen

Controle door onafhankelijk persoon

Hoofdstuk: Afwegingen vanuit de enquête


87


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.

Hoofdstuk: Afwegingen vanuit de enquête

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.

88

Deel D; Afwegingen en conclusies


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.

11.2

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

11.3

91


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.

11.4

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 €100.000,- 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.

11.5

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)

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-


Hypothese: Systems Engineering is alleen zinvol in projecten waar voldoende keuzeruimte wordt geboden

92


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.

11.6

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.

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


Hypothese: Systems Engineering zorgt voor verrassende oplossingen

93


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.

11.7

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.

11.8

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).

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 10.000 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


Hypothese: eisen worden aan functies gesteld

94


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.

11.9

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.


•

95


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 12.3. Als laatste worden in dit hoofdstuk aanbevelingen gegeven in paragraaf 12.4.

Hoofdstuk: Conclusies en aanbevelingen

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.

97


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.

12.2.1 Systems Engineering Onderdeel

Kenmerk

Systems Engineering

Algemeen

Wel (bij)

Niet bij

Zorgt voor

Zorgt niet voor

Twijfel bij

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) Transparantie (3)

Belangen en belanghebbenden

Complexiteit

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)

Reductie van complexiteit bij Risico-reductie (9.4 & 11.3) ervaren team mbt SE (≥4 jaar) (4 & 9.4) Zorgen voor verrassende en innovatieve oplossingen (9.3.2, 9.4 & 11.7)

Innovatie

Kosten

Tijd

Fase V-model

Projectgrootte in de ontwerpfase vanaf €100.00,- (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)

Soort project

GWW-projecten (9.3.2)

Keuzeruimte

Installatietechnische projecten (9.4 & 11.5) Keuzevrijheid (11.5)

Weinig keuzevrijheid met ervaren team mbt SE (≥4 jaar) (11.5)

Kostenreductie (9.4 & 11.4) Tijdreductie (9.4 & 11.2)

Renovatieproject met weinig ervaren team mbt SE (9.4 & 11.5)

Weinig keuzevrijheid (11.5) Standaardoplossin gen (11.5)

Tabel 12.1: afwegingen Systems Engineering

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


Aantal disciplines Afhankelijkheid

98


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

12.2.2 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) Systeem-beschrijving Ongeacht (9.3.3) Complexiteit Projectomvang Planning Aantal disciplines Ongeacht Eisenanalyse (9.3.4) Complexiteit

Niet bij

Zorgt voor

Zorgt niet voor

Twijfel bij

Sturen in een bepaalde oplossingsrichting

Projectomvang Planning Aantal disciplines Altijd (9.4)

Ontwerpafweging

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)

Raakvlakken (9.3.7)

Ongeacht Complexiteit Projectomvang Planning Aantal disciplines Ongeacht (9.4) Complexiteit

RAMS

Projectomvang Planning Verificatie (9.3.9)

Aantal disciplines Ongeacht Complexiteit

Randvoorwaarden (6)

Onvolledige systeembeschrijving (9.3.8)

Zorgen voor verrassende oplossingen (9.3.5, 9.4 & 11.6)

Het zoeken naar Volledigheid (9.4) andere alternatieven (9.3.8) Overtuiging (9.3.8) Ontwerpcontrole

Projectomvang Planning Aantal disciplines

Tabel 12.2: afwegingen SE onderdelen

Wanneer er een verwijzing staat bij het onderdeel, geldt dit voor alle toepassingsmogelijkheden en eigenschappen die daarachter genoemd zijn.


Functieanalyse

99


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.

12.4

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)

12.4.1 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


•

10 0


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 9.2.2 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.

12.4.2 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?


• • • •

10 1



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.

10 2


13

Gebruikte begrippen en afkortingen

13.1

Begrippenlijst

Begrip Beschikbaarheid

Beschrijving ‫=ܣ‬

Betrouwbaarheid Complexiteit

Decomponeren Raakvlakken

Risico’s Systems Engineering

Systems Engineering Effort

Het betreft de absolute (aaneengesloten) tijd dat het systeem werkt zonder falen. mean time between failure (NEN-EN 50126) Het percentage van de tijd dat het systeem werkt en beschikbaar is. 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) het ontleden van een op hoger niveau staand systeem De functionele en fysieke eigenschappen die dienen te bestaan voor het in samenhang functioneren van delen op een gemeenschappelijke grens (ProRail & Rijkswaterstaat, 2007) Kans x gevolg (Helm, 1996) 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. SEE bestaat uit de kwaliteit van de uitgevoerde Systems engineering en het percentage project kosten wat besteed is aan Systems Engineering. (Honour, 2004)

Afkortingen

Afkorting GWW HBO HSL HVVOS ICT MCA RAMS SE SEE WO

(NEN-EN 50126)

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

13.2

௠௘௔௡ ௧௜௠௘ ௕௘௧௪௘௘௡ ௙௔௜௟௨௥௘ (௠௘௔௡ ௧௜௠௘ ௧௢ ௥௘௣௔௜௥ା௠௘௔௡ ௧௜௠௘ ௕௘௧௪௘௘௡ ௙௔௜௟௨௥௘)

10 3


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.

14.2

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.

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

California department of transportation, division of research and innovation (2007) “Systems Engineering Guidebook for ITS” Caltrans.

10 5


Department of Defense (2001) “Systems Engineering Fundamentals” Virginia Defense acquisition press. Eelants, J.P. & Visser, A. (2007) “Programmaplan; CROW-kennisprogramma Systems Engineering 2007-2010” CROW. Helm, P (1996) “Integrated risk management for natural and technological disasters” Tephra, 15(1): 4-13. 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) www.incose.org INCOSE. Institute of Electrical and Electronics Engineers (1990) “IEEE STD 610.12-1990; IEEE Standard Glossary of Software Engineering Terminology” IEEE ISO/IEC 15288: 2002 (NL) Leijten, Martijn & Bruijn, Hans de (2004-2005) “Algemene kenmerken van grote infrastructuur projecten” Tweede Kamer, vergaderjaar 2004-2005, 29 283, 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

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

ONRI (2005) “Posities en rollen van advies- en ingenieursbureaus in een dynamische markt” ONRI.

10 6


Rijkswaterstaat (2006) “Werkwijzer Marktconsultatie” Rijkswaterstaat. Systems Engineering applications technical committee (2000) “Systems Engineering applications profiles, version 3.0” INCOSE.

Hoofdstuk: Bronnen

US Department of transportation, Federal highway administration & Federal transit administration (2007) “Systems Engineering for intelligent transportation systems; an introduction for transportation professionals” FHA.

10 7

Bijlagen


E. Vink De Bilt, 18 december 2008

Bijlagen


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


Inhoudsopgave Bijlage 1 Literatuuronderzoek................................................................................. 7 Bijlage 2 uitwerking interviews ............................................................................... 9 Bijlage 3 enquête ................................................................................................... 15 Bijlage 4 verantwoording enquête........................................................................ 29 Bijlage 5 enquête resultaten losse vragen .......................................................... 37 Bijlage 6 enquête resultaten gemiddelden ........................................................ 133


Bijlage 7 kruistabellen ......................................................................................... 155

5


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 2007-2010” 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

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

Kennisinstanties • INCOSE • CROW • Rijkswaterstaat • ProRail

7


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 • • • • • • • • • • • •

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

2.2

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

9

• • • • • • • • • • • • • • • • • • • • • •

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



10

Systems Engineering in de praktijk • • • •

2.3

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

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 • • • • • •

Functieanalyse • • • • • • • • •

2.6

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.

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


2.5

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

11

Systems Engineering in de praktijk • • • • • • • • • • •

2.7

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.

Ontwerp • • • • •

2.8

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

RAMS • • • •

Raakvlakken • • • • • • • • •

2.10 • •

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


2.9

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

12


2.11 • • • • •

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


• • • • • • • •

13


enquête

Hoofdstuk: enquête

Bijlage 3

15

Hoofdstuk: enquête


16


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))

Hoofdstuk: enquête

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.

17


Systeembeschrijving

Hoofdstuk: enquête

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)

18

Hoofdstuk: enquête


19


Eisenanalyse

Hoofdstuk: enquête

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)

20


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)

Hoofdstuk: enquête

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).

21

Hoofdstuk: enquête


22


Ontwerpafweging

Hoofdstuk: enquête

De ontwerpafweging heeft als doel het afwegen van alternatieven in het ontwerp om zo aantoonbaar te maken dat het best passende alternatief gekozen is.

23

Hoofdstuk: enquête


24


Ontwerp

Raakvlakken

Hoofdstuk: enquête

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)

25

Hoofdstuk: enquête


26


RAMS

Hoofdstuk: enquête

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.

27


Verificatie

Hoofdstuk: enquête

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)

28


Bijlage 4

4.1

Systems Engineering ...................................................................................................... 29 Systeembeschrijving ....................................................................................................... 30 Eisenanalyse .................................................................................................................... 30 Functieanalyse ................................................................................................................. 31 Ontwerpafweging............................................................................................................. 33 Ontwerp ............................................................................................................................ 33 RAMS ................................................................................................................................ 35 Verificatie .......................................................................................................................... 35

Systems Engineering

Stellingen SE biedt structuur SE biedt een controlemiddel ten behoeve van kwaliteit

Herkomst Theorie Insteek HOMIJ vanwege A73 project

SE zorgt voor verrassende oplossingen

Interviews

SE biedt beheersbaarheid van het project in tijd en geld SE reduceert de benodigde tijd SE maakt alle beslissingen expliciet SE reduceert complexiteit SE maakt het werk eenvoudiger SE is zinvol om toe te passen bij grond-, wegen waterbouwprojecten SE is zinvol om toe te passen bij Installatietechnische projecten

Interviews Theorie Theorie Theorie Theorie Theorie

Interviews

Opmerkingen Eens Eens, er moet bewezen worden dat HOMIJ wel kwaliteit kan leveren. Niet binnen HVVOS, want er was geen keuzeruimte geboden door de Opdrachtgever Daarin zit de meerwaarde van Systems Engineering. Controlevraag Eens Eens Controlevraag Eens (Leidraad SE)

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

Theorie, projectkenmerken

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)

Interviews

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


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

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

verantwoording enquête

29


projectduur in de ontwerpfase vanaf (tijdsduur in maanden) SE moet toegepast worden in nieuwbouw projecten SE moet toegepast worden in renovatieprojecten

Leidraad Systems Engineering

Theorie Interviews

Eens Oneens, want alles ligt al vast dus heeft SE geen meerwaarde meer.

Systeembeschrijving

Stellingen De systeembeschrijving wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Het is nodig om deze stap expliciet op te schrijven

Herkomst Interviews

Opmerkingen Draagt bij aan het doel van het onderzoek

Interviews

Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig?

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 1


Controlevraag





Controlevraag

Interviews

Theorie

Jan in ’t Veld

Interviews

Dat werd bij HVVOS als gemis gezien.

Theorie

Theorie 1

Gesprekken

Eisenanalyse

Gesprekken met afstudeercommissie


4.2

Theorie

30


Stellingen De eisenanalyse wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Het is nodig om deze stap expliciet op te schrijven

Herkomst Interviews


Interviews


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 Elke eis heeft een topeis Eisen stellen zonder te sturen op een oplossingsrichting is onmogelijk

Interviews





Controlevraag

Interviews

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. 2

Interviews, gesprekken

2

Interviews, gesprekken 2

Gesprekken Interviews

Oneens

Herkomst Interviews


Functieanalyse

Stellingen De functieanalyse wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is 2

Controlevraag



4.4


31


Het is nodig om deze stap expliciet op te schrijven

Interviews

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

Interviews

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


Controlevraag





Controlevraag

Theorie, projectkenmerken 3

Gesprekken

HVVOS

Interviews

Interviews


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.


3


32


Eisen worden aan functies gesteld Eisen worden aan functievervullers gesteld Functionele eisen zijn oplossingsvrij Een functionele eis beschrijft de prestatie van een functie

Interviews

Controlevraag

Theorie

CROW 4

Theorie, gesprekken

Ontwerpafweging

Stellingen De ontwerpafweging wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Het is nodig om deze stap expliciet op te schrijven

Herkomst Interviews


Interviews

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

Interviews

Systems Engineering betekent veel papierwerk en administratie, is dat allemaal nodig? Voor standaardsituaties zijn standaardoplossingen

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

Interviews

4.6

Voor specifieke installatietechnische problemen zijn al specifieke oplossingen.

Interviews

Interviews Interviews

Interviews

Gegenereerde alternatieven voldoen niet aan de criteria (bijvoorbeeld budget) omdat bij het formuleren van die criteria al uit is gegaan van een bepaalde oplossing

Interviews

Ontwerp

Stellingen Op basis van een objectenboom kan gebouwd worden Een objectenboom formuleren 4

Interviews

Herkomst 4 Gesprekken 4

Gesprekken


Opmerkingen Oneens, maar het maken van ‘bestekstekeningen’ wordt uitgesteld.


4.5

Theorie

33


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 De raakvlakken worden ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Het is nodig om deze stap expliciet op te schrijven

Herkomst Interviews


Interviews


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


Controlevraag





Controlevraag

Interviews

Interviews

5

Gesprekken

5

Gesprekken

Interviews


Raakvlakken kunnen ook visueel worden uitgebeeld, en plaatjes zeggen meer dan


5


34


woorden.

RAMS

Stellingen De RA(MS) analyse wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Het is nodig om deze stap expliciet op te schrijven

Herkomst Interviews


Interviews


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

Interviews Interviews

4.8

Controlevraag





Controlevraag

Interviews

RAMS voorwaarden zijn meer bindend dan de selectiecriteria. Hier valt niet over te onderhandelen.

Interviews

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.

6

Gesprekken

Verificatie

Stellingen De verificatie wordt ingevuld omdat het meerwaarde heeft en niet alleen omdat vereist is Het is nodig om deze stap expliciet op te schrijven 6


Herkomst Interviews


Interviews

Systems Engineering betekent veel papierwerk en



4.7

35


administratie, is dat allemaal nodig? 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


Verificatie is, in de huidige vorm, maar beperkt zinvol. Het is nog steeds lastig grijpbaar of ontwerpen nu echt aan de eisen voldoen Verificatie is de ontwerpcontrole De opdrachtgever is verantwoordelijk voor het juist formuleren van de topeis

Interviews

Controlevraag


Theorie, projectkenmerken Theorie, projectkenmerken


Controlevraag

Theorie, projectkenmerken Interviews

Het wordt nu vaak ingevuld zonder terug te kijken naar documenten, maar op geheugen.

7

Gesprekken 7 Gesprekken



7


36


Bijlage 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

5.1

enquête resultaten losse vragen

Algemeen .......................................................................................................................... 37 Systems Engineering ...................................................................................................... 43 Systeembeschrijving ....................................................................................................... 55 Eisenanalyse .................................................................................................................... 66 Functieanalyse ................................................................................................................. 76 Ontwerpafweging............................................................................................................. 91 Ontwerp .......................................................................................................................... 100 Raakvlakken ................................................................................................................... 102 RAMS .............................................................................................................................. 111 Verificatie ........................................................................................................................ 122

Algemeen In welke soort organisatie bent u werkzaam? Valid Cumulative

Valid Aannemer

3

Percent

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

Total

34

100,0

100,0

Wat is uw hoogst genoten opleiding? Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Frequency Percent Percent

37


Wat is uw hoogst genoten opleiding? Cumulative Frequency Valid

Percent

Valid Percent

Percent

HBO

13

38,2

38,2

38,2

WO

20

58,8

58,8

97,1

WO+

1

2,9

2,9

100,0

Total

34

100,0

100,0

Hoeveel jaren werkervaring heeft u? Cumulative

Valid

Percent

Valid Percent

Percent

1-4 jaar

10

29,4

29,4

29,4

4-10 jaar

4

11,8

11,8

41,2

meer dan 10 jaar

20

58,8

58,8

100,0

Total

34

100,0

100,0


Frequency

38


Hoeveel jaren projectervaring heeft u? Cumulative Frequency Valid

Percent

Valid Percent

Percent

1-4 jaar

12

35,3

35,3

35,3

4-10 jaar

3

8,8

8,8

44,1

meer dan 10 jaar

19

55,9

55,9

100,0

Total

34

100,0

100,0

Wat is de gemiddelde omvang van de projecten waar u bij betrokken bent? Cumulative

Valid

Percent

Valid Percent

Percent

klein

1

2,9

2,9

2,9

middel

14

41,2

41,2

44,1

groot

19

55,9

55,9

100,0

Total

34

100,0

100,0


Frequency

39


Hoeveel ervaring heeft u met Systems Engineering? Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Hoeveel projecten heeft u doorgaans naast elkaar lopen waarbij Systems Engineering wordt ingezet? Cumulative

Valid

Percent

Valid Percent

Percent

1

11

32,4

32,4

32,4

2-4

16

47,1

47,1

79,4

meer dan 4

5

14,7

14,7

94,1

weggevallen

2

5,9

5,9

100,0

Total

34

100,0

100,0


Frequency

40


Hoelang bent u betroken geweest bij HVVOS Cumulative

Valid

Percent

Valid Percent

Percent

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.

21

61,8

61,8

97,1

weggevallen

1

2,9

2,9

100,0

Total

34

100,0

100,0

De definitie die hierboven gegeven is is juist Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

2

5,9

5,9

5,9

mee oneens

3

8,8

8,8

14,7


Frequency

41


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

Total

34

100,0

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 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


geëxploiteerd. Daarnaast is SE voor mij het theoretisch kader om het gedrag van complexe

42


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 Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE biedt een controlemiddel ten behoeve van kwaliteit Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

43


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

Total

34

100,0

100,0

SE zorgt voor verrassende oplossingen Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

44


SE biedt beheersbaarheid van het project in tijd en geld Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE maakt alle beslissingen expliciet Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

45


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

Total

34

100,0

100,0

SE maakt het werk eenvoudiger Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0 Hoofdstuk: enquête resultaten losse vragen

Frequency

46


SE reduceert de benodigde tijd Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE reduceert complexiteit Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

47


Het gebruik van SE komt de kwaliteit van het eindproduct niet ten goede Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE is zinvol om toe te passen bij grond, wegen waterbouwprojecten Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

2

5,9

5,9

5,9

neutraal

14

41,2

41,2

47,1


Frequency

48


mee eens

14

41,2

41,2

88,2

helemaal mee eens

4

11,8

11,8

100,0

Total

34

100,0

100,0

SE is zinvol om toe te passen bij Installatietechnische projecten Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE moet toegepast worden wanneer de projectonderdelen afhankelijk van elkaar zijn


Frequency

49


Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE moet toegepast worden bij projecten waar veel partijen belangen in hebben of er veel tegenstrijdige belangen zijn Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

50


SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt gegeven Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

SE moet toegepast worde wanneer het project multidisciplinair is Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

51


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

Total

34

100,0

100,0

SE moet toegepast worden voor een projectgrootte in de ontwerpfase vanaf Cumulative

Valid

Percent

Valid Percent

Percent

weggevallen

2

5,9

5,9

5,9

< 1000 euro

4

11,8

11,8

17,6

10.000 euro

6

17,6

17,6

35,3

100.000 euro

10

29,4

29,4

64,7

1.000.000 euro

7

20,6

20,6

85,3

> 10.000.000

5

14,7

14,7

100,0

Total

34

100,0

100,0


Frequency

52


SE moet toegepast worden vanaf een projectomvang van Cumulative

Valid

Percent

Valid Percent

Percent

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


2

5,9

5,9

88,2


1

2,9

2,9

91,2

> 25 projectmedewerkers

3

8,8

8,8

100,0

Total

34

100,0

100,0

SE moet toegepast worden bij een projectduur in de ontwerpfase vanaf Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

53


< 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

Total

34

100,0

100,0

SE moet toegepast worden in nieuwbouw projecten Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

54


SE moet toegepast worden in renovatie projecten Cumulative

Valid

5.3

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Systeembeschrijving Ik heb ervaring met het begrip systeembeschrijving Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

55


Valid

Ja

32

94,1

94,1

94,1

Nee

2

5,9

5,9

100,0

Total

34

100,0

100,0

De definitie die hierboven gegeven is is juist Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

De systeembeschrijving wordt ingevuld omdat het meerwaarde heeft


Frequency

56



Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de systeembeschrijving expliciet op te schrijven Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

57


De systeembeschrijving wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een systeembeschrijving moet gegeven worden ongeacht de complexiteit Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

58


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

Total

34

100,0

100,0

Een systeembeschrijving moet gegeven worden ongeacht de projectomvang Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

59


Een systeembeschrijving moet gegeven worden ongeacht de planning Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een systeembeschrijving moet gegeven worden ongeacht het aantal disciplines Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

60


De verschillen tussen de huidige en gewenste situatie moeten duidelijk in beeld komen Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ook bij weinig complexe projecten is een systeembeschrijving zinvol Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

61


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

Total

34

100,0

100,0

Ook bij monodisciplinaire projecten is een systeembeschrijving zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een systeembeschrijving geeft een beeld van het project


Frequency

62



Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een systeembeschrijving geeft aan wat er moet veranderen Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

63


Een systeembeschrijving geeft aan welke functies een complex heeft Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een systeembeschrijving geeft relaties weer Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

2

5,9

5,9

5,9

helemaal mee oneens

1

2,9

2,9

8,8


Frequency

64


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

Total

34

100,0

100,0

Een systeembeschrijving beschrijft de functies van het project Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

65


5.4

Eisenanalyse Ik heb ervaring met het begrip eisenanalyse Cumulative Frequency

Valid

Percent

Valid Percent

Percent

Ja

30

88,2

88,2

88,2

Nee

4

11,8

11,8

100,0

Total

34

100,0

100,0


Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

66


De eisenanalyse wordt ingevuld omdat het meerwaarde heeft Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de eisenanalyse expliciet op te schrijven Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

4

11,8

11,8

11,8

mee oneens

2

5,9

5,9

17,6


Frequency

67


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

Total

34

100,0

100,0

De eisenanalyse wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

68


Een eisenanalyse moet gegeven worden ongeacht de complexiteit Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een eisenanalyse moet gegeven worden ongeacht de projectomvang Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

69


Een eisenanalyse moet gegeven worden ongeacht de planning Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een eisenanalyse moet gegeven worden ongeacht het aantal disciplines Cumulative Frequency Valid

weggevallen

4

Percent 11,8

Valid Percent 11,8

Percent 11,8


Frequency

70


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

Total

34

100,0

100,0

Een eisenanalyse bevooroordeeld je in het denken in een bepaalde oplossingsrichting en moet dus na de ontwerpafweging gedaan worden Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

71


Ook bij weinig complexe projecten is een eisenanalyse zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ook bij monodisciplinaire projecten is een eisenanalyse zinvol Cumulative Frequency Valid

weggevallen

4

Percent 11,8

Valid Percent 11,8

Percent 11,8


Frequency

72


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

Total

34

100,0

100,0

Een opsomming van de eisen van Rijkswaterstaat is voldoende, er hoeft geen analyse gedaan te worden Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

73


Hoe meer eisen er geformuleerd worden, des te minder ontwerpvrijheid heb je Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Hoe meer eisen je formuleert, des te kleiner is de kans dat je krijgt wat je verwacht Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

74


Elke eis heeft een topeis Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Eisen stellen zonder te sturen op een oplossingsrichting is onmogelijk Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

5

14,7

14,7

14,7

helemaal mee oneens

8

23,5

23,5

38,2


Frequency

75


5.5

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

Total

34

100,0

100,0

Functieanalyse Ik heb ervaring met het begrip functieanalyse Cumulative

Valid

Percent

Valid Percent

Percent

Ja

26

76,5

76,5

76,5

Nee

8

23,5

23,5

100,0

Total

34

100,0

100,0

De definitie van functie die hierboven gegeven is juist


Frequency

76



Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

De definitie van functieanalyse die hierboven gegeven is juist Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

77


De functieanalyse wordt ingevuld omdat het meerwaarde heeft Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de functieanalyse expliciet op te schrijven Cumulative Frequency Valid

weggevallen

8

Percent 23,5

Valid Percent 23,5

Percent 23,5


Frequency

78


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

Total

34

100,0

100,0

De functieanalyse wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

79


Een functieanalyse moet gegeven worden ongeacht de complexiteit Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een functieanalyse moet gegeven worden ongeacht de projectomvang Cumulative Frequency Valid

weggevallen

8

Percent 23,5

Valid Percent 23,5

Percent 23,5


Frequency

80


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

Total

34

100,0

100,0

Een functieanalyse moet gegeven worden ongeacht de planning Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

81


Een functieanalyse moet gegeven worden ongeacht het aantal disciplines Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een functieanalyse moet altijd worden gedaan Cumulative Frequency Valid

weggevallen

8

Percent 23,5

Valid Percent 23,5

Percent 23,5


Frequency

82


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

Total

34

100,0

100,0

Een functieanalyse wordt gedaan om innovatieve oplossingen in de hand te werken Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

83


Een functieanalyse wordt gedaan om ervoor te zorgen dat er geen gaten vallen in het eisenpakket Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ook bij weinig complexe projecten is een functieanalyse zinvol Cumulative Frequency Valid

weggevallen

8

Percent 23,5

Valid Percent 23,5

Percent 23,5


Frequency

84


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

Total

34

100,0

100,0

Ook bij monodisciplinaire projecten is een functieanalyse zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

85


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. Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een functieanalyse is niet zinvol als er al functievervullers zijn, die alleen niet meer voldoen. Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

86


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

Total

34

100,0

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. Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

87


Een functieanalyse kan niet gemaakt worden zonder dat het ontwerp voor handen is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een functie wordt beschreven door een werkwoord en een zelfstandig naamwoord Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

9

26,5

26,5

26,5

mee oneens

2

5,9

5,9

32,4


Frequency

88


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

Total

34

100,0

100,0

Eisen worden aan functies gesteld Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

89


Eisen worden aan functievervullers gesteld Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Functionele eisen zijn oplossingsvrij Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

90


Een functionele eis beschrijft de prestatie van een functie Cumulative

Valid

5.6

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ontwerpafweging Ik heb ervaring met het begrip ontwerpafweging Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

91


Valid

Ja

28

82,4

82,4

82,4

Nee

6

17,6

17,6

100,0

Total

34

100,0

100,0


Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

De ontwerpafweging wordt ingevuld omdat het meerwaarde heeft


Frequency

92



Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de ontwerpafweging expliciet op te schrijven Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

93


De ontwerpafweging wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft Cumulative Frequency Valid

weggevallen

6

Percent 17,6

Valid Percent 17,6

Percent 17,6


Frequency

94


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

Total

34

100,0

100,0

Ontwerpafweging van specifieke installatietechnische oplossingen zijn niet zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

95


Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het gaat slechts sporadisch om verassende oplossingen Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

96


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

Total

34

100,0

100,0

De voordelen die de ontwerpafwegingen opleveren, wegen niet op tegen de tijd die het kost Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

97


Keuzes zijn vaak al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om het hier nog een keer te doen. Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

80% van de ontwerpen in de installatietechniek zijn nu hetzelfde als 10 jaar geleden Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

98


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

Total

34

100,0

100,0

De 20% die verschilt in de ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

99


5.7

Ontwerp Op basis van een objectenboom kan gebouwd worden Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een objectenboom formuleren is gelijk aan ontwerpen Cumulative Frequency Valid

weggevallen

2

Percent 5,9

Valid Percent 5,9

Percent 5,9


Frequency

100


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

Total

34

100,0

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. Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

101


5.8

Raakvlakken Ik heb ervaring met het begrip raakvlakken Cumulative

Valid

Percent

Valid Percent

Percent

Ja

29

85,3

85,3

85,3

Nee

5

14,7

14,7

100,0

Total

34

100,0

100,0

De definitie die hierboven gegeven is is juist Cumulative Frequency Valid

Percent

Valid Percent

Percent

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


Frequency

102


helemaal mee eens

10

29,4

29,4

Total

34

100,0

100,0

100,0

De raakvlakken worden ingevuld omdat het meerwaarde heeft Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de raakvlakken expliciet op te schrijven Cumulative Frequency Valid

weggevallen

5

Percent 14,7

Valid Percent 14,7

Percent 14,7


Frequency

103


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

Total

34

100,0

100,0

De raakvlakken wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

104


De beschrijving van de raakvlakken moet gegeven worden ongeacht de complexiteit Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

De beschrijving van de raakvlakken moet gegeven worden ongeacht de projectomvang Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

105


De beschrijving van de raakvlakken moet gegeven worden ongeacht de planning Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

De beschrijving van de raakvlakken moet gegeven worden ongeacht het aantal disciplines Cumulative Frequency Valid

Percent

Valid Percent

Percent

weggevallen

5

14,7

14,7

14,7

mee oneens

4

11,8

11,8

26,5


Frequency

106


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

Total

34

100,0

100,0

Ook bij weinig complexe projecten is een raakvlakanalyse zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

107


Ook bij monodisciplinaire projecten is een raakvlakanalyse zinvol Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Raakvlakken moeten afgestemd worden tussen de verschillende systemen en disciplines, alleen interne raakvlakken (per systeem) opschrijven is zinloos. Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

108


Interne raakvlakken zijn onzinnig, want deze zitten binnen een ontwerp waar je als team mee bezig bent en verantwoordelijk voor bent. Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het formuleren van raakvlakken gebeurt op basis van een objecten structuur Cumulative Frequency Valid

weggevallen

5

Percent 14,7

Valid Percent 14,7

Percent 14,7


Frequency

109


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

Total

34

100,0

100,0

Het formuleren van raakvlakken gebeurt op basis van een ontwerp Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

110


Raakvlakken moeten weergegeven worden in een tekening Cumulative

Valid

5.9

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

RAMS Ik heb ervaring met het begrip RAMS Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

111


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

Total

34

100,0

100,0


Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

112


De RA(MS) analyse wordt ingevuld omdat het meerwaarde heeft Cumulative Frequency Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de ramsanalyse expliciet op te schrijven Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

113


De ramsanalyse wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een ramsanalyse moet gedaan worden ongeacht de complexiteit Cumulative Frequency Valid

weggevallen

10

Percent 29,4

Valid Percent 29,4

Percent 29,4


Frequency

114


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

Total

34

100,0

100,0

Een ramsanalyse moet gedaan worden ongeacht de projectomvang Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

115


Een ramsanalyse moet gedaan worden ongeacht de planning Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een ramsanalyse moet gedaan worden ongeacht het aantal disciplines Cumulative Frequency Valid

weggevallen

10

Percent 29,4

Valid Percent 29,4

Percent 29,4


Frequency

116


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

Total

34

100,0

100,0

Ook bij weinig complexe projecten is een ramsanalyse zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

117


Ook bij monodisciplinaire projecten is een ramsanalyse zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

RAMS bepaalt vaker dat er andere alternatieven gezocht en gekozen moeten worden dan de selectiecriteria in de ontwerpafweging Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

118


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

Total

34

100,0

100,0

RAMS is weinig overtuigend want het is ‘slechts’ statistiek Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

119


Als RA(MS) gechecked is en voldoet dan ben ik volledig Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

RA(MS) is onnodig duur Cumulative Frequency Valid

weggevallen

10

Percent 29,4

Valid Percent 29,4

Percent 29,4


Frequency

120


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

Total

34

100,0

100,0

Voor een goede RA(MS) analyse is een volledige systeembeschrijving nodig Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

121


5.10

Verificatie Ik heb ervaring met het begrip verificatie Cumulative Frequency

Valid

Percent

Valid Percent

Percent

Ja

25

73,5

73,5

73,5

Nee

9

26,5

26,5

100,0

Total

34

100,0

100,0


Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

122


De verificatie wordt ingevuld omdat het meerwaarde heeft Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Het is nodig om de verificatie expliciet op te schrijven Cumulative Frequency Valid

Percent

Valid Percent

Percent

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


Frequency

123


helemaal mee eens

10

29,4

29,4

100,0

Total

34

100,0

100,0

De verificatie wordt ingevuld omdat het vereist is Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een verificatie moet uitgevoerd worden ongeacht de complexiteit


Frequency

124



Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een verificatie moet uitgevoerd worden ongeacht de projectomvang Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

125


Een verificatie moet uitgevoerd worden ongeacht de planning Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Een verificatie moet uitgevoerd worden ongeacht het aantal disciplines Cumulative Frequency Valid

Percent

Valid Percent

Percent

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


Frequency

126


helemaal mee eens

10

29,4

29,4

Total

34

100,0

100,0

100,0

Een verificatie moet altijd uitgevoerd worden Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ook bij weinig complexe projecten is een verificatie zinvol


Frequency

127



Percent

Valid Percent

Percent

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

Total

34

100,0

100,0

Ook bij monodisciplinaire projecten is een verificatie zinvol Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0


Frequency

128


Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

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. Cumulative Frequency

Percent

Valid Percent

Percent


Frequency

129


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

Total

34

100,0

100,0

Verificatie is de ontwerpcontrole Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

130


De opdrachtgever is verantwoordelijk voor het juist formuleren van de top eis Cumulative

Valid

Percent

Valid Percent

Percent

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

Total

34

100,0

100,0


Frequency

131


Bijlage 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9

6.1

enquête resultaten gemiddelden

Systems Engineering .................................................................................................... 133 Systeembeschrijving ..................................................................................................... 136 Eisenanalyse .................................................................................................................. 139 Functieanalyse ............................................................................................................... 142 Ontwerpafweging........................................................................................................... 145 Ontwerp .......................................................................................................................... 147 Raakvlakken ................................................................................................................... 148 RAMS .............................................................................................................................. 151 Verificatie ........................................................................................................................ 153

Systems Engineering Statistics N Valid

SE biedt structuur

Missing

Mean

Std. Deviation

Variance

32

2

4,31

,738

,544

32

2

3,84

,987

,975

32

2

2,78

,906

,822

32

2

3,09

1,118

1,249

32

2

3,66

,937

,878

32

2

2,53

1,016

1,031

32

2

2,53

,950

,902

SE reduceert complexiteit 32

2

2,84

1,110

1,233

32

2

2,31

,896

,802

passen bij grond-, wegen 32

2

3,69

,693

,480

2

3,84

,987

,975

SE biedt een controlemiddel ten behoeve van kwaliteit SE zorgt voor verrassende oplossingen SE biedt beheersbaarheid van het project in tijd en

SE maakt alle beslissingen expliciet SE maakt het werk eenvoudiger SE reduceert de benodigde tijd

Het gebruik van SE komt de kwaliteit van het eindproduct niet ten goede SE is zinvol om toe te waterbouwprojecten SE is zinvol om toe te passen bij Installatietechnische projecten

32

Hoofdstuk: enquête resultaten gemiddelden

geld

133


SE moet toegepast worden wanneer de projectonderdelen

32

2

3,72

,813

,660

32

2

3,78

,706

,499

32

2

3,12

1,289

1,661

32

2

3,94

,759

,577

32

2

4,12

,707

,500

32

2

3,12

1,185

1,403

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 projecten waarbinnen weinig vrijheid wordt gegeven SE moet toegepast worde wanneer het project

SE moet toegepast worden in nieuwbouw projecten SE moet toegepast worden in renovatie projecten


multidisciplinair is

134



135


6.2

Systeembeschrijving Statistics N Valid

Missing

Mean

Std. Deviation

Variance

De systeembeschrijving wordt ingevuld omdat het

32

2

4,19

,644

,415

32

2

4,31

,644

,415

32

2

3,00

1,078

1,161

32

2

4,19

,821

,673

32

2

4,16

,847

,717

32

2

4,16

,808

,652

32

2

4,22

,751

,564

32

2

4,31

,738

,544

32

2

4,28

,729

,531

32

2

4,25

,718

,516

32

2

3,94

,982

,964

meerwaarde heeft Het is nodig om de systeembeschrijving expliciet op te schrijven De systeembeschrijving wordt ingevuld omdat het vereist is Een systeembeschrijving moet gegeven worden ongeacht de complexiteit 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

huidige en gewenste situatie moeten duidelijk in beeld komen Ook bij weinig complexe projecten is een systeembeschrijving zinvol Ook bij monodisciplinaire projecten is een systeembeschrijving zinvol Een systeembeschrijving geeft een beeld van het project


De verschillen tussen de

136


Een systeembeschrijving geeft aan wat er moet

32

2

3,16

1,194

1,426

32

2

3,84

,987

,975

32

2

3,31

1,120

1,254

32

2

3,78

1,070

1,144

veranderen Een systeembeschrijving geeft aan welke functies een complex heeft Een systeembeschrijving geeft relaties weer Een systeembeschrijving beschrijft de functies van


het project

137



138


6.3

Eisenanalyse

Statistics N Valid

Missing

Mean

Std. Deviation

Variance

De eisenanalyse wordt ingevuld omdat het

30

4

3,97

,850

,723

30

4

4,00

,871

,759

ingevuld omdat het vereist 30

4

3,27

1,230

1,513

4

3,93

,944

,892

4

3,83

1,053

1,109

4

3,83

1,085

1,178

4

3,83

1,020

1,040

5

2,07

1,334

1,781

30

4

3,77

,971

,944

30

4

3,87

,860

,740

meerwaarde heeft Het is nodig om de eisenanalyse expliciet op te schrijven De eisenanalyse wordt is Een eisenanalyse moet gegeven worden ongeacht 30 de complexiteit Een eisenanalyse moet gegeven worden ongeacht 30 de projectomvang Een eisenanalyse moet gegeven worden ongeacht 30 de planning Een eisenanalyse moet gegeven worden ongeacht 30 het aantal disciplines Een eisenanalyse bevooroordeeld je in het oplossingsrichting en moet 29 dus na de ontwerpafweging gedaan worden Ook bij weinig complexe projecten is een eisenanalyse zinvol Ook bij monodisciplinaire projecten is een eisenanalyse zinvol


denken in een bepaalde

139


Een opsomming van de eisen van Rijkswaterstaat is voldoende, er hoeft

29

5

1,72

,702

,493

29

5

3,45

1,183

1,399

29

5

2,34

,897

,805

29

5

3,72

1,131

1,278

29

5

2,48

1,379

1,901

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 Elke eis heeft een topeis Eisen stellen zonder te sturen op een oplossingsrichting is


onmogelijk

140



141


6.4

Functieanalyse

Statistics N Valid

Missing

Mean

Std. Deviation

Variance

De functieanalyse wordt ingevuld omdat het

26

8

3,73

1,041

1,085

functieanalyse expliciet op te 26

8

3,92

1,017

1,034

26

8

3,12

1,177

1,386

gegeven worden ongeacht de 26

8

3,35

1,294

1,675

8

3,35

1,294

1,675

8

3,42

1,301

1,694

26

8

3,54

1,240

1,538

26

8

3,23

1,275

1,625

26

8

3,46

1,104

1,218

26

8

3,42

1,238

1,534

26

8

3,46

1,104

1,218

meerwaarde heeft Het is nodig om de schrijven De functieanalyse wordt ingevuld omdat het vereist is Een functieanalyse moet complexiteit Een functieanalyse moet gegeven worden ongeacht de 26 projectomvang Een functieanalyse moet gegeven worden ongeacht de 26 planning Een functieanalyse moet gegeven worden ongeacht het aantal disciplines Een functieanalyse moet altijd worden gedaan

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 Ook bij weinig complexe projecten is een functieanalyse zinvol


Een functieanalyse wordt

142


Ook bij monodisciplinaire projecten is een

26

8

3,54

1,067

1,138

26

8

3,85

1,120

1,255

26

8

2,58

,987

,974

26

8

3,65

,892

,795

26

8

1,96

,824

,678

25

9

3,96

,935

,873

26

8

3,00

1,233

1,520

26

8

4,00

,800

,640

26

8

3,58

1,102

1,214

26

8

3,69

1,158

1,342

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 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 alleen niet meer voldoen. 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. Een functieanalyse kan niet gemaakt worden zonder dat het ontwerp voor handen is Een functie wordt beschreven door een werkwoord en een

Eisen worden aan functies gesteld Eisen worden aan functievervullers gesteld Functionele eisen zijn oplossingsvrij Een functionele eis beschrijft de prestatie van een functie


zelfstandig naamwoord

143



144


6.5

Ontwerpafweging Statistics N Valid

Missing

Mean

Std. Deviation

Variance

De ontwerpafweging wordt ingevuld omdat het

28

6

4,14

,591

,349

27

7

4,15

,770

,593

28

6

3,25

1,143

1,306

28

6

3,11

1,286

1,655

28

6

2,32

1,124

1,263

28

6

2,64

1,129

1,275

28

6

3,21

1,067

1,138

28

6

2,36

,678

,460

28

6

2,93

1,052

1,106

meerwaarde heeft Het is nodig om de ontwerpafweging expliciet op te schrijven De ontwerpafweging wordt ingevuld omdat het vereist is Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft Ontwerpafweging van specifieke installatietechnische oplossingen zijn niet zinvol Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn

om verassende oplossingen De voordelen die de ontwerpafwegingen opleveren, wegen niet op 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.


Het gaat slechts sporadisch

145


80% van de ontwerpen in de installatietechniek zijn nu hetzelfde als 10 jaar

26

8

2,73

,827

,685

26

8

2,92

,891

,794

geleden De 20% die verschilt in de ontwerpen is puur te wijten aan nieuwe technologische


ontwikkelingen

146


6.6

Ontwerp

Statistics N Valid

Missing

Mean

Std. Deviation Variance

Op basis van een objectenboom kan

32

2

2,69

1,148

1,319

32

2

2,81

1,230

1,512

32

2

2,84

1,081

1,168

gebouwd worden Een objectenboom formuleren 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.

147


6.7

Raakvlakken

Statistics N Valid

Missing

Mean

Std. Deviation

Variance

De raakvlakken worden ingevuld omdat het

29

5

4,31

,604

,365

29

5

4,38

,677

,458

29

5

3,00

1,254

1,571

29

5

3,97

,865

,749

29

5

3,90

,939

,882

29

5

3,83

1,002

1,005

29

5

3,93

1,067

1,138

29

5

3,97

,906

,820

29

5

3,69

1,137

1,293

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

Ook bij weinig complexe projecten is een raakvlakanalyse zinvol Ook bij monodisciplinaire projecten is een raakvlakanalyse zinvol


disciplines

148


Raakvlakken moeten afgestemd worden tussen de verschillende systemen en

29

5

3,69

1,198

1,436

28

6

1,79

,995

,989

raakvlakken gebeurt op basis 29

5

3,76

,786

,618

5

3,21

1,082

1,170

5

2,97

,906

,820

disciplines, alleen interne raakvlakken (per systeem) opschrijven 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 van een objecten structuur Het formuleren van

raakvlakken gebeurt op basis 29 van een ontwerp Raakvlakken moeten weergegeven worden in een 29


tekening

149



150


6.8

RAMS Statistics N Valid

Missing

Mean

Std. Deviation

Variance

De RA(MS) analyse wordt ingevuld omdat het

24

10

3,83

1,007

1,014

ramsanalyse expliciet op te 24

10

4,21

,721

,520

24

10

3,25

1,113

1,239

gedaan worden ongeacht de 24

10

3,38

1,279

1,636

10

3,42

1,283

1,645

10

3,46

1,285

1,650

24

10

3,46

1,285

1,650

24

10

3,33

1,204

1,449

24

10

3,54

1,141

1,303

24

10

3,21

1,141

1,303

23

11

2,04

1,065

1,134

meerwaarde heeft Het is nodig om de schrijven De ramsanalyse wordt ingevuld omdat het vereist is Een ramsanalyse moet complexiteit Een ramsanalyse moet gedaan worden ongeacht de 24 projectomvang Een ramsanalyse moet gedaan worden ongeacht de 24 planning Een ramsanalyse moet gedaan worden ongeacht het aantal disciplines Ook bij weinig complexe projecten is een ramsanalyse zinvol

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


Ook bij monodisciplinaire

151


Als RA(MS) gechecked is en voldoet dan ben ik

24

10

2,29

1,083

1,172

24

10

2,38

,875

,766

24

10

3,92

1,060

1,123

volledig RA(MS) is onnodig duur Voor een goede RA(MS) analyse is een volledige


systeembeschrijving nodig

152


6.9

Verificatie

Statistics N Valid De verificatie wordt ingevuld

Missing

Mean

Std. Deviation

Variance

25

9

4,16

,688

,473

25

9

4,20

,764

,583

25

9

3,52

1,229

1,510

uitgevoerd worden ongeacht 25

9

4,28

,678

,460

9

4,32

,627

,393

9

4,32

,690

,477

9

4,28

,678

,460

25

9

4,08

,954

,910

25

9

4,24

,723

,523

25

9

4,20

,764

,583

25

9

3,00

1,041

1,083

25

9

2,60

1,080

1,167

omdat het meerwaarde heeft Het is nodig om de verificatie expliciet op te schrijven De verificatie wordt ingevuld omdat het vereist is Een verificatie moet de complexiteit Een verificatie moet

uitgevoerd worden ongeacht 25 de projectomvang Een verificatie moet uitgevoerd worden ongeacht 25 de planning Een verificatie moet uitgevoerd worden ongeacht 25 het aantal disciplines Een verificatie moet altijd uitgevoerd worden Ook bij weinig complexe projecten is een verificatie zinvol

projecten is een verificatie zinvol 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.


Ook bij monodisciplinaire

153


Verificatie is de ontwerpcontrole

24

10

3,50

,885

,783

25

9

3,96

1,020

1,040

De opdrachtgever is verantwoordelijk voor het juist formuleren van de top


eis

154


Bijlage 7 7.1 7.2

7.1

kruistabellen

Onafhankelijke variabelen ............................................................................................ 155 Vergelijking afhankelijke variabelen met onafhankelijke variabelen ....................... 158

Onafhankelijke variabelen

Hoofdstuk: kruistabellen

In welke soort organisatie bent u werkzaam? * SE reduceert complexiteit

155



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

156



157


7.2

Vergelijking afhankelijke variabelen met onafhankelijke 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 in voorgaande paragraaf al is aangetoond dat organisatie en opleiding verband met elkaar hebben. Alle stellingen die onbetrouwbare gemiddelden hebben opgeleverd, worden in deze bijlage kort besproken. Systems Engineering SE biedt beheersbaarheid van het project in tijd en geld Allereerst wordt gekeken naar het verband tussen de organisatie waar men werkzaam is en de stelling ‘SE biedt beheersbaarheid van het project in tijd en geld’. Het gemiddelde van de antwoorden op deze stelling is 3,09. Dat wil zeggen neutraal met een kleine hang naar mee eens.

SE biedt beheersbaarheid van het project in tijd en geld Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5

Organisatie Respondenten die de vragenlijst beantwoord hebben vanuit de opdrachtgever en consultancy zijn overwegend positief. De aannemer is echter negatief. Het ingenieursbureau vertoont zowel positieve als negatieve antwoorden. Eenzelfde verdeling is terug te vinden bij de koppeling tussen organisatie en opleidingsniveau. Beide kruistabellen samengenomen kan geconcludeerd worden dat in theorie Systems Engineering beheersbaarheid biedt in tijd en geld, maar dit in de praktijk nog niet opgaat.

SE biedt beheersbaarheid van het project in tijd en geld Total meer dan 4 jaar 2-4 jaar minder dan 2 jaar 1,5

2

2,5

3

3,5

4

4,5

5

SE ervaring Uit deze figuur valt af te leiden dat hoe meer Systems Engineering ervaring men heeft, hoe positiever men staat tegenover de stelling ‘SE biedt beheersbaarheid van het project in tijd en geld’.


1

158


SE biedt beheersbaarheid van het project in tijd en geld Total n.v.t. vanaf de gunning vanaf de aanbieding vanaf de initiatie 1

1,5

2

2,5

3

3,5

4

4,5

5

HVVOS Bij HVVOS kan geconcludeerd worden dat respondenten betrokken vanaf de initiatie de beheersbaarheid in tijd en geld wel af en toe hebben gezien. Maar respondenten die later betrokken zijn, deze beheersbaarheid niet als kenmerk van het project hebben opgemerkt. Dit kan liggen aan de functie die men bekleedde binnen het project. Conclusie Gekeken naar organisatie, opleidingsniveau, SE ervaring en betrokkenheid bij HVVOS, kan geconcludeerd worden dat SE beheersbaarheid biedt in tijd en geld wanneer je een aantal jaren ervaring hebt met SE en werkt 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 Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 2,84. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

SE reduceert complexiteit Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5


Organisatie Door de consultancy en opdrachtgever wordt hier neutraal tot positief op gereageerd, door het ingenieursbureau en de aannemer neutraal tot negatief.

159


SE reduceert complexiteit Total meer dan 4 jaar 2-4 jaar minder dan 2 jaar 1

1,5

2

2,5

3

3,5

4

4,5

5

SE ervaring Hoe meer SE ervaring men heeft, hoe positiever er gereageerd wordt op de stelling ‘SE reduceert complexiteit’.

SE reduceert complexiteit Total n.v.t. vanaf de gunning vanaf de aanbieding vanaf de initiatie 1

1,5

2

2,5

3

3,5

4

4,5

5

HVVOS Binnen HVVOS heeft Systems Engineering de complexiteit niet gereduceerd. Conclusie Alleen respondenten met meer dan 4 jaar SE ervaring, 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 Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,12. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt gegeven Total Consultancy Opdrachtgever Aannemer 1

Organisatie

1,5

2

2,5

3

3,5

4

4,5

5


Ingenieursbureau

160


Alleen de opdrachtgever gelooft erin dat SE nut heeft bij projecten waarbinnen weinig vrijheid gegeven wordt. De aannemer beaamt de stelling volledig.

SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt gegeven Total meer dan 4 jaar 2-4 jaar minder dan 2 jaar 1

1,5

2

2,5

3

3,5

4

4,5

5

SE ervaring Respondenten met meer dan 2 jaar ervaring vinden dat SE nut kan hebben binnen projecten waar weinig vrijheid gegeven wordt.

SE heeft geen nut bij projecten waarbinnen weinig vrijheid wordt gegeven Total n.v.t. vanaf de gunning vanaf de aanbieding vanaf de initiatie 1

1,5

2

2,5

3

3,5

4

4,5

5

HVVOS Bij HVVOS werd door de opdrachtgever weinig vrijheid gegeven en binnen dit project is de mening dat SE daardoor geen nut heeft gehad. Betrokkenen vanaf de initiatie zijn daar iets milder over gestemd, maar binnen deze groep bevindt zich ook de opdrachtgever, wat deze score verklaart. Conclusie 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.


SE moet toegepast worden bij renovatieprojecten Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,12. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

161


SE moet toegepast worden in renovatie projecten Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5

Organisatie De opdrachtgever beaamd deze stelling, overigen zijn neutraal tot mee oneens.

SE moet toegepast worden in renovatie projecten Total meer dan 4 jaar 2-4 jaar minder dan 2 jaar 1

1,5

2

2,5

3

3,5

4

4,5

5

SE ervaring Hoe meer SE ervaring, hoe meer nut men inziet van het toepassen van Systems Engineering bij renovatieprojecten.

SE moet toegepast worden in renovatie projecten Total n.v.t. vanaf de gunning vanaf de aanbieding vanaf de initiatie 1,5

2

2,5

3

3,5

4

4,5

5

HVVOS De HVVOS projectmedewerkers zijn er over eens dat SE niet toegepast moet worden bij renovatie projecten. Conclusie Alleen de opdrachtgever en mensen met veel Systems Engineering ervaring zien nut in het toepassen van Systems Engineering bij renovatieprojecten. Systeembeschrijving


1

162


Een systeembeschrijving geeft aan wat er moet veranderen Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,16. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Een systeembeschrijving geeft relaties weer Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,31. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Eisenanalyse Elke eis heeft een topeis Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,72. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Functieanalyse Een functieanalyse moet gegeven worden ongeacht de complexiteit Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,35. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Een functieanalyse moet gegeven worden ongeacht de projectomvang Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,35. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Een functieanalyse moet gegeven worden ongeacht de planning Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,42. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Een functieanalyse moet altijd worden gedaan Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,23. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden.


Eisen worden aan functies gesteld Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,00. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

163


Eisen worden aan functies gesteld Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5

Organisatie De aannemer is het met de stelling eens. De andere organisaties zitten net boven of onder neutraal.

Eisen worden aan functies gesteld Total meer dan 4 jaar 2-4 jaar minder dan 2 jaar 1

1,5

2

2,5

3

3,5

4

4,5

5

SE ervaring Hoe minder ervaring hoe positiever over de stelling ‘Eisen worden aan functies gesteld’

Eisen worden aan functies gesteld Total n.v.t. vanaf de gunning vanaf de aanbieding vanaf de initiatie 1,5

2

2,5

3

3,5

4

4,5

5

HVVOS Binnen het project is men het erover eens dat eisen aan functies gesteld worden. Conclusie Door de aannemer en respondenten die weinig ervaring met Systems Engineering hebben en betrokkenen bij HVVOS wordt positief gereageerd op de stelling. Functionele eisen zijn oplossingsvrij Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,58. Dat


1

164


wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Ontwerpafweging Ontwerpafwegingen zijn alleen zinvol wanneer het geen standaardsituaties betreft Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,11. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5

Organisatie De opdrachtgever en consultancy zijn het niet eens met de stelling, terwijl het ingenieursbureau en de aannemer dat wel zijn. Dit heeft wellicht te maken met het verschil tussen theorie en praktijk.

Ontwerpafweging zijn alleen zinvol wanneer het geen standaardsituaties betreft Total n.v.t. vanaf de gunning vanaf de aanbieding vanaf de initiatie 1

1,5

2

2,5

3

3,5

4

4,5

5

HVVOS Alle betrokkenen bij HVVOS zijn het eens met de stelling. Waarschijnlijk omdat zij verplicht werden afwegingen te maken, terwijl er veel standaardsituaties voorkwamen.

Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 2,64. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.


Conclusie In de praktijk is het niet zinvol om afwegingen te maken wanneer het standaardsituaties betreft.

165


Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5

Organisatie De opdrachtgever is het hier natuurlijk niet mee eens, aangezien zij degene zijn die de keuzeruimte wel of niet bieden en daarnaast ontwerpafwegingen vereisen. De aannemer is het er als enige organisatie wel mee eens dat de ontwerpafwegingen zonde van de tijd zijn wanneer er geen keuzeruimte geboden wordt. Er wordt door de opdrachtgever vaak zo weinig keuzeruimte geboden dat ontwerpafwegingen zonde van de tijd zijn Total meer dan 4 jaar 2-4 jaar minder dan 2 jaar 1

2

3

4

5

SE ervaring Hoe meer ervaring, hoe meer mee oneens de respondenten het zijn met bovenstaande stelling. Conclusie 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.

De 20% die verschilt in ontwerpen is puur te wijten aan nieuwe technologische ontwikkelingen Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 2,92. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden.


Keuzes zijn vaak al in de aanbiedingsfase gemaakt (maar niet opgeschreven), het is dus eigenlijk dubbel om dat nog een keer te doen Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 2,93. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden.

166


Ontwerp De gemiddelden van de antwoorden van alle respondenten al de stellingen binnen het onderwerp Ontwerp kunnen zonder op of aanmerkingen meegenomen worden. Er is geen verband gevonden tussen de onafhankelijke en afhankelijke variabelen. Raakvlakken Raakvlakken moeten weergegeven worden in een tekening Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 2,97. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. RAMS Analyse RAMS analyse moet gedaan worden ongeacht de complexiteit Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,38. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. RAMS analyse moet gedaan worden ongeacht de projectomvang Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,42. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. RAMS analyse moet gedaan worden ongeacht de planning Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,46. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS blijkt er geen duidelijk verband te onderscheiden zijn en kan dit gemiddelde zonder op of aanmerkingen meegenomen worden. Als RAMS gecheckt is en voldoet, ben ik volledig Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 2,29. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

Als RA(MS) gechecked is en voldoet dan ben ik volledig Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1,5

2

2,5

3

3,5

4

4,5

5

Organisatie 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.


1

167


Verificatie Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan Het gemiddelde van de antwoorden van alle respondenten op de bovenstaande stelling is 3,00. Dat wil zeggen dat er neutraal tot mee oneens op gereageerd is. Vergeleken met organisatie, SE ervaring en HVVOS levert dit de volgende resultaten.

Verificatie moet eigenlijk door een onafhankelijk persoon worden gedaan Total Consultancy Opdrachtgever Ingenieursbureau Aannemer 1

1,5

2

2,5

3

3,5

4

4,5

5


Organisatie De opdrachtgever en aannemer zijn het redelijk eens dat dit door een onafhankelijke partij moet gebeuren.

168

Systems Engineering in de praktijk. Een onderzoek naar toepassingsmogelijkheden

Recommend Documents