INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001 TRANSFERRING DESIGN RESEARCH INTO ROLLS-ROYCE

Transcription

1 INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001 TRANSFERRING DESIGN RESEARCH INTO ROLLS-ROYCE S S Wiseall; J C Kelly; T P Kelly Keywords: Capability acquisition; technology transfer 1 Introduction Some ten years ago Rolls-Royce decided that to strengthen its capability acquisition strategy it needed a fully co-ordinated university research programme. This was to be focused in a relatively small number of academic centres whose commitment in each case would be reinforced by a long-term business agreement with the company. The outcome was the concept of the University Technology Centre or UTC [1]. It is flattering to note that the UTC concept is currently being copied closely by GE Aero Engines (Rolls-Royce s prime competitor in the global aero engine market). This fact has been acknowledged explicitly by David Wisler of GEAE [2]. The Design University Technology Partnership is a recent development of the basic UTC model in which two companies (BAE SYSTEMS and Rolls-Royce) and three universities (Cambridge, Sheffield and Southampton) have come together to research matters of common interest in the field of engineering design. The prime themes of the UTP research at present are knowledge management, human factors creativity and innovation, and design optimisation. Much of the research is destined to appear in the design systems of the two companies by means of technology transfer. This paper will take a holistic view of technology transfer and discuss its nature based on the experience gained with the UTCs. 2 External influencing factors External influencing factors over which the company has little control, but set in the context of transferring design research, can be categorised under the headings: Politics; Economics; Social and Technical, (PEST) [Table 1]. Many of these factors are influencing the nature of the existing UK based UTC models. Recent examples of this include the collaboration within the Design UTP and the emergence of a CFD Development Community which involves a collaboration between five UTCs. Globalisation will become of increasing importance as the company spreads capability and its acquisition around the world. 3 Technology transfer Assessments of UTC-RR performance invariably identify technology transfer as the area offering the greatest opportunity for improvement [3]. There are many mechanisms by which technology transfer is encouraged and planned to take place. At the working level these include people transfer in either direction, project categorisation methods to identify appropriate technology transfer mechanisms and the use of simple check-lists as an active project management tool and for comparison across projects. As an example each Design

2 UTP project is encouraged to develop and maintain its own portfolio of mechanisms within a project management framework called a Potential Exploitation Plan [4]. Table 1 P.E.S.T. Analysis Politics Emphasis on education, training and mobility Science White Paper July 2000 University exploitation of Intellectual Property Competitiveness White Paper, Dec 1998 development of UK plc as a knowledge economy EU harmonisation laws, eg employment, Euro Social Environmental issues, eg noise, chemical pollution Ageing population Pressure for homeworking and part-time working Multi-skilling Multi-cultural work environments Economics Globalisation Productivity and man-power reduction Strategic partnerships, risk and revenue sharing partnerships, reduced number of suppliers Increased collaboration between suppliers Outsourcing of non-core activities, eg for IT services, agility of remaining core team Use of sub-contracting to manage fluctuating demand Frequent organisational change Technical e-business and knowledge management Growth and utilisation of computing power Internets and Intranets, knowledge re-use Standardisation and common methods High quality GUI driven Commercial Off The Shelf Tools (COTS) Integration 3.1 Process models capability acquisition and product life-cycle In the UTC Benchmarking and Performance Assessment Project undertaken by University of Leicester researchers for the past two years much attention has focussed on modelling the technology transfer process [3]. Their simple control box [input/process/output] model [Figure 1] highlights an important point. A distinction must always be made between the delivery of outputs from the university and the eventual outcomes that have a real impact on the company s business. Between the two lies some kind of translation process. STRATEGY EVALUATION COMMISSION RESEARCH TRANSLATION APPLICATION OUTPUTS OUTCOMES Figure 1 Control Box Model

