Sie sind auf Seite 1von 90

Collaborative Innovation in Dommel Valley

From subcontracting to collaborative innovation in high tech systems

II

PREFACE
In the Collaborative Product Innovation in Manufacturing (CPIM) project, initiated by the BOM and the Telematica Instituut, Assembleon, FEI Electron Optics and Philips Medical Systems on the OEM side, and Benchmark Electronics (formerly Pemstar), Bosch Rexroth, CCM, Frencken Mechatronics, NTS, Prodrive and Sioux on the supply side, work together on new forms of collaboration in product development. These companies are except for Benchmark Electronics located in the neighbourhood of Eindhoven in the Netherlands (in this guide book referred to as Dommel valley). This geographical concentration of innovative companies provides companies in this region with unique possibilities to become a world class region for the development of complex mechatronic systems such as electron microscopes, pick & place machines, and medical imaging systems. The main aim of CPIM is to exchange best practices and insights on collaboration and to create commitment for new forms of collaboration. A new form of collaboration is required to stay competitive and ensure economic growth in the region. It entails a change from traditional subcontracting and outsourcing to what we have coined collaborative innovation. This guide book describes the main characteristics of this new form of collaboration and the necessary steps to implement the required changes.

To move from subcontracting to collaborative innovation several obstacles need to be overcome first. In the discussions between OEMs and suppliers in the CPIM project on how to realise the envisioned form of collaboration five important issues emerged: Risk-reward models: models are suppliers willing to engage in risk-reward types of collaboration? What investments can be reasonably be expected from suppliers and what are fair compensations for these investments? What are attractive models to both suppliers and OEMs? Capability management: how to build the capabilities necessary for collaborative innovation? How to reliably measure these capabilities? Change management: how to keep track of engineering changes in collaborative innovation? How to deal with different PDM systems and procedures for change management? Trust: how to swiftly build trust between suppliers and OEMs? Intellectual Property: how to deal with intellectual property that is built up in projects? Can suppliers re-use knowledge in projects for other OEMs? Three issues have been addressed by working groups with members of the involved OEMs and suppliers. Each working group was facilitated by two researchers. The aim was to develop a toolbox (see Figure 1), which the participating companies could use to implement collaborative innovation projects.

IV V

Vision

Best practices

CPIM toolbox

Business models

Checklists

.. Based on hands on experience in projects

Figure 1: CPIM toolbox

Important ingredients of the CPIM tool box are: Business models which describe the possible spectrum of agreements regarding the division of risks, investments and revenues. Check lists to avoid typical pitfalls in collaborative innovation, including dos and donts for collaboration. Best practices for dealing with typical problems in collaborative innovation. Vision on how the collaboration between OEMs and suppliers should be organised. This guide book summarizes the first results on building such a toolbox. The guide book is structured as follows. Chapter 1 focuses on the drivers behind collaborative innovation and lists the challenges for suppliers and OEMs. Chapter 2 describes and

classifies the business models that are currently being used by suppliers and OEMs. It lists the advantages and disadvantages of these models for suppliers and OEMs and addresses the question when to apply which model. Chapter 3 touches upon the important topic of capability management. It identifies the capabilities required for collaborative innovation and ways to assess these capabilities. Chapter 4 discusses the implications of collaborative innovation for change management and lists four best practices. Chapter 5 summarizes the main findings and a road map towards collaborative innovation. Finally, in the appendix of this guide book one can find practical check lists to improve the collaboration between suppliers and OEMs.

VI

TABLE OF CONTENTS

INTRODUCTION ....................................................... 1

1.1 Experiences with collaboration .......................................... 2 1.2 From classical subcontracting to collaborative innovation. 3 1.3 Obstacles that need to be resolved ..................................... 5 2 BUSINESS MODELS ................................................ 7

2.1 Business models currently in use ....................................... 7 2.2 Business models and entrepreneurship............................... 9 2.3 Pros and cons of different business models...................... 11 2.4 When to apply which business model? ............................ 14 Minimal conditions for applying business models .......... 14 Business models and task uncertainty ............................. 16 2.5 Trust................................................................................. 17 2.6 Controversial issues in business models .......................... 18 Risk and reward balance.................................................. 18 Financing of specialization.............................................. 20 Intellectual property ........................................................ 21 2.7 Conclusion ....................................................................... 23 3 CAPABILITY MANAGEMENT ................................ 25

3.1 Introduction ..................................................................... 25 3.2 Capabilities for collaborative innovation ......................... 26 Capability areas............................................................... 30 3.3 Capability assessment ...................................................... 35

3.4 Capability management.................................................... 37 Specific challenges of high tech systems......................... 38 Capability management through collaboration ................ 39 Capability management through investments .................. 41 3.5 Conclusion ....................................................................... 43 4 CHANGE MANAGEMENT ...................................... 45

4.1 Introduction ..................................................................... 45 4.2 Change management in collaborative innovation............. 46 4.3 Best practices in change management.............................. 47 Best practice strategic CCB............................................. 48 System architect .............................................................. 51 Fast track......................................................................... 52 Informal communication ................................................. 54 4.4 External perspective......................................................... 57 4.5 Conclusion ....................................................................... 59 5 TOWARDS COLLABORATIVE INNOVATION........ 61

5.1 Achievements so far......................................................... 61 5.2 Next steps for realizing collaborative innovation............. 62 Business models .............................................................. 62 Capability management................................................... 63 Change management ....................................................... 64 6 APPENDICES: CHECK LISTS................................ 67

6.1 Check list collaborative innovation OEMs ..................... 68 6.2 Check list collaborative innovation suppliers................... 70 6.3 Check list memorandum of understanding ....................... 71

6.4 Check list business models .............................................. 71 6.5 Check list capability management.................................... 73 6.6 Check list change management ........................................ 75 6.7 Check list best practices change management.................. 76

1 INTRODUCTION
Over the past decades, product innovation has become a focal point of competition in many industries due to (1) the increasing number of companies capable of competing at a world-class level, (2) more demanding and sophisticated customers, (3) diverse and rapidly changing technologies provide engineers and marketers with more options to fulfil the needs of customers. These changes in market and technologies have created a new set of imperatives for product innovation in many industries. In the Mechatronics industry Original Equipment Manufacturers (OEMs) are pressed to increase innovation speed, beat the markets price erosion, and continuously deliver high quality and high performance at the same time. For Assembleon, Philips Medical Systems, and FEI Electron Optics product innovation (e.g. new features) and time to market are key differentiators and a way to avoid price competition in the early stages of the product life cycle. Whereas in the maturity and decline stages of the product life cycle, reducing prices faster than the markets price erosion becomes more important. Prompted by these stringent market demands and by resource constraints in R&D functions (both in terms of budget and personnel) OEMs have learned that they cannot do all product innovations on their own. Companies have been re-organising their activities by concentrating on their core competencies, and outsourcing activities to partners and suppliers, which possess complementary core competencies. As OEMs have become more dependent on suppliers to stay competitive, competition is no longer a matter of OEMs against OEMs but rather supply chain against supply chain.

1.1 Experiences with collaboration


Initially OEMs started to subcontract relatively simple tasks (e.g. jobbing and assembly activities) to suppliers. Increasingly OEMs are starting to subcontract and outsource more complex and higher level development tasks as well. This is, however, not going without problems. The following issues were identified in the case studies: Core competencies: unclear views on what are core and key competencies resulting in inconsistent and protective views on outsourcing and IP management. Business models: lack of fair business models (balance between risks and rewards). Current business models do not fit with the higher responsibilities and risks taken by suppliers. Working mode: problems of suppliers with switching from a your wish is our demand mode to a more proactive we think you can improve mode of collaboration. Not Invented Here (NIH) syndrome: problems of OEM to leave development activities to suppliers. Specialisation: too broadly oriented suppliers and lack of investments in core competencies. Competitive pricing: difficulty to reduce costs due to limited scale of operation, lack of buying power and high wages of personnel. Capabilities: mismatches between expected and observed capabilities of suppliers. Change management: incompatible change management processes and systems. Transparency: limited sharing of strategic information between OEM and suppliers negatively impacting trust.

1.2 From classical subcontracting to collaborative innovation


The problems mentioned in previous section made us rethink current collaboration practices and develop a new vision on collaboration and collaboration practices. This change can be summarized as a movement from classical subcontracting to collaborative innovation (see Table 1).
Table 1: differences between classical subcontracting and collaborative innovation
Issue Supplier responsibility Collaboration with Involvement Transparency IP Risks & rewards Working mode Specialisation Crossfertilization Classical subcontracting Limited responsibilities (e.g. jobbing) OEM: large pool of suppliers Late involvement of suppliers Limited sharing of knowledge IP at OEM OEM prime risk taker Hierarchical: your wish is our command approach Broadly oriented suppliers relying on craftsmanship Limited synergies from applying capabilities in different domains Collaborative innovation Far reaching responsibilities (e.g. life cycle management, knowledge creation) OEM: limited set of key suppliers Early and profound involvement of suppliers Extensive sharing of knowledge Opportunities for supplier to specialise and build IP Sharing of risks and rewards Partners: equal partners with a proactive attitude Suppliers specializing and leading in key technologies Many synergies from applying capabilities in different domains

The new vision on collaboration requires suppliers to: Choose and be top in what you choose: develop and invest in world class competencies on one or more specific areas (e.g. motion control, high precision manufacturing, frame building, vision, etc.) Create critical mass: apply core competencies in projects with multiple OEMs (economies of scale). Take ownership: be responsible for sub assemblies instead of monos, supply chain management and product life cycle management Under take: be prepared to share risks and rewards with OEMs, build and exploit IP Continuously improve: speed up the learning curve, reduce costs, and increase functionality, speed etc. The new vision on collaboration requires OEMs to: Identify core competencies: be clear what are core and what are key technologies. Subcontract key technologies to specialised suppliers Share road maps: share technology and product road maps with key suppliers. Re-organise: re-organise engineering departments responsible for key technologies (e.g. letting go engineers, re-educate them to engineers that can monitor subcontracted activities) Develop capabilities: develop sourcing, project management and review capabilities and techniques to manage subcontracted activities Develop system architectures: develop modular system architectures to reduce the complexity of collaboration, subcontracting and outsourcing Define IP: define and discuss no fly zones on the re-use of knowledge with suppliers from the start. Build long term relations: build long term relations with a limited set of strategic suppliers yet make sure that suppliers are not too dependent (<25%).
4

