General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

Users may download and print one copy of any publication from the public portal for the purpose of private study or research.

You may not further distribute the material or use it for any profit-making activity or commercial gain

You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.

Downloaded from orbit.dtu.dk on: Jul 08, 2020

How to Scope a Product Configuration Project in an Engineering Company

Shafiee, Sara; Hvam, Lars; Bonev, Martin

Published in:Proceedings of 6th International Conference on mass Customization and Personalization in Central Europe(MCP-CE 2014)

Publication date:2014

Link back to DTU Orbit

Citation (APA):Shafiee, S., Hvam, L., & Bonev, M. (2014). How to Scope a Product Configuration Project in an EngineeringCompany. In Proceedings of 6th International Conference on mass Customization and Personalization in CentralEurope (MCP-CE 2014) University of Novi Sad.

1

How to scope a product configuration projectin an engineering company

Sara ShafieeDepartment of Management Engineering, Technical University of Denmark

Lars HvamCentre for Product Modelling (CPM), Department of Management Engineering, Technical University of Denmark

Martin BonevDepartment of Management Engineering, Technical University of Denmark

Abstract: When implementing a product configurationsystem in a company making complex and highly engi-neered products, many decisions need to be made inthe early phases of the project. This article presents aframework for supporting the initial scoping processand discusses experiences from applying the frame-work in an engineering company. The framework co-vers a number of topics, such as identifying the users ofthe configuration system, prioritizing the user require-ments, defining the input and output, and the overallfunctionality of the configuration system. Furthermore,the scoping process considers the availability of theproduct knowledge to model into the configurationsystem, the level of detail and which particular productparts and aspects to include in the system.

Key words: Configuration Systems, Product configu-ration, Scoping, Level of Detail, Early Phases.

1. INTRODUCTIONImproving the quotation process by the help of con-

figuration systems is a huge opportunity for enhancingpresales and production process efficiency in compa-nies. Furthermore, configuration systems can be ap-plied to support the decision process and to illustratethe possible product alternatives [1]. The scope of mostof the work done in the configuration conspectus hasbeen very limited and specialized, as stated by Tii-honen [2]. However, in early phases of the configura-tion project decisions are made which are very im-portant for the success of the entire project. This meansthat both the structure of the product and the cost esti-mations are influenced by the content of the configura-tion system.

A product configurator is a subtype of software-based expert systems or knowledge-based systems witha focus creating product and process specifications [3].

A configurator supports the users in specifying theproduct’s different features by confining how prede-fined entities (physical or non-physical) and their prop-erties (fixed or variable) may be combined [4]. At theearly phases of a configuration project, it is often diffi-cult to identify and retrieve the right information to beimplemented in the system. Collecting and discussingproduct knowledge from product experts helps in find-ing robust modelling solutions which meet the desiredquality. A number of strategies dealing with this chal-lenge have been proposed in academia, such as theProduct Variant Master (PVM) by Hvam et al. [12] andthe Product Family Master Plan by Mortensen [15].However, modelling products with high complexity,e.g. due to the variety of outputs expected from config-urator and integrations to other IT systems, is still chal-lenging. Additionally, configuration engineers oftenlack experience in specific technical areas of a productand thus have difficulties in implementing the relevantaspects of it.

Problem statement: The present paper addressesthe challenge of modelling complex and highly engi-neered products based on a practical example of a con-figuration project for an entire production plant. Amajor challenge in configuration projects of this type isto find a way of retrieving knowledge that is based ondeep technical experiences, establishing a quick over-view of various engineering areas, and creating a satis-factory level of analysis and communication. There-fore, a configuration engineer has to ask for and com-bine information which is relevant but often out of hisexpertise. Due to this lack of overview, companiesspend a considerable amount of time and resources onretrieving, filtering and processing the information tobe modelled in the system. Yet, as companies are undertime and resource pressure in their sales and pre salesprocesses, they are challenged with high costs andresources on tasks which are not creating much value

2

and which could otherwise be spent on research andinnovation. Organizations are typically aware of theopportunity to limit non-value adding activities, butoften lack the methodology to address it properly.

Activities in quotation processes involve peoplewith different expertise from different departments,provoking problems in communication and overlappingskills. As a result, engineers are spending a relativelyhigh amount of their time on coordination and waitingfor feedbacks. Working in such a company makes iteasy to observe the difficulties encountered in a realcase; e.g. when engineers spend the majority of theirtime just to maintain and update thousands of wide-spread documents that are used for the quotation pro-cess. Each of these documents belongs to differentpeople with different backgrounds and is supposed tocontribute to a specific proposal when a quotation ismade for a particular order. We believe that in such acase the solution is to use a unified configuration sys-tem which documents the required product infor-mation.

