Controlling enigneering-to-order processes in shipbuilding, a model-based approach

(1)

C

ONTROLLING

E

NGINEERING

-

TO

-O

RDER

P

ROCESSES IN

S

HIPBUILDING

-A MODEL-BASED APPROACH-

Proefschrift

ter verkrijging van de graad van doctor aan de Technische Universiteit Delft,

op gezag van de Rector Magnificus prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties,

in het openbaar te verdedigen op maandag 2 juni 2008 om 15.00 uur door Johanna Maria Gerarda COENEN

scheepsbouwkundig ingenieur

(2)

Dit proefschrift is goedgekeurd door de promotor: Prof. dr. ir. U. Nienhuis MBA

Samenstelling promotiecommissie: Rector Magnificus, voorzitter

Prof. dr. ir. U. Nienhuis MBA, Technische Universiteit Delft, promotor Prof. dr. ir. A. Verbraeck, Technische Universiteit Delft

Prof. dr. ir. J.L.G.Dietz, Technische Universiteit Delft Prof. Dr-Ing. S. Wenzel, Universität Kassel

Prof. ir. D. Stapersma, Technische Universiteit Delft Prof. ir. J.J. Hopman, Technische Universiteit Delft Dr. ir. M. van Hees, Qnowledge BV

(3)

SUMMARY

CONTROLLING ENGINEERING-TO-ORDER PROCESSES IN SHIPBUILDING -A MODEL BASED APPROACH-

The engineering process in Western European shipbuilding constitutes an important part of the complete ship-creation process. It not only requires a substantial number of labour hours, but also influences the total process course to a large extent, being the cradle of production and purchase information. The ship-engineering process not only comprises activities at a main contractor (mostly a shipyard, occasionally an engineering contractor) but also activities of many other parties like sub-contractors for instance for the electrical installation or hydraulic installation, suppliers of specific components, the classification society and the customer.

The most important characteristics of the engineering processes within this context are that:

The process is positioned between the stages ‘design’ from which it receives a conceptual design that has been described in requirements specification documents and production to which it supplies dimensioned product specifications of the ship’s structure and its outfit;

It can be characterized by two different stages: systems engineering (focusing on the configuration and specifications of technical systems) and detailed engineering (the stage in which all systems are further detailed into layout drawings, the networks are routed and the ship’s structure is specified in order to enable production or, depending on the organisation, work preparation);

Tasks are performed in parallel (so-called concurrent engineering), not only due to the time pressure, but also because of pre-assembly of sections in production during which phase parts of various systems of the ship are integrated (pre-outfitting):

The transition from the engineering stage to the production stage is not a fixed point in time, but has for each section of the ship its own milestone. This causes considerable overlap between engineering, procurement, pre-fabrication, assembly, pre-outfitting and outfitting activities;

Most products are unique, in the sense that within a certain product range specific characteristics can be chosen and specified by the customer. This is often referred to as ‘Engineering-to-Order’ (ETO).

A large problem regarding these shipbuilding engineering processes, but also other ETO processes, is that they display large –and often not anticipated- effort and throughput time ‘variations’, also for products that are comparable in size and complexity.

Reasons for this problem lie partly in the nature of the process:

Ships are very complex products, consisting of many sub-systems and components that must be integrated;

(8)

Different parties participate actively in the engineering process (yard, client, subcontractors etc.) and they all have different interests;

In ETO; each product that is engineered has unique features;

Networks of process participants and tasks are large and complicated; Error sources in engineering processes are of a stochastic nature;

A process -as it happens- is always only a realization of one of the possible scenarios.

Other reasons are related to the limited possibilities for process control: There is a lack of insight into these processes;

Most planning or control tools handle iterations poorly;

Most planning tools treat engineering processes like deterministic processes. Some tools allow for applying stochastic variables for effort, but still ignore the effect of iterations and alternative events;

Only small sample sizes of historical data are available due to the limited number of projects per organisation.

This research is based on the assertion that the engineering process can be explained (to a certain extent) by a mechanism that governs the process behaviour and that this mechanism can be described in terms of organisation and product characteristics. Therefore it should be possible to apply such a process description throughout different projects and even organisations and to make tools based on such models widely applicable too.

A process description is provided in the form of a dynamic model, with as two main purposes:

Introduction of additional means for operational planning;

Facilitation of tactical and/or strategic analyses of organizational changes. An important constraint to the method is that it should allow for efficient generation of process models (‘Modelling-to-Order’) as otherwise the effort and time necessary for analyzing a process might not outweigh the anticipated benefits.

The introduced modelling method applies to both small-scale engineering behaviour on the level of the smallest units of behaviour and information exchange in the engineering process as well as to the large-scale behaviour that focuses on the more human side of communication and transactions leading to specific task chronology. In both aspect models the ‘desire for information’ that exists in all activity elements in an information-intensive process such as shipbuilding engineering, initiates events.

On the small-scale level, the modelling method is characterised by the introduction of two different task class objects; one for the processing and creation of new information objects and one for the evaluation of these information objects. It is necessary for the control of the engineering process model to introduce an abstract, intangible object that reflects a ‘folder’ or container object for information that is exchanged. This allows for capturing also informal and preliminary exchange of information. Additionally an iteration concept is introduced that is essentially governed by two parameters: the likelihood of rejection of ‘information objects’ in an evaluation task (confidence level) and the impact of rejection in term of the quantity of rework that is caused (Instability). These confidence level and Instability attributes are ‘carried’ by the

(9)

so-called ‘information objects’ that are either created or enter and are processed in the tasks that together comprise the engineering process model. The handling of information objects is formalized for both types of task class object. The other essential driver for rework is so-called ‘Reprise’, a term that is used to cover the starting over of certain tasks because of new insights or information further “downstream”.

Important attributes of task objects are the necessary effort and skill for a task. The base effort value relates to product properties like scale, complexity, innovation etc. But due to the presence of the iteration construct the variance on the necessary effort caused by internal evaluation is large. Confidence level reflects ‘how well the maker estimates the quality of his creation’ while the Instability reflects the potential consequences of being wrong. The start confidence and Instability values of information objects entering the engineering process importantly influence the following process course. They reflect to a large extent how mature a design is at the close of the sale (when engineering proper starts), how innovative the ship is, whether ‘sister-ships’ are available etc.

Aggregation of combinations of task objects to large-scale ‘activity objects’ lead to the introduction of ‘jobs’. Looking at the essential behaviour and consistency of jobs in terms of information processing and information evaluation actions, it has been concluded that the variation in jobs is limited. Therefore the process can be modelled with a limited number of job types. A job type is always built in the same manner from the same ‘task’ building bricks.