3 Whilst the control box model has the virtues of simplicity, familiarity and acceptability within Rolls-Royce it also has one fundamental weakness - it tends to confuse the company s capability acquisition process with its gated product life-cycle process [5]. The distinction is easier to understand if we refer to a more elaborate model, [Figure 2] in which the horizontal capability acquisition process is seen to be orthogonal to the vertical product life-cycle process. Capability acquisition process Step One New product planning Full concept definition Product life-cycle process Science Applied science Focussed technology Validated technology Capability realisation Product realisation University Knowledge base Production Company Knowledge base Service support Step Two Disposal Figure 2 Capability Acquisition compared to Product Life-cycle The capability acquisition process involves embedding within the company all of the required human and physical attributes needed for a new technology to be ready to be applied whereas the latter process involves applying proven capabilities to develop a company s products and services. Capability acquisition can be thought of as putting the technology on the shelf ready for its use when needed. This model also emphasises the important point that the new capability could be applied at any or all stages in the product life cycle process. For example, a new knowledge-based engineering method and associated software could be specifically designed to improve the New Product Planning process. Inherent in the capability acquisition process is the assumption that risks associated with a new technology are reduced sufficiently so that it can be applied with minimal unknowns within one or more stages of the product life-cycle process. Capability covers many items ranging from facilities, design or manufacturing methods, IT hardware and software through to education, familiarity, experience, training, culture etc. Within Rolls-Royce Capability Owners are used to help establish research priorities and to monitor and operate the capability acquisition process in their field. As an example, the Rolls-Royce co-ordinator for the Design UTP is also the Design Capability Owner. Traditionally the domain of University Research is located towards the front end of the capability acquisition process and that of Industrial Research towards the latter part of the capability acquisition process. The term technology transfer can be confusing since one component of this activity occurs between the University and Industrial researchers and the second component, traditionally located within the company, is to complete the capability acquisition ready for its application within the product life-cycle process. It is only if this latter stage is completed and the new capability applied that the technology has any effect on a company s products or services. The application of the new capability can be in the form of

4 tacit knowledge, (expertise and skills) and codified knowledge, (data, equipment, computer models..) [5]. On this basis it is useful to consider technology transfer in terms of a two-step process. Step 1 is the capability acquisition process and Step 2 is the application of the capability in the product life cycle process. Success in Step 2 is the ultimate measure of the benefit of any research conducted in Step 1, both steps need to be measured. In practice there is a tendency to measure codified knowledge since this is more tangible. The measurement of tacit knowledge originating from the UTC can be difficult [5]. 3.2 Translation from research outputs to outcomes We can now return to the simpler control box model, [Figure 1] to emphasise that the translation process represents in fact the capability acquisition process downstream of the research outputs. Experience within Rolls-Royce has concluded that capability acquisition (Step 1 of technology transfer) has two important dimensions of acceptance and assimilation [Figure 3]. STRATEGY EVALUATION ACCEPTANCE COMMISSION RESEARCH APPLICATION ASSIMILATION OUTPUTS OUTCOMES ACQUIRED CAPABILITIES Step One Step Two Figure 3 Enhanced Control Box model 3.3 Acceptance Gaining acceptance for the results of a piece of design research can be thought of as winning over the hearts and minds of the key stakeholders. In a large company this can mean all of the key people who are influential in deciding whether the outputs from the research will become part of the fabric of the company s processes and/or products. The acceptance critical success factors include: Identifying who are the key stakeholders Building an open and trusting working relationship with the key stakeholders Frequent quality interaction with the key stakeholders Adequate risk reduction to attract internal company attention Active support from a senior company sponsor Active support from an internal company technology champion Often in large companies it is not always clear to University research groups who the key stakeholders are and what their level of influence is. In some cases there may be many key