2. LITERATURE BASEUsing a standard framework such as the Rational

Unified Process (RUP) as an iterative process helpsengineers to perform their tasks professionally in earlyphases of the project and to develop and test their solu-tions in short life cycles. The RUP methodology in-cludes different tools that empower engineers to learnand work independently. The RUP is a software devel-opment process which contains many of the moderndevelopment techniques and approaches such as: objecttechnology and component based development, Uni-fied Modelling Language (UML), architecture model-ling, iterative development cycles to verify the modelquality etc. [5]. According to the iterative developmentprinciple, the whole system is frequently tested so as toaddress the risks of modelling in early stages of con-figuration projects [6]. In complex and highly engi-neered products with high connectivity of componentsand many constraints, early tests and mistake preven-tions are vital for keeping the development costs at areasonable level. However, generic development meth-ods, such as the RUP, are not necessarily suitable forevery type of project but require content specific ad-justments [7].

2.1 Previous research on configuration projects

Literature suggests that various benefits can be de-rived from the use of configuration systems. L. Hvamet al. carried out four empirical case studies and listedsome of the significant benefits [8]. Ladeby and

Oddson define the total configuration system (TCS) asthe configuration system including the business contextin which the configuration system operates [9]. Forzaand Salvador define a configuration system as the “setof human and computing resources” needed to “ac-complish configuration and modelling processes” [10].Blecker considered the advisory system as an inde-pendent software system. The configurator contains theproduct model, whereas the advisory system takes overthe consulting role [11].

Table 1. Approaches to configuration projects

Concepts

Publication 3.IT

stru

ctur

e:In

put/

Out

putM

anag

ing

and

UI

4.Pr

oduc

ts’f

eatu

res:

upda

ting

and

mai

nte-

nanc

e

5.Pr

ojec

tpla

n

RU

P

1.A

imsa

ndpu

rpos

esof

the

conf

igur

atio

nsy

stem

:Con

-fig

urat

ion

Syst

emsB

enef

its

2.St

akeh

olde

rs’r

equi

rem

ents

Lev

elof

deta

ils

Mod

ellin

gte

ch-

niqu

es

Hvam et al. [8,12,19,22] XX X

X

Forza et al, 2002[13] X X X

Salvador et al, 2004 [14] X

Mortensen et al. 2008[15] X XX

Haug et al. [16,20,21] X X XX

Ladeby et al, 2011 [9] X

Blecker et al, 2004 [11] X

Tidstam et al, 2010 [17] X

Jannach et al, 2013, [18] X X

Dvir et al, 2003 [23] X

Felfernig et al, 2000 [24] X

Trentin et al, 2012, [26] X

As illustrated in Table 1, only few researches havefocussed on how to scope configuration projects in theinitial phase of a project, define the input and output ofthe system, clarify the modelling details, and describethe interaction with the stakeholders.

3

3. RESEARCH METHODOLOGYThe research aim is dedicated to scope the devel-

opment procedure of the configuration systems as ageneral concept. We use an empirical case to defineand validate a general process, from information gath-ering and tools introduction to the maintenance part.This allows us to contribute to both theory and praxis.Aligned with the overall objective, the research hasbeen structured into two phases. The first phase isconcentrating on the most efficient process accordingto the investigations. To test the introduced process ona real case, the second phase is emphasising the practi-cal aspect of the research.

3.1 Procedure development

This phase is considered to introduce all availabletools, combine them on a specific case and educate theengineers as to how to use them. To identify the case-specific obstacles, the procedure has been developed bythe researchers working directly in the industrial envi-ronment and in closed dialogue with product experts.

3.2 Reporting the process efficiency of a real case

Providing feedback from real cases and supplyingthe process with suggestions for creating functionaleffectiveness offers a great opportunity to achieveempirical validity. Hence, the framework has beentested in a company as a realistic situation for complexand highly engineered products. The major challengewas to find a way to configure an operation which isextendible to all other projects. The process was testedfor at least one month, and the results have been com-pletely accepted by the organization.

4. HYPOTHESIS DEVELOPMENTBased on the theory presented above we suggest

that a scope for a configuration system should include:

1. Aim and purpose for the configuration systemand overall process flow [12, 25]

2. Identification of stakeholders and their re-quirements [22, 12]

3. IT-architecture incl. flow in the configurationsystem, UI, input, output, integrations, andmain functionality of the configuration system[2,27]

