Managing Knowledge in an Engineering Environment

My team and I have created what is called the Engineering Knowledge Management System. Essentially, it is a set of tools that allows groups to follow some pre-defined steps to set up repositories and searching capabilities for electronically based content.

 

A few years back the Boeing Flight Deck organization in Everett, Washington, realized that its knowledge was becoming harder and harder to locate and deep experts were starting to retire. We weren’t missing knowledge and information—it was simply difficult to find in filing cabinets and on servers. I was hired to "get them organized." Sounds simple, but almost 3 years later we’re still working on the volume of content that is used in this organization.

I was given the great opportunity to develop a system that allows Flight Deck engineers to capture, retain and retrieve knowledge and information. There were a couple mandates given when I started this project. First, new Boeing employees 10 years from now must be able to find what they need to do their work, and they need to be able to "bet their paycheck on it." These were big orders, and to date, we have made tremendous strides in meeting those requirements.

My team and I have created what is called the Engineering Knowledge Management System. Essentially, it is a set of tools that allows groups to follow some pre-defined steps to set up repositories and searching capabilities for electronically based content. It was not designed to be a content or document management system; it was designed to be a way for individuals to find relevant information from former design decisions about our products.

There are several major considerations that needed to be worked through before the system could be developed. First of which is an identification of a taxonomy or language that is common among the users of the system. I used screenshots of people’s Outlook folders since we have to be organized because of the server limitations. What I discovered was that at an aggregate level people did organize much the same way—around our products and their systems. This seems rather obvious, but without the analysis, it was difficult to see those similarities.

The next consideration is identification of what is going to be captured and stored. Not everything needs to be converted to electronic documents—some documents are unnecessary and, therefore, need to be taken out of the system. Once the types of documents are identified, then the group must locate and prioritize the content. The scanning and migration of documents can be a monumental activity. We have more than 25,000 documents in our repository, which serves about 200 people. Clearly, volume of documents is not an issue.

The next issue was that simply because we built it did not mean they would come and use it. The issue of velocity, which was lacking in the paper world, needed to be addressed. My team and I accomplished this by using a Google search appliance to search our file servers. This is a bit unusual at Boeing, as our Google search appliance is really only for Web servers, but with a little effort, we were able to identify how to point our search box directly to our server, which houses all of the documents. All of the documents had been put through Optical Character Recognition and were completely searchable, which was critical for finding relevant documents.

Now we had volume and velocity, but that still didn’t mean that people saw value in what we had created. This meant we had to prove in an engineering way that this system was superior to the way content is managed today. As a result, we conducted a time/motion study to validate the velocity and relevancy of the repositories. This study showed a statistically significant difference (E-10) between searching on paper and electronically. While this seems obvious, we were actually able to show a time savings as well as a higher relevancy of the documents being searched. Not to mention, it was a great visible campaign to draw attention to the new system.

Finally, I had to answer the question, "What are the benefits to the Flight Deck group for its investment in capturing and managing data and knowledge?" First and foremost, the need to assure that organizational memory, in the form of the different repositories, is stored and maintained for future use. Next, knowledge management represents an effort to avoid mistakes and is an insurance policy against the loss of that organizational memory in the future. The measures for achieving those benefits are an increase in reuse and efficiency of knowledge, an increase in accuracy of information captured, and usability and retrieval of information.

We have successfully deployed this system to not only the Flight Deck group, but also to seven other engineering organizations within Boeing Commercial Airplanes, one engineering group in the Integrated Defense Systems organization and one in the Advanced Manufacturing Research Center in Sheffield, England—a Boeing partnership organization.