Scoping a Product Configuration Project for Engineer-to-Order Companies

When implementing a product configuration system in a company making complex and highly engineered products, many decisions need to be made in the early phases of the project. This article presents a framework for supporting the initial scoping process and discusses experiences from applying the framework in an engineering company. The framework covers a number of topics, such as identifying the users of the configuration system, prioritizing the user requirements, defining the input and output and considering the overall functionality of the configuration system. Furthermore, the scoping process considers the availability of product knowledge to model into the configuration system, the level of detail and which particular product parts and aspects to include in the system.


INTRODUCTION
Improving the sales and engineering processes with the help of configuration systems is a huge opportunity for enhancing the order acquisition and fulfilment efficiency in companies.Companies offering customized products use product configurators in support of their decision process and to illustrate possible product alternatives [1].A product configurator is a subtype of software-based expert systems or knowledge-based systems with a focus on creating product and process specifications.It supports the users in specifying a product's different features by confining how predefined entities (physical or non-physical) and their properties (fixed or variable) may be combined [2].The scope of most of the work done in the configuration conspectus has been very limited and specialized, as stated by Tiihonen [3].However, in the early phases of a configuration project, decisions are made which are very important for the success of the entire project.At the early phases of a configuration project, it is often difficult to identify and retrieve the right product information to be implemented in the system.Collecting and discussing product knowledge from product experts helps in finding robust modelling solutions, which meet the desired quality.A number of strategies dealing with this challenge have been proposed, such as the use of a Product Variant Master (PVM) by Hvam et al. [2] and the Product Family Master Plan by Mortensen [4].Furthermore, in the early phases of the configuration project the scope of products to include needs to be defined as well as objectives and requirements from stakeholders, the IT-architecture, etc.The present paper focuses the challenge of scoping a product configuration system in companies making complex and highly engineered products.Experiences from projects in this kind of companies reveal that often confusion and lack of focus occur already from the first steps of the project to its final release.This lack of focus often results in both, limiting the performance of the configuration system and increasing the time and resource consumption for developing and implementing the configuration system.Acting upon this challenge, this paper suggests a framework for scoping the product configuration projects for companies with complex and highly engineered products.This framework is based on a general and well-established framework for scoping

LITERATURE BASE
Using a standard framework such as the Rational Unified Process (RUP)as an iterative process helps engineers to perform their tasks professionally in the early phases of an IT project and to develop and test their solutions in short iterations.The RUP methodology includes different tools that empower engineers to learn and work independently.It is a software development process, which contains development techniques and approaches such as object technology and component based development, Unified Modelling Language (UML), architecture modelling, iterative development cycles to verify the model quality, etc. [5].According to the iterative development principle, the whole system is frequently tested to address the risks of modelling in early stages of configuration projects [6].In complex and highly engineered products with a high connectivity of components and many constraints, early tests and mistake preventions are vital for keeping development costs at a reasonable level.However, generic development methods, such as the RUP, are not necessarily suitable for every type of project and require content specific adjustments [7].Jiang et al.(2006) propose a configuration management process model using UML for complex products such as aerospace and automotive industries [8]