4. Products and product features to include in theconfiguration system, incl. level of detail [12]

5. Project plan incl. resources, time table, model-ling approach, test and development, systemmaintenance, etc. [23, 28, 26, 29, 30, 21, 31,33, 34, 1]

4.1 Aims and purpose of the configurator

This part will discuss the overall aim of implement-ing the configuration system.

4.1.1 Vision of product configuration projectsThe vision states the purpose of implementing the

configuration system. What aims should the configura-tion systems follow? As an example the vision to use aspecific configuration system could be less time andresource for introducing a new system and fewer errorsin the implementation process. Configuration projectscan in general be divided into two major categorieswith each having a different vision. The first categoryis performing presales or the commercial process, andthe second one is configuring the sale and productionor technical process [10].

4.1.2 Objectives and gap analysisBesides the vision, additional operational objec-

tives can be listed such as [12]:

· Lead time reduction for product customizationand document generation

· Less resources consumption for producingspecifications

· Higher quality of specifications· Quality improvements in quotations· Higher independency from product experts· etc.

When the objectives of the configuration systemshave been formulated, the next step is to carry out aseries of measurements in relation to the individualtargets. When the targets and the current performanceare known, they are summarized via a so-called gapanalysis [12]. For example, if the lead time for thecurrent situation is 7 days and the target is 2 days (theaim of the project) it means that a 75% gap or reduc-tion in the lead time is intended.

4.1.3 Process flowThe purpose of this part is to have a standard definitionof the current and future flow of business processes.

AS-IS and TO-BE flowcharts: an AS-IS flowchartshows exactly the current situation of the company andthe complications of the process. According to thecompany requirements there will be a number of sce-narios for the future process. The TO-BE flowchartscan be drawn according to these scenarios. As an ex-ample, the configuration system could have differentpurposes from varying product perspectives [25]: maketo order, configure to order, engineer to order, or inte-grate-to-order.

4

4.2 Stakeholder requirements

Stakeholder requirements are a wish list from dif-ferent type of users to be considered in the subsequentsteps. One of the reasons for having a strategy in thefirst phases of the project is to support the prioritizationof individual stakeholder requirements. It is importantfor the further development that all stakeholders areidentified along with their use patterns. This is neces-sary in order to prioritize functions and interfaces ofthe configuration system [22].

4.2.1 Stakeholder identificationStakeholders could be among different groups of

people such as sales staff, product developers, produc-tion staff, marketing staff etc. with different require-ments to the configuration system.

4.2.2 RequirementsThese are some examples of stakeholders’ require-

ments in different sections: language variety, currencyvariety, online functionality, required output docu-ments, and different user interfaces (UIs). The stake-holders and their necessities can be drawn through twospecific methods: the first one is by using processflowcharts (TO-BE process), and the second one is byutilizing the use case diagrams from the RUP method[5]. A use case is a pattern for a limited interactionbetween a system and actors in the area of application.Use case diagrams are the means of expressing therequirements and the actors involved in the project.According to the RUP rules the same use case is uti-lized in system analysis, design, implementation andtest. Note that an actor can be a person or an IT systemwhich delivers and fetches information from the sys-tem. It is vital to develop the system aligned with theuser requirements. Thus, it is important to describe theactors and their desired use cases. An actor is a rolethat includes users or other systems that have the sameuse patterns [12].

4.3 IT-architecture

IT architecture is addressing the structure and tech-niques of the configuration system. RUP covers almostall aspects of a typical software development project.The IT architecture has to include:

· Definition of the configuration system,a) Inputs, Outputsb) UI

· Main functionalities such as online and offlinefunctionality

· Decision flow in the configuration system

· Specification of integrations with other sys-tems in the company such as ERP or the cal-culation systems.

4.4 Products and products’ features

4.4.1 Which products and which product features toinclude in the model?

In order to limit task for registering the knowledgeduring the life cycle of products it is useful to considerthe product range from four different points: productstructure, product functions and properties, product lifecycle properties, variation and family structure [12].

4.4.2 Level of detail to includeHaving described which products and product fea-

tures to include, the next step is to define the level ofdetails to include in the system. This detail manage-ment will help us save a lot of time and resources.There are always a number of questions about the levelof detail in the configuration systems, while it is noteasy to answer which aspect of a product should betaken into consideration. If no specific managementstrategies are used in early phases for controlling thedetails, the impact on the performance and businesswill be enormous. The technical and business aspectsare:

Ø Further complexity in the configuratorØ Difficulties in data documentation, updating

