The Knowledge Engineer is the key role in any Knowledge Management program that focuses on analysing complex decision making applied by experts, and turning this into rules and guidance that less experienced people can use. It can therefore be a crucial role in Knowledge Retention. This is not an easy role, and needs a set of unique skills.
Even without developing an expert system, the Knowledge Engineer role is an important one in creating Knowledge Assets and Knowledge Bases from the knowledge of experts.
The focus of the Knowledge Engineer was historically on the creation of the knowledge system, but in reality the major challenge for the knowledge engineer is in eliciting the knowledge in the first place. It is in the elicitation and analysis that the skill lies, rather than in creating the expert system.
The task of the Knowledge EngineerAssess the problem. The step that initiates the process of knowledge engineering is the assessment of the problem for which the knowledge needs to be acquired and packaged.
Elicit the knowledge. This is the most difficult step, and where the skills of the knowledge engineer are most important. There is a range of techniques for Knowledge Elicitation, from the structured and unstructured interview, through analysed problem solving, to card sorting and the creation of concept maps.
Structure the knowledge. Once the knowledge has been elicited it needs to be structured into an expert system, a database, a knowledge base or a knowledge asset. The knowledge engineer creates the structure and format for the knowledge, and populates it with the knowledge which has been elicited.
Validate the knowledge
The knowledge engineer needs to verify the final system, database or asset, by asking the experts to review it, and by validating the knowledge against known outcomes. The objective is to produce knowledge of high integrity.
What it's like being a knowledge engineer.This is a really interesting piece about the experience of being a knowledge engineer, from the viewpoint of Maurice King; an editor creating medical manuals. He describes the perceptions of the KM role as a somewhere between "all you do is listen and write things down" and "you become an expert in everything".
Here is how he describes some of the challenges of the Knowledge Engineer role;
Like other knowledge engineers, I have had great problems in getting knowledge out of experts. Real ones are hard to find, and when you have found them, they may only be master of a small field, and be so busy that they can spare you little time....
An expert often forgets what he does, and may not know what he does. Even when an expert can describe what he does, he can be wrong. He is more likely to be able to remember actions given conditions, than conditions given actions... expert surgeons know when to operate, but have difficulty listing the indications for doing so. They need cues which a knowledge engineer has to supply.
An expert is often better at criticizing someone else's ideas than explaining his own, and may only express his knowledge in response to something he disagrees with. Knowledge engineers have to learn the expert's language: in doing so I became a particular kind of ''theoretical' surgeon, anaesthetist, and obstetrician.
I worked mostly by asking experts to comment on innumerable drafts assembled from tiny fragments of knowledge. As one expert said when I began, ''You will have to build it up comma by comma''. Looking back, it is remarkable that the task was accomplished at all. Only by combing the earth was it possible to find just enough appropriate experts.
Paradoxically, any merit in these manuals lies with the experts, and any faults with the knowledge engineer ... it is his job to spot the fault and patch it with another expert's knowledge. The sixth sense that he needs to develop is to know what knowledge is useful, and when it is likely to be faulty.