Previous research on configuration projects
Configuration systems are essential elements of the information management infrastructure of companies offering a large variety of products, as they enable a number of important product variety management functions [9].Well running configuration systems can play an important role in enabling these companies to utilise their production capacity effectively and to avoid excessive inventory-holding costs, long leadtimes, and high costs [10] [11]. 1  The literature suggests that various benefits can be derived from the use of configuration systems.Ladebyand Oddson define the total configuration system (TCS) as a configuration system including the business context in which the configuration system operates [12].Forza and Salvador define a configuration system as the "set of human and computing resources" needed to "accomplish configuration and modelling processes" [13].Blecker considered the advisory system as an independent software system.The configurator contains the product model, whereas the advisory system takes over the consulting role [14].Felfernig, Friedrich, and Jannach (2000) describe representing configuration knowledge with the Unified Modelling Language (UML) in such a way that leads in system development and maintenance [15].One deficiency common in most of the configuration systems is that they do not completely support stakeholders for the purpose of identifying their requirements [16].Blecker et al. [14] present a concept of advisory systems for making the interaction processes between customers and configurators simple and short.They discuss the advisory systems technical implementation, and the necessity of their integration with product configurators; and design new advisory systems in a way that they can simplify the process of configuring the products that could provide the stakeholders'' needs [17].Jinsong, Z. et al. [18] introduce configuration-oriented product model which consists of several sub models: an assembly model, a product function model and a product configuration model.Hong et al. [19] suggest a customer-centric product model called AND-OR trees for determining the relations between stakeholders' requirements and industrial performance.Within IT structure main focus in the related articles is on the development of algorithms, methods and tools to solve product configuration tasks covering managing the input/ output and UI structure and the different integration with other systems.Falkner et al. [20] is providing a comprehensive review of these configuration solving approaches.Leitner et al. provide an overview of relevant principles of developing the user interface for configuration environment focusing both on interface for the end users and also knowledge engineers who are in charge of knowledge base development and maintenance [21].Forza and Salvador discuss scoping of configuration systems focusing on the order decoupling point in the company's value chain, but they do not discuss which products or which parts of the products to configure.Furthermore they discuss the architecture of the configuration system focusing on technical configuration versus commercial configuration, but they do not include details on e.g.input, output, integrations etc [13].As illustrated inTable 1, the literature provides input of parts of the scoping, however no scholars have provided a complete framework for how to scope a product configuration system, i.e. identification of stakeholders and their requirements, objectives of the configuration system, the IT-architecture (inputs, outputs, integrations etc.), products and product features to include and a project plan.

RESEARCH METHODOLOGY
The purpose of this research is to develop and test a framework for scoping product configuration systems.
Based on the literature, we develop a framework for scoping configuration systems by customizing the general framework for scoping IT-systems from the Rational Unified Process (RUP).For this, other theories needed for scoping product configuration systems have been added.These theories are in particular related to the steps of product modelling or functions in a configuration system, aims of product configuration systems etc.; hence, there is a combination of IT project frameworks and product modelling tools.More specifically the framework should include objectives and identification of stakeholders and their requirements for product configuration systems, ITarchitecture specifically for the product configuration system, products and product features to be included, and finally conducting a project plan fit for product configuration projects.

Developmentof the framework
The first phase of the research has been devoted to develop the framework.In this development both related literature study and industrial experiences have been used.More specifically the framework was setup based on general theory on scoping IT systems using UML, tools and theories identified on scoping different parts of product configuration systems; and finally the framework was setup in close dialogue with practitioners and by researchers with a research background in mass customization, product configuration, and modelling products.The authors have been involved in more than 20 product configuration projects in industrial companies, and the framework is also based on experiences from these projects as to which aspects are important to include in the scoping as well as how to apply the scope in the further work on modelling and implementation of the product configuration system.

Test of the framework
For test and analysis of the framework a project team was formed in an industry company, including two researchers from the university, two configuration experts and two IT developers from the case company.The role of the researchers was to provide the framework for scoping the configuration system.The suggested framework was tested and further developed in a close cooperation with the working team in the company.
The participation in the testing involved several activities for the researchers, including: describing the steps of the scoping in detail, discussing the scope and optimizing it, and using the scope in the subsequent configuration project.The testing was carried out within a period of 4 months in 2014.The configuration project selected for the testing parties seen as representative for other configuration projects in companies making complex and highly engineered products.

FRAMEWORK DEVELOPMENT
Based on the theory presented above, we suggest that a scope for a configuration system should include: 1. Aims and purpose for the configuration system and overall process flow [2, 13] 2. The identification of stakeholders and their requirements [2, 27] 3. IT-architecture incl.flow in the configuration system, UI, input, output, integrations, and the main functionality of the configuration system [2,32] 4. Products and product features to include in the configuration system, incl.level of detail[2] 5.A project plan incl.resources, time table, modelling approach, test and development, system maintenance, etc. [2,27,28,33,24,34,35,36] 4