and maintenanceØ Facing lack or additional data when generat-

ing documentsØ Integration problemsØ Difficulties in communicating with domain

expertsØ Spending a lot of time and resources on gath-

ering irrelevant additional informationØ Spending a lot of time and resources on asking

questions because of the deficiency ofknowledge or misunderstandings.

After all, when a configuration engineer is gather-ing knowledge, he is the one who should know what isneeded according to the requirements and vision of theconfiguration system.

4.5 Project plan and modelling approaches

4.5.1 An introduction to Unified ProcessThe Unified Software Development Pro-

cess or Unified Process is a popular iterative and in-

5

cremental software development process framework. Infact, it is not simply a process, but rather an extensibleframework which should be customized for specificorganizations or projects. The RUP is similarly a cus-tomizable framework. On the time axis in Fig. 1, RUPdivides a project into the following four phases: Incep-tion, Elaboration, Construction, and Transition [28]. Inthis stage, the modelling approaches are includingmethods and strategies such as:

1. Product Variant Master2. CRC Cards3. Testing and development4. Documentation and maintenance5. Stakeholders’ identification with use case dia-

grams6. Iteration process for each component7. Component based development8. Project planning

Fig.1. Unified Process [26]

Number 1 and 2 in Fig. 1 are purely product con-figuration modelling techniques, while number 3 to 7are related to the RUP methods, and number 7 is theproject planning techniques containing some tools thatare to be fulfilled for any project. It is also possible tofind the obstacles for the project in the risk analysis.For a configuration project a risk could for example becomplications in the modelling of products or duringprogramming. According to Kruchten (1998) manydecisions related to an iterative lifecycle are driven byrisks; and for effective decisions a good understandingof the risks and project faces, and afterwards clearstrategies to deal with them, are required [5].

4.5.2 Product Variant MasterThe major step is to find the most efficient and

structured modelling tools such as the PVM [29]. Thepurpose is to understand the product hierarchy andensure that all the people in the company have a com-mon view about the product structure, variants andconstraints.

4.5.3 CRC CardsThe detailed information about the product is in-

cluded in the specific cards called CRC cards. CRCstands for “Class, Responsibility, and Collaboration”and these cards are used to define classes, including theclass’ name, their possible place in a hierarchy, togeth-er with a date and the name of the person responsiblefor the class [12]. In addition, the class’ task (responsi-bility), the class’ attributes and methods, and withwhich classes it collaborates (collaboration) are given[30].

4.5.4 Testing and development:Testing is included in the iteration template, and it

is as critical for configuration projects as other IT pro-jects. It is seen as an iterative process which enablesearly feedback in the early phases of the project. Thetest work flow will help to measure the project qualityand defects, and it will omit unnecessary budget fordebugging processes at the end of the project. Feed-backs from users help to go in the right direction andlearn a lot in the early phases of the project. Testing theproject step by step makes the debugging procedureeasier for both the tester and engineer.

4.5.5 Documentation and maintenanceDocumenting of the system is the most critical tool

for establishing a strong communication with domainengineers during and after the project. The suggesteddocumentation system is based on the RUP methodol-ogy and modelling strategies, including the ProductVariant Master method for modelling product families[12]. The fact of not having a documentation systemthat supports the modelling techniques means thatdifferent software must be applied throughout a project[21]. Avoiding errors and continuously updating thesystem is crucial for avoiding failure and for getting anacceptance of the system. So the expert cooperationwith the configuration team will be necessary, especial-ly for the highly engineered products.

4.5.6 Use case modelling and diagramUse cases are the means of expressing functional

requirements which are understandable by stockhold-ers. Use cases create a design model which could de-fine the test cases and plan the iterations. Scenarios arethe instances of use cases which are applied for TO-BEprocesses in a modelling technique demonstration.Each use case is described in detail, and the use casedescription shows how the system interacts step by stepwith the actors. The same use-case model is employedduring requirements capture, analysis, design, and test[31].

6

4.5.7 Iteration process:If a project is too big and has a long schedule, it of-

ten seems to have been bound to fail in most compa-nies. Therefore, we have chosen to split this case pro-ject into smaller projects. Each phase in the RUP canbe further broken down into iterations. Iteration is acomplete development loop resulting in a release (in-ternal or external) of an executable product, i.e. a sub-set of the final product under development whichgrows incrementally from iteration to iteration to be-come the final system [32]. Some benefits from theiteration process in comparison with the waterfallmethod are: reusing the system, learnings during theproject and better quality and management. Figure 1demonstrates the possibility of planning a general itera-tion loop for configuration projects.