Finding start settings for simulation models for engineering from regression analysis is not easy as historical data reflect just one realization of many possible scenarios for a certain project. Additionally hour registration data that are the main component of these data are of insufficient level of detail. Validation of the model therefore requires simplification of the job behaviour and also leaving out the ‘coincidental’ rework term that is constituted by ‘reprise’. For a set of six benchmark ships, model start settings have been obtained, partly by means of the simulation model itself. Instability, confidence level and skills have been systematically varied in order to verify the engineering process model behaviour. The results show consistent behaviour of engineering processes in reaction to these parameters. This implies a certain predictability of behaviour (despite its stochastic nature). The number of possible scenarios increases with the ‘uncertainty’ of information objects.

Additionally the effects on throughput time and the so-called ‘reprise’ have been investigated although in a more qualitative manner as for a full investigation of these issues further validation of the model, extension to multi-project analysis and inclusion of all jobs (including subcontractors) is required.

Also a short inventory of the influence of the structure of the ‘process network’, specifically the position of its nodes, has been made, showing that the particular shipbuilding engineering process studied in the case has evolved to a very efficient process in terms of throughput time, at the cost of relatively large engineering effort, largely accounted for by reprise.

(10)

These results allow for better understanding and awareness of process behaviour that can be implemented in daily planning practice:

Acceptance of the fact that planning is not deterministic is an important step to anticipation of schedule risk, which is defined by the probability of schedule overrun multiplied by the impact of the overrun. The variance in process scenarios can be straightforwardly related to the quality, state and ‘stability’ of the information objects available at a certain time in the planning; The effect of the task orders and the more coincidental reprise behaviour is

substantial but seems of less relative importance than assumed in literature. This supports the assumption made for this research that engineering processes are not truly unpredictable;

Scenarios for network planning can be generated by means of the developed simulation method and imported into a planning program;

Also ‘average’ schedules, including most likely prognoses that are deduced from the simulation method can be used for project management;

Sensitivity analyses can be made to indicate to project management which information objects, milestones of activities have priority when it comes to completing the (engineering phase of the) project in time and within budget. Together this provides a project manager with new insights into engineering processes and for the future additional control means for processes are within reach. Also applications for more strategic implementations have been explored as the method is flexible enough to analyse -relatively fast- the effect of changes in an organisation or engineering methods.

Further development of this engineering modelling method lies in the field of improved validation and regression of data (requiring better data acquisition in everyday engineering practice), and more ‘agent-like’ behaviour of workers regarding to prioritization and other means of control. Finally expansion of the model to include subcontractors is necessary.

(11)

SAMENVATTING

BEHEERSING VAN ‘ENGINEERING-TO-ORDER’ PROCESSEN IN DE SCHEEPSBOUW -EEN MODELGEBASEERDE AANPAK-

In de west Europese scheepsbouw beslaat het engineering proces een belangrijk deel van het totale voortbrengingsproces van een schip. Engineering kost een substantieel deel van de totaal benodigde manuren. Bovendien wordt het overige procesverloop in hoge mate beïnvloed door het engineering proces, onder andere omdat inkoop- en productie-informatie grotendeels op de tekenkamer tot stand komen. Activiteiten in het engineering proces zijn niet beperkt tot de hoofdaannemer (meestal een scheepswerf, soms een engineeringbureau) maar vinden ook plaats bij vele andere partijen zoals onderaannemers voor bijvoorbeeld de elektrische installatie of de hydraulische installatie, toeleveranciers, de classificatie maatschappij en de klant zelf. De belangrijkste kenmerken van het engineering proces zijn:

Start- en eindpunt van het proces worden gekenmerkt door het ontwerpstadium en het productiestadium. Input van de ontwerpafdeling is een ontwerp dat beschreven is in een bestek- en specificatiedocument, output naar de productie-afdeling zijn gedimensioneerde specificaties van de scheepsconstructie en de volledige uitrusting;

Het wordt globaal verdeeld in twee fasen: de zogenaamde ‘systeem engineering’ (waarin de nadruk ligt op de configuratie en specificatie van de technische systemen) en de ‘detail-engineering’ (het stadium waarin alle systemen verder gedetailleerd worden in lay-out tekeningen, de routering van de systeemnetwerken plaatsvindt en de scheepsconstructie uitgedetailleerd wordt voor productie);

Door de vele benodigde specialismen, tijdsdruk en niet te vergeten de bouwmethode waarbij ‘prefabricage’ plaatsvindt van verschillende scheepssecties, is het nodig dat engineering taken parallel plaatsvinden: ‘concurrent engineering’;

Dit maakt ook dat het einde van de detailengineering en de start van productie niet op één tijdstip afgebakend zijn, maar voor elke sectie een eigen overgangsmoment hebben;

Elk product is uniek en wordt uitgevoerd volgens klantspecificatie, al dan niet binnen een bepaalde range van producten: ‘Engineering-to-Order’ (ETO). Een groot probleem van engineering processen in de scheepsbouw en andere ETO processen is, dat er vaak -onvoorziene- uitschieters zijn in benodigde inspanning (manuren) en doorlooptijd. Dit wordt ook waargenomen voor producten die qua afmetingen en complexiteit heel vergelijkbaar zijn met eerder gebouwde schepen. Redenen voor dit probleem zijn deels terug te voeren op de aard van het proces:

Schepen zijn hele complexe producten en bevatten vele subsystemen en componenten die geïntegreerd moeten worden;

Het proces wordt uitgevoerd door verschillende partijen die elk een eigen belang hebben: werf, klant, subcontractors etc.;

(12)

Elk product heeft unieke kenmerken;

Zowel het netwerk van actoren in het proces als het netwerk van taken zijn omvangrijk en ingewikkeld;

De foutbronnen in engineering processen zijn stochastisch; Een proces is altijd slechts 1 realisatie van de mogelijke scenario’s;

Andere redenen hebben te maken met de beperkte beheersingsmogelijkheden voor processen:

Vanwege bovengenoemde kenmerken van het engineering proces is er weinig inzicht in hoe procesgedrag tot stand komt;

De meeste planningsprogramma’s kunnen slecht omgaan met iteratieve processen;

De meeste planningsprogramma’s benaderen het proces zijnde deterministisch. Er zijn gereedschappen die stochastische variabelen voor benodigde ‘effort’ kunnen verwerken in een simulatie, maar ook dan wordt het effect van iteraties of alternatieven in procesverloop genegeerd;