.1 Aims and purpose of the configurator
This part will discuss the overall aim of implementing the configuration system.

Vision of product configuration projects
The vision states the purpose of implementing a configuration system.What aims should the configuration system follow?As an example, the vision for a specific configuration system could be less time and resources for introducing a new product and fewer errors in the sales and engineering processes.Configuration projects can, in general, be divided into two major categories each having a different vision.The first category is performing sales or the commercial process, and the second one is configuring products for production in the technical process [13].

Objectives and gap analysis
Besides the vision, additional operational objectives can be listed such as [2]:  Lead time reduction for product quotation and document generation  Less resource consumption for producing specifications  Higher quality of specifications  Quality improvements in quotations  Higher independency from product experts, etc.
When the objectives of the configuration systems have been formulated, the next step is to carry out a series of measurements in relation to the individual targets.When the targets and the current performance are known, they are summarized via a so-called gap analysis [2].For example, if the lead time for a current situation is seven days and the target is two days (the aim of the project),this means that a 75% gap or reduction in the lead time is intended.

Process flow
The purpose of this part is to have a standard definition of the current and future flow of business processes.

AS-IS and TO-BE flow charts:
An AS-IS flowchart shows exactly the current situation of a company and the complications of the process.According to company requirements, there will be a number of scenarios for the future process.TO-BE flowcharts can be drawn according to these scenarios.As an example, the configuration system could have different purposes from varying product perspectives [2] making to order, configuring to order, engineering to order or integrating to order.

Stakeholder requirements
Stakeholder requirements are a wish list from different type of users to be considered in the subsequent steps.One of the reasons for having a strategy in the first phases of a project is to support the prioritization of individual stakeholder requirements.It is important for further development that all stakeholders are identified along with their use patterns.This is necessary in order to prioritize the functions and interfaces of the configuration system [2].

Stakeholder identification
Stakeholders could be among different groups of people such as sales staff, product developers, production staff, marketing staff, etc. with different requirements in terms of the configuration system.

Requirements
These are some examples of stakeholder requirements in different sections: language variety, currency variety, online functionality, required output documents and different user interfaces (UIs).The stakeholders and their necessities can be drawn through two specific methods: the first one is by using process flowcharts (TO-BE process) and the second one is by utilizing the use case diagrams from the RUP method [5].A use case is a pattern for a limited interaction between a system and actors in the area of application.Use case diagrams are a means of expressing the requirements and the actors involved in the project.According to the RUP rules, the same use case is utilized in system analysis, design, implementation and testing.Note that an actor can be a person or an IT system, which delivers and fetches information from the system.It is vital to develop the system aligned with the user requirements.Thus, it is important to describe the actors and their desired use cases.An actor is a role that includes users or other systems that have the same use patterns [3,5].

IT-architecture
IT architecture addresses the structure and techniques of a configuration system.As mentioned in the literature part, for the complex and highly engineered products, customers are often overwhelmed by the size and complexity of product assortments resulting from configuration, thus not being able to choose an optimal solution [37] and designing a recommendation system in the IT architecture is recommended.Tiihonen,J et al. [38] discuss how the recommendation technologies can be integrated in the configuration systems to support product configuration and end users.RUP covers almost all aspects of a typical software development project.The IT architecture has to include:  Definition of the configuration system a) Inputs, outputs b) User Interface (UI)  Main functionalities such as online and offline functionality  Decision flow in the configuration system  Specification of integrations with other systems in the company such as ERP or the calculation systems.

Which products and which product features to include in the model?
In order to limit the task of registering knowledge during the life cycle of products it is useful to consider the product range from four different points: product structures, product functions and properties, product life cycle properties, variation and family structure [2].