Change organisation culture: fight the Not Invented Here syndrome among engineers and convince them of the positive sides of collaborative innovation Reduce organisational complexity: establish clear lines of communication with suppliers. Shield suppliers from organisational complexity Collaborative innovation in electron optics A cluster of suppliers developed a compact table top electron microscope from prototype to mature product in just one year for FEI Electron Optics. NTS and Sioux were the main suppliers and were responsible for the entire project. FEI was responsible for marketing, sales and service to customers. The main suppliers choose a risk-reward business models for the collaboration. This resulted in an active involvement of the suppliers and an open and trusting collaboration environment. Problems were solved jointly and strategic information was shared. FEI actively transferred its technical knowledge to NTS and Sioux. The aim is that both suppliers gradually take over all work from FEI. For many suppliers and OEMs these are big steps, several obstacles need to be resolved.

1.3 Obstacles that need to be resolved


To move from subcontracting to collaborative innovation several obstacles need to be overcome first. In the discussions between OEMs and suppliers in the CPIM project on how to realise the envisioned form of collaboration three important issues emerged:
5

Risk-reward models: are suppliers willing to engage in risk-reward types of collaboration? What investments can be reasonably be expected from suppliers and what are fair compensations for these investments? What are attractive models to both suppliers and OEMs? Capability management: how to build the capabilities necessary for collaborative innovation? How to reliably measure these capabilities? Change management: how to keep track of engineering changes in collaborative innovation? How to deal with different PDM systems and procedures for change management? These issues are discussed in chapters 2, 3, and 4 respectively.

2 BUSINESS MODELS
Collaborative innovation as described in previous chapter requires OEMs and suppliers to rethink their business models. Business models are essential for converting ideas and technologies into economic value. However, business models are not all the same. Consider a business model as a framework to discuss the value proposition and value exchanges in a network of collaborating organisations. A business model describes how partners share the risks, investments and revenues of developing new products.

2.1 Business models currently in use


Several business models are currently being used in the hightech mechatronic industry. These business models can be classified into three types: Cost-based models: in these business models suppliers are rewarded for their effort in terms of man power and use of materials and facilities. Examples are: time-material and amortization. Performance-based models: in these business models suppliers are rewarded if they succeed in meeting predefined goals. Examples are: fixed price and cost down. Revenue-based models: in these business models suppliers are rewarded for investments in product development, either by developing own products or sharing in the risks of developing a product. Examples are: risk-reward, value, and license. Table 2 provides a description of the different business models. In practice these business models are often combined. For instance amortisation is combined with risk-reward models.
7

Table 2: Overview of business models in use


Business model Cost-based models Time material Description Real costs of the deployment of man power, materials and facilities are billed to the OEM. Development costs are not paid until production starts. Two variants: with and without production guarantees. Fixed price for function according to predefined specifications. Revenues for supplier if he succeeds in beating the target price and meeting the specifications. Agreements on price erosion curve. Cost price needs to be reduced with a specific % in a specific time period. Suppliers invest in product development. Reward is dependent on the number of sold products. Supplier or OEM grants an external party permission to use certain technology in return for a certain reward. OEM pays for the real usage of the developed functionality, predominantly used for software application.

Amortisation

Performancebased models

Fixed price

Cost down

Revenuebased models

Risk-reward

License

Value

Combining business models in placement control In the placement controller project of Assembleon and Prodrive the amortisation, fixed price, and risk-reward models were combined. Prodrive invested in product development and these costs were earned back (without production guarantees) in product delivery. Development costs were not specified but included in the agreed target price. Prodrive will have a higher reward if a higher number of products are sold. An important agreement is that Prodrive can reuse the build knowledge in other projects (excluding predefined no-fly zones). If less products are being sold than expected Prodrive is still able to earn back the investments in other projects.

2.2 Business models and entrepreneurship


The business models identified differ in terms of the entrepreneurship required by the supplier. Entrepreneurship can be expressed in terms of the degree of taking risk and level of investments required by suppliers. In general one can distinguish between two types of risks: Market risk: the risk of introducing a product to the market which is not taken up by customers as expected due to economic stagnation, competition, mismatch with customer needs, etc. In classical subcontracting this risk is normally taken by the OEM. In collaborative innovation suppliers might share a part of this risk.

Development risk: risk the risk of developing a function which does not meet the predefined specifications due to immature technologies, lack of capabilities, interface problems, unstable supply and manufacturing processes etc. In time-material models this risk is taken by the OEM, whereas in fixed price models the entire development risk is taken by suppliers. Besides accepting variable revenues (taking risk) suppliers might be asked to pre-finance development efforts (amortization) and to invest in facilities (e.g. clean rooms, machines, software licenses) and capabilities (e.g. knowledge and skills of employees). When these investments are project specific and of limited strategic value to a supplier the costs are often passed on to the OEM. Suppliers will be more willing to pay for the investments if they see strategic value in it and see possibilities to earn it back in other projects. Since suppliers, compared to OEMs, have limited financial resources they have to carefully consider in which projects they will take risk and invest and in which projects not. The entrepreneurship required for the different business models is summarized in Table 3 below. Note that these are not absolute values but just indications of the entrepreneurship required for a particular business model.

Product ownership at Bosch Rexroth Bosch Rexroth has developed a motion control platform in collaboration with research partners. Two OEMs (FEI and Alphasem) act as launching customers. The platform is a generic solution which can be customized to wishes of individual customers. Customers pay for both the product and the customization effort.
10 0

Table 3: entrepreneurship required for different business models


Business models Time-material Amortisation Fixed price Cost down Risk-reward License Value Required entrepreneurship Low Low Medium Medium High High High Market risk No No No No Yes Yes Yes Development risk No Yes Yes Yes Yes Yes Yes

2.3 Pros and cons of different business models


The business models identified have advantages and disadvantages to OEMs and suppliers. The most important ones are listed in Table 4 for suppliers and in Table 5 for OEMs. In general one can say that OEMs interests in more entrepreneurial business models is that these models contain more incentives for suppliers to reduce costs and increase performance. Moreover, they offer opportunities to share investments and risks and hence allow them to do more development activities with a given R&D budget. For suppliers, these models may, when negotiated in a fair way, offer more rewards and provide opportunities to improve their collaboration relationships with OEMs. The models presuppose a higher involvement and responsibility of suppliers and this provides them with opportunities to specialize and strengthen their capabilities. There is however also a negative side to it: suppliers run, depending on the arrangement chosen, considerable financial risks.
11

Table 4: advantages and disadvantages for suppliers


Business model Time-material Advantages Relatively simple agreement. Reduces risks: actual material and labour costs are being paid Disadvantages Services such as TPD management, logistics, and inventory are often not included in the tariff. Project can be stopped easily if priorities change Financing structure of suppliers leaves little room for pre-financing. Difficult to predict exact costs and risks in advance. Risk of budget exceeding at supplier In case of supplier prescribed supply base system, suppliers have little influence on costs Substantial risk and investments required, OEM may be less committed, complex agreement Requires considerable investments in development of IP Reward not until product is being sold and used

Amortisation

Increases service to OEMs, prospect on production Determine own destiny, fit for function design possible, reward for cost price reductions Determine own destiny, high supplier responsibility: life cycle management Higher reward, stimulates collaboration, more focus and drive from both supplier and OEM Determine own destiny. Opportunity to earn back investments in technology Increases service to OEMs

Fixed price

Cost down

Risk-reward

License

Value

12

Table 5: advantages and disadvantages for OEMs


Business model Time-material Advantages Disadvantages

Relatively simple agreement, No incentives for speeding specifications can be up and delivering quality, changed easily without extra will increase costs costs Cost can be better spread out over lifecycle. Frees up development budget Risk of budget exceeding at supplier. Price guarantee, build in incentive driver to reduce feature creep. Fit for function design possible Limited incentives for speeding up development Requires detailed specifications, costly to change specifications, may be threatening for own organisation. May harm quality of development (budget driven instead of quality driven) May harm quality of development (cost driven instead of quality driven). Danger that possible cost reduction is divided in steps in stead of at once. Value break down must be clear. More effort is needed in making agreements, dependency on supplier

Amortisation

Fixed price

Cost down

Fixed agreements on cost reductions, allows KPI management, ensures competitive advantages over other regions; supplier has drive to reduce cost Sharing of risks and investments, stimulates collaboration, more focus and drive, market demands are put central. License costs can be passed on to customer, no development time and costs. Fixed costs are traded for viable costs. Fast access to new developments Cost are being made not until product is being sold and used, no development budget needed

Risk-reward

License

Dependency on supplier, costly on long term

Value

Difficult to implement: administrative burden requires mature and secure IT infrastructure. Maybe too costly on long term

13

2.4 When to apply which business model?


An important issue is when to apply which business model. Several contextual factors influence this decision. For instance, experiences with suppliers/ OEMs in past collaboration projects, available resources (financial, human, technological resources), trust, etc. Moreover, research shows that there is not one best business model for a given situation. Often different business models can be applied to the same situation and often models are combined. We therefore provide only rough indications of the applicability of business models. The focus is on the minimal conditions that need to be met to apply a particular business model, and the applicability of business models in the different stages of the product life cycle and product development.

