Leveraging the dimensions of K: Knowledge Engineering for Web Based Knowledge Management

Feature

posted 1 Oct 1999 in Volume 3 Issue 2

Leveraging the dimensions of K: Knowledge Engineering for Web Based Knowledge Management

What constrains your company's success; experts burdened with mundane tasks rather than innovating or seeking new business; too many engineers spending precious time just troubleshooting? Some knowledge engineering detective work may be just what you require. Here, Mark Hammersley & colleagues explain how two University graduates work within Rolls-Royce Plc to do just what the phrase implies; apply engineering principles to the design of "structures" of knowledge. Just as a civil engineer forms a road or building from the earth's elements, so does a knowledge engineer form systems from raw knowledge.

How to speed up the design of the longest lead-time component in a jet engine? This was the challenge presented to Mark Loweth and Richard Tasker, graduate engineers with Rolls-Royce aerospace group, at the start of their attachment to the company's SPEDE programme. For the next 12 weeks, Mark and Richard were based at Nottingham University to learn about knowledge engineering and develop a web site for the company's Capability Intranet.

Rolls-Royce Capability Intranet roles & responsibilities

Process Owner: Director with overall responsibility for the business process.

Capability Owner: Senior manager appointed by the process owner to 'own' and administer a topic web. Establishes the scope of the web, user access rules, and procedures for approval of content.

Customer: A user representative who is appointed by the Capability Owner to oversee a particular web development project.

Technical Authority: A subject matter expert who is appointed by the Capability Owner to approve the technical content of the web.

One of the most important considerations regarding the function of a department is the ability to learn from past experience. Repeating previous mistakes can be very costly and time consuming. Knowledge is seen as an essential ingredient for reducing lead times and maintaining the highest quality standards. The vision of the Rolls-Royce Capability Intranet is to be a central quality knowledge base to which users can gain access and constantly feed back lessons as they are learnt.

SPEDE is developing tools and techniques for understanding and improving business processes, including efficiently eliciting process knowledge from key staff and being able to represent and disseminate that knowledge using structured methods. The programme is being run by Rolls-Royce plc in conjunction with Rover group, Parametric Technologies Ltd and the Universities of Warwick, Leeds and Nottingham. It is part-funded by a grant from the EPSRC's Innovative Manufacturing Initiative.

Initial training

The first two weeks of the placement at Nottingham University were an intensive training course during which the participants learned about knowledge management, knowledge engineering and user-centred web design. The training included seminars, workshops and exercises covering the full lifecycle of a web based knowledge management project. There was a particular emphasis on the 'knowledge acquisition' skills needed to capture and codify previously undocumented tacit knowledge.

Understanding the needs

Mark and Richard started their 10-week project by visiting the Capability Owner. Steve Icke is the Process Improvement Manager in Rolls-Royce's Transmissions and Structures business. He explained that the primary object of the project would be to create a web site containing essential knowledge about the structural analysis of static load bearing structures. This web would become part of the new 'key system' which will enable the company to significantly reduce its product lead-times.
There are four different static structures in a Rolls-Royce jet engine. They hold the engine parts together and transfer load to the plane. The structures must be strong but they also double up as aerodynamic shapes that must hold air pressure and direct its flow. As with all parts of an aircraft, weight is a very important consideration. Stress analysis predicts potential problems with the design of a structure - it is a long and complex process and late changes to the design can be very expensive.

Mark and Richard next met some of the stress analysts to better understand the process and to gain some early insights. Most importantly, they wanted to identify the key leverage points at which knowledge was needed for quick and effective action. To find this knowledge they observed the engineers at work in Bristol and Derby and arranged a series of short introductory interviews. Nick Chilton and Mark Rogerson were the project's customers - they facilitated access to the engineers and helped to clarify and prioritise the needs.

There are ten different types of stress analysis and over 35 different software packages available for use by the engineers. Within the company, Mark and Richard found pockets of expertise in using each of the packages but little consensus on which ones were best to use under which circumstances. Few of the engineers knew how to efficiently transfer data between the packages.