Level of detail to include
Having described which products and product features to include, the next step is to define the level of detail to include in the system.This detail management will help save a lot of time and resources.There are always a number of questions about the level of detail in configuration systems, and it is not easy to answer which aspect of a product should be taken into consideration.If no specific management strategies are used in early phases for controlling details, the impact on the performance and business will be enormous.The technical and business aspects are:  Further complexity in the configurator  Difficulties in data documentation, updating and maintenance  Facing a lack of or additional data when generating documents  Integration problems  Difficulties in communicating with domain experts  Spending a lot of time and resources on gathering irrelevant additional information  Spending a lot of time and resources on asking questions because of a deficiency of knowledge or due to misunderstandings.
The level of detail is decided upon based on e.g. the needed detail and accuracy of the outputs from the configuration system.Considering lean rules and eliminating waste and non-value adding processes for knowledge acquisition are recommended [39].

An introduction to the Rational Unified Process
The Rational Unified Process(RUP) is a popular iterative and incremental software development process framework.In fact, it is not simply a process, but rather an extensible framework, which should be customized for specific organizations or projects.The RUP is, similarly, a customizable framework.As shown on the time axis in Fig. 1, RUP divides a project into the following four phases: Inception, Elaboration, Construction, and Transition [33].

Figure 1.
Unified Process [36] The scoping is part of the inception phase, where the modelling approach is outlined, and a project plan is generated.For product configuration, the modelling approaches include methods and strategies such as: 1. Product Variant Master 2. CRC Cards 3. Testing and development 4. Documentation and maintenance 5. Stakeholders' identification with use case diagrams 6. Iteration process for each component 7. Component based development 8. Project planning "Business modelling" and "requirements" parts in Fig. 1 are purely product configuration modelling techniques, while the rest of them from "analysis and design" to "configuration and change management" steps are related to RUP methods, and project management part is the project planning techniques, containing some tools which are vital for any project.It is also possible to find obstacles for the project in the risk analysis.For a configuration project, a risk could, for example, be complications in the modelling of products or during programming.According to Kruchten many decisions related to an iterative lifecycle are driven by risks, and, for effective decisions, a good understanding of the risks a project faces and, afterwards, clear strategies to deal with them are required [5].

Product Variant Master
The major step is to find the most efficient structured modelling tools, such as the PVM [2].The purpose is to understand product hierarchy and ensure that all the people in a company have a common view about a product's structure and the variants and constraints.

CRC cards
Detailed information about a product is included in specific cards called CRC cards.CRC stands for "Class, Responsibility and Collaboration", and these cards are used to define classes, including a class's name and its possible place in a hierarchy, together with a date and the name of the person responsible for the class [2].In addition, the class's task (responsibility), in terms of the class's attributes and methods and with which classes it collaborates (collaboration) is given [40].

Testing and development
Testing is included in the iteration template, and it is as critical for configuration projects as it is for other IT projects.It is seen as an iterative process, which enables early feedback in the early phases of a project.The test work flow will help to measure project quality and defects, and it will remove the need for unnecessary budgeting for debugging processes at the end of a project.Feedbacks from users help to go in the right direction, and users can learn a lot in the early phases of a project.Testing a project step by step makes the debugging procedure easier for both the tester and engineer.

Documentation and maintenance
Documenting the configuration system is the most critical tool for establishing strong communication with domain engineers during and after a project.An efficient documentation system can simplify the communication between the configuration team and domain experts and speed up the flow of gathering, filtering and processing of the information.The suggested documentation system is based on the RUP methodology and modelling strategies, including the Product Variant Master method for modelling product families [2].Not having a documentation system that supports the modelling techniques means that different software must be applied throughout a project [24].Avoiding errors and continuously updating the system is crucial for avoiding failure and for getting acceptance of the system.So, expert cooperation with the configuration team will be necessary, especially for highly engineered products.The Agile Unified Process (AUP) developed by Scott Ambler is a simplified version of the Rational Unified Process.An effective agile method in project development, according to Scott Ambler [41], and not keeping information or keeping duplicated information, according to Bran Selic [42], are the most important mentioned points in this research work.

Use case modelling and diagram
Use cases are the means of expressing functional requirements, which are understandable by stakeholders.Use cases create a design model, which can define test cases and plan iterations.Scenarios are the instances of use cases, which are applied for TO-BE processes in a modelling technique demonstration.Each use case is described in detail, and the use case description shows how the system interacts step by step with the actors.The same use-case model is employed during requirement capture, analysis, design and testing [34].