Omdat elke organisatie slechts een beperkt aantal projecten heeft uitgevoerd (met veelal verschillende schepen) is er maar hele kleine set historische project data beschikbaar.

Een van de uitgangspunten van dit onderzoek is, dat ondanks het bovenstaande, het gedrag van engineering processen verklaard kan worden door een mechanisme dat procesgedrag controleert. Bovendien moet zo’n mechanisme beschreven kunnen worden als functie van organisatie- en productkenmerken, zodat het een algemeen toepasbare procesbeschrijving oplevert die gebruikt kan worden voor verschillende projecten binnen en zelfs buiten organisaties. Hetzelfde geldt voor methoden en gereedschappen die op zo’n model gebaseerd worden.

In dit onderzoek is een poging ondernomen om een dynamisch procesmodel (simulatie) te maken met als hoofddoel:

Het introduceren van methoden om operationele planning te verbeteren en uit te breiden;

Het faciliteren van het maken van tactische en/of strategische analyse van veranderingen in organisaties;

Een belangrijke randvoorwaarde voor een dergelijke modelleermethode is dat zogenaamd ‘Modelling-to-Order’ mogelijk moet zijn. Hiermee wordt bedoeld dat een specifiek model zo snel en met zo weinig inspanning geconfigureerd moet kunnen worden, dat het loont om bij aanvang eerst een modelanalyse uit te voeren, ook voor processen die telkens andere producten opleveren.

De geïntroduceerde modelleermethode heeft betrekking op zowel het micro- als het macrogedrag van engineering. Het microgedrag richt zich op de kleinste ‘gedragseenheden’ en informatie eenheden. Het macrogedrag is gerelateerd aan de ‘menselijke' aspecten van engineering: communicatie en informatie-uitwisseling die leiden tot een specifieke chronologie van taken. In beide aspect modellen is ‘informatiebehoefte’ de aanleiding voor het initiëren van gebeurtenissen in het proces.

(13)

Om het procesgedrag op microschaal weer te kunnen geven, zijn twee zogenaamde ‘class’ objecten geïntroduceerd. De eerste voor het verwerken en genereren van nieuwe informatieobjecten en de tweede voor het evalueren van deze objecten. Een belangrijke stap voor het beheersen van het engineering procesgedrag is de introductie van een abstract en ‘vaag’ gedefinieerd object dat als het ware een containertje met informatie weergeeft. Dit object wordt geïntroduceerd om ook informele en voorlopige uitwisseling van informatie te kunnen beschrijven. Aanvullend hierop is een concept voor iteratie geïntroduceerd dat in essentie bestuurd wordt door twee parameters: de kans op afwijzing van een informatie-object in een evaluatie taak (het ‘confidence level’) en de impact van een dergelijke afwijzing in termen van de benodigde hoeveelheid herstelwerk die hierdoor veroorzaakt wordt (Instability). Het confidence level en de Instability zijn attributen van de informatie objecten, die gecreëerd en bewerkt worden in het engineering proces model. Het verwerken van informatie objecten door taken kan formeel en algemeen worden beschreven. Een andere vorm van itererend werk is de zogenaamde ‘reprise’. Deze term wordt gebruikt om weer te geven dat taken opnieuw gestart worden vanwege vernieuwde inzichten of nieuwe informatie.

De belangrijke attributen van taakobjecten zijn de benodigde ‘effort’ en vaardigheden voor een taak. De benodigde basis ‘effort’ van een taak kan in principe gerelateerd worden aan product eigenschappen zoals de omvang, complexiteit, innovativiteit etc. Maar door het geïntroduceerde iteratieconstruct kan de variantie op benodigde effort, veroorzaakt door interne evaluatie, groot zijn. Het ‘confidence level’ reflecteert hoe ‘goed’ en/of nauwkeurig een engineer zijn eigen creatie acht en de ‘Instability’ reflecteert wat de consequenties van een afwijzing van engineeringinformatie zijn. Het ‘startniveau’ van deze twee waarden vertegenwoordigt in grote mate hoe ‘volwassen’ een ontwerp is op het moment van het sluiten van het contract en hoe innovatief het ontwerp is. Dit heeft een grote invloed op het procesverloop. ‘Jobs’ zijn het resultaat van het aggregeren van sets taakobjecten naar activiteiten op een hoger niveau. Op basis van het essentiële gedrag van jobs en hun samenstelling uit taken, is geconcludeerd in elke organisatie slechts een beperkt aantal typen jobs voorkomen. Dit impliceert dat het proces gemodelleerd kan worden met een beperkt aantal typen jobs. Een job-type is altijd op deze wijze opgebouwd van dezelfde ‘taakbouwstenen’.

Het vinden van startinstellingen voor simulatiemodellen voor engineering met behulp van regressie analyse is lastig, gezien de beperkte beschikbaarheid van historische data, die bovendien slechts 1 realisatie van vele mogelijke scenario’s weergeven. Ook is de belangrijkste bron voor het verzamelen van deze data, de urenregistratie, vaak niet van hetzelfde detailniveau als het engineeringmodel. Voor validatie-doeleinden is het daarom nodig geweest het gedrag van het engineering model te versimpelen door de reprise-rework term weg te laten. Vervolgens zijn voor 6 benchmark-schepen de overige ‘rework’ termen (namelijk intern, door klasse en door klant geïnduceerd rework) geanalyseerd. Voor deze zes schepen zijn de belangrijkste model-startinstellingen, te weten Instability, confidence level en de ‘vaardigheid’ van resources, systematisch gevarieerd. De resultaten laten een consistente reactie op deze parameters zien. Dit impliceert een zekere mate van voorspelbaarheid van het procesgedrag, maar dit is wel stochastisch van aard. Het aantal mogelijke scenario’s neemt toe met de onzekerheid van de informatie objecten in het model.

(14)

In aanvulling op de gevoeligheidsstudie, zijn de effecten op doorlooptijd en reprise kwalitatief geanalyseerd. Hierbij moet opgemerkt worden dat een volledige analyse pas mogelijk is, wanneer de modelleermethode ook geschikt is voor multi-project analyse en wanneer ook subcontractor processen aan het model zijn toegevoegd. Een verkenning naar de invloed van de ‘structuur’ van het procesnetwerk en de posities van de ‘knopen’, heeft laten zien dat het casestudy proces blijkbaar ontwikkeld is naar een efficiënt proces in relatie tot doorlooptijd. Dit is wel ten koste van een relatief grote benodigde effort, die voor het grootste deel toegeschreven moet worden aan ‘reprise’ effort.