Fig. 2. The general iteration process template forconfiguration systems

4.5.8 Component-based development:Component-based development is about how to

build quality systems that satisfy business needs quick-ly, preferably by using parts rather than handcraftingevery individual element [1]. For a highly engineeredand complicated product the best way is to split it intosmaller components and then follow the iteration loopevery time and test it. It makes the project less compli-cated and allows the delivery of the product to happenas soon as possible.

4.5.9 Project planningIn general, it is possible to have two different plans.

The first one is a coarsely project plan with all start andend dates of all phases and iterations. The second level

of the project plan is a detailed plan for all iterations[28]. Each phase of the project plan should have aspecific responsibility. As an example in the develop-ment phase the following roles could be required: theproject owner, the project manager, facilitator, thechange manager, end user, model manager, processmanager, domain experts, and programmer [12]. Everyproject is a special task, making it difficult or evenimpossible to plan all the activities at the initial plan-ning phase [32]. Although would argue that too muchplanning can curtail the creativity of the project work-ers [33] and others who propose to do milestone plan-ning instead of activity planning. There is no argumentthat at least a minimum level of planning is required[23]. In fact, planning is considered a central elementof modern project management. There are very im-portant aspects to be manifested in the project plansuch as: resources for the project and their responsibili-ties, timing tables, milestones, proposals, deliverables,success criteria, risk estimation etc.

5. CASE STUDY

5.1 Aims and purpose for the configuration system

This article is based on the empirical data collectedin collaboration with an international company special-ised in the production of heterogeneous catalysts andthe design of process plants based on catalytic process-es. The Wet Sulphuric Acid (WSA) process is backedby more than 25 years of commercial experience andhas proven its value in industries like oil refining, cok-ing, coal gasification, and viscose fibres. A main chal-lenge for the WSA section in the case study is the pre-sales procedures, where a long time (more than 1 week)is needed to accomplish the current situation (morethan enough resources), and they cannot overtake theircompetitors. The regional offices all over the world arenot capable of making the quotations themselves be-cause of the amount of the complexities

5.1.1 VisionThe purpose is to introduce a configuration system

which can act as a knowledge management system,provide an easy access to product information and offera simple way of customization. The system will reducethe lead time for generating quotation for sales peopleand act as a presale technical configuration system[10].

5.1.2 ObjectivesThe main purpose of implementing a configuration

project is to make the sales process more effective. Thesystem empowers salesmen to act more independentlyfrom technical experts. By using product configurators

7

to support the engineering of the custom tailoredplants, the company is automatically forced to work onmodularizing and standardizing the machines in theplants. To engineering companies making complex andhighly engineered machines and complete factories asignificant challenge remains how to develop and de-scribe modules on a high level of abstraction that maybe used in the early phases of the engineering process-es. Hence in this project the use of a product configura-tor will lead to:

• Reduced lead time in sales and engineering processes

• Improved quality of machines and plants

• Increased sales – as it gets easier to generate quota-tions

• Reduced complexity of the machines and factories

• Cost savings in sales, engineering, production andinstallation due to the use of product configuration andmore well defined and standardised modules in theprojects

• Improved accuracy in the cost calculations and adecrease in projects that go over budget

5.1.3 Current situation and future scenario (AS-ISand TO-BE)

In order to describe future scenarios it is necessaryto have a comprehensive overview of the current situa-tion. Sales people are currently using excel sheets and acomplex homemade calculation system as the mainfoundation for the creation of technical proposals. Thecalculation system is a way of calculating the complexchemical process. Another problem is that the timespent on generating a quotation is not competitive incomparison to other companies around the world. Thepurpose of the project is primarily to create a stabletool aimed at generating proposals with as few errors aspossible. The accepted scenario has been shown in theflowchart in Figure 3 below.

WSA TO-BE process

Salesmen Engineers Mechanicalengineering ProcessCost estimationCustomer

TC siteTC site

Configurator

TC site

Excel and GIPS

Send enquiry Receiveenquiry

Collectinformation

Profitableproject

Work out basisfor offer

Checkinformation

Yes

NotificationPlans and listspreparation

Possible?

YES

Productproduction

Sales Department (EDU) Analysis Department (EDU) Process Department

Reviewinformation

Calculate flowheat balaces

Addoptimation

Recalculatecases

Calculate SO2convertor

firm

Reviewmeeting

yes

Hourestimation

Cost estimation(PCS) (For two

specificcomponents)

Add mark up(PCS)