Minimal conditions for applying business models To be able to safely apply a business model the minimal conditions have to be met. Table 6 provides an overview of minimal conditions for the different business models. When for instance a fixed price model is used and the functional specifications of the product to be developed are unclear suppliers run the risk that the development will take more time and hence the project budget is exceeded.

14

Table 6: Minimal conditions for applying business models


Business model Time material Minimal conditions Requires agreements on how value adding services such as TPD management, supply chain management, etc are billed. Requires financial reserves of suppliers, often suppliers have to finance amortization from their working capital. Production guarantees should be clear. Requires detailed and clear specifications. Risks and costs should be predictable in advance. To make it more manageable development is often divided into different stages. Requires extensive technical and process capabilities. Supplier should own cost monitor. Requires agreements on cost owners and what can be influenced by suppliers and what not. System suppliers should be able to control supply base. Cost targets should be realistic. Requires that rewards are in line with the risks being taken (fair deal). Requires mutual management commitment to ensure sufficient priority. Requires suppliers to deepen their product and market knowledge. Requires OEMs to share market forecasts. It should be possible to earn back investments in more than one project. Requires suppliers to build own IP which is difficult to copy and work for multiple OEMs. Requires explication of the value being added by suppliers. Requires suppliers to build own IP which is difficult to copy and work for multiple OEMs.

Amortization

Fixed price

Cost down

Risk-reward

License Value-based

15

Business models and task uncertainty The nature of the task changes from highly uncertain in the technology development stage to relatively predictable in the regular production stage. Depending on task uncertainty different suppliers (see also chapter 3) and different business models are required. In general one can say that in the very early stages of product development (see Figure 2), innovation driven suppliers (wizz kids and specialists) are required and time material business models are preferred to govern the collaboration because of the difficulties in specifying the required time needed and hence costs to complete a task. Most suppliers find the risks simply too high to engage in performance or revenue based business models.

Wizzkids The Specialist Troopers


External manpower