Bovengenoemde resultaten maken een beter begrip mogelijk van engineering procesgedrag. Dit kan nuttig zijn voor de dagelijkse planningspraktijk om de volgende redenen:

Het accepteren van het feit dat planningen niet deterministisch zijn is een belangrijke stap naar het beter anticiperen op planningsrisico’s. De mogelijke varianten voor processcenario’s kunnen gerelateerd worden aan de kwaliteit, status en stabiliteit van informatie-objecten die beschikbaar zijn op een zeker tijdstip in de planning;

Het effect van het ‘netwerk’, de volgorde van taken en het meer ‘toevallige’ reprise gedrag is substantieel, maar lijkt minder groot dan gesuggereerd in de relevante literatuur. Dit ondersteunt de aanname dat engineering processen minder ‘onvoorspelbaar’ zijn dan algemeen wordt aangenomen;

Door middel van het simulatieprogramma kunnen verschillende planningsscenario’s gegeneerd worden en vervolgens geïmporteerd in een planningspakket;

Ook gemiddelde planningen (in de zin van meest waarschijnlijk) kunnen afgeleid worden uit simulatieresultaten en gebruikt worden voor projectmanagement.

Bij elkaar voorziet dit de project manager van een aantal nieuwe inzichten en voor de toekomst mogelijk van instrumenten om processen te beheersen.

Het is ook mogelijk om toepassingen voor meer strategische doeleinden te realiseren, aangezien de modelmethode flexibel genoeg is om relatief snel het effect van veranderingen in een engineering organisatie of methoden te analyseren.

Verdere ontwikkeling van de beschreven methode is gewenst, met name in het gebied van verbeterde validatie en verzamelen van start-informatie. Ook het implementeren van ‘agent’-gedrag voor de resources, heeft prioriteit als het gaat om het verbeteren van het processimulatiemodel.

(15)

1 IMPROVING PROCESS CONTROL IN SHIPBUILDING

ENGINEERING

1.1 A

N

I

NTRODUCTION TO THE

C

ONTEXT OF

S

HIPBUILDING

E

NGINEERING

Despite a somewhat negative, rusty image the shipbuilding industry in Europe is a high-tech knowledge-intensive sector, accounting for an annual turnover of 3 billion euros in the Netherlands alone 1_{. A brief look into the global history of shipbuilding}

helps to understand the actual state of the sector: After World War II the Japanese and later the Korean and Chinese industry took over most of the high-volume, relatively non-complex ships like oil tankers, bulk ships and container ships. It forced the (Western) European shipyards, handicapped by their high production costs due to high wages, to specialize and concentrate on knowledge-intensive niche markets (that remained remunerative because of the exclusiveness of their products). Therefore nowadays many Western European shipyards typically produce small series or one-of-a-kind ships on customer specification. For these specialised ship-types and customer-specific ships, the (higher) costs of ship production (cutting, welding, assembly, outfitting) are of relative less importance, since the costs involved in the design and engineering and specialised equipment already result in a quite different cost level compared to ‘bulk yards’. The necessary, specific product-knowledge is maintained within a Western European network of shipyards, suppliers, research centres and universities (Hopman, 2007). Another important asset of the European yards has always been short throughput times in combination with reliability of delivery dates. Throughput times still tend to shorten, while complexity of ships increases, due to ongoing product innovation (Bronsart, 2004).

To maintain its market position the sector puts much effort into product innovation, but also into research in the field of improving shipbuilding ‘processes’. Targets of these improvements in the ‘process of creating a ship’ are reduction of necessary effort and man hours, shorter throughput times and higher customer (lifetime) value of the resulting product. Unfortunately design and engineering are not very transparent or predictable processes that are even further obscured by the unique nature of the products that are designed and engineered. Still, design and engineering are considered to be of crucial importance in retaining the competitive position, as product knowledge and innovation are created and applied mainly in these two stages. Also the foundation for the final customer value is laid to a large extent in this stage.

(16)

1.1.1 DEMARCATION OF THE ENGINEERING PROCESSES

A general definition of ‘engineering’ is: ‘the creative application of science in technique to design or develop products’ (also called engineering design)2_{. ‘Design’ is the process}

of inventing and describing something new. According to Lamb there is a substantial difference between the nature of ‘engineering’ and ‘design’: Design decides all technical matters, while engineering develops and documents the design to enable its manufacture (Lamb, 2003). This definition is somewhat problematic as in shipbuilding for organizational reasons often the demarcation between what are called design activities and engineering activities is simply based on the moment the contract is signed. At that moment the ‘work’ is passed on to another department. This does not necessarily mean that ‘decision-making’ has ended: additional choices between possible alternatives or decisions regarding the prioritization of conflicting requirements must still be made.

When interested in ‘the process at the engineering department’ (from now on referred to simply as ‘engineering’) it must be recognized that also for engineering this ‘decision-making’ element is an important characteristic.

When referring with ‘design’ to ‘the process at the design department’ it is difficult to generalise its results, as these depend to a large extent on the time that was available for a tender or offer. Mostly these results include at least:

dimensions; displacement; stability;

propulsive characteristics; hull form;

preliminary general arrangement;

principal structural details (Rawson, 2001).

Thus, in the context of this research ‘design’ refers to the stage in which customer’s questions, requirements and constraints are used as input to arrive at a set of specifications mainly at the aggregation level of the entire ship. As the quality of the specifications in terms of ‘maturity’ and detail differs from project to project and from organisation to organisation, the starting point for the ‘engineering process’ cannot be clearly defined. The term ‘design’ will in this thesis refer to the design process and not its result (for which design specification will be used) unless explicitly stated otherwise.

The definition of engineering as ‘a process of transformation of specifications and requirements into a complete description of a physical product that matches this specification’ (Nahm, 2005) does not exclude this ‘design’ or decision-making element. Top-level product specifications are mostly ‘functional’, expressing which functions a product must be able to ‘perform’. At a lower level, specifications can also be more tangible and conclusive, requiring e.g. specific make and type of components.

Another term related to engineering is product development (PD), which is often

(17)