5 stakeholders, eg for generic research potentially applicable in all stages of the product lifecycle. In this case the use of tools such as Stakeholder Analysis [6] can be helpful. The support of a senior company sponsor will also help in this case. Many of the acceptance factors are people centred and involve: trust, openness, frequency and quality of communications and attitudes to company problems. These combined with adequate risk reduction are all aiming to improve awareness and credibility within the stakeholder community. Where barriers do exist the support of an internal company technology champion who has the drive, energy and tenacity to overcome barriers often associated with change can be very helpful. In the UTC context these people are usually termed UTC co-ordinators. 3.4 Assimilation Assimilation in contrast describes the more mechanical set of activities within the Capability Acquisition process that ensures a piece of research work can be assimilated by the company into its: infrastructure; processes (including methods and procedures; working practices and tools) or knowledge bases, (eg for design, manufacturing or support). In the case of software, this also includes its computing portfolio, fully accessible to its potential users. The assimilation critical success factors include: Understanding of the pressures, constraints and existing practices within the product lifecycle process Understanding of strategies and planned company improvement programmes which may influence the research programme Conducting technology demonstrations that are close to real user problems Conducting technology demonstrations that can be readily replicated or adopted in the industrial applications environment Building in acceptable maintenance, support and development mechanisms A powerful mechanism to achieve the required understanding and successful technology demonstration is via secondment of people. There have been many cases in the past where acceptance has been frustrated by a lack of assimilation, and vice versa. Both activities are vital to be able to claim that capability has been fully acquired. 3.5 Trends in the university company interface In recent years there has been an increased pressure to shift the division of labour between the university and company consistent with the economic and technological factors in table 1. Traditionally the task of the university has been to do the research and hand over the results, or outputs to the company. It was the responsibility of the company from that point onwards to ensure successful acceptance and assimilation of the outputs. This translation stage, (acceptance + assimilation) was expected to utilise 5-10 times the internal company resources compared to that required to support the research stage. The result of the creation of strong research centres (such as the Rolls-Royce UTCs), coupled with the increased productivity required from internal company resources, has been a pressure for the dividing line between the responsibilities to move towards the right, [Figure 4]. This is certainly the explicit intention in the GEAE USA initiative [2]. Perhaps the worst of all worlds is for the dividing line to sit uneasily in an ill-defined mid-position, with all the consequent ambiguities as to who s doing what???.

6 STRATEGY EVALUATION ACCEPTANCE COMMISSION RESEARCH APPLICATION ASSIMILATION OUTPUTS OUTCOMES ACQUIRED CAPABILITIES University TREND? TREND? Company Figure 4 Movement trends for the university company interface This pressure to change the division of responsibilities has potentially important consequences in the field of design research, where a prime contrast can be drawn between what can be called people-based capability acquisition to develop tacit knowledge and software-based capability acquisition to develop codified knowledge, although in many cases both are necessary. People-based capability acquisition, which may often involve behavioural or cultural issues, will only take root if backed up by comprehensive presentations, workshops and training programmes. This is explored more fully in section 4. Assimilation of any software from the Design UTP is a key issue at the current time since the research outcomes are potentially applicable in many disciplines across the complete product life-cycle. The PEST analysis in Table 1 identifies pressures on companies towards standardisation and the use of high quality GUI driven commercial software systems. In a typical university research team, however, there are few PhD students and Research Assistants who wish to work as full-time programmers. The result is that the role of the university team is aimed at the demonstration of prototype or breadboard software. This is completely consistent with the traditional strengths of university research and its evaluation in the HEFCs Research Assessment Exercise. Two problems arise today. The first is a hearts and minds issue. It is now much more difficult to sell software with a primitive appearance to customers who are used to a working with a sophisticated user interface. There is a real danger that valuable software concepts may be prematurely rejected as a result. Hearts and minds acceptance is necessary, but not sufficient without the assimilation of any associated software-based capability. In former times this was not too worrisome, since virtually all large companies had a substantial in-house organisation of systems analysts and programmers often within the Engineering function - for integration of foreign software of this kind. The second, and potentially more serious problem is that the internal company infrastructure that used to productionise software has greatly reduced in many large engineering companies. It is now likely that the service provision of a company s IT capability will have been outsourced to another company, an IT service provider. The emphasis of the latter will be on managing and operating large scale networks, commercial software and providing