Iteration process
If a project is too big and has a long schedule, it often seems to have been bound to fail in most companies.Therefore, we have chosen to split this case project into smaller projects.Each phase in the RUP can be further broken down into iterations.Iteration is a complete development loop resulting in a release (internal or external) of an executable product, i.e. a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system [43].Some benefits from the iteration process in comparison with the waterfall method are: reusing the system, learning during the project and better quality and management.Fig. 1demonstrates the possibility of planning a general iteration loop for configuration projects.

Component-based development
Component-based development is about how to build quality systems that satisfy business needs quickly, preferably by using parts rather than handcrafting every individual element [2].For a highly engineered and complicated product, the best way is to split it into smaller components and then follow the iteration loop every time and test it.This makes the project less complicated and allows the delivery of the product as soon as possible.The first plan is a coarse project plan with start and end dates of phases and iterations.The second level of the project plan is a detailed plan for all iterations [33].Each phase of a project plan should have a specific responsibility.As an example, in the development phase, the following roles could be required: project owner, project manager, facilitator, change manager, end user, model manager, process manager, domain expert and programmer [2].Every project is a special task, making it difficult or even impossible to plan all the activities at the initial planning phase [43].Some argue that too much planning can curtail the creativity of project workers [35], and others propose to do milestone planning instead of activity planning.There is no argument about the fact that at least a minimum level of planning is required [27].In fact, planning is considered a central element of modern project management.There are very important aspects to be manifested in a project plan such as resources for the project and responsibilities, time tables, milestones, proposals, deliverables, success criteria, risk estimation, etc.

CASE STUDY
The proposed framework has been applied in a real context to assess its functionality.The case company is an international company specialised in the production of heterogeneous catalysts and in the design of process plants based on catalytic processes.The Wet Sulphuric Acid (WSA) process is used in industries like oil refining, coking, coal gasification and viscose fibre use.

Aims and purpose for the configuration system
A main challenge for the WSA process plant in the case study is within sales and pre-engineering, because a long time (more than one week)was needed to make a quotation.The regional offices all over the world are not capable of making the quotations themselves because of the complexity of the WSA.

Vision
The purpose is to introduce a configuration system, which can act as a knowledge management system, to provide easy access to product information and offer a simple way of making quotations.The system will reduce the lead time for generating quotations for sales people and act as a presale technical configuration system [13].

Objectives
The main purpose of implementing a configuration system is to make the sales process more effective.The system empowers salesmen to act more independently from the technical experts.Hence, in this project, the use of a product configurator will lead to:  Reduced lead time in sales and engineering processes  Improved quality of machines and plants  Increased sales -as it becomes easier to generate quotations  Reduced complexity of machines and factories  Cost savings in sales, engineering, production and installation due to the use of product configuration and more well defined and standardised modules in the projects  Improved accuracy in cost calculations and a decrease in projects that go over budget.

Current situation and future scenario (AS-IS and TO-BE)
In order to describe future scenarios, it is necessary to have a comprehensive overview of the current situation.Sales people are currently using excel sheets and a complex homemade calculation systems as the main foundation for the creation of technical proposals.The calculation system is a way of calculating a complex chemical process.Another problem is that the time spent on generating a quotation is not competitive in comparison to other companies around the world.The purpose of the project is primarily to create a stable tool aimed at generating proposals with as few errors as possible.The accepted scenario is shown in the flowchart in Fig. 3 below.