no

Firm

Commercialproposal

yes

Cover letteres

noQuotation

Acceptno

Plot planRequest

Drawing

yes

Call forconsulting and

bettersuggestions

no

Read inoutputs from

GIPS

Select customer/service/unit/..

Startconfiguration

TechnicalproposalDesign basisScope of supply

Load the information from Gips

Arranging theinformationfrom excel

sheets

Plantselection

Get supplierquotation

Fig. 3. TO-BE process

5.2 Stakeholders’ identification and requirements

In this case, the stakeholders are sales staff, cost es-timators, product developers, marketing staff and re-gional offices with different requirements to the con-figuration system. The aim is to find a way to integratethe complicated calculation software into the configu-ration system and make it easier for sales people to getinvolved in the calculating process. The specific tasksexpected to be done during configuration project are:

Ø Developing a configuration based on feedstream properties and requirements to theemissions of a specific plant type (all stake-holders).

Ø Combining document snippets into full tech-nical or commercial proposals (sales peopleand cost estimators)

Ø Loading data from the configurator into tablesin the technical and commercial (sales, costestimators and marketing group)

Ø Price calculation, bills of material and scopeof supply (all stakeholders)

8

Ø Integration with high performance calculationsystems and other systems for receiving thecalculated outputs and flow diagrams (allstakeholders).

Ø User friendly and independent solution (allstakeholders)

Ø Currency and language versions (regional of-fices)

Ø Online based and saving functionality (sales)Ø Maintenance and updating the system (sales

people and product developers).

5.3 IT-architecture

5.3.1 Inputs/ outputsOutputs are in need of inputs and have been deter-

mined in the TO-BE process and case diagrams. Theinputs and outputs examples in this case could be: thesize and volume of the components, the entrance orexhausted pressure and temperature, the number oftubes in a condenser, and the number and size of bedsin a converter.

5.3.2 Main functionalityThe configuration system aligned with this specific

case study defines some functionality:

· Capacity dimensioning for the entire plant· Cost estimation of the machineries· Needed engineering hours for specification· Energy consumption during operation

Fig. 4. The integration user interface

5.3.3 Integrations The configuration system used for this case study

is a commercial configurator. For each project muchdevelopment and integrations are needed according tothe stakeholders’ requirements. The programmers anddevelopers could perform the plug-ins and integrationsaccording to the stakeholders’ request with the desiredUI. Figure 4 is the performance of the UI for the inte-gration part. Figure 5 below illustrates an integrationexample where a specific plug-in makes tables anddraws the diagrams according to the tables in the con-figurator environment.

Fig. 5. An example for plug-ins in the configuratorenvironment

5.4 Products and product features

5.4.1 Products WSA plants include many machines and materials

which are all engineer-to-order according to the cus-tomer requirements [12]. Most of them are producedinside the company, and some of them are provided byvendors. The company is covering almost seven stand-ard plant types, and these different plants vary in theirmachines, materials, number of components based onthe requested productions. There are more than 20different components, and some of them are mandatorydue to plant type. Depending on the expected product,others can be optionally selected.

5.4.2 Products featuresThe product features for the case study focus on prop-erty models and product structure models as describedby Hvam et al. [12]. No cycle models are considered,as the products are not evolving according to custom-ers’ needs throughout the phases. The product func-tions and properties to be modelled are for example theprice, volume, size, mechanical and chemical proper-ties built in our property model. The product structuredefines how the products are built up and which partsthey consist of. The solution principles in our exampleinclude the cooling of machines during chemical pro-cess.

5.4.3 Input/ output (level of details) Figure 6 gives us a very brief overview of the in-

formation needed for our project. The research workfor finding a tool to manage the level of detail for inputgathering during the first stages of the project is inprocess. Currently, reverse engineering for finding theoutputs’ level of detail is considered. As an example,stakeholders asked for Price Calculation Sheets (PCSs),which are a combination of all component prices ac-cording to their internal selections and size, the engi-neering hours based on the plant complexities, consul-tancy hours, transportation expenses depending on thesize and type, insurance, and destination. Taking these

9

requirements for the PCS, it is possible to search forthe relevant inputs.

5.5 Project plan and modelling approaches

5.5.1 Product Variant Master All the discussions about understanding the struc-

ture of each individual component have been per-formed via PVM as a common language between do-main experts and the configuration team.

5.5.2 Documentation and maintenanceConcerning the complications in the WSA plants