used in the context of bringing a new product to market. This product is often produced in larger quantities: series or mass production. Used in that connotation, PD also includes design and engineering activities. A ‘product’ is something that is produced and in the context of this research when using the term product this refers to a ship. A ship is a complex product, composite of many ‘sub-products’ that can be identified by their different functions that often interface and interact with each other. Typical for Western European Shipbuilding is that each design specification leads to a single product or a small series of products. Therefore design and order-specific product development in shipbuilding will often coincide. It implies that aspects of product development can be relevant for shipbuilding engineering too. (Of course in shipbuilding, product development is not exclusively related to specific client requests or orders.) Therefore the term PD will be replaced with Engineering-to-Order wherever its use would be confusing.

In daily practice the engineering process is in several aspects regarded to be less complex than design:

Typical shipbuilding engineering deliverables are closer to ‘routine’ product specifications than those of truly ‘new’ product development. This may imply that design failure is less unpredictable for engineering than it is for design and product development since engineering is a further developed part of the process;

Generally only sub-systems of the product are developed of which the coherence with the majority of other systems is well-known;

Also the required output and deliverables are well-defined; for in-stance by drawing lists, but also in the customer specification contract document; Historical information on at least part of the process behaviour (e.g. on

rejection of output) is available;

Not many possibilities for changing the order of processes exist as very much is dictated by the production and purchase schedules; this forces engineers to have very productive iterations, thus limiting number of alternative process scenarios.

Engineering in shipbuilding (including procurement and project-management) is a large cost item with respect to labour (about 20-35% of the total shipyard labour hours). Of these, the drawing room accounts for 15-25% of the labour hours.

The effect in labour costs is even larger because of the high education level of engineers. For an average ship engineering requires tens of thousands to hundreds of thousands man hours. But also other considerable cost drivers as production efficiency and purchase costs have a direct relation with engineering activities. This is also the case for failure costs that can be the result of errors in engineering. Throughput times of engineering are always under pressure due to attempts to further shortening of ship delivery times.

(18)

Engineering-to-Order (ETO) is the term used to indicate that a product is designed specifically for one user. Although the term ETO refers to engineering only, design and production of ETO products are custom too (other names like one-off engineering/building, project-based manufacturing, design-to-order or custom building are in use too). The shipyards under study can therefore be regarded as examples of Engineering-to-Order companies. Engineering-to-Order companies design, produce and deliver complex, customer specific products. An important part of the design process of an ETO company consists of customer specific adaptation of some form of predefined design specification. This predefined design specification can range from a complete ship design, to standard modules, to product families or specific technology. The ‘degree of customer specification freedom’ is an indication of the extent to which the customer is allowed to deviate from the standards incorporated in the pre-defined product descriptions, which were developed independently of the customer order (Muntslag, 1993).

1.1.2 CONCURRENCY AND MULTI-DISCIPLINARITY IN SHIPBUILDING ENGINEERING PROCESSES

Multidisciplinary engineering is inherent to shipbuilding. This certainly applies to engineering of the ‘specialised ship types’ that are within the focus of this research. A ship is designed to perform certain operational tasks (Klein Woud, 2002). The product -the ship- integrates dedicated “payload” or operational functions (like dredging, fishing, heavy lift) and so-called platform functions (providing accommodation, providing survivability, providing mobility). The resulting extreme integration of operational and platform functions in order to fulfil a mission, is something that ‘special ship type’ shipbuilding has in common with for instance aerospace and offshore construction. The resulting product is generally a compromise: for instance between functional requirements and safety requirements, or between functional and hydrodynamic constraints etc. The ship’s structure (the hull, including decks, frames, bulkheads, super-structures, foundations etc.) is a prominent part of the product platform. Payload functionality is provided by e.g. the ‘dredging system’. A system is in this context a combination of components and their interfaces that together fulfil a certain function. In shipbuilding the term system often refers to a mechanical ‘auxiliary’ or support system like cooling (cooling water system), air-conditioning etc. Shipbuilding engineering processes are generally characterised as ‘concurrent’.

Concurrent Engineering (CE) is a way of arranging engineering processes of the different sub-products, sub-systems and sub-structures simultaneously or at least with overlap in time. Although sometimes presented as an engineering management “philosophy” and a set of operating principles that aim to accelerate the engineering process (Yassine, 2003a), in many cases concurrent engineering is a natural and pragmatic answer to situations where the:

Decomposition of processes is required because of the limitations on cognitive and information processing capabilities of the engineers (Yassine, 2003b). In other words, different people are necessary for the different (specialistic) disciplines of engineering;

(19)

A certain degree of parallelism is a necessary condition to reach the desired acceleration of processes, for keeping the throughput time of engineering in line with that of production.

Proven to be an effective strategy (Graaf, 1996) to shorten throughput times, it has replaced sequential processes (Culley, 1999). Other reported advantages of concurrent engineering are amongst others less engineering changes and lower manufacturing costs (Graaf, 1996).

1.1.3 CONCURRENCY OF ENGINEERING AND PRODUCTION

Just as its starting point, the end demarcation of engineering is also not clearly defined. Engineering is followed by the production process (the process of manufacturing), which is a phased process of constructing sub-assemblies as blocks and sections. A section is a multi-deck segment of the hull or superstructure, a ‘slice’ of ship so to say. A block (e.g. fore ship, aft ship, engine room) is formed by a number of sections, block assembly (or erection) is generally performed at the slipway.

This building method has been introduced as a form of process rationalization, departing the original strict order of keel-laying, erection and outfitting in favour of so-called ‘section building’ in roofed workshops with much better conditions for quality control. (This was amongst others facilitated by the introduction of welding, making it possible to assemble the sections (Weijers, 1985)). Another productivity enhancing factor of this building method is the fact that separate sections are better accessible than the often constrained compartments aboard. A compartment is an enclosed volume such as a cabin, boatswain store, boiler room etc. Additionally the possibility to rotate sections drastically reduces non-ergonomic work in positions above the head. Generally in shipbuilding engineering a division between the stages ‘systems engineering’ (sometimes also called detailed design, or initial engineering) and ‘detailed engineering’ is employed.

‘Systems engineering’ includes the specification of the main structural elements, the specification and arrangement of all main systems and specification of parts and properties for purchase and the layout of compartments. This also includes the specification of connections and couplings between components in a system, often in the form of a sketch or diagram. Engineering purchase specifications (not to be confused with design specifications) are made as the yard may also act as a buyer or customer (of components and material) and will therefore put functional requirements (at the system and component level rather than the ship level) together. The term Systems Engineering is also used in (naval) shipbuilding to denote an integrated approach to the design of systems in order to meet customer requirements in terms of desired functionality (Andrews, 2003). The definition applied for this research is narrower.

