Beruflich Dokumente
Kultur Dokumente
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
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.
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.
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.
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.
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
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
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
Value
Difficult to implement: administrative burden requires mature and secure IT infrastructure. Maybe too costly on long term
13
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
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.
Uncertainty is very high. No product in mind or available in the market Uncertainty is medium / Similar technology available in other products`
Low Volume
Jobbers
High Volume
Uncertainty is very low / Production driven (repeating assembly) Engineering change control only
Technology Development
Alpha / Concept
Regular production
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.
18 8
other words: the costs and benefits for both supplier and OEM should be in balance (see Figure 3).
High
REWARDS
Low
RISKS
High
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
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
Develop and work with those partners that give competitive advantage 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.
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
27
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).
Low Volume
Jobbers
High Volume
Technology Development
Alpha / Concept
Regular production
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
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 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
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
Collaborative project management Well defined development process implemented in practice 3D-CAD Modeling Inter-organizational collaboration platform
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
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.
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
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
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
Investment needed
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
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.
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
New CRs
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
Project CCB
Company B
Repository for CRs
CCB
Development staff
54 4
Company A
CCB System Arch. Development staff
Company B
Repository for CRs
CCB
System Arch.
Development staff
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
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
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.
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
67
Reorganize
Collaboration
Knowledge transfer
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
Cross-fertilization
Ownership
Entrepreneurship
Financial resources
70
Commitment Objectives
Planning
Decision making
Communication Means
Business model
Cost down
Risk-reward
Value-based
72
73
Collaboration
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
75
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