and updating importance to the engineers in all fields,the programming of a documentation system was start-ed in the early phases of the project. For a long time theidea was discussed to use XML files from the configu-rator with descriptions to make it possible to transferall the information inside the configurator with nounnecessary manual intervention. Furthermore, every-thing inside the configurator, from attributes to rules,will be visible and understandable for everybody in thecompany and enable sending comments and updatesdirectly to the responsible.

Fig. 6. The model subject layer and integration withother systems

Fig. 7. Documentation and maintenance

5.5.3 Identification of Stockholders and their re-quirements using use case diagrams

As mentioned, scenarios and flowcharts for the sce-narios are a part of the use cases in RUP. In Figure 7the use case for the mentioned company has beendemonstrated. In fact, specific rules for the use casediagrams should be take into consideration, as inRUP use cases are utilized to capture only the func-tional requirements [5]. Figure 8 shows the specific usecase diagram utilized in the project. However, someuse cases, such as integration and documentation, areto be explained in separated use cases as separate sub-projects. In this project the general iteration process hasbeen used, as described in the previous section.

Fig. 8. Use case diagram

5.5.4 Component-based developmentThe purpose of using a component based structure

is to break a big complicated project into smaller piec-es, making the process easier both for users and devel-opers. When categorizing the expected results andoutputs from the configurator, the expectations for theproject become clear. Table 2 depicts the weightedcomponents and determines their priorities and im-portance in the project. As indicated, the configurationproject is expected to be challenging as a number ofdifferent complex components with varying prioritieshave to be implemented.

10

Table 2. An example for the components weightingComponent

name Expected result Weight (0-10)

Condenser

Scope of Supply 9Bills of Material 10

Technical Proposal 5Quotations 5

Hardware lists 8Process simulationfor integration… 10

Result No ofCond.* (∑/No)=~2*8

6. CONCLUSIONThis paper clarifies that having a standard frame-

work for implementing configuration projects has aremarkable effect on decision making in the earlyphases of a project. The experiences from applying andadjusting the Rational Unified Process in this paperreveal a standard way of scoping the configurationsystems. The research confirms that having a certainscope for determining the stakeholders’ requirement,modelling tools, input and output managing, level ofdetails, maintenance and documentation is vital for thesuccess of configuration projects.

7. REFERENCES[1] L. Hvam, S. Pape, M. K. Nielsen, “Improvingthe quotation process with product configuration”,Computers in Industry, vol. 57, pp. 607-621, 2006.[2] J. Tiihonen, T. Soininen, T. Männistö, R. Sulo-nen, “State-of-the-practice in product configuration- a survey of 10 cases in the finish industry”, InKnowledge Intensive CAD, First Edition, Tomi-yama, T., Mäntylä,M.,andFinger,S.,Eds., Chapman& Hall, vol. 1, pp. 95–114, 1996.[3] A. Haug, L. Hvam, N.H. Mortensen, “Defini-tion and Evaluation of Product Configurators De-velopment Strategies”, Computers in Industry, vol.63, pp. 471-481, 2012.[4] A. Haug, “Representation of IndustrialKnowledge – As a Basis for Developing and Main-taining Product Configurators”, PhD dissertation,Technical University of Denmark, Lyngby, 2007.[5] P. Kruchten, The Rational Unified Process: AnIntroduction. New York, Addison-Wesley, 1998.[6] T. Gilb, Principles of Software EngineeringManagement. Harlow, UK: Addison-Wesley,1988.[7] F. Karlsson, Meta method for method configu-ration- a Rational Unified Process case. PhD The-sis, Linköping, 2002[8] L. Hvam, A. Haug, N. H. Mortensen, “Assess-ment of Benefits from Product Configuration Sys-