‘Detailed engineering’ generally includes making production drawings for the construction and pre-production departments, for pre-outfitting of sections and the outfitting of the erected ship.

A useful term in this context is ‘transition engineering’. This refers to the phase where the transition is made from system oriented to zone or block oriented engineering

(20)

(Lamb, 2003). This phase marks the end of systems engineering and the start of detailed engineering.

Work preparation for production (including nesting of materials, detailing parts lists for pre-fabrication etc.) is sometimes considered as a stage of engineering, but as it has such a strong focus on production, and is often located at the production department, it is not included in ‘engineering’ as defined for this research.

Sub-assembly production (mostly at section level) needs information from both ‘main engineering paths’ that is from structural engineering and outfitting. Structural engineering concerns the definition of the ship’s structure in terms of part topology and dimensions and corresponding material specification resulting in the strength, stiffness, etc. (the ‘steel’). Outfitting engineering concerns the definition of the payload and support systems, including pipeline and cable networks and the layout of the ship. Sub-assembly production generally starts before the complete detailed engineering has finished, implying that structural and outfitting engineering must converge just-in-time before the start of the production of each sub-assembly. Sub-assembly building puts time-pressure on the engineering department to deliver structural drawings early in the process.

(21)

Figure 1.1 shows the overlap between the different phases in the shipbuilding process: In the detailed-engineering phase it is aimed to provide the desired production drawings and instructions (because that is what the engineering process is meant to provide) in time for the production process. This implies that detailed engineering has time-overlap with almost the complete ‘production cycle’. Engineering activities in a very late stage of the shipbuilding process are for instance the creation of manuals, sea-trial documents or as-built documentation. The detailed view in the lower part of Figure 1.1 also shows an example (on the level of ship’s sections) of further detailing of detailed structural engineering and the following production activities (all related to steel building).

In Figure 1.2 it is attempted to give some more insight into the different activities in the engineering process. It discerns five main subjects of engineering:

The hull form with its hydrostatic and therefore weight constraints;

The ship structure: first engineered on main aspects per block, then in second instance per section;

The layout and outfitting of ‘zones’. Zones can be compartments (like the engine room) or a selection of adjoining compartments (like the accommodation). These type of activities concentrate on the positioning of the (main) components in a compartment. This stage is phased to provide in first instance necessary information for structural engineering and is later expanded and detailed;

The specifications for outfitting of components and systems. A division is made between main systems and components with priority and the secondary work;

Network outfitting is used to indicate the engineering of for instance ducts in a system, some of these must also be considered in an early stage because of their volume or necessary openings in for instance decks or bulkheads, others are engineered at a later stage in the engineering process.

(22)

All this work converges in the set-up of a three-dimensional model of the ship including all its components, ducts etc. Whenever possible, information is already converted into detailed production information for pre-outfit. Other work has to wait until outfitting. Outfitting in production relates to the installation of components and systems, including the pipe and cable networks on board. In many cases it is preferred to install components and parts already in sub-assemblies before erection on the slipway has taken place. This is normally indicated with the term pre-outfitting.

1.1.4 A STRONG PRODUCT-PROCESS LINK

In engineering a strong relation exists between the resulting product and the process that brings forth the product: the product dictates what kind of engineering activities are necessary. In specialistic shipbuilding each product has unique properties because of the level of freedom in customer specification and because of ongoing innovations. Still within a certain product range, regardless of the different results of the specification and engineering processes, the performed engineering tasks will to a large extent be the same (for instance hull and structural design, mechanical support systems etc). New or substantially different products of course require new or unusual engineering tasks, but even then shipbuilding engineering tasks will to some extent be common (like making a weight calculation: the procedure remains the same but the outcome is different). It implies that basic task patterns are available for ships within a certain functionality range. Moore states that over 50% of the work of a designer on a day-to-day basis consists of routine based on past design solutions (Moore, 1993). Also in engineering re-use of solutions is normal (Browning, 2006, Nieuwenhuis 2007). It is also suspected that a strong parametric relation exists between certain product parameters, like size and complexity of the ship and process behaviour. Indicators for complexity are for instance the number of interactions between sub-systems of the ship or the “depth” of the product decomposition into sub-systems (Lamb, 2003). The ‘volatility’ of a client of a certain project is also considered as a ‘product’ parameter as this may largely influence the process course and total necessary effort for a project if it leads to adjustments of product requirements during the process. Volatility in this connection refers to the propensity of a client (frequency and extent) to change requirements relative to the product or the interpretation of these requirements. Also the complexity of the product is an important parameter that will be further elaborated in Chapter 2. The suggested product-process relation implies that if the shipbuilding process of a certain product is transposed to another organisation the essential process will to a large extent consist of the same engineering tasks. How these tasks are implemented within an organisation may differ, therefore also organisational parameters for process behaviour supposedly exist.

1.2 C

HALLENGES IN

S

HIPBUILDING

E

NGINEERING

1.2.1 INSUFFICIENT UNDERSTANDING OF ENGINEERING PROCESSES

Shipbuilding engineering processes are often characterised as opaque and unpredictable. This statement is supposedly supported by the fact that substantial

(23)

variance on necessary engineering effort and throughput time is shown over ranges of products that are comparable in complexity and/or size. In complex design and engineering environments, severe oscillations in budget and throughput time are ‘normal’ (Ford, 2003, Muntslag 1993). An interesting question is to what extent the characteristics of shipbuilding engineering influence this behaviour. Will simply the nature of these processes account for the observed oscillations?

The shipbuilding industry has similar to many other industries (Culley, 1999), focussed on its own core competences which are the erection of the ship structure (although in many cases this is sub-contracted too) and the coordinator role in bringing all necessary functionality together and facilitating this integration process. The engineering and manufacturing of many systems, parts or assemblies is often sub-contracted to highly specialised third parties. In shipbuilding sub-contracting generally concerns the electrical engineering, fabrication and installation of pipelines, Heating, Ventilation and Air-conditioning (HVAC), furbishing, painting and section building (although some tendencies to in-house section building -for instance for protection of specific knowledge is seen too). Suppliers deliver goods to the main and sub-contractors. All sub-contractors actively participate in the engineering process. The customer may also be an important participator. If the degree of customer specification freedom is high, active customer participation in the engineering process often leads to change requirements during a running project (Vajna, 2005). Building and engineering of seafaring ships also requires the participation of a so-called classification society, which is a private inspection service that guards the seaworthiness and safety of the ship’s structure and the ship as a whole. This makes the classification society (abbreviated as ‘class’) an important partner in the engineering process too.