Stakeholders' identification and requirements
In this case, the stakeholders are sales staff, cost estimators, product developers, marketing staff and regional offices with different requirements to the configuration system.The aim is to find a way to integrate the complicated calculation software into the configuration system and make it easier for sales people to get involved in the calculating process.The overall requirements for the configuration system are:  Configure a process plant based on feed stream properties and requirements in terms of the emissions of a specific plant type (all stakeholders)  Combining document snippets into full technical or commercial proposals (sales people and cost estimators)  Loading technical and commercial data from the configurator into tables (sales, cost estimators and marketing group)  Price calculation, bills of material and scope of supply (all stakeholders)  Integration with high performance calculation systems and other systems for receiving the calculated outputs and flow diagrams (all stakeholders)  A user friendly and independent solution (all stakeholders)  Currency and language versions (regional offices)  Online based and saving functionality (sales)  Easy access to maintenance and updating the system (sales people and product developers).

Inputs/ outputs
Examples of input and output in this case are: the size and volume of the components, the entrance or exhaust pressure and temperature, the number of tubes in a condenser and the number and size of beds in a converter.

Main functionality
Examples of main functions in the configuration system are:  Capacity dimensioning for the entire plant  Cost estimation of the machinery  Needed engineering hours for specification  Energy consumption during operation.

Integrations
The configuration system used for this case study is a commercial configurator.For each project, much development and much integration are needed according to the stakeholders' requirements.The programmers and developers could perform plug-ins and integrations according to the stakeholders' request with the desired UI.Fig. 4 illustrates an integration example where a specific plug-in makes tables and draws diagrams according to the tables in the configurator environment.Fig. 5shows the performance of the UI according to the specific requirements.WSA plants include several machines and components, which are all engineered-to-order according to customer requirements [2].Most of them are produced inside the company, and some of them are provided by vendors.The company is covering seven standard plant types, and these different plants vary in terms of their machines and components and the number of machines due on the requested production capacity.There are more than 20 different machines, and some of them are mandatory due to plant type.Depending on the expected catalyst material, others can be optionally selected.

Product features
The product features for the case study focus on property models and product structure models as described by Hvam et al. [2].The product functions and properties to be modelled are, for example, the price, volume, size and mechanical and chemical properties built into the property model.The case study is consisting of more than 20 machines, each described with a number of features and constraints.The product structure defines how the products are built up and which parts they consist of.The solution principles in the example include the cooling of machines during the chemical process.

Input/output (level of details)
Fig. 6 gives us a very brief overview of the information needed for our project.The research work for finding a tool to manage the level of detail for input gathering during the first stages of the project is in process.Currently, reverse engineering for finding the outputs' level of detail is being considered.As an example, stakeholders asked for Price Calculation Sheets (PCSs), which are a combination of all component prices according to their internal selections and sizes, the engineering hours based on the plant complexities, consultancy hours, transportation expenses depending on the size and type, insurance IJIEM and destination.Taking these requirements for the PCS, it is possible to search for the relevant inputs.

Product Variant Master
All the discussions about understanding the structure of each individual component have been performed via PVM as a common language between domain experts and the configuration team.

Documentation and maintenance
Concerning the complications in the WSA plants and the importance of updating the engineers in all fields, the set up of a documentation system, was initiated in the early phases of the project.It has been decided to use XML files from the configurator with descriptions to make it possible to transfer all the information inside the configurator with no unnecessary manual intervention.Furthermore, everything inside the configurator, from attributes to rules, will be visible and understandable for everybody in the company and will enable sending comments and updates directly to those responsible.

Use case diagrams for documentation and maintenance
As mentioned, scenarios and flowcharts for the scenarios are a part of the use cases in RUP.In Fig. 7, the use case for the mentioned company has been demonstrated.In fact, specific rules for the use case diagrams should be taken into consideration, as, in RUP use cases are utilized to capture only the functional requirements [5].Fig. 8 shows the specific use case diagram utilized in the project.However, some use cases, such as integration and documentation, are to be explained in separate use cases as separate sub-projects.In this project, the general iteration process has been used, as described in the previous section.