tems” in 19. Europe Conference on Artificial Intel-ligence ECAI 2010, Lisbon, August, 2010.[9] K. Ladeby, G. Oddsson, “Reference Frame forProduct Configuration” in 2011 World Conferenceon Mass Customization, Personalization, and Co-Creation, 2011.[10] C. Forza, F. Salvador, Product InformationManagement for Mass Customization, New York:Palgrave Macmillan, 2007.[11] T. Blecker, N. Abdelkafi, G. Kreuter, G.Friedrich, “Product Configuration Systems: State-of-the-Art, Conceptualization and Extensions” inEight Maghrebian Conference on Software Engi-neering and Artificial Intelligence, 2004.[12] L. Hvam, N. H. Mortensen, J. Riis, ProductCustomization, Springer, 2008.[13] C. Forza, F. Salvador, “Product configurationand inter-firm co-ordination: an innovative solu-tion from a small manufacturing enterprise”, Com-puters in Industry, vol. 49, pp 37-46, 2002.[14] F. Salvador, C. Forza, “Configuring productsto address the customization- responsivenesssqueeze: A survey of management issues and op-portunities”, International Journal of ProductionEconomics, vol. 91, 2004.[15] N. H. Mortensen, U. Harlou, A. Haug, “Im-proving decision making in the early phases ofconfiguration projects”, International Journal ofIndustrial Engineering, pp. 185-194, 2008.[16] A. Haug, L. Hvam, N. Mortensen, S.Lundvald, and P. Holt, “Implementation of con-ceptual product models into configurators: Frommonths to minutes,” in 5th World Conference onMass Customization & Personalization MCPC2009, 2009, pp. 1–23.[17] J. Tidstam, J. Malmqvist, Information Model-ling for Automotive Configuration, NordDesign,2010.[18] D. Jannach and M. Zanker, “Modeling andSolving Distributed Configuration Problems: ACSP-Based Approach”, IEEE transactions onknowledge and data engineering, vol. 25, no. 3,2013.[19] L. Hvam, K. Ladeby, “An approach for thedevelopment of visual configuration systems”,Computers and Industrial Engineering, vol. 53,2007.[20] A. Haug, “A software system to support thedevelopment and maintenance of complex productconfigurators”, International Journal of AdvancedManufacturing Technology, vol. 49, 2009.[21] A. Haug, “The modelling techniques of adocumentation system that supports the develop-ment and maintenance of product configuration

11

systems”, International Journal of Mass Customi-sation, vol. 2, 2007.[22] L. Hvam, M. Bonev, A. Haug, N.H. Morten-sen, "The Use of Modelling Methods for ProductConfiguration in Industrial Applications" in 7thWorld Conference on Mass Customization, Per-sonalization, and Co-Creation MCPC 2014, 2014.[23] D. Dvir, T. Raz, A. J. Shenhar, “An empiricalanalysis of the relationship between project plan-ning and project success”, International Journalof Project Management, vol. 21, 2003.[24] A. Felfernig, G. Friedrich, D. Jannach, “UMLas domain specific language for the construction ofknowledge based configuration systems”, Interna-tional Journal of Software Engineering andKnowledge Engineering, vol. 10, 2000.[25] L. Hvam, “Mass customisation in the elec-tronics industry: based on modular products andproduct configuration”, International Journal ofMass Customisation, vol. 1, no. 4, pp. 410-426,2006.[26] A. Trentin, E. Perin, C. Forza, “Product con-figurator impact on product quality”, InternationalJournal of Production Economics, vol. 135, 2012.[27] RUP 2001 documentation, “RUP version2001 A.04.00.13”, Rational Software Corporation,2001.[28] M. Hirsch, “Making RUP Agile”, OOPSLA2002 Practitioner Report, 2002.[29] L. Hvam, M. Bonev, B. Denkena, J. Schür-meyer, B. Dengler, “Optimizing the Order Pro-cessing of Customized Products Using ProductConfiguration”, Production Engineering, vol. 5,no. 6, 2011.[30] N.H. Mortensen, L. Hvam, A. Haug, “Model-ling Product Families for Product ConfigurationSystems with Product Variant Master and CRC-cards”, AI Communications: The European Jour-nal on Artificial Intelligence, 2010.[31] Rational Unified Process Best Practices forSoftware Development Teams, Rational SoftwareWhite Paper, TP026B, Rev 11/01.[32] P. Kruchten, “A Rational Development Pro-cess”, CrossTalk, 9 (7), STSC, Hill AFB, UT,pp.11-16.[33] E.S. Andersen "Warning: activity planning ishazardous to your project's health!", InternationalJournal of Project Management, vol. 14, no. 2, pp.89-94, 1996.[34] C.K. Bart, “Controlling new product R&Dprojects”, R&D Management, vol. 23, pp. 187–97,1993.

CORRESPONDENCE

Sara Shafiee, Industrial PhDstudentTechnical University of Den-mark, Faculty of OperationManagement,Produktionstorvet, building 424,room 225, 2800 Kgs, Denmarksashaf@dtu.dk

Dr. Lars Hvam, Prof.Technical University of Den-mark, Faculty of OperationManagement,Produktionstorvet, building 424,room 224, 2800 Kgs, Denmarklahv@dtu.dk

Martin Bonev, PhD studentTechnical University of Den-mark, Faculty of OperationManagementProduktionstorvet, building 424,room 225, 2800 Kgs, Denmarkmbon@dtu.dk