Engineers from all mentioned parties (yard, customer, sub-contractor, class) have to rely heavily upon each other for information and expertise throughout the engineering process (Culley, 1999). Therefore the quality of communication and information exchange is vital to engineering processes: some studies about engineering activities during complex product design have shown that a very high share of engineering hours is spent on organisational matters rather than on productive tasks. A general estimation for large engineering projects is that approximately 25% is consumed while waiting on decisions or information from other work-groups (Rouibah, 2003). Also specific shipbuilding related research reports substantial waiting times for technical information (Bronsart, 2004, Tann, 2005).

The structure of different co-working organisations, each with their own organisational structures and dynamics and their own interests easily leads to ‘fragmentation’. Communication often fails because engineers lack awareness of the process, tasks and competences of the other engineers and the existing interfaces between them (Eckert, 2005). In a concurrent engineering environment this often results in ‘schedule failure’. This phenomenon implies that a project almost reaches completion according to the initial scheme, but then its progress stalls and the project only finishes after sometimes even twice the original duration. This is regarded to be the result of both underestimating project size and poor assessment of true project progress. Everyone withholds knowledge about being behind schedule and waits with

(24)

reporting this until another person confesses delay. That explains why only in the planned end of the project all this extra work is revealed (Ford, 2003).

1.2.2 INSUFFICIENT ENGINEERING MANAGEMENT METHODS

Current planning and management methods for engineering seem insufficiently sophisticated to prevent or even capture oscillating behaviour. Two specific shortcomings of daily shipbuilding engineering planning are the rather narrow viewed concentration on smoothing worker capacity and the lack of documentation of the numerous start conditions for engineering tasks. Therefore, changes in the plan are hardly anticipated and as in other engineering fields this may result in large discrepancies between the planned and actual costs (Muntslag, 1993).

This lack of anticipation can be partly accounted for by shortcomings of existing planning software tools as these have difficulty handling the uncertainty typical for engineering-to-order processes and handle design iterations poorly (Austin, 2002, Eckert, 2004). Existing network scheduling techniques link activities in predecessor-successor relations but do not force the user to explicitly include also the other start conditions for tasks, such as the availability of information, links from activities that lie outside the network, or available worker capability. On the other hand it has been observed that within shipbuilding engineering the available standard functionality for network scheduling is only modestly utilized. The integration of schedules for the different shipbuilding stages (including engineering, purchase, production, or even the work of sub-contractors) has been limited. As also seen in other branches of engineering, compensational behaviour of engineers often results in slack being built into plans, and uncertainty is hidden by using only low levels of detail in planning (‘O Donovan, 2004). This also results in poor data registration of realised effort, implying that historical data for improving plannings are only limitedly available. Additionally, measurement of progress is often constrained to hour registration supplemented by effort predictions for the remaining part of the work. A rough monitoring system for the status of drawings is used that often only contains states as ‘released for production’, ‘approved by customer’, ‘approved by class’. The status of drawings, or engineering information in general, with respect to their utility within the engineering process, for instance as input information for another drawing, is not monitored. A yard’s order planning is in its base normally dictated by optimal utilization of the available slipway capacity, which often puts the available engineering time under pressure. Many engineering activities become critical for the total through put time; material and components need to be ordered and have critical delivery times, production drawings must be ready in time. High workload or -worse- labour and throughput time budget overruns are difficult to compensate in engineering as only very few activities can be accelerated by increasing the resources (of course over-time is possible; but working with many people on the same activity is not, also the availability of necessary specialisms is limited). All in all, the activities in shipbuilding companies are inter-related in such a manner that domino-effects seem inevitable. This implies that budget and throughput time overruns in engineering are very likely to induce budget overruns in production and purchase too.

(25)

Overall there is a lack of insight into the consequences of various decision alter natives and their effect on costs, timeliness and quality (Muntslag, 1993). With ‘timeliness’ expresses Muntslag the relation between capacity and throughput time, with quality the ‘customer value’. This is bound to undermine the account ability and controllability of projects. In addition, no suitable means are provided to estimate schedule risk, i.e. the product of the probability of undesirable events or scenarios to occur and their impact on the schedule (Browning, 1999).

Process management concerns the control of (engineering) processes, trying to make processes behave as desired. With process behaviour is indicated the way the process reacts on input, boundary conditions, or its surroundings. Interesting metrics for process behaviour are necessary effort in terms of man hours or throughput time. To effectively manage concurrent engineering processes it is required to:

Make a schedule that includes the aimed start and end dates for tasks plus a specification of which worker will do which tasks;

Track progress, not only expressed in realised effort versus the budget, but also status of information objects and documents (a definition of information object will be provided later in this chapter);

Register relationships between tasks and their information output and input; Register who is working on the basis of preliminary versions of information

objects so that they can be notified about a change etc.

Hanssen explains that the challenge of engineering process control lies in the fact that initially the number of problems that needs a solution increases due to rework. Process control is therefore primarily aimed at the eventual convergence of the process into stable behaviour, meaning that the total number of engineering problems must fall below an acceptable threshold within a specified timeframe (Hanssen, 2000).

Considering the above, it is not surprising that risk assessment related to process behaviour is under-developed for the described engineering environment. Plannings for engineering usually do not contain a systematic review of the scenarios in which case budget-overrun may occur, neither do they include the impact of such scenarios.

1.2.3 IMPROVEMENT OF SHIPBUILDING PROCESSES

Previous research in the field of improving shipbuilding processes has mainly concentrated on streamlining shop-floor production (Steinhauer, 2006, Bentin, 2005, Nedess, 2006, Bernaert, 2005, Kaarsemaker, 2006, Nienhuis, 2005, 2006).

Research in engineering has concentrated on the development of tools to facilitate concurrent design and engineering (like Computer Aided Design (CAD) environments), automation of engineering (like product configuration by Blom 2006) and automatic pipe routing (Asmara, 2006). Also business process applications for shipbuilding have been developed for in stance for product data management and Enterprise Resource Planning (ERP) (Hildebrandt, 2005, Gongora, 2004) and shipyard planning (Massow, 2004).

(26)

Research or applications specifically aimed at engineering process management in shipbuilding are rare. Therefore, this research is meant to be the first step in streamlining engineering processes from a viewpoint of ‘information logistics’.

1.3 A

M

ODEL

-B

ASED

A

PPROACH

1.3.1 PROCESS SIMULATION