Uncertainty is very high. No product in mind or available in the market Uncertainty is medium / Similar technology available in other products`

Uncertainty is very low / Design is finished and needs detailing

Low Volume

Jobbers
High Volume

Uncertainty is very low / Production driven (repeating assembly) Engineering change control only

Technology Development

Alpha / Concept

Beta / Specials / NSR


one-offes / low volume

Regular production

Figure 2: task uncertainty in product development (Source: FEI Company)

16

On the other end of the spectrum, in the regular production stage the risks are more manageable and the emphasis shifts from innovation to operational excellence. It is here that OEMs need suppliers that are production driven (Troopers and Jobbers) and performance based business models such as fixed price and cost down are predominantly used to govern collaboration. In the alpha concept and beta / specials stages of product development, combinations of different business models can be applied. For instance, an amortization combined with a risk and reward business model. The time material business model is, however, often not accepted in these stages.

2.5 Trust
An important pre-condition to start discussions on business models is trust. Without trust it is very unlikely that partners are willing to engage in more entrepreneurial forms of collaboration. Trust enhances the willingness to participate in a business transaction and become vulnerable to the actions of other business partners. In general, peoples trust in others can be based on three information sources. First the characteristics of a person (e.g. looks, family background, competencies), referred to as characteristic-based trust. Second, on past experiences (e.g. collaboration history, reputation), referred to as processbased trust. Third on laws and codes of conduct (e.g. contracts and memorandum of understanding), referred to as institutionbased trust. These forms of trust illustrate that contracts and capability assessments are not the only ways to build trust. A good practice is to build trust by jointly doing small projects together
17

before doing more serious projects. A good example is the design workshop Philips Medical Systems organized for suppliers (see below). Building trust in suppliers at PMS Philips Medical Systems built trust in the supplier stage by asking two suppliers to participate in a design workshop. The suppliers have to present their solution to the problem assignment of PMS. In this way they can check the problem solving capabilities of both suppliers. Frencken convinced PMS of their capabilities and got an assignment for the development of a new patient table. With respect to business models, some suppliers distrust the motives of OEMs to more risk sharing forms of collaboration. Is it just a disguised way of shifting costs to suppliers or does it really help speeding up innovation? This distrust is nurtured by OEMs which overemphasise risk sharing and underemphasise reward sharing. It would help if OEMs are prepared to discuss both risks and rewards.

2.6 Controversial issues in business models


When negotiating the business model of collaborative innovation efforts, companies are confronted with several controversial issues. Risk and reward balance When negotiating business models the starting point should be that both supplier and OEM can earn a living, hence profit. In

18 8

other words: the costs and benefits for both supplier and OEM should be in balance (see Figure 3).
High

Revenu based models

REWARDS

Performance based models

Cost based models

Low

RISKS

High

Figure 3: balance between risks and rewards

Shifting risks to suppliers without compensating for these risks in the form of e.g. revenue sharing is thus not a durable and fair arrangement. OEMs and suppliers in CPIM have, however, different opinions what they regard as a fair deal. The most important negotiation points on the risk and reward side are listed in Table 7.

19

Table 7: negotiation points on risk and rewards


Risk side Investments at own expense in product development Reward side Possibility to re-use build knowledge in other business settings Bonus for risk taking Higher chance of getting the business

Investments in facilities required for a Follow up projects which need these project such as clean rooms and facilities machines Investments in getting an assignment (e.g. proof of concepts) Bonus for risk taking Higher chance of getting the business

Pre-financing of product development Production order as reward for pre(supplier acting as bank) financing product development Committing to penalties for e.g. late delivery and poor quality Committing to price and price reduction targets Accepting development job without production guarantees Building own IP Bonus for risk taking (e.g. bonus per sold product) Closed book calculation (difference between price and costs is for supplier) Follow up projects Higher chance of getting the business License costs

Suppliers have in general limited financial resources to engage in risk sharing. Careful monitoring of cost calculations have induced many suppliers to charge OEMs only for hours and materials (and not for R&D). Time material does not build core competences and financial reserves for engaging in risk taking forms of collaboration. This brings us to the second controversial issue, financing of specialization. Financing of specialization An important issue between OEMs and suppliers is who is going to pay for the capability development and investments in facilities of suppliers. Some suppliers argue that if OEMs want them to specialize and build certain capabilities and invest in
20

facilities they have to charge these additional costs to the OEM. In contrast OEMs argue that they have to educate suppliers on their own expenses. Suppliers learn from OEMs in the projects and often the capabilities of suppliers are not on the desired and expected level (see chapter 3). In dealing with this issue it is important to adopt a longer term perspective on these matters. Both supplier and OEM will on the long run benefit from specialization and economies of scale (working for different OEMs). On the short run it requires, however, investments of both suppliers and OEMs. Strategic investments in capabilities and facilities should not be debited on one single project but on several projects. This requires OEM and supplier to commit themselves to long term collaboration relations. In situations in which changing supplier is relative costly this is almost the case. If investments are project specific suppliers should be able to pass on these investments to the customer. Another way to deal with this problem is to attract venture capital from venture capitalists or the government. Intellectual property Another important issue is IP. Some OEMs are very restrictive in what suppliers may do or not do with knowledge that is being built by suppliers in projects for the OEM. They are concerned that this knowledge will spill-over to competitors and consequently the supply chain will loose its competitive advantage. Suppliers, which invest in capability development, argue that they should in return be allowed to exploit this knowledge in other projects. In this way they are able to earn back their investments, become specialists, and achieve economies of scale. To decide what knowledge may be exploited by supplier it is crucial that OEMs have a clear image of what are core and what key competencies. Competencies are considered core if
21

they differentiate a company strategically in the market place. It requires companies to answer the following questions: Are we better then our competition? Does it give our customers additional value? Is it sustainable; in other words hard to copy? Can we communicate it internally and externally? Not before OEMs are able to clearly distinct core from key competencies it is possible to make clear and fair agreements on reuse of knowledge and IP. To make matters even more complex, in supply chain collaboration there is not only explicit IP at stake but also the more implicit skill to create customer solutions together. This tacit knowledge is difficult to include in IP agreements. IP management at Assembleon Assembleon has assessed all its development activities on contribution to core competencies. Its strategy is to outsource all key competencies on the highest possible level. Discussions on what are key and core competencies were tough, but after a while really helped Assembleon to get a clear image of their strengths vis--vis competitors and to decide what and what not to outsource and to protect with agreements on IP and re-use of knowledge. Basically Assembleons view on IP is that OEMs have to accept that joint knowledge can be exploited elsewhere. The supply base has to accept that there can be exclusions (so-called no fly zones) to where OEMs want the knowledge to be exploited (e.g. competing companies). This has to be agreed on in the beginning of collaboration.

22 2

2.7 Conclusion
In this chapter we have discussed three types of business models: cost-based, performance-based and revenue-based models. The models have been typified and analyzed on advantages and disadvantages for suppliers and OEMs. The business models differ in terms of the entrepreneurial orientation required by suppliers. Suppliers need to carefully determine if they are prepared to share a portion of the market and development risk and invest in product development. Key points in negotiating an appropriate business model are: (1) balance between risks and rewards, (2) financing of specialization, and (3) Intellectual Property.

23

24

3 CAPABILITY MANAGEMENT
3.1 Introduction
Subcontracting strategies even of product development tasks have traditionally been driven by considerations of capacity levelling or cost reduction. Capability management in such situations is primarily concerned with ensuring that the supplier is sufficiently up to the task.
Product development performance/ innovativeness

Product development performance/ innovativeness

Develop and work with those partners that give competitive advantage in collaborative innovation

Price competition with those that fulfill the standards


Minimum Capability level to be up to the task (OEM / supplier)
Minimum to be up to the task

Capability level (OEM / supplier)

Figure 4: Capability as performance driver in collaborative innovation

Collaborative innovation, however, strives for additional competitive advantage by using and combining specific capabilities beyond those that the OEM has available internally. For success, not only the technical capabilities of the supplier are of importance, but equally project management related capabilities and the meta-capabilities of identifying, organising and developing the necessary capabilities both at the OEM and the supplier. Also experience often showed a
25

mismatch between desired and presented capabilities and the actual capabilities. Three main topics are of main concern in : Which capabilities are needed for different project types and supplier roles in them? What are methods and tools to realistically assess the capabilities of partners for a specific project? How to best develop or work around missing capabilities? The following sections discuss each of the three main topics, but also give outside examples of approaches other companies use.

3.2 Capabilities for collaborative innovation


PMS and FEI developed frameworks to position suppliers within projects and through this define the expected capabilities for the role of the supplier.
R&D Conceptual design Detailed design Manufacturing engineering Mono product One technology assembly Multi technology assembly Complex product

PMS uses a framework that creates a matrix between the expected product development and the production role: The different columns and rows are defined as follows:
26

Development capability classification

Production capability classification

Figure 5: PMS Supplier classification framework

Table 8: PMS Definition of Supplier roles


Classification R&D Definition Research: Create new technology, e.g. revision of accepted theories or laws and practical application Predevelopment: prove that given concepts, can be transferred to a feasible product and/or market. Translate the requirement specifications (hardware, software and mechanics) into design solutions Translate conceptual design to product-, module-, building block specifications. Detailed designs to be weighted against relevant criteria like: costs, specification, produce ability, risks, timing, logistics, flexibility, serviceability etc. Describe how to make, assembly, test, etc. Translate technical product documentation in working instructions, production flow, etc. Transfer basic materials into products, purchasing mostly done by production preparation, logistic process is simple. Material value normally maximal 20 % of the total product price, added value in labour and/or machining relatively high Assembling in the own technology area, e.g. mechanical machining company that is assembling two or more own machined mechanical and purchased parts onto a more logical sub assembly. Logistics and purchasing getting more important. purchase function more operational oriented. main benefits for these companies from core expertise in house machining of mono parts. More complex assembly capabilities with also other technology areas. Often more than one basic technology is in house available. Not necessary to have own parts production facilities. Necessary to have a good production engineering department. Supplier market knowledge is available. Separate purchase department in place. Logistics and stock control is very important.

Conceptual design Detailed design

Manufacturing engineering Mono parts manufacturing

One technology assembly

Multi technology assembly

27

Classification Complex product manufacturing/ assembly

Definition Multi technology assembly + extended capabilities of the control- and assembly people. Example features are: dependent control loops, dependency in constructions, complex adjustments, special assembly facilities (like clean room and gluing), specialized (often own developed) highly sophisticated test equipment. Difference from multi technology assembly is failure detecting instead of adjusting.

FEI is developing a somewhat similar framework called Yellow brick road. It captures the roles and capabilities needed of suppliers along the development and production lifecycle (see Figure 6).

Wizzkids The Specialist Troopers


External manpower

Low Volume

Jobbers
High Volume

Technology Development

Alpha / Concept

Beta / Specials / NSR


one-offes / low volume

Regular production

Figure 6: FEI Supplier classification framework (Source: FEI company)

Wizzkids are suppliers with highly innovative and leading edge competences that are able to come up with completely new ideas and concepts. They are needed especially in the early invention and concept phases. The Specialist has deep
28 8

knowledge in his field of competence and through this brings competitive advantage into collaborative innovation projects. Troopers can especially solve capacity constraints. They bring in sufficient capabilities to be productive under guidance, but cannot develop new ideas independently. The Hands only group finally provides clearly defined services e.g. in production. Supplier marketing at a car maker A major German car maker has defined some 150 complex modules that are highly relevant for the innovativeness and performance of the car. For these modules, the company takes a collaborative innovation approach. Most prominent characteristic for the purchasing of these modules is a supplier selection process that is mainly capability driven, not price driven. The responsible purchasing groups for the different modules regularly screen the market for potential suppliers independently of the specific project at hand. Also suppliers can apply by demonstrating their innovativeness and performance e.g. through reference projects or show cars. The purchasing group assesses the capabilities of the proposed suppliers through questionnaires and extensive audits according to a requirement profile covering both general characteristics and specific capabilities for the module at hand.

29

A special focus is placed on innovativeness of the supplier besides the typical criteria of quality, project management, production and logistics. Only 2-4 suppliers per module are short listed for long-term collaboration. Specific projects are then assigned to this supplier pool based on detailed competence fit or competence development paths per project and portfolio considerations. The car maker defines a target price for the module based on e.g. top-down costing, similar projects, external benchmarking, cost calculations, and typical cost degradation, which the supplier has to achieve. Excessive margins on the supplier side are seen as breach of trust and can lead to the removal from the preferred supplier pool. The car maker frequently audits the capabilities of the supplier. Areas for improvement are identified and measures agreed, which can be the responsibility of the supplier, but can also include knowledge transfer and change support from the OEM to the supplier. Since being part of the supplier pool secures future orders with usually relatively good conditions, there is a high incentive on capability development at the supplier side. Capability areas Which capabilities are needed for successful collaborative innovation and product delivery? Examples were provided in the workgroup sessions by the OEM companies that use similar capability dimensions. The general FEI supplier assessment questionnaire for example contains the following capability dimensions:

30 0

Table 9: FEI Supplier capability assessment dimensions


Capability area Quality Assurance Management Examples for assessment dimensions Quality assurance system in place Failure monitoring and management Quality assurance roles and responsibilities Business mission and market and product strategy Business plans for functional areas (e.g. Marketing & Sales, Development, Production) Long term strategy with customer, potential win-win situations Experiences and capabilities in joint technology development projects Technical personnel involvement in bidding process (to ensure realistic proposals) Continuous training in production Work plans actually used in production Manufacturing equipment quality and availability Production planning process and flexibility Production management flexibility Continuous productivity improvement Supplier marketing and management Supplier performance management Supplier quality management

Development

Production

Logistics

Purchasing

These more general supplier qualification dimensions are supplemented by detailed technical capabilities assessments for the specific project at hand. The analysis of the CPIM cases and more general research results of collaborative innovation recommends a focus on three key dimensions of capabilities:

31

Functional capabilities Project capabilities Dynamic capabilities

Figure 7: Key capability dimensions for collaborative innovation

Functional capabilities are traditionally in the focus of supplier assessments. They include the technical competencies and facilities required for the project at hand. In some areas minimum standards are required, while other core competences can make the difference for a highly innovative product.
Technical competencies

Mechatronic development and manufacturing Electron microscopy technologies Quality management processes

Specific facilities

Clean room facilities High precision tool machinery

Figure 8: Examples functional capabilities

Project capabilities form a second capability dimension. While they are already important for internal development projects, they become critical in collaborative innovation. All CPIM cases highlighted the fact that these capabilities are also required on the customer side by exhibiting problems if the OEMs capabilities were weak, while their availability clearly supported project success.

32

Project management skills and processes

Collaborative project management Well defined development process implemented in practice 3D-CAD Modeling Inter-organizational collaboration platform

System support and usage skills

Figure 9: Examples project capabilities

The third set of capabilities, dynamic capabilities, has recently received wide recognition in the management literature to explain the success and failure of seemingly similar companies in highly innovative and fast changing markets. Dynamic capabilities describe the ability to recognise new opportunities and reconfigure and adapt quickly to them. The Summit project demonstrated the importance of these capabilities in understanding and capturing the opportunity both on FEI and the suppliers side, building a high performance team with the right partners and implementing mechanisms (e.g. System architect support) for fast learning.
Business opportunity spotting

Identifying new business opportunities Building suitable business models for opportunities Investing in profitable capabilities Selecting the right partners for project Building quickly high-performing teams Building project portfolio for learning

Deployment capabilities

Learning

Investing in profitable capabilities Capturing and reusing experiences

Figure 10: Examples dynamic capabilities

33

Dynamic capabilities in the Summit project The Summit project is a best practice example of the importance and benefits of dynamic capabilities in all dimensions introduced above. The original invention of a small, low cost electron beam was with a different application in mind. Some people at FEI recognised however the opportunity to build a low cost electron microscope targeted at a completely different market segment than traditionally served by the company and found a promoter of the idea in the person of Ben Borman. He saw quickly that the traditional business model of FEI would not suit the opportunity, and decided for a virtual enterprise approach and negotiated a relatively innovative agreement with the suppliers around risk and reward distribution for the project. Partner selection was supported by the BOM based on earlier understanding of the virtual enterprise approach. Deployment capabilities can be seen especially in making the partner selection based on a combination of capabilities and entrepreneurship of the supplier, with the latter being seen somewhat more important for success. Again, the suppliers had the capabilities (management outlook, decision processes) to understand the opportunity and make investment decisions to build the technical capabilities and project management.

34 4

The project organisation set up also in contrast to some of the other CPIM case projects was ideally suited to quickly build a high performing team and to support efficient knowledge transfer including the tacit dimensions of electron microscopy experiences. Relevant are especially the use of FEI system architects as specialists and facilitators in the design process, but not in a project management function. The suppliers agreed jointly on a project manager for supporting collaboration and tracking progress and key indicators, while especially the steering group with senior managers involved had the power and willingness to make entrepreneurial decisions.

3.3 Capability assessment


Customers find it rather difficult to realistically assess the capabilities of suppliers. Two widely used practices are audits that try to measure capabilities relatively objectively and are suitable especially for certifying new suppliers, and positioning based on experience (e.g. within the FEI yellow brick road) that is more useful for evaluating established suppliers and to manage their capability development. A typical audit is built on a two step process: In the first step, the supplier receives a questionnaire to be filled in as self assessment. In a second step, a team of the customer visits the supplier and jointly reviews the questionnaire and compares it with the impressions from supporting documents, walks through the different departments and other evidence provided. However, all case study projects analysed in the CPIM project showed considerable discrepancies between the capability level

35

expected and the one experienced in the project. This can be attributed to three main factors: Each project requires a specific set of capabilities due to the project scope, organisation, and other goals. Questionnaires need to be adapted to cover at least the most important aspects of the specific project. Capabilities are usually assessed through evidences such as specific processes in place. In turn, capabilities only influence the final outcome, but do not determine them alone. These two levels of indirectness make assessments an indicator, but no guarantee for success. Research shows that the capabilities of key personnel play a crucial role in project performance. These capabilities are usually not covered by assessments. There are no good tools for accessing technological capabilities, and suppliers have a tendency to over-sell themselves. When the customer is (too) eager to subcontract, this can lead to misalignment. Several recommendations can be derived from these experiences: Collaborative innovation for critical components or modules requires long-term relationships such that realistic views on the capability levels can be developed and the roles and scope agreed accordingly. For example, FEIs experience with established suppliers gives them a relatively consistent view on the positioning of the respective supplier in the Yellow Brick Road framework (see Figure 6). For new suppliers, capability assessments should be extended to include elements related to the project profile, the analysis of reference projects with a similar scope, and individual team assessments. Finally, the team on both customer and supplier side should be aware of unexpected capability gaps and quickly take measures to overcome them.
36

Almost as important as the actual capability level is the willingness of suppliers to learn and close important gaps. In a new assessment approach targeted towards technical competencies, FEI thus introduces a matrix of experience vs. interest, i.e. whether the supplier has proven expertise or not on the one side, and whether it has a strong or no interest to engage and learn in a certain technology. A match of interest and expertise is of course optimal, but a good mark in the interest dimension can make up for some missing capabilities.
Interest: 1 = Very interested, would very much like to (continue) do this 2 = Interested, likes to (continue) do this 3 =A slight preference not to do this 4 =A strong preference not to do this Expertise: 1 = One of the key strengths 2 = Something he/she can do well 3 = An area to learn 4 = Knows little / nothing about. Can learn a lot in this area

3.4 Capability management


It is unlikely that the supplier has the perfect match of capabilities needed for the specific project at hand. In principle, there are two strategies to deal with such situation: To collaborate in order to cover the missing capabilities. Collaboration can be vertical with the customer or horizontal with other suppliers as partners To invest in building the capabilities needed, e.g. by buying a special resource, hiring a specialist, or training.

37

Specific challenges of high tech systems Mechatronic suppliers and OEMs face specific challenges in capability management: mechatronics has many applications in very different industries. To excel in product innovation, both strong technological competences and deep application and system knowledge need to come together. In other industries such as automotive or aerospace, suppliers usually work only in one or two application domains and can thus build profound domain understanding. While a certain domain specific knowledge is required to at least understand the main issues, building deep knowledge is usually even uneconomical and locks the supplier in a subset of potential applications. Instead bridging many application domains may add considerable value to the customers as the supplier can transfer solutions and experiences from other applications to which the OEM does not have readily access. Again, some of the CPIM case study projects have shown the advantage of such knowledge transfer even if it requires higher OEM involvement to cover for the application and system specific knowledge.
Application/system knowledge
Precision machines Medical devices Electronmicroscopes

Technology competences

Precision mechanics

Motion control

Figure 11: Matrix of technology and application knowledge

38

Capability management through collaboration In the workgroup discussions members described the ideal supplier role to receive a clearly described development task e.g. for a module that exactly matches the capabilities of the supplier. Any need for collaboration is at first glance seen as weakness and loss of independence on the part of the supplier. However: Capabilities can only be grown through experience and learning usually from somebody else, and It is in many cases uneconomical to build capabilities that are either very costly or rarely needed. As an alternative, collaboration with partner suppliers that have the specialist competences needed or with the customer can better close the gap. The CPIM case projects all very clearly indicated that open, trustful and well managed vertical and horizontal collaboration contributed to project performance in all dimensions. It seems that such collaboration does not only close capability gaps, but even enhances the capabilities of partners mutually towards more productive and better innovation. Good practices for such collaboration include e.g.: Strong team building including shared objectives, understanding each other roles and responsibilities. Not permanent collocation, but longer periods (several days) of productive work in one place, looking in the others kitchen. Full openness and transparency. Backing of an appropriate steering committee and project sponsor, keeping away constant commercial issues from the team members.

39

Virtuele Fabrik Virtuelle Fabrik is a network of about 20 small and medium sized companies in the north-western part of Switzerland. They cooperate regularly in collaborative innovation projects one of the products won the Swiss innovation prize 2004 , joint marketing and capability development. The core idea of the Virtuelle Fabrik is to combine the best capabilities from different partners according to the specific project needs. This can be for example design, mechanical components, mechatronics, and electronic controls for a special machine. To this end, the network has developed sophisticated capability management mechanisms. In an independent assessment, the functional capability profile of each company is evaluated and made available to others and especially brokers that develop new orders. In a joint strategy process, the network identifies interesting target markets and the required capabilities needed for them, which in turn determines selection criteria for new network members. Project capabilities such as project management are regularly trained. Based on the experiences, the University of Applied Science for the region, itself member in the network, has developed a master in virtual project management. Similarly, the network agreed on a common collaboration platform and standardised key engineering tools. Essential for the functioning and success of the network and a continuous challenge to develop and maintain are the dynamic capabilities. In order to spot new business opportunities, the network employs a broker, but also trains sales personnel from member companies to identify possible joint projects.

40 0

Members meet biweekly to discuss potential projects, define teams for bidding, and agree next steps. The broker, but also the member companies have a good view of the partners capabilities based on the profiles, regular exchanges and visits, and joint project experiences, and thus can select the most suitable team, but also identify and address capability gaps early. Since collaboration processes and systems have been predefined in the network, team building and becoming operational is usually a fast process.

Capability management through investments While many capabilities are essential for a supplier to own in order to have the right to play, some bring additional value to the customer such as specific facilities or technical competences. If collaboration is no long-term solution, investments are required to build such capabilities.
Gap of single project view

Value for project w/o investment

Investment needed

Value for project with investment

Figure 12: Investment gap

41

Such investments should be in the interest of both customer and supplier, but two main issues often make the investment decision difficult: The investment needed exceeds considerably the value gained (e.g. in productivity, quality, cost reduction) within a single project, though the payback across several projects can be considerable Who should pay for the investment, and how should value gains be allocated As in the case of business models, there are no simple solutions for these issues. As recommendations, the following points have proved useful: Reliable long-term collaboration eases investment decisions for mutual gain. Sensible value improvements through investments do by far outweigh short-term price haggling, as for example, the case of Toyota and their suppliers shows. Openness in product roadmap and supplier development plans reduces the risks of wrong investments further. Especially in mechatronics, investments should be general enough to serve several application domains. Suppliers should thus invest rather in technological and project competences rather than in deep domain and system understanding or specific facilities. Other industries show that for some non-differentiating components leverage of investments even with competitors makes sense. In almost any case, the customer should have high interest in the supplier leveraging the investment across application domains in order to benefit not only from economies of scale, but also in economies of experience.

42

3.5 Conclusion
This chapter discussed a number of principles and practices of capability management in collaborative innovation based both on the workgroup results and an external practice view. In collaborative innovation, the capability view becomes even more important than in traditional subcontracting decisions, a suitable capability profile of partners enhances the competitive advantage e.g. through innovativeness, product performance or cost position. To be able to judge requirements, OEMs need to position the role and responsibilities of the supplier in order to derive the required capability profile. This should not only include technical competences, but also project capabilities, and dynamic capabilities to adapt to and drive change and it should not only include the supplier, but also look at the necessary capabilities at the OEM to manage and support such projects. Capability assessments are useful to select new suppliers or to evaluate directions for supplier development, but should be applied with consideration for their limitations. Capability management approaches are thus more important to detect gaps early and to make up for them especially through collaboration.

43

44

4 CHANGE MANAGEMENT
4.1 Introduction
OEMs are increasingly looking for technical expertise from suppliers. Collaborative innovation extends the interface between companies. Innovations come with high uncertainty and consequently organisations have to revise their plans because their environment has changed or organisations themselves have a new understanding. Product data is constantly changing and new versions emerge. Inconsistency lies in wait. Changes are inherent to product development, which, in essence, is working on a product model that is evolving through a constant flow of changes. There are however three kinds of problems, that tend to get more serious in co-development: Different parties involved in the process maintain distinct copies, which become inconsistent if changes are not recorded carefully. Changes late in the project are many times more expensive than changes early in the process. Changes may have effects through interfaces and thereby cause new inconsistencies. The purpose of change management is to handle changes in a controlled way in order to reduce development cost and time to market and to make sure that the product meets the customer requirements. This chapter deals with change management. How to manage product data and the exchange of change requests and versions in different phases of the project? What makes change management between organisations difficult and what improvements are attractive for the Dommel valley?
45

4.2 Change management in collaborative innovation


Change management is not new. In fact, every organisation has some form of process to handle changes to technical product data. But when different organisations need to develop jointly, the change management processes often appear not to be compatible. Even worse, the habits coming from their own processes may cause wrong assumptions, which only become evident when consequences become painfully clear later on in the project. To avoid these problems organisations must agree on how to handle changes. The easiest way seems to refer to a standard in change management. In practice, however, this is difficult. The impact on the internal operations could be too large, for instance if companies invested in their structures and tooling. That is why this chapter points out simple arrangements between organisations with minimum changes to their processes. There are a number of other issues related to change management. Keeping overview is identified as a challenge when more independent organisations are involved. Despite local change management efforts, the total time and costs needed may overrun planned budgets. Copies of TPD roam the supply chain. There is a need to synchronise these copies. But tracking and tracing TPD versions and change requests is difficult due to tooling incompatibilities. Standardisation is desirable but difficult to implement. Not only tooling but also processes are incompatible. Companies handle changes differently; their concepts are different (e.g. whether or not requirements are part of TPD). Handling changes is dependent on the phase of development or sustaining. There are different opinions on when to freeze functionality and when to defrost. Some organisations use prototypes, others use paper for
46

specifications. The status of these different forms of specification could be confusing. Sometimes responsibility for TPD maintenance is divided over parties, sometimes shared, sometimes all responsibility is with the OEM, sometimes with the supplier, and sometimes it is linked to IP-ownership. There is a need to minimize overhead induced by change management. Developers tend to first fix the system and then calculate the cost. Enforcing change management procedures is difficult. Perhaps change management is too formal. Communicating changes takes time, especially when more organisations are involved. Although informal communication is encouraged to improve change management, there is a need to draw a line. The main problems coming forward in the Change Management working group were: How to keep data in both PDM systems consistent, How to keep overview, How to manage changes with minimal additional effort. The best practices, proposed and discussed to solve those problems were: Strategic CCB System architect Fast track procedure Informal communication The following section will discuss these best practices in detail.

4.3 Best practices in change management


Questions we would like to answer in best practices are: What are the dos and donts of change management? What are the pitfalls and the ways to avoid them? How do companies handle issues now, what is their experience and do they have

47

instruments? During the sessions change management practices were discussed and the best were chosen. Change management is part of configuration management. Configuration management is the process of managing a companys product, facilities and process by managing their requirements, including changes (change management), and ensuring that results conform in each case. In other words Configuration Management is the approach to keep all documentation consistent during the product life cycle and to keep the physical product instances and the execution of processes consistent with the documentation. Consistency means that each design document, product instance and process instance conforms to its requirements. Inconsistencies cause errors, delay and avoidable cost. Change management is not a purpose in itself but a means to enable a company to fulfill customer needs effectively and efficiently. In this document CMII (pronounce CM-two) will be referred to as industry standard for change management. This means that we lend concepts and terminology from this standard, but not that we propose its full implementation as best practice. Best practice strategic CCB One change can have multiple effects. It can impact hardware, software, documents, systems, designs, etc. Many parts of the organisation may be involved like R&D, engineering, logistics, purchasing, production, service or marketing & Sales. If these organisational functions are spread over OEM and suppliers, the chance of unforeseen change costs is even greater. In the sustaining phase large cost may be incurred because stocks of expensive components become obsolete. To be sure that all possible impacts of changes are detected, all departments that may be involved must be represented in the CCB. This however makes the process very inefficient, because in most changes only few of these parties really are involved.
48

The working group proposed to split the CCB in a Light CCB and a Strategic CCB. The Light CCB should meet frequently (like weekly) and consists only of the system architect, the project leader and the QA officer. In the Strategic CCB all parties should be represented, but it meets less frequently. All change proposals are handled by the Light CCB, which decides when changes must be passed on to the Strategic CCB. The actual implementation of accepted change requests must be handled by a separate body, since this does not require the capabilities and authority of the CCB members. CMII In CMII a change is initiated by a problem report specifying the problem, proposing a solution and estimating the cost en benefits of the change. The change process consists of three phases, performed by three functions: Analysis by a Change Specialist: check whether the problem report is sufficiently clear, Business decision by a Change Review Board (CRB): decide whether and when the change should be implemented, Implementation controlled by a Change Implementation Board (CIB): issue and monitor the change order. The function of change specialist corresponds to the proposed Light CCB, while the CRB corresponds to the Strategic CCB. The CIB separates the implementation from the strategic business decision In collaborative innovation projects there should be a projectCRB for changes touching the interfaces between the companyresponsibilities. Changes that are local to a company design task can be treated by the company CRB.

49

The strategic task of a CRB is to move changes upfront in the product life cycle. Their primary instrument is to decide when to implement a change: now or in the next product generation. The last option implies that the change can be early in the next life cycle and thus will be cheaper to implement. If the change is implemented now, part of the decision is whether the problem should have been detected earlier and who is to be accounted for overlooking the error. In that case proper measures in the product development process should be taken to make sure that the kind of problems will be detected by proper review processes in the proper life cycle phase. At times of emergency the strategic CCB may assemble at once. This may appear to be impossible. In practice a person may walk members in sequence to get a decision. A better way however is to collect the individual response by electronic means. First factor for the strategic CCB is profitability for the company. Every change costs money and resources, both of which are limited. A guideline is that every change must have a ROI within 1 year. Longer periods may be used to avoid show stoppers. Second factor is deadline. The strategic CCB decides if and when a system will be changed. A decision could be that the request will be honored in a next generation, outside the scope of the project but strategically important for the companies. Note that arranging a strategic CCB in a project makes collaboration prepared for difficult decisions. There is no need to escalate a disagreement.

Product improvement board at FEI . FEI has installed a Product Improvement Board (PIB) for strategic decisions: assess, validate, choose alternatives, and planning. A CCB monitors execution of the changes
50 0

System architect The systems architecture defines the high level components of the system and their interfaces. A good architecture makes the complexity of the system manageable, reduces development cost and assures maintainability and extendibility of the system. In fact the system architecture is a complex set of rules for interfaces between the system components (see figure below)

1
Systeemarchitect

3
Figure 13: Interfaces in system architecture

In a narrow sense, the systems architect is responsible for design and enforcement of the systems architecture. He also is responsible to make each products architecture fit in the product portfolio architecture (cohesion in products for different customers). In a broad sense he: Is a person with technical responsibility, optionally supported by engineers responsible for an interface. Decomposes the system in sub-systems. Defines and guards interfaces. Also agreements between other organisations affecting external interfaces. Guards system functions and performance. Is acquainted with customer requirements and environment restrictions. Plays a key role in keeping the design(s) consistent.
51

Is involved in integrating the sub-systems. Is the contact person for sustaining. Is preferably not the project manager at the same time. Is appointed in all CCBs and is not allowed to have personal interest in changes. Is named in the agreement. In some companies the system architect is also know as technical coordinator or apparaatvader. A system architect is a senior function, difficult to find. Knowledge transfer could be a risk when he is leaving a company or when he is over-occupied. A system entering the sustaining phase may have difficulty getting enough time from the system architect when he is involved in new and perhaps more attracting developments. To reduce this risk the company sustaining of the system preferably provides the system architect. Fast track Current CCBs are flooded with change requests. As a result long waiting lists of unprocessed change requests cause unwanted long lead times for changes. The fast track is proposed as a remedy for this.

Fast track in CMII In CMII about 75-85% of changes walk a fast track. The processes in CMII are not entirely comparable but it gives an indication of the ambition to relief the CRB.

52 2

Company A

Full CCB
CRs with business impact

15% - 25%

75% - 85%

Development staff

Light CCB
Handling of CRs Update CR status & new CRs

Repository for CRs

New CRs

Figure 14: Fast track procedure

Although all decisions need to be formal and traceable, there are differences between smaller and larger changes depending on cost and impact. The definition is a matter of agreement between companies. The proposal is to let the Light CCB (or even the change specialist) classify changes as small or big. Large changes are passed to the Strategic CCB, small changes are passed directly to the creator, who takes care for implementation. In the project plan explicit budget for change activities should be specified, especially in early project phases. Late changes seldom are small and must be subject to budget assignment by the CRB. About 75-85% of changes should walk the fast track.

53

In case of emergencies where immediate assembly of the CCB is not possible, approval for the change can be obtained by electronic communication. Informal communication Informal communication between engineers is often suppressed by formal procedures, because it tends to result in the 'implement first, propose later' type of changes. On the other hand, informal communication is needed to maintain a common view on the product and to find solutions form problems fast en efficiently.
CCB Development staff

Company A

Repository For CRs

Project CCB

Company B
Repository for CRs

CCB

Development staff

Figure 15: formal communication

54 4

Company A
CCB System Arch. Development staff

Repository for CRs

Company B
Repository for CRs

Determine this interface beforehand

CCB

System Arch.

Development staff

Figure 16: informal communication

We suggest having a project CCB (light) for alert, but formal handling of changes in the project. An important channel for informal communication is a direct interface between the system architects of the collaboration companies. These architects should also encourage direct communication between engineers of different companies for specific problems. They should guard that this informal communication is only to generate the problem report including the detected cause and the proposed solution. The decision to implement should be left to the project CCB. As long as a document has not been reviewed, changes can be implemented directly by the creator without and published in a new version, without any further action. It is important to organise the process such that documents are communicated to relevant stakeholders before they are submitted for review, in order the detect inconsistencies as early as possible and correct
55

them without formalities. Also these stakeholders must have time budgeted for commenting on other designers work, to encourage them to actually spend effort on this activity. When the review process has started, changes must be documented in a problem report (by the reviewer) and a change note (by the creator). Change specialist and CRB need not be involved. Informal communication at Bosch Rexroth Bosch Rexroth recognizes the need for informal communication. In projects with OEMs they filter technical issues before turning the issue into a change request. The informal communication is restricted to informing the issuer, checking opinions and helping to formulate the problem.

When a document has been released, change should be formally documented en passed to the change specialist, who takes care for further action. For the weight of the change it makes a difference whether the product, specified in the document, has been released or not. Review processes should be defined formally, since they are the main instrument to prevent problems later in the process. Formal communication starts after a formal decision. The communication between companies can be complicated by conflicting interests. Before changes are committed a formal decision is needed. This decision is easily communicated to third parties.

56 6

4.4 External perspective


The best practices as described above will indeed ease the pain caused by the indicated problems; however, they still are point solutions. Change Management fits in a bigger picture. CM should be considered as a basic product development capability and be deployed as a lever for process improvement. Product development and change are two sides of the same coin. One side is the product model to be developed by a team of specialists, from an initially generic and abstract idea into a concrete and detailed specification of the product, including all design considerations and all processes needed to sell, manufacture and sustain the product. Also the product model should be fit for reuse in future product versions and variants. The other side is the continuous flow of changes, manifested in series of versions of partial product models. The purpose of change management is to maintain, at all times during this evolutionary process, a consistent subset of versions to enable each designer to perform his individual and collaborative design tasks as efficient en effective as possible. The central concepts to define consistency in evolving models are version and status. Versions embody the stepwise improved specification of product components and aspects. Status indicates stepwise increase of affectivity of each version from 'for information only' to 'release for full intended application'. Status is a powerful instrument to coordinate concurrent design activities, to speed up the process work flow and to monitor real time progress of the project. The prime principle of change management is that changes late in the product life cycle are many times more expensive than early changes. Therefore the primary task of Change Management is to force changes upfront the product life cycle. This can be achieved in two ways:
57

Encourage changes in early phases. Use 3D visualisations of the product Evoke intensive communication between peer designers Encourage change as a creative game Keep change action free from administrative burden Prevent changes in late phases: Plan distinct create and review tasks Stimulate thorough review of partial models before release Postpone improvements to next product generations Identify causes of errors Establish accountability for errors Take action to prevent identified errors in next projects.

CMII CMII (Configuration-Management-two) has evolved as a widely accepted industry standard. It describes in detail the principles, approaches, processes and forms as required for maintaining consistent complex product configurations. Certified CMII consultants, as well as course programs to educate them, are available to help implementing this standard. Of course there is no single best solution for every situation. Each company and each project requires its specifically tailored set of CM procedures, but it seems wise to build on the CMII experience when setting up new product development projects. In collaborative innovation projects some requirements for Change Management should be specified and agreed specifically for each project: A change control process, defining how changes are identified, assessed and implemented,

58 8

Conventions for version and status coding, defining what document versions can or must be used for what design task at which point in the project, A (preferably digital) project collaboration space holding the single source of all shared design document versions, A shared set of ICT-tools to support the project and make it fun to follow the rules. Looking back on how IT, during the last decades, enabled an unforeseen boost of manufacturing performance, resulting in price and lead time reductions with one or two orders of magnitude, there is strong reason to believe that a similar boost of performance will be going to happen in product development in the next decades. The average time from technological innovation to delivered product will be decimated and the number of product variants derived from the same technical principle will explode, in order the meet new customer needs faster and better tailored to individual requirements.

4.5 Conclusion
Three best practices seem to converge to organisational arrangements of CRBs. A strategic CCB is needed to keep overview of supply chain wide changes. A Fast track is needed because a strategic CCB is difficult to assemble. Finally a system architect is needed to decide what track to take. Considering the amount of avoidable corrective activities and unnecessary procedural delays in current co-development processes, there is room for reduction of development cost with 50% and reduction of throughput time with 75%. Change management is the process where corrective actions and delays can be detected and eliminated. 4Currently available PLM software is an enabler to implement:
59

Intensified communication between developers, inside and between companies. Extensive recording of change events without additional effort. Better change procedures in a way that the system encourages following the rules rather than enforcing them: making the best way of working also the most attractive way. While the technology is in place to share product models between companies, this technology has been developed from an inside company perspective. Best practices of how to implement the technology for co-design networks and even more best practices of how to reorganise the development process so that the functional capabilities of the ICT are fully deployed in the actual product creation process, are still to be developed and implemented by learning processes. The recommendation is to agree at the start of the project on the change management procedure and to identify the primary contact for change proposals and approvals at both sided. A joint CCB (supplier and OEM) could be a practical way to address the issue, and prevent miscommunication. Discipline at both sides is crucial to prevent misalignment in the change archives; a single common document vault could offer an appropriate solution.

60

5 TOWARDS COLLABORATIVE INNOVATION


5.1 Achievements so far
The aim of the CPIM project is to exchange best practices and insights on collaboration and commitment for new forms of collaboration. In this guide book the characteristics of a new form of collaboration, labelled collaborative innovation have been discussed and the implications for both OEMs and suppliers have been identified. The focus was on three improvement areas: The business models, which can be used to govern this new form of collaboration The capabilities required at both OEM and supplier side to make this type of collaboration a success The change management practices required for collaborative innovation In the CPIM project for the first time OEMs and suppliers were sitting at the same table and exchanged their views and experiences on collaboration. This increased the mutual understanding, made controversial issues more explicit, and led to mutually agreed best practices and check lists. So what is still missing? The proof of the pudding is in the eating. The identified dos and donts and best practices should be implemented in new collaborative innovation projects. Identifying new business cases with OEMs and suppliers proved to be difficult in the context of this project because competing suppliers were sitting on the same table.

61

In next section we discuss in more detail for the improvement areas business models, capability management, and change management what needs to be done.

5.2 Next steps for realizing collaborative innovation


In this section we discuss what steps to take to achieve the vision on collaborative innovation as discussed in chapter 1. Business models With respect to business models it is important to find solutions to the controversial issues identified in section 2.6. An important precondition to resolve these issues is trust. Only in trusting environments one can expect that companies will change and find answers to the controversial issues of riskreward balance, financing of specialisation and intellectual property. To enhance trust, companies should jointly work out a memorandum of understanding at the start of each new collaboration project (see appendix 6.3 for a memorandum of understanding checklist). Companies should not only preach collaborative innovation but also practice it. The check lists on collaborative innovation (see section 6.1 and 6.2) help to monitor if companies are really moving in the direction of collaborative innovation. As we have seen in section 2.3, different business models can be applied in collaborative innovation. There is no single solution. We are still on the forefront of experimenting with and finding suitable business models. The first experiences with risk-reward models are promising yet these models are certainly not a panacea for every collaboration project.

62

As next steps we recommend to: Use the momentum of the CPIM project to continue experimenting with forms of collaborative innovation and associated business models. Use these new projects to find new ways to deal with controversial issues such as risk-reward balance, investments in specialisation, and intellectual property management. Jointly (both OEMs and suppliers) evaluate new collaborative innovation efforts and associated business models. Work towards standard contract elements for the different business models, which allow fast setting up of collaborative innovation projects Set up an investment fund for high risk collaboration projects. Set up a guarantee fund for suppliers that can be used in high risk collaboration projects. This guide book provides important starting points for designing new collaborative innovation initiatives. Capability management The CPIM case projects have shown that many capabilities for collaborative innovation are in principle available in the region. However, they are not evenly spread and systematically exploited, but depend considerably on individuals and good constellations. Important capabilities to be developed, besides technical capabilities, are the project and dynamic capabilities. External examples show that these capabilities can be developed to strengthen not only individual companies but the region as a whole Selecting people with the right capabilities and chemistry between people who need to collaborate are crucial for
63

collaboration success. However, to avoid that success is just a stroke of luck capabilities should be inscribed in suitable processes, organisational designs and decision methods. While some companies take individually steps towards developing such elements, joined alignment and exchange are crucial to reap regional network effects. As next steps we recommend to: Invest in specialization, suppliers should choose and be top in what they choose, and collaborate with suppliers with complementary capabilities Build a regional support programme for developing and assessing project management and dynamic capabilities (e.g. facilitating project management courses specifically for collaborative innovation). Discuss product roadmaps with related capability needs between OEM and suppliers Conduct project portfolio planning in order to develop and strengthen specific capabilities across several projects

Change management Collaborative innovation poses severe challenges to change management. Considering the amount of avoidable corrective activities and unnecessary procedural delays in current codevelopment processes, there is room for reduction of development cost with 50% and reduction of throughput time with 75%. In this guide book four best practices have been worked out to improve change management: 1. Strategic CCB, 2. System architect, 3. Fast track procedure 4. Informal communication.

64

These improvements mark an important contribution to realizing collaborative innovation. These best practices are at best however point solutions. Change Management fits in a bigger picture. CM should be considered as a basic product development capability and be deployed as a lever for process improvement. The mechatronics industry in Dommel valley could benefit much from a combined effort to implement a regional codevelopment data sharing infrastructure and sharing change management practices. Such an advanced co-development environment alone could enable to double the number of new products developed in the region within a five years period. As next steps we recommend to: Agree at the start of every joint development, on the change procedure to follow and the contact persons at both sides, and have the discipline not to bypass this structure; possibly having a joint CCB. To implement the four best practices (strategic CCB, system architect, fast track procedure, and informal communication) in collaborative innovation projects and jointly evaluate the working of these practices Set up an advanced IT infrastructure, which enables the sharing of product data in collaborative innovation Build on the CMII (Configuration-Management-two) experiences when setting up new collaborative innovation projects.

65

66

6 APPENDICES: CHECK LISTS


Check list collaborative innovation OEMs Check list collaborative innovation suppliers Check list memorandum of understanding Check list business models Check list capability management Check list change management Check list change management best practices

67

6.1 Check list collaborative innovation OEMs


Check list collaborative innovation OEMs Core competencies be clear what are core and key competencies and act accordingly. Source core competencies on the lowest possible level and key competencies on the highest possible level. Allow suppliers to re-use knowledge on key competencies in projects for other OEMs. Define no fly zones in advance. Reorganize departments responsible for key technologies. Consider moving engineers to key suppliers, reorient them to monitoring subcontracted development work on key technologies, or involve them in the development of core technologies Develop long-term collaborative relations with a limited set of world class system suppliers. Subcontract development work on a higher level and give them responsibility for product life cycle management. Invest in these collaboration relations by transferring knowledge and dont stop when problems occur but work together to solve these problems. Develop system architectures that enable modular subcontracting or outsourcing. Develop excellent sourcing, project management and review techniques to manage collaborative innovation. Please note that the best technical experts are not necessarily the best project manager. Share strategic information on technology and product roadmaps and market forecasts with key suppliers, which are involved in risk taking forms of collaboration

Reorganize

Collaboration

Knowledge transfer

System architects Capabilities

Share strategic information

68

Check list collaborative innovation OEMs (continued) Closed book Do not stick to open book calculation but if possible determine the value of key functions (bench mark with competitors) and ask suppliers to develop these functions for a target price with agreements on price erosion. Fight the Not Invented Here syndrome among engineers and convince them of the positive sides of collaborative innovation. Give them the opportunity to visit the suppliers and see the areas they are excelling. Establish clear lines of communication with suppliers. Shield suppliers from organisational complexity

NIH syndrome

Lines of communication

69

6.2 Check list collaborative innovation suppliers


Check list collaborative innovation suppliers Specialize Choose a limited set of core competencies and be top in what you choose. Examples of core competencies are motion, vision, frame building, robotics. Invest in the development of these core competencies. Make sure that this knowledge does not reside by one single expert but with a group of experts. Apply the build core competencies in projects with different OEMs. Aim is to create synergy from applying knowledge in different settings. Proactively bring in knowledge and experience in one domain in projects in other domains. Take ownership of subassemblies instead of monos and take ownership for the product life cycle. Develop the required multidisciplinary capabilities or work together with complementary specialist suppliers. Engage in risk-reward business models with care. See investments in facilities and capabilities as strategic investments which need to be earned back over several projects. Develop a continuous improvement mindset with engineers. Not just tell, but show possible improvements to OEMs. Develop sufficient mass to be able to develop required capabilities (see specialisation), to increase buying power and to realize economies of scale. On the long term it is expected that smart design, automation, efficient supply chain management are not sufficient to beat the market price erosion. Build financial resources to be able to invest in capabilities, facilities and engage in risk taking by engaging in target price business models (value of function instead of open book calculations) or by attracting external funds.

Cross-fertilization

Ownership

Entrepreneurship

Continuous improvement Critical mass

Financial resources

70

6.3 Check list memorandum of understanding


Memorandum of understanding Motives Description of reasons behind collaboration Description of added value brought in by collaboration partners Description of long term objectives of collaboration (commitment to the future) Description of objectives and deadlines Description of expected obstacles Description of when project will be terminated Description of time plan (deadlines, milestones, dependencies) Description of possible hick ups and impact on time plan Description of who is doing what Description of who is responsible for what Description of who is reporting to whom Description of communication structure in particular for change management Description of means (personnel, capabilities, facilities, financial resources) that are needed for realizing the objectives Description of how mismatches between required and actual means are being solved Description of business model that is used to govern the collaboration (time-material, amortization, fixed price, riskreward, etc.) Description of expected rewards and risks Description of investments needed for collaboration Description of how rewards, investments and risks are divided over partners Description of who owns IP and TPD Description of possibilities and impossibilities (no fly zones) to re-use knowledge Description of licensing rights

Commitment Objectives

Planning

Decision making

Communication Means

Business model

Risks, investments and rewards Ownership

Source: Handboek Strategische Allianties, Geert Duysters et al.


71

6.4 Check list business models


Check list business models Time material Fair tariffs? Have agreements been made on billing of value adding services such as TPD management, supply chain management, etc? Have agreements been made for the situation if production goes to another supplier? Are specifications detailed enough and clear? Are specifications stable? Can the development be divided into different stages? What is the track record/ experience of the supplier in performing these type of activities? Is the used technology stable, mature? Can the costs be monitored by the supplier? Can the cost owners be influence by the supplier? Have agreements been made on the re-use of knowledge and IP? Are the cost targets realistic? Can the costs be monitored by the supplier? Can the cost drivers be influence by the supplier? Is it possible to determine the value of the function? If so consider closed book calculation to avoid lengthy discussions on cost prices Are the rewards sufficiently in line with the required risks and investments of the supplier? Is there enough management commitment on the side of the supplier and OEM? Are market forecasts been shared with suppliers? Is knowledge transfer arranged for? Have agreements been made on the re-use of knowledge and IP? Can the added value be determined and monitored? Is the IT-infrastructure capable of monitoring the usage of certain functions (pay per use)? Have agreements been made on exclusive use of delivered technology?

Amortization Fixed price

Cost down

Risk-reward

Value-based

72

6.5 Check list capability management


Check list capability management Have a long term orientation in supplier selection and Capability collaboration strategy Make the strategic value of knowledge/ capabilities explicit Define no fly zones in an application area (only if really necessary) and enable suppliers to become specialist in a specific technology area Negotiate what to do with the costs of competence development ! Operational people involved in strategic issues Be explicit about expectations on capabilities that are Assessment required for the role in the project Evaluate interest in capabilities and willingness to learn as much as actual capability level Supplier should be able to show he has/ has access to the capabilities needed, even if not in house but through partners Evaluate supplier resources at the start of the project Investigate the capability level of key personnel ! Underestimation of required capabilities, overestimation of own capabilities Define a clear architecture with separate modules and Project setup clear interfaces (patient table was unmanageable project due to many interfaces) Align processes & definitions/deliverables Involve supplier early, even if they only do manufacturing and maintenance, so they can develop understanding for project and check consequences early Establish steering group with decision makers on the appropriate level, project sponsor on a high level Organize for learning get acquainted to way of working, concepts used, knowledge transfer between partners Develop a common language try to understand each other, do not assume that they do ! Eagerness to get started (start too soon)

73

Collaboration

Long-term capability maintenance

Plan for team building (e.g. team kick-off) to get to know each other and to understand their roles Work in a single physical location at least on several occasions for a week Establish and live full openness / transparency with partners Look in each others kitchen for learning, but also for trust building Look after trust (outcome of openness, commitment, etc) Have commitment to make it a success on management and team level, do not stop at the first failure Monitor collaboration to see guard fit between partners (including chemistry between people) ! Too focused on quick wins (short term orientation) Make sure that key persons stay allocated to the project and at the same time make sure that there are people that can replace this person ! Be too open (spill over of knowledge) ! Be too protective regarding exchange of knowledge ! Be too dependent on key persons (ran over by bus test) ! No embedding of knowledge that is build up by persons in organization

74

6.6 Check list change management


Check list change management Agree on what products are to be developed and how to identify them (preferably just sequence numbers) Agree on the main architecture of the product Agree on how to identify components to be defined during the project (preferably just sequence numbers) Agree on how to specify the bills of material Agree on what documents are to be delivered Agree on the method of numbering versions of products, BOM-lines and documents (preferably just sequence numbers) Agree on the sequence of status levels to be used for the different types of products and BOMs Agree on the sequence of status levels to be used for the different types of documents (preferably meaningful names) Agree on the kind of activities/purposes a product- or document version can be used for depending on its status Agree on the place and medium to store all original document versions, Agree on whether document version originals are shared in native format (CAD, Word, Excell etc.) or in view format (recommended) (JT, pdf, etc.) Describe how every design document is informally commented by peer engineers of different partners Agree on how every design document is formally reviewed by defined specialists Plan commenting and reviewing tasks and allocate time for them in budgets Appoint a product father to the project Describe what changes can when (on basis of document type and status) either be handled by creators or passed the CRB and who should decide Set up a project CRB and its interfaces with partner company change processes, Define the responsibility for change implementation Agree on how change cost are allocated to project or partners

75

6.7 Check list best practices change management


Check list change management Strategic CCB Make arrangements for updating products during production and sustaining. Changes tend to have large impact in these later stages of the product life cycle. Attendants must have enough decision power Include the system architect. The strategic CCB decides on the moment of implementation and market introduction Profitability is the major consideration in decisions taken by the strategic CCB. As a rule of the thumb use a one-years ROI. Other considerations are: is it incidental or structural, is safety concerned, are specifications not met or is it only an nice to have improvement. The system architect is may filter change requests before submitting it to the strategic CCB. ! Dont try to fix everything in the current release. Consider next generations. ! Dont change specifications without revisiting the requirements. ! If design and production are within one company, the interface (specifications) may become invisible for the manufacturer.

76

Check list change management System Architect Is a person with technical responsibility, optionally supported by engineers responsible for an interface. Decomposes the system in sub-systems. Defines and guards interfaces. Also agreements between other organizations affecting external interfaces. Guards system functions and performance. Is acquainted with customer requirements and environment restrictions. Plays a key role in keeping the design(s) consistent. Is involved in integrating the sub-systems. Is sustaining Is preferably appointed by the sustaining company. Is appointed in all CCBs Is named in the agreement. A products life cycle can be 10 years arrange for knowledge transfer. ! Is not allowed to have personal interest in changes. ! Is preferably not the project manager at the same time?

77

Check list change management For fast decisions assign a light CCB with at least the Fast track project manager and system architect. For more difficult or risky decisions assign a full CCB with representatives from needed disciplines and companies. Fine tune procedures and responsibilities in a project plan. ! All decisions need to be formal and traceable. Balance formal and informal communication; both have Informal their merits. communication Use informal (off the record) communication for clarifying problems and avoiding bouncing of problem reports and change requests. The preferred contact person for formal and informal (technical) communication is a system architect. Make arrangements on formal communication between companies: procedures, forms, responsibles, etc. Make internal change management process transparent for your partners. A clear set of requirements significantly reduces the amount of formal communication. ! To many developers formal communication is not attractive. Even more so if the pressure to release is high. Keep change management easy and fun, ICT may help. ! Investigating possible causes of a problem take time! Make it a formal decision first. ! If a change management tool training takes two days it is not easy to use. Formal structure Define the points of contacts for change proposals and problem reports (during and after development) Agree on the communication and decision process Consider a joint CCB Make clear why discipline is needed

78

COLOPHON
Date : Version : Project reference: TI reference : Access permissions : Editor : Company : Author(s) : Reviewers: Acknowledgments: March 2007 Final CPIM TI/RS/2007/008 Public Edward Faber Telematica Instituut Hermann Loeh (CeTIM), Henk-Jan Pels (TUE), Freek Ebeling & Edward Faber (TI) John Blankendaal (BOM), Alef Schippers (PMS), Geert Duysters (TUE) and Wil Janssen (TI) Many of the results and ideas originated from discussions with different people of the participating companies.

Copyright 2007 Telematica Instituut Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from or via Telematica Instituut (

http://www.telin.nl).

79

80

Das könnte Ihnen auch gefallen