From Technical Writing to Knowledge Engineering--One Writer’s Journey News & Views Feature Article

by Elinor Knodel, Information Manager and Program Manager, E. I. DuPont de Nemours Originally published in News & Views May, 1997 issue. Copyright 1997 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.

Six years ago I joined what was then called the Technical Communications group in DuPont as a technical writer. Before that I had held various positions in manufacturing and R&D in DuPont’s clinical chemistry analyzer business. For the first several years in Technical Communications, I worked with my former colleagues in Medical Products writing peer-reviewed journal articles and various technical marketing pieces. Later I led a team that developed a large operator’s manual for a new clinical chemistry analyzer. My projects were not all standard fare for information developers at DuPont, but provided a good proving ground for the wisdom of my career change from scientist to technical writer. From the beginning, though, I was intimately involved with generating content, occasionally to the discomfort of my former colleagues in the business. My story describes an evolving process that is changing the nature of my work from technical writing to knowledge engineering, a journey that is both exciting and rewarding. A Need For Knowledge-Base Development A project opened up to work with polymer engineers in the Nylon business unit, and I started to learn about a field quite foreign to my academic training in biochemistry. Finally, I was in the position of most of the information developers in our group--a communicator, not a subject matter expert. It was simultaneously unsettling and intriguing. I began to pick up some of the technical jargon and concepts as I met with teams of six to twelve engineers who were technical experts in one or more stages of nylon production. Our main objective was to document the group wisdom about technical matters pertaining to the operation of nylon processes. This accumulated wisdom has finally been recognized as an invaluable resource, worth the effort to develop in a readily accessible form for a wide cross-section of people to make better and faster decisions in a globally competitive market. Many technical reports already existed, dating from the start of nylon production in the 1940s to the present. A few senior technical experts had a good grasp of the whole history of nylon production at DuPont, but most would soon retire. What were we to do with the mountains of information (and data)? How could we incorporate parts of it into the existing knowledge base that the engineers currently used? In our work together on teams, individual engineers at first focused on how and why their particular processes were "different" from the rest. After all, nylon for lingerie is quite different from that used in tire cord. As time went on, however, we began to see the similarities among the processes. We decided there was value in describing the commonalities and then in clearly defining the true differences and special requirements for individual products. Different products branched off the common database at different points. I began to visualize the body of information as some kind of decision tree. Although I didn’t fully understand the meaning of the term, I thought it sounded like a knowledge-based expert system. I found a group of computer scientists in DuPont who make up the Artificial Intelligence (AI) Task Force. Happily for me, they turned out to be a congenial bunch, glad to introduce this scientist-turned-communicator to the world of expert systems, and they even explained it in English. I discovered that expert system shells are programs that contain the structure for entering both the knowledge (subject matter or domain facts) and the rules of thumb (heuristics) for making decisions. These programs allow the development of small expert system applications with minimal training. I went back to my partners in Nylon brimming with possibilities. But expert systems turned out to be a very hard sell with them--most of their misgivings centered around unfamiliarity with the medium and accessibility for the widely-dispersed users. Although we subsequently developed an "expert system" on paper, I had planted some seeds. I had also gained their acceptance as one of the team, a fine compliment.

What Is Knowledge Engineering?
Perhaps a bit of background on expert systems would be helpful. Expert systems are a practical outgrowth of the broader field of artificial intelligence (AI) that strives to discover how machines can be programmed to think and act somewhat like humans, modeling especially how we solve problems. The main branches of applied AI are natural language processing, robotics, and expert (or more generally, knowledge) systems. Knowledge systems embody the knowledge of experts in a field (domain) that includes both textbook and experiential knowledge. The knowledge engineer is the intermediary who captures domain knowledge from experts and encodes it into an expert system, making best use of machine reasoning and knowledge representation. (See the bibliography for books that explain the development of expert systems from a very practical viewpoint.)

If we broaden the knowledge system concept to include other online and even paper media that information developers create, knowledge engineering stands squarely in the domain of what we do as technical communicators. Some of our information products are really knowledge products that contain both types of expert system input—the facts and how to use them to make decisions or solve problems. And our focus on effective communications allows us to construct very usable knowledge products, whatever the interface between knowledge and users.