To this end -studying the aspects mentioned above-, the set-up of a model of engineering processes seems a logical starting point. Such a model may serve as a reference frame by which problems can be described and explained. It can also be used to evaluate the effect of proposed solutions (Veld, 2000).

When considering process re-engineering to change process behaviour, objective measures and quantitative measures are necessary to get an indication of their potential effect (MacArthur, 1994). As process behaviour expresses itself amongst others in necessary effort, and throughput times. Therefore, a model should provide insight in these throughput times and should be able to handle calculation of throughput times based on requested and available capacity, and also queuing problems. This makes the application of a simulation model a logical choice (Pidd, 2004, Hlupic, 2005). A very useful definition of simulation is given by Shannon: “Simulation is the process of designing a model of a real system and conducting experiments with this model for the purpose either of understanding the behaviour of the system or of evaluation of various strategies (within the limits imposed by a criterion or set of criteria) for the operation of the system” (Shannon, 1975).

Simulation is an attempt to model a real-life situation to study its behaviour, with the possibility to change variables and generate predictions. Simulation is mostly applied when ‘closed-form’ analytic solutions are not possible. Simulation models can help to identify deficiencies, such as bottlenecks in capacity or information that is delayed, early in processes, or even before starting them (MacArthur, 1994). Models can be useful for defining new engineering strategies when improvements are required as they help to predict in which cases and with what parameter values for which variables the engineering process will meet the new requirements (Nevins, 1989). Models can therefore provide insights that are non-obvious to experts (Norden, 1993). A simulation-based process model may serve as a test facility for experimental work. Simulation techniques have demonstrated to be useful in solving planning and control problems for shipbuilding production processes (Steinhauer, 2005, Kaarsemaker, 2006). Examples of simulation models for engineering processes are described by amongst others Clarkson (2000), Eppinger (1997) and Pels (2006). Also when simulation models are not directly used for planning and control of processes, building and using them can have the additional benefit of ‘teaching’ engineers, project managers and planners how processes may react to their actions, giving them deeper understanding of the process. It also encourages a culture of measurement, which can provide a basis for continuous process improvement (Paul, 1999). Simulation models can be valuable problem-under standing tools (rather than problem solving tools)

(27)

appropriate for processes with a stochastic nature, with complex interdependencies, and complex flow (Hlupic, 2005).

1.3.2 SETUP OF SIMULATION STUDIES

Guidelines for the setup and execution of simulation model studies are provided by amongst others Banks (2005), Law (2000) and Wenzel (2008). Constituent steps are:

Problem formulation: It is important to understand the problem clearly. This problem formulation must be shared by the problem owners and the analyst; Set objectives and define the research questions that should be answered by

the simulation study;

Analysis of the ‘real-world’ system in order to construct a conceptual model that abstracts the elements and their relations of the system;

Data collection, analysis of available data and preparing them to serve as simulation input;

Model translation, this is the step in which the conceptual model is translated into computer code in order to serve as a process execution environment; Verification of the model: Is it performing properly?

Validation of the model in order to evaluate if it accurately represents the real system;

Design of the experiment;

Running experiments, analysis and interpretation of results.

According to Robinson, a substantial part of the benefit obtained by a simulation study is the result of the development of a conceptual model. The requirements to design a simulation framework form a system investigation that is extremely useful in its own right (Robinson, 2004). This conceptual model is independent of the software in which the simulation will be developed. The key elements of the conceptual model are: inputs to the model, outputs, the content of the model in terms of elements and their relations, the assumptions being made about the real-life behaviour and the simplifications or reductions that have been incorporated in the model.

For this study, the conceptual model of engineering behaviour in an ETO shipyard is indeed regarded as a separate result of analysis.

1.4 R

ESEARCH

Q

UESTIONS

A

ND

O

BJECTIVES

Three different ‘directions’ for research questions and objectives have been discerned: Creation of a conceptual model of engineering process behaviour in order to

improve the understanding of this behaviour in terms of effort drivers and throughput time;

Representation of a conceptual model of engineering in order to improve the (mutual) understanding of engineers relative to their tasks and (inter)dependencies;

(28)

Investigation of the applicability of newly obtained conceptual understanding of engineering processes in management and control tools.

Additionally these questions must be addressed from a ‘Modelling-to-Order’ viewpoint: the ETO environment calls for a generic modelling framework and flexible configuration of models as otherwise the cost of building project-specific models may outweigh the benefit gained through their use (Whitney, 1990).

Improved understanding of the engineering process opens up opportunities for the development of more sophisticated planning and control tools on the one hand, and process re design on the other.

In the future such a model could be used to evaluate the impact of alternative strategies for organizing shipbuilding engineering processes, for instance related to:

Optimising engineering skills (like the introduction of multidisciplinary teams and/or multi skilled personnel, integration of subcontractor pro cesses into the yard organisation);

Improving communication and information flow patterns;

Improving the quality of activity sequencing (thus minimizing sending information upstream where it may cause unintentional iterations, Browning, 1999).

But as this research is only the first step in the analysis of engineering behaviour in shipbuilding, it cannot be expected to cover these objectives to a full extent. Research questions will have to be stated at a less ambitious level and are stated as follows:

Of which elements consist task structures of shipbuilding engineering processes?

How do these relate?

To what extent can the elements be typified in order to share them between different engineering processes?

Which behavioural elements are unique for specific processes?

Which instantiations of behavioural elements can be generally applied to the investigated engineering processes?

Does a model provide means for evaluation of process scenarios?

Can scenarios for engineering process behaviour be quantified in terms of ‘effort’ (man hours spent by human resources) and throughput time?

Can a model be used to investigate process improvement strategies? Can process behaviour be related to product characteristics?

Can process behaviour be related to organisation characteristics, for instance the extent to which engineering work is sub-contracted, the type of organization, people being multi-skilled or working in project teams etc.? What are the possibilities for estimation of risks and process performance

variation in a qualitative or quantitative way?

Which modelling techniques are suitable for representation of conceptual models of engineering behaviour with respect to improving understanding by both the modeller and the process owners?

Can a task model of engineering provide additional management information and how should this be implemented?

Controlling enigneering-to-order processes in shipbuilding, a model-based approach

C

E

-

-O

P

S

CONTENTS

SUMMARY

SAMENVATTING

1

IMPROVING PROCESS CONTROL IN SHIPBUILDING

ENGINEERING

1.1

A

I

C

S

E

1.2

C

S

E

1.3

A

M

-B

A

1.4

R

Q

A

O