Nigel Twiggs, Structures Team Leader in Bristol was one of the main experts involved in the project. He explained that most of his time was taken up having to deal with fairly basic questions, such as where to find data needed in calculations: 'It is relatively easy to write a technical definition for the calculations we do - but people mainly need practical advice about where to get the data, who to ask, how to ask and what you can expect to get.'

Nick Chilton and Mark Rogerson wanted the SPEDE team to investigate the different working practices and promote the best aspects in a usable and maintainable form for everyone to share. They wanted something that would support their goal of drastically reducing the design lead times. It was decided that the project should focus on the Intermediate Casing (Intercase). 'It is the trickiest of the four static structures and many of the lessons learned there are applicable elsewhere,' explained Mark Loweth.

Mark and Richard prepared a Knowledge Storyboard¹ to visualise the scope and content of the Intercase web site. The storyboard shows the major stages of the process and knowledge needed.

Knowledge Storyboard for Structural Analysis Process © Rolls-Royce plc 1999

The Project proposal

After two weeks' investigation and preliminary analysis, Mark and Richard presented their proposal and plan to the project steering committee including the Capability Owner and Customers. They agreed that the project deliverables would be:

1	A validated and audience-usable web site structured around the best working practice.

2	A final report outlining achievements, proposals and recommendations for further work.

3	A final presentation to the steering committee and others.

Knowledge capture & analysis

Mark and Richard next produced a Knowledge Model for the Intercase Analysis process, based on knowledge engineering templates provided by Nottingham University.

We started by going through a recent analysis project and listed each of the major activities together with the analysis methods and software packages used,' explained Richard. 'This gave us the basic framework and we found experts who could tell us more about each topic.' Nigel Twiggs described his experience of being interviewed by the SPEDE team: 'Mark and Richard had a good understanding of the company organisation, our product groups and customers. In around 2 hours of interview/discussion each week I was able to highlight the main topics and list four or five key points on each. They didn't waste my time by going over basic stuff, but they did sometimes come back and challenge what I'd said. In between our meetings they would pick up many important insights by talking to the other engineers about how things really worked.'

'They were able to draw out the context of what was being said - an engineer who has spent a lifetime working on one product line will have some well developed rules-of-thumb which may or may not be relevant to other types of engine. Sometimes rules get written down then followed completely out of context. Mark and Richard's ability to apply common-sense checks to what the experts said was really valuable.'

The important process knowledge divided into two areas:

Analysis Planning - planning an analysis strategy for a particular component design

Analysis Process - doing the analysis on a particular design

The best-practice knowledge used by engineers to carry out an analysis was categorised as follows:

Data Types - Any type of data file, report or communication format

Resources - Software, hardware or services

Components - Examples and explanations of structural components

FE Concepts - The theory behind stress analysis

Tasks - how to carry our specific functions using specific software packages

Mark and Richard interviewed about 17 experts to obtain the knowledge needed for their web. They mainly used semi-structured interviews and quickly learned that good preparation was essential. Mark described their approach: 'We always went into an interview knowing what questions we wanted to ask. It's best to use specific questions that you've already guessed the answers to.' Questions that were too broad didn't work well: 'If you ask woolly questions people give you woolly answers. If necessary, give them something to disagree with to get them going'

Mark and Richard found that instead of asking 'How do you do your job ?' it was better to ask questions such as 'When you look at this shaft, why do you analyse the natural frequency?-. These led to more fruitful discussion, and even if the engineer told them he didn't perform that particular analysis it was easier to go on and explore exactly what tests were used, in what order and why.

But it didn't always go smoothly. 'A lot depends on how forthcoming your interviewees are,' went on Mark. 'Not everyone likes talking about what they know or what they do. If people were too busy or unwilling to collaborate with the project we didn't waste their time but instead moved on to look for someone else who could help.'

Each interview was tape-recorded and later transcribed. Mark and Richard summarised the main points from each interview into a prototype database system developed at Nottingham University.² Mark said: 'Working from the full transcript is immensely time-consuming and we found it best to map out the key concepts, checking that we had got the facts right and covered everything important. The Process Knowledge Editor database helped us to structure and link the concepts.'