Knowledge Engineering for Nylon
As I continued to work with the technical teams in Nylon, I gradually began to moderate some of the meetings where we developed content for various knowledge products. My limited understanding of polymer engineering allowed me to pose some naive but thought-provoking questions that sometimes led to spirited discussion. At the end of one project, the team told me that they had tried on several occasions to reach consensus on how to practice that part of the nylon production process and never got beyond the disagreement stage. My intellectual curiosity, persistence, and most of all my neutrality helped to create a safe place to question some long-held assumptions and to explore options.

Another skill that I brought to the table was that common tool of information developers--a needs analysis--to define the knowledge product’s users and objectives, the tasks or learnings to be accomplished by using the knowledge product. Knowledge engineers from a computer science background might call this process "front-end loading." The teams I work with are gradually seeing value in this exercise, because they get the knowledge product that they really need, and because they see parallels to their own formal design processes when they build new plants or production lines.

There is one other area in which I think we communicators can contribute to the knowledge engineering process: we can offer new avenues for creative thinking and problem-solving. DuPont has long had an informal, almost bootleg group called the Oz Creative Thinking Network that sponsors presentations on creativity and how to access and develop it in ourselves. I have been exposed to a wide variety of approaches for knowledge prospecting for both individuals and groups, and I’ve applied a few with the generally "nuts and bolts" engineers I work with. On occasion, we’ve even broken out of the familiar linear thinking patterns and built an understanding of a subject that used intuitive, creative, and unexpected ways of thinking.

Future Directions
It’s been a grand tour developing the kind of working relationships I enjoy with the teams in Nylon, and most of all, it’s been fun. I have several goals for at least the next five years. I’d like to broaden our repertoire of knowledge-gathering techniques, through both human interaction and computer inputs. The teams are learning different ways to classify and structure their engineering knowledge, and they’re exploring various online and paper media to find those that work best with a particular body or type of information.

The teams are just beginning to hold electronic meetings using Microsoft’s NetMeeting software, available from Microsoft’s home page. It’s essentially a whiteboard that allows real-time collaboration using any program available on the host computer. The rest of the participants can take long-distance control of the host computer’s mouse. My engineering colleagues love to create models of their processes in spreadsheets and do a lot of "what-if" analyses, where they change processing conditions and predict the effects on product characteristics. NetMeeting allows them to incorporate the group’s collective wisdom in documents that can then be sent immediately to each participant’s computer. The effectiveness of this global collaboration has inspired great enthusiasm among a normally reserved group of professionals.

I’d also like to broaden the choice of media for sharing, storing, and maintaining the group’s knowledge base. Most of our output to date has been either on paper for the larger information products or by electronic mail for summary position statements on various technologies used in the Nylon business. We have a DuPont Intranet through which people are still finding new ways to communicate. More of our technical expertise needs to move onto the Intranet with appropriate security measures in place. Of course, I’d like to develop expert systems for effective knowledge transfer of basic nylon processing technology, as DuPont moves into new areas globally. Typically, such expert systems also free up the experts to work on more challenging issues.

As an information developer in a large corporation, I see the importance of measuring the value added by our collaboration with the businesses, both as a good business practice and because downsizing is a way of life in corporate America. We need to get more feedback on the usability and usefulness of the knowledge bases that we develop jointly with our business partners. And with that feedback and other financial information, we need to determine the value to the business of more accessible expert knowledge. I believe our group of information developers has found a niche where we do add value as internal partners, and I’m delighted to be a part of it.

Bibliography
Beerel, Annabel. 1993. Expert systems in business: real world applications. New York, NY: Ellis Horwood.

Feigenbaum, Edward, Pamela McCorduck, and H. Penny Nii. 1988. The rise of the expert system company. New York, NY: Random House, Inc.

Harmon, Paul and David King. 1985. Expert systems: artificial intelligence in business. New York, NY: John Wiley & Sons, Inc.

Higgins, James M. 1994. 101 creative problem solving techniques--the handbook of new ideas for business. Winter Park, FL: The New Management Publishing Co.

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Last updated: May 18, 1997 (rst)