Component-based development
The purpose of using a component based structure is to break a big complicated project into smaller pieces, making the process easier both for users and developers.When categorizing the expected results and outputs from the configurator, the expectations for the project become more clear.Table 2 depicts the importance of outputs for one specific component (in this case a machine in the process plant) and this way it provides the possibility of comparison and then prioritization in the project.The repeated use of the component (machine) in a factory is considered by multiplying the importance mean value with the number of times the machine is used.In this example in Table 2, the number of this machine in the plant is 2 and it means two of them are necessary for the plant implementation and therefore we need to multiply the importance mean value by 2. As indicated, the configuration project is expected to be challenging as a number of different complex components with varying priorities have to be implemented.The comparison between the tables related to the components weights is giving a sense of the importance of the components regarding different aspects.This will help the engineer to divide the project and start with the components one by one and combine them all in one project.In this specific case, before any specific plant type for WSA has been selected to be done first; this plant type was the most requested one from the stakeholders and the most sold one in the previous years.Henceforth, the components were evaluated according to their weights and they were divided to three big categories from the first priority components to third priority components and the project was also subdivided to three major versions.

Summary of the case study
In the case company the framework for scoping the configuration system was used in the initial phase of the configuration project.The framework was used a checklist of issues to clarify in the initial phase of the project.By following this "checklist" the configuration team and the stakeholders had a better basis for defining the project and establish a common understanding of the configuration system to be developed from an early point of in the project.
During the project execution the scope developed served as a project definition for the configuration team and as a contract between the configuration team and the stakeholders.During the later phases of the project the initial scope was used and adjusted whenever new requirements arouse from the stakeholders or other changes in the configuration project had to be made.

DISCUSSION AND CONCLUSION
The suggested framework for scoping product configuration projects is developed based on literature and based experiences from implementing product configuration projects in other ETO companies such as: GEA2 , MAN Diesel and Turbo3 , APC 4 , FL Smidth5 , CIMBRIA6 , NOVENCO 7 , ALTAN8 , and EMERSON 9 .All these com-panies are producing complex and highly engineered products like our case study Haldor Topsoe A/S10 .These companies are similar from different perspectives.Firstly, they are all producing highly engineered and complex products and they all want to use the product configuration system as a solution for decreasing complexity; and make the sales and engineering processes more efficient [16].Without a clear scoping from the first stages the configuration system tends to get complicated and with lack of focus.Second similarity is that they are all using the configuration systems for the sales and pre-engineering processes.Thirdly, they work on a high level of abstraction for the configuration projects.The stakeholders for all these companies are highly experienced engineers and sales employees.The configuration system is new to these people, so the configuration team need to discuss the scope with sales people and engineers with no particular knowledge or experience on product configuration systems.This paper clarifies that having a standard framework for implementing configuration projects has a remarkable effect on decision making in the early phases of a project.The suggested framework for scoping a configuration system has been tested in a case company.
In the case company the framework proved to be useful for the project team in supporting an early clarification of the configuration project, and the scope developed formed a solid basis for the subsequent configuration project in that the scope developed helped to focus and give priority only to needed parts of the configuration system.However additional research is required regarding the maintenance and testing stages.
In the case study there were some challenges in identifying and prioritizing the stakeholders and their requirements, which is a field that needs more researches in the future.Finding a solution for the documentation and maintenance part of the configuration project also need further research.Furthermore, the suggested framework needs to be tested in a number of companies to further validate it, and to test if the framework could be used also in other kind of companies than only ETO companies with complex and highly engineered products.
Customizing the URP methods and combining different modelling tools introduce a scoping framework for the configuration project.This scoping is able to clarify a project plan and the time estimation for the project managers and configuration team even before project Određivanje okvira projekta konfigurisanja proizvoda u preduzećima koja se bave inženjeringom prema narudžbini Sara Shafiee, Lars Hvam, Martin Bonev Primljen (12.07.2014.);Recenziran (02.11.2014.);Prihvaćen (02.12.2014.)

Figure 3 .
Figure 3. TO-BE process example

Figure 4 .
Figure 4.The integration user interface example

Figure 5 .
Figure 5.An example for plug-ins in the configurator environment

Figure 6 .Figure 7 .
Figure 6.The model subject layer and integration with other systems

Figure 8 .
Figure 8. Use case diagram example

Table 2 .
An example for component weighting