'We went back to some people more than once. Much of the follow-up was short telephone calls to clarify specific points. Once we'd met face-to-face and developed a relationship then it was often more efficient to use the telephone. Some people were immensely helpful and wise and made a lot of input - we would go back to them for clarification or to fill gaps as we built the bigger picture.'

Mark described that he and Richard had also visited Rolls-Royce's process benchmarking partner, Rover, where similar procedures are followed during the design of cars. 'It was very helpful to get a different perspective on the knowledge that we were collecting.'

Throughout their project, the trainees were supported by a coach from the academic staff of Nottingham University's Knowledge Technology Centre. Hugh Cottam is a researcher with considerable experience in Knowledge Engineering. He commented: 'It is particularly useful to see how we can use high level knowledge structures to provide practitioners with guidance in performing knowledge acquisition. Mark and Richard used the high level structure that I presented them with, and together we adapted it as their work progressed. The use of structure is crucial within any work that addresses knowledge issues. Knowledge doesn't organise itself anymore than a filing cabinet does. A high level knowledge structure enables a common understanding of abstract concepts to be achieved.'

Building the web site

'By this time we had over 200 concepts in our knowledge model' , continued Richard. 'We were tracking how much information we had collected about each one, and we kept a list of current questions that we still needed to explore. Some concepts were more relevant to the scope of our project then others. The process model gave us the basic framework for the web site. Previous projects had evolved a series of web design standards so we were able to draw from considerable prior experience of what worked well.'

'Each activity in the process, each analysis method and software package had its own web page which we structured according to predefined templates. There were natural cross-links between the analysis methods and the software packages that implemented them. We created supporting pages in other topic areas' sometimes one concept from the database was important enough to have a page of its own, other concepts became sub-sections of more general pages. On average our web pages were between 2-4 screens long including diagrams and pictures.'

The draft web pages became a further way of eliciting knowledge from experts, Mark explained. 'Sometimes we would show a draft page to one of the engineers and he would laugh. But that could lead to him telling us the real gems of wisdom that we needed and next time round we would have something really useful.'

Nigel Twiggs, was nominated as the Technical Authority, with responsibility to oversee the factual accuracy of the web content. 'In the past we have felt that everything written down must be backed up with reams of evidence to prove its accuracy. Consequently most of our knowledge and experience never got written down. We want to use the Capability Intranet as a medium to help us share knowledge in a much more informal way but it is still very important that it can be trusted and that the context is clear.' Each web page lists the names of the experts who have contributed and/or validated its content. 'Sometimes the telephone number of the right person to speak with is the most valuable piece of information you can give out.'

Richard explained that the users were heavily involved throughout the process. 'Most of the stress analysts have been involved in validating some of the pages and they are really positive about it because they can see what is going into it. They've seen that they can make an input and that what's in there is good quality.'

Deployment

Mark and Richard's final presentation was just 8 weeks after the proposal. By this time most of the 170 pages had had been validated and were available on the 'trials' area of the intranet for evaluation by stress engineers at all company sites. Richard Nicholson, head of Rolls-Royce's transmissions and structures business unit reflected on the achievement of these trainees: 'There is a lot of competition for places on this course and we had to wait 9 months before we could get a placement. This project achieved in just 3 months more than we could have achieved in all 12 months without using SPEDE's structured approach'.

Nigel Twiggs evaluated the web site: 'Mark and Richard have compiled a huge amount of information in a short period of time. Some of that information was already written down, but it was totally inaccessible and spread around 20 different people at several different sites and with no common framework. It takes a while to remember this stuff unprompted and the people who have the knowledge are called upon to deal with many higher priority issues. In this project we've got beyond simple words, translating valuable experience into useful advice relevant for any newcomer to this department.'

Both of the SPEDE trainees feel that they gained significant personal benefits as a result of this placement. Richard had previously worked as a stress analyst, 'I now know much more about the process of planning an analysis task' I've gained new insights about the range of techniques available and when and why they should be used. 'Mark, having followed a general graduate engineering programme within the company, has just started work as a stress analyst in Derby.' This was a really good preparation for my new job.'

