[Back]Explicit knowledge
Explicit knowledge is knowledge that can be transmitted in formal, systematic language. It is discrete or ‘digital’. It is captured in records of the past such as libraries, archives and databases and is assessed on a sequential basis. It can be expressed in words and numbers and shared in the form of data, scientific formulate, specifications, manuals and the like. This kind of knowledge can be readily transmitted between individuals formally and systematically.
Explicit knowledge, as the first word in the term implies, is knowledge that has been articulated and, more often than not, captured in the form of text, tables, diagrams, product specifications and so on. “In a well-known and frequently cited 1991 Harvard Business Review article titled "The Know-ledge Creating Company," Ikujiro Nonaka refers to explicit knowledge as "formal and sys-tematic" and offers pro-duct specifications, scientific formulas and computer programs as examples. An example of explicit knowledge with which we are all familiar is the formula for finding the area of a rectangle (i.e., length times width). Other examples of explicit knowledge include documented best practices, the formalized standards by which an insurance claim is adjudicated and the official expectations for performance set forth in written work objectives.
In a knowledge management system explicit knowledge takes the form of data servers and traditional knowledge bases. Explicit knowledge fits well into call centers that handle a large volume of similar requests that have relatively simple answers. However, it falls short in business critical situations that generate complicated discussions requiring a variety of expertise, with interactions that often extend across multiple organizations. In order to capture explicit knowledge to be used in a knowledge management system we must first recognize where does explicit knowledge exits.
Explicit knowledge exists in many sources. The following represents areas where explicit knowledge exists:
Literature
Additional sources of information may come in the form of printed documents such as reports, regulations, guidelines, books, etc. At a minimum, if these documents exist, the knowledge engineer should review them to gain an overview understanding of the problem area. These documents can also be helpful in defining and clarifying the terminology of the problem domain. Moreover, they can often provide details on the business rules that will eventually be used in the final system. Such documents are additionally valuable in that they are an excellent source to provide insight into the major issues that will need to be addressed.
However, printed materials should never be considered as sufficient sources of information for the development of a rules-based application. These materials are only valuable as supplementary sources of information and should never replace an experienced business analyst.
Company Policy Manuals and Regulations
Company policy manuals and printed regulations are by far the best source for supplementary information about the problem area for a rules-based application. Such documents are generally formatted and organized in a manner that is analogous to the format and organization of business rules specifications. All existing policy and regulation documentation should be made available to the knowledge engineer as early as is possible in the elicitation phase of development.
Reports, Memos and Guidelines
While reports, memoranda and other printed guidelines do have value to the knowledge elicitation process, these types of documents are generally not formatted and organized in a manner that is useful to the elicitation process. Documents such as these will require a substantial amount of explanation and clarification from the business analysts or other content providers on the development team.
Published Books and Journal Articles
Published sources are generally the least useful forms of documentation to the elicitation process. Essentially, the only realizable value of these types of documents is as a source for high-level information about a problem area. Two valuable types of high-level information that can be obtained from published materials are clarifications of terminology and overview descriptions of the problem area.
Existing Application Code
The least useful alternative source for information about a problem area is application source code. Many rules-based development efforts are actually upgrades to existing applications that already solve parts of the problems to be addressed with business rules automation. Customers often believe that providing source code for the existing components is an effective means of communication the business rules to be incorporated into the upgraded system. This is not the case. Most application source code is formatted in a way that is effectively useless to the knowledge elicitation process.
Database-Stored Procedures
Database-stored procedures are definitely the lesser evil. Well-designed stored procedures are generally rule-oriented. Such stored procedures are designed to answer specific questions that are asked by the application. The knowledge engineer may have some success in extracting business rules from stored procedures. However, this is far from an ideal approach. Most importantly, stored procedures should never be provided as the sole source of information about a problem area.
Program Source Code
COBOL or other programming language source code is generally of no use to the business rules elicitation process. Programming languages are algorithmic and procedural in nature; even object-oriented languages like C++ and Java tend to follow an algorithmic approach to problem solving. Procedural analysis and algorithmic thinking is not conducive to business rules automation. These sources should never be relied upon as a source for information about a problem area.
Once knowledge is explicit it should be organized in a structured document that will enable multipurpose use. The best KM tools fit the needs of multimedia contact centers by being channel agnostic and enabling knowledge creation once and then leveraging it across multiple channels, including phone, email, chat, Web self-service, IVR, and any new channels that come online.
Organizations that have already experienced the pain of updating content in one repository for email and another repository for phone, and yet another one for FAQ’s on a Web site, should look at ways to centralize their support KM practices.
[Back]