Knowledge management (KM) is the latest buzzword to fly out of academia and into a meeting near you. I constantly hear the term bandied about, and most of the time, it’s improperly used.

First, let’s look at the term knowledge management. At its root, it seems deceptively simple: the science of managing knowledge. However, doing a Web search on knowledge management will soon make you beg for words that can express the concept in under six syllables. There is the academic definition, which is usually several paragraphs that even the author doesn’t understand, and then there is the practical definition of KM and how it can relate to you. I say we stick with the practical and see how it can help your organization.

Simplified KM

I know that I am going to get angry letters from purists, but here is how I see it: KM is the art of leveraging, distributing, and applying what you know. The goal of KM is to make something called the “learning organization.” That is to say, you could set up a company that would learn and remember from its experiences and be better able to adapt to the ever- changing marketplace. What it really boils down to is looking at an organization as what it truly is. A business is a collection of individuals that come together for the purpose of doing some activity that will keep them gainfully employed and generate profits for the shareholders. The business has knowledge inherent in its design. Examples include a list of inventory, an accounts receivable report, product brochures, a list of all support calls and their resolutions, etc.

But the most important knowledge that a business has is its people. Inside the heads of these individuals is the information on how customer X reacts to a late shipment, who to call to get client Y to pay the bill, where to find all of the source code for product Z. These things are called knowledge capital. It is embedded in the heads of the employees that you work with right now, and, to me, the measure of a business is the sum total of its knowledge capital.

One of the scariest things that can happen to a small business is losing knowledge capital. I have seen it a hundred times. A small shop has a programmer responsible for maintaining some key systems. Because the business cannot afford enough people to do the work required, documentation of the systems is poor or not maintained at all. Then, the key programmer leaves for greener pastures, and what do you have? A business that has lost the expertise that it has relied on for maintaining a mission-critical system.

And this is not just the case of poor documentation. You can have fantastic documentation, but if you lose a programmer or analyst that has worked for your organization for a number of years, you are losing business insight. Yes, you can replace a programmer by running an ad and maybe even getting someone more skilled than the one you had, but you have lost the accumulated knowledge of your business processes and equipment: key skills and thought processes that only come with experience working at your shop, on your equipment, and with your customers.

It’s not just a case of capturing knowledge of programmers and analysts. Your tech support people know who are the problem children and who are the technical superstars in your and the customer’s organizations. Your salespeople know who the go-to person is for getting approval on a new project or development effort, and your accounting people know who to contact with sticky contract or payment issues. All of this information is stored in wetware (their brains), not codified or backed up.

Employees at an organization are not just cogs in a wheel of production. They are links of information that, when chained together, function to produce a product or service, and the sum total of their working knowledge and how that knowledge is pooled and shared can have a direct effect on productivity. Working with your employees about how to identify knowledge that needs to be shared can have great impact on your bottom line.

From Academia to Practicality

Here is an example of practical knowledge sharing from customer support data that had a direct effect on my last company. The company had a maintenance management software product. “Maintenance management” means tracking all of the requests (like a support call) that customers make and sending technicians to the customers’ sites to repair the problem. Typical calls were like, “It’s too hot in my area,” “It’s too cold,” or “The toilets are backed up.” We had a lot of customers across the nation in a variety of different businesses, from college campuses to large hospitals to weapons disposal facilities. The software we provided could track maintenance requests and all materials and labor used in satisfying them and could generate preformatted documents that explained how to perform a routine preventive maintenance task. These documents could be huge, as sometimes customers were maintaining large, complex pieces of machinery. Subprocesses that had to be performed might also be attached to the document, and the software would ensure that all processes were reported and scheduled in order of requirement.

Once, a customer reported a problem with the document feature of the preventive maintenance (PM) scheduler. Our representative explained the feature to the customer and fixed the problem. Because my company kept detailed information on how customers used the software and their lines of business, our representative knew that this customer had never used the PM scheduler before. The representative wanted to know if the customer was starting a PM program and how we might be able to help in that process. The answer surprised our support person. The customer was going to use the maintenance scheduler to track the disposal of hazardous materials from his organization. (It turns out that waste disposal has complex tracking, documentation, and reporting requirements.) The customer saw that the documentation features of our software and its ability to generate dependent tasks and reports would satisfy these reporting requirements with no modification and was well on the way to building a system to track waste removal processes using our system.

Now, the point is this: We were in the maintenance management business, not the waste disposal business. We had never thought of going into that business, but here was a

customer using our product to track another critical facet of his business. We would have never known about it without the diligent work of our support representatives. The bottom line? We used the code from our preventive maintenance software and fashioned a hazardous waste disposal reporting system. We created a new product and were able to fill a need we did not know existed by tapping the knowledge of our customer support representatives and our customers.

With this example in mind, let’s examine the support processes and how you can leverage that knowledge.

Starting a Learning Organization

Let’s look at the mythical company Potemkin Vaporware. It makes software that allows its customers to track and support widgets. Potemkin has the following departments: programming, telephone support, onsite training and consulting, sales, and accounting. What knowledge stores does Potemkin have, and how can it leverage these stores to become a more dynamic organization?

The front lines in Potemkin are the customer support representatives. These people are in constant contact with the customers that use and abuse the Potemkin product. Since Potemkin is like a normal software company, it tracks each customer support or information request call, problem, and resolution. This is the first knowledge store that Potemkin should pry open.

Whether the support call information is on paper or in a help desk program, it is a database full of marketing opportunities, product upgrade ideas, and ways to improve the existing software. It is a knowledge base of customer experience with Potemkin’s software. In order to take complete advantage of it, Potemkin should create a Web site that leverages this knowledge base. Here are some justifications for this Web site:

• Programmers can use failure information to make better versions of the software.

• Customer feedback can drive new features for future versions.

• Marketing can determine how customers use the software and its common problems, then leverage this information in the selling process.

• Management can utilize information on feature requests or unusual uses of the software to drive new product development.

Of course, those are just the tip of the iceberg. The point is that, by not sharing information between departments and with customers, the knowledge is retained in only one area of the company or possibly within the head of one individual and therefore cannot be used to grow the organization. If we can share the knowledge, we can capitalize on it in our daily business.

Exploiting Free Tools

If you do not have any software for tracking your support calls, you need to purchase or create it immediately. This does not have to be a really fancy system, but it does need to have a few key pieces for functionality. It must be able to track the status and process of a support call from inception to completion. It must be able to categorize the calls by product, version, problem type, severity, and customer type. Finally, the database used by the software must support ODBC or OLE DB access to the support data. Buying a proprietary product that does not support external access is like buying a locked jewelry box that you don’t have a key for: It may look pretty, but it isn’t very useful. You will not be able to get to the information with third-party or homegrown products, and you are thereby limited to only what the vendor offers. If you cannot find a suitable system, I suggest using a product

like Microsoft Access to create a small database for tracking support calls. Access ships with Microsoft Office, and most organizations have this product. I have placed a sample database on Midrange Computing’s Web site (www. midrangecomputing.com/mc) that contains a simple support call management database that could be used by your organization if you do not have a program in place.

Once you have a system for tracking calls, the next step is to leverage the information collected in the system in an intranet for all departments to peruse. I am a firm believer in using the browser, so I am going to outline how to do this with a Web server targeting browser clients. By using the browser, you can later open up the knowledge base to mobile users and those outside your organization. The browser doesn’t tie you to a specific platform.

Lastly, you need to work with customer support representatives so that they clearly understand how to properly tag and categorize information that they place into the system. Support personnel need to understand that their job is not only to help the customer but also to identify marketing opportunities, new products, and needed features and, most of all, to categorize the knowledge that you are gathering so that it can be properly used for real solutions.

Summarize for Knowledge Power

Let’s look at some of the views that you should create with the support information. Figure 1 shows a tree view of the Potemkin support Web site. The top level is the main page, which provides links to all subpages and disseminates critical companywide information. From there, users can link to the Find Customer page and, after filling in the prompt, will get the Customer Summary page, which is probably the most important view. Individuals make support calls, but each individual works at a company. Accounting has to deal with the company, and the sales department is trying to sell additional products, services, and customizations to the company. By making a summary of all activity for each customer available to these departments, you can empower employees with information that they can use during dealings with the organization or customer.

The summary information should include relevant items, like company name, total calls, open calls, and total hours expended. The number of calls and hours expended should also be shown by some type of problem severity indicator. For example, Potemkin’s access database allows a call to be tagged as Critical, Severe, Feature Request, etc. By summarizing the number of calls and hours expended by the severity of the call, we give the user a sense of how well the software is being used at the organization and how the customer may feel about the software.

Another important summarization is to look at how problems are tracked and reported by problem classification. The classification of a support call is extremely important. Without proper classification, you cannot route the problem summary or detail information to the proper respondent in your organization. Let’s look at the classification of problems in detail.

First, a support incident can be defined as either a customer-created or a system- created problem. Customer-created problems could be defined as areas where the software did not perform as the customer expected, the customer broke the software through improper interaction with the code/database, or the customer just doesn’t understand the software and its use. A number of high incidences of the latter should be a clue to the sales department to sell training and consulting services to the customer. It should also be routed to the documentation department, as it might signify deficiencies in the product manuals.

System-created problems can have a much greater depth of detail as to their classification. A system problem could be an actual bug in the software, in which case it should be routed to the programming department. However, it could also be a limitation in the system’s design; The customer may be trying to complete a function that the system was never designed to do. Or it could be a design error where the system is actually

functioning correctly but the customer does not understand the result he is achieving because of improper training, perception, or bad documentation.

Summarizing call types by these classifications can give you a sense of how a product is doing in the field. If you see a large percentage of similarly classified calls within a certain time period, you need the ability to drill into the incidence detail so that you can review the calls and their resolutions. This can lead to changes in the system that could reduce these types of calls. You may want to summarize this information by product version. This could allow you to spot trends in support by release level. You should also have an overall summary for all products. This summary may help you deal with issues at a company level. For instance, maybe your overall software quality assurance program is not robust enough for the given task, or maybe you need to spend more time on documentation.

By making views like these available over an intranet, you are empowering your employees to make better-informed decisions in dealing with customers. This can also help you deal with larger issues, like new product development and the creation of new features. But the best part is that you are transforming an information store that you are already creating and maintaining into a knowledge asset for your company.

There are uncharted islands of knowledge at all companies. Mapping and distributing the knowledge via an intranet can be your first steps to becoming a learning organization. Identifying the knowledge stores that you already maintain and finding ways to distribute and codify that knowledge to relevant departments need to become a high priority, because companies that don’t learn will cease to earn in our new knowledge-based economy.

Potemkin Support Main Page

Find Customer Choose Product By Classification

Stats by Version

List of Incidents

Incident Details

Stats for Product

Customer Summary

Figure 1: This is an idealized view of an intranet to disseminate customer support information.

Also Read

9 data governance strategies that will unlock the potential of your business data

Data observability: The missing piece in your data integration puzzle

From Legacy to Modern: Upgrading Your BI Strategy with LANSA BI for IBM i