Knowledge Engineering Principles

Knowledge Engineering is the process of identifying, analysing and reducing a body of knowledge into a precise form, presented in a useful and usable manner. Originally coined to refer to the process of developing knowledge based computer systems, the skills and methods of knowledge engineering are now recognised as being more widely applicable within the field of knowledge management.

The field of knowledge engineering comprises a range of well developed tools and techniques, including knowledge elicitation, knowledge representation and knowledge modelling. The popular approaches are influenced by cognitive psychology and computer science and are often supported by software packages. Some of the important lessons that have been learned by knowledge engineers are summed up in the following principles:

Principle 1:Recognise that knowledge has structure: form, content and context Knowledge has many dimensions. It is helpful to understand and be able to recognise some of the dimensions of knowledge when selecting different approaches to capturing and codifying knowledge at work. Knowledge Engineering contributes tools and techniques which can be used to change the form of knowledge, for example making tacit knowledge explicit, or deriving abstract knowledge from specific.

Principle 2: Recognise that there are different types of experts - and expertise Not only are there different types of knowledge, but there are different types of experts. The nature of experts' knowledge depends upon their training and experience. The knowledge engineer must be alert to this because the various types of expert will perform very differently when asked to articulate their knowledge. Furthermore experts will vary in their ability to recall knowledge accurately under different conditions. Knowledge Engineers have devised a number of methods to deal with this, such as aggregating knowledge from various sources and validating knowledge across sources.

Principle 3: Recognise that there are different ways of representing knowledge The ease of solving a problem is largely determined by the way the problem is conceptualised and represented. There are many tools at our disposal for representing knowledge - from pure logic to poetry to pictures. A well-chosen analogy, anecdote or diagram can make all the difference when trying to communicate a difficult idea to someone, especially someone who is not an expert in the field.

Principle 4: Recognise that there are different ways of using knowledge People use knowledge in different ways depending on the task they are performing. Understanding the user context is essential before developing a knowledge web site. Under what circumstances will users turn to the web for help ? Will they be in a hurry to solve a particular problem or are they more likely to be browsing ? How much prior knowledge can be assumed ? Are they expected to read and remember or will they refer back to the web site as a reference each time they need the knowledge?

Over 40 graduate trainees from Rolls-Royce plc have attended the Knowledge Engineering course at Nottingham University' s Knowledge Technology Centre since February 1998. This is an example of just one of the knowledge management projects completed by the trainees. Other projects have used Knowledge Acquisition software supplied by Epistemics Ltd :http://www.epistemics.co.uk

For further information about knowledge management and web based knowledge management see the Knowledge Technology Centre web site at http://www.psychology.nottingham.ac.uk/research/ktc

Mark Hammersley is Co-ordinator for the knowledge management training programme at the University of Nottingham Knowledge Technology Centre. He can be contacted at:mark.hammersley@nottingham.ac.uk

Professor Nigel R. Shadbolt, PhD is Director of the Universtiy of Nottingham Knowledge Technology Centre. He can be contacted at:nigel.shadbolt@nottingham.ac.uk

David Golightly, PhD is a researcher at the Knowledge Technology Centre, working on User-Centred Design for Intranets. He can be contacted at:dag@psychology.nottingham.ac.uk

Paul Riley is project manager of the SPEDE programme for Rolls-Royce plc. He can be contacted at:paul.riley@rolls-royce.com

Hugh Cottam is a researcher at the University of Nottingham Knowledge technology Centre, working on knowledge engineering projects with Rolls Royce Plc. He can be contacted at:hdc@psychology.nottingham.ac.uk

¹ Knowledge Storyboards are fully described in Managing Knowledge: A Practical Web-based Approach by Wayne Applehans, Alden Globe, and Greg Laugero (Addison-Wesley, 1999)

² The Process Knowledge Editor was developed by Hugh Cottam as part of Nottingham University s contribution to the SPEDE project. For further information see Milton, N., Shadbolt, N., Cottam, H. & Hammersley, M. (1999). Towards a Knowledge Technology for Knowledge Management. International Journal of Human-Computer Studies, Special Issue on Organisational Memory.