Implement an Expert Knowledge Base and Keep It Running – Part 2
By Rich Clark
Part 1 of this series (SSPA News, Aug. 10) explained the nuts-and-bolts of an expert knowledge base. This article assumes that you’re now familiar with expert knowledge bases and systems, what they are, what they can and can’t do, and how they do what they do in relation to the knowledge and the people within your company. To get a better idea of what specific vendors and products offer, the magnitude of your initiative, and the costs, you’ll have to contact a few providers.
Here are some recommendations for assessing your knowledge and selecting an expert knowledge base.
The functional purpose of an expert knowledge base is to accumulate your company’s valuable information and knowledge into a single repository so the people who need it can easily find it – both internal support professionals and customers using self-help tools. While that much is likely obvious, the ramifications of such a statement can be daunting.
For example, for an expert knowledge base in a support department, this usually means first assessing the amount of your valuable technical information, then assessing the types of knowledge that you have. The knowledge your support organization has could be in the form of white papers, technical documentation, blueprints, subject articles, technical bulletins, resolved engineering change requests, resolved service requests, original design specifications, and more. From this list, you can see that the types of information and knowledge can be very diverse. What this means is that whoever is going to view all this diverse data needs to have the appropriate client application(s) installed on their machines for the type of information being returned.
A commonly-used client application is some sort of text editor like Microsoft Notepad. In most cases, the expert system client will have to be able to interpret and display text data through some sort of built-in interface. In other words, the client application for the expert knowledge base should be compatible with raw ASCII data, even if that client is a web browser like Internet Explorer.
From here, it gets more complicated. If the knowledge you want returned from your expert system is, say, an MS Word document, not every other word processor like Word Perfect will display the document in its original WYSIWYG format. Important formatting could be missing or not interpreted correctly by the foreign client application. To resolve this level of incompatibility, Adobe has taken care of some of this issue by its Adobe Acrobat application, which users can use to create and view PDF files and guarantee, for the most part, that what you see viewed is what you get. The Adobe Reader is a free download for anyone connected to the Internet, so that when your knowledge is displayed it will look correct, if viewed through this client application.
But what about engineering specifications, drawings, blueprints, service requests, engineering change requests, and any other file types and the requisite viewers? Some expert systems contain converters that interpret a variety of common file types and have ways to display them. Photos or drawings converted to a .JPG or .GIF format, among others, are widely compatible. AutoCAD or Corel DRAW! drawings on the other hand may not be. While there are third-party viewers that can look at single-layered proprietary drawings, it gets tricky when trying to display complicated multiple layer drawings unless the user has a compatible application viewer installed. Downloading these types of files can be an issue, as they can be several hundred megabytes or larger.
If your Customer Relationship Management (CRM) or change management tool clients are proprietary, they could cause issues in displaying information or knowledge from these systems into another client application like the expert system you implement. One other issue is that too much information may be available when using these systems as sources of knowledge, as proprietary information, confidential customer records, or raw comments by engineers or developers may be exposed when displaying the records in these systems unless they are first sanitized by your knowledge authors. The overhead in mining these systems’ databases and converting the records into usable knowledge can be quite high, requiring dedicated personnel and a lot of time.
The point is that it can be quite tricky to display knowledge in a usable form at the final destination, whether that’s an internal engineer or an external customer. That’s why you need to give your implementation a lot of careful thought and systems engineering before you purchase anything! Asking a lot of hard questions up front about your knowledge and what your intentions are with it will immediately rule out various expert systems providers as being inappropriate for your implementation.
Statistical analysis techniques can also be very helpful in determining whether or not to mine your CRM system for customer data. Generally speaking, the majority of issues that your customers contact you about may be recurring issues. These customers’ calls will therefore not be “unique” issues. Even though each recurring issue as described by the support engineer in the CRM system might not be identical in description to another issue, it generally is identical in content and resolution. Some clever SQL statements should return most of these similar issues and solutions for your analysis.
As soon as you have a list of these customer issues for a given particular solution, you can determine the approximate period that the data for it is getting “refreshed” within the CRM database. If that period is short enough, it isn’t necessary to employ a staff of knowledge authors to mine the CRM database for knowledge, which can be a huge cost savings and an overhead that you do not have to maintain.
In this case, customers drive the creation of the knowledge and it is simply recorded by your support staff by building a “bridge” from the CRM system to the new expert system and modifying the staff’s work flow a bit. When this recording/creation of knowledge objects is incorporated into the engineer’s work flow, three important things happen:
1) The engineers automatically check the expert knowledge base for a solution, and if the solution exists, they simply press a button to transfer the information from the expert system into the CRM and the case can be closed as soon as the customer has verified that the solution works in their environment.
2) If the solution doesn’t exist, the new knowledge object is created on-the-fly or while the engineer is researching a correct solution for the customer.
3) The customer solutions recorded in the CRM system become uniform and identical because the engineers are using the solutions from the Expert System to close the customer issues. There are no more “shoot-from-the-hip” solutions in the CRM system! Customer satisfaction is immediately increased. This also makes the future issue of managing the content in the Expert System into a far easier and simpler task
The efficiency and utility of this process is elegant. It avoids the need to employ a large (and often redundant) staff of subject matter experts and knowledge authors to create new knowledge.
The technique of using statistical analysis involves analyzing the CRM database and determining the refresh length and the life-cycle length for specific recurring past issues, and other issues that have similar refresh and life cycles. If you have recurring data such as this in your CRM system, you can calculate and project refresh periods for current products with some level of statistical certainty. The analysis also gives you some idea about the life cycles of previous knowledge so that you can retire similar knowledge appropriately in the expert system. You may need to superimpose several similarly supported products and use standard deviation and leveling methods to get results that mean something useful to you.
When you’re finished with your analysis, you should be able to answer questions about your knowledge including:
1) How much work is involved in making the knowledge base usable to mitigate approximately 80% of the customer issues?
2) Is it possible to extrapolate a curve to show issue mitigation of 70%, 60%, or less?
3) When is it likely that the work mentioned in (1) will be finished?
4) At what point during pre-population can the knowledge base be deployed so that at least 80% of the customers looking for answers to common questions will be satisfied with the information contained in the database, and won’t need to contact technical support?
The answer to question four is a crucial element in your decision about when to release your expert knowledge base to customers. Engineers and internal users can benefit from the system during the pre-population period, but if your customers look for an answer and can’t find it in three tries, studies indicate that it’s unlikely that the customer ever returns to the resource to look for solutions. On top of that, any discussion between an unsuccessful customer and others who haven’t used the system will discourage nearly all use of the system.
If you don’t see any recurring use of knowledge within your CRM system or other resources that you may have available, it’s very likely that you need to mine your resources for sources of new knowledge for the expert system. This, in effect, is a recompiling and sanitizing of your current knowledge. This should be done using a dedicated, independent staff and the new knowledge objects should be authored according to documented, in-house standards so that all knowledge in the expert system will be uniform in appearance, making searching for a correct solution a simpler task rather than sorting through a lot of partially or wholly incomplete documentation. This area of knowledge object consistency is also vitally important to customers returning to use your expert system.
This article should have you thinking about the content of your existing knowledge and the quality of that content. You should have some idea about what’s involved in your situation to pre-populate an expert system that will, from the outset, satisfy 80% of your customers with correct resolution to their issues.
You should also have a good idea about some of the benefits that an expert system can provide you and your staff—you’re beginning to understand that there is going to be an efficiency gain by displaying all of your knowledge and solutions in a single interface to your entire support staff. Finally, you should now know what sort of authoring and publishing overhead is required of your staff, and knowing all of these things, you should be able to make a decision on what type of expert system and what specific vendors have to offer you in terms of solutions for your particular situation.
In the next few articles, I’ll discuss how to view ROI on expert knowledge bases and how they can be pitched to upper management, and we’ll look at metrics that we should expect to see from the system and ways to achieve our expectations. Finally and most importantly, we’ll discuss what it takes to keep an initially useful and popular system from failing within the industry average time span of two years.
Rich Clark is the Senior Knowledge Engineer for Invensys Wonderware. He has published numerous technical articles, tech notes, and white papers on a wide range of subjects using Wonderware products including: ODBC and database usage, SPC, time functions, and more. He currently is responsible for the content, usability, and health, and ongoing success of the Wonderware Expert Knowledge Base.
|