7 associated services which can include writing software. Typically there is little resource available for extended dialogue with research groups. 4 A practical example of technology transfer Many of the observations made in the previous sections are echoed in the recent experience of transferring a new approach to managing system safety justifications and certification the Goal Structuring Notation (GSN) Method from the University of York to Rolls-Royce (Marine Power). The GSN approach was developed in the 1990s as part of the work of the Systems and Software Engineering UTC located at the University of York. The GSN a process technology is concerned with the clear and explicit representation and management of safety arguments within the system safety case. As such, the method can be applied at many stages of the product lifecycle. For example, GSN can be applied at the Full Concept Definition phase for the preparation of Preliminary Safety Cases or at the Disposal phase when developing the safety arguments for system decommissioning. After several years of small-scale trials conducted by both Rolls-Royce and York it was decided in 1998 that GSN was sufficiently mature (and beneficial) to be transferred into the working procedures of the company. To bring this about, the first activity was to carry out a rudimentary stakeholder analysis. Both potential champions (from those who had been involved in successful case-studies) and blockers were identified. It was recognised that although managerial champions were critical to gaining acceptance and support of the technology transfer programme we also required grass-roots support from the safety engineers carrying out safety case development on a day-to-day basis. Without such support, we recognised that the programme could easily be spoiled in implementation. A training programme was established to train safety engineers in the use of the method. Over two hundred potential trainees for the course were identified. The training course in the form of a one-day workshop involving traditional lecture sessions and group exercises was initially planned, created and led by the university research staff member primarily responsible for the method. In addition, the university also provided after-sales support in the use of the method. However, as the number of engineers trained and those requesting training grew, it was recognised that the long-term training and support role also needed to be transferred to the company. Towards this aim, a number of GSN Facilitators were identified. The role of these facilitators was threefold to act as champions, trainers and provide in-house support of the method. A process of training the trainers was established. New facilitators first ran courses with shadowed support from the university and then eventually ran them independently without external support. Although the GSN method can be applied without computer tool-support, the latter soon becomes desirable when managing large safety justifications. Tool support for the GSN method, in the form of the SAM (Safety Argument Manager) software package had been brought-to-market by York Software Engineering a commercial consultancy company spun-off from the Department of Computer Science at the University of York. In parallel with the GSN training and support activity, Rolls-Royce also initiated the process of acquiring the SAM tool for use in support of the method on projects. Acquisition of acceptable tool support was identified as a critical success factor in the adoption of the GSN method.

8 5 Conclusions Beyond the production of research outputs from a University research programme is a translation stage which involves both acceptance and assimilation. Both of these are required to ensure the capability acquisition process is complete and the new capability ready to be applied in the product life-cycle process. It is only in the application of the new capability in this latter process that benefits from the initial investment in the research are realised. The increasing emphasis on productivity within the company will focus the need for University-Industry research teams to develop clear technology transfer routes and responsibilities encompassing both acceptance and assimilation. There will also be a need to make these issues clearly visible and understood at the project proposal stage. References [1] J C Kelly, Management of Rolls-Royce University Technology Centres, EPSRC Technology Management Network Forum Technology Management Network Looking Forward, University of Cambridge, (22 September 2000) [2] D Wisler, GE Aircraft Engines University Strategic Alliance (USA) Initiative, Academic-Industry Technology Transfer Global Network Group, University of Leicester, June 2000 [3] L A Boulter, UTC Technology Transfer and Benchmarking Research Project, University of Leicester Report on Technology Transfer Workshops (UTC Co-ordinators & Directors), (5 November 1999) [4] J C Kelly; S S Wiseall, D Knott, Managing for effective technology transfer, [Paper in preparation] [5] S S Wiseall, The Role of Universities in Innovation and Technology Acquisition for the Rolls-Royce Aerospace Group, MBA project thesis, Loughborough University of Technology (September 1994) [6] M Hiebert, Powerful Professionals, Recursion Press, Canada, 1999 Dr S S Wiseall Rolls-Royce plc, PO Box 31, Derby, DE24 8BJ, UK, Tel: , Fax: , steve.wiseall@rolls-royce.com