tdog.blog

KM — Know your Users

Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

Your company just spent a ton of money on knowledge management vendors who installed and configured a data warehouse. It is supposed to be the answer to all your employee productivity problems. You spent some more money on the web developers who built a custom web-based portal to hook into the data warehouse.

But after six months, you look at the records and the system has met only 10% of your target acceptance rate among employees. The only e-mails that IT gets about the system are complaints. "The screens are unintuitive. Why are there these 8 report options, but the 2 that I need—why are they not there?

And why can’t I link the data in the customer trouble tickets to the bug fix repository?"

The message from the knowledge management vendors was admittedly seductive. “Purchase our product, install it, set it up, maybe add a little web front-end to manage it all, and your employees will start generating immediate value for your organization. Your customers will benefit, and your organization will prosper.”

Alas, true knowledge management involves more than just a technical implementation. It involves people, business culture, and business processes as well. No amount of implementation can help an organization “manage” its knowledge if your company’s culture hinders open collaboration. Nor can knowledge management products, be they groupware or databases, actually contain knowledge—they can only contain information in the form of bits and pixels. It’s people that create and use the information—they alone can create knowledge.

There are better ways, of course, that take human factors and business culture into account first, and then apply technology. This approach is best summarized by Thomas Davenport’s general rule of thumb: “If you’re spending more than one-third of your time on technologies for knowledge management, you’re neglecting the content, organizational culture, and motivational approaches that will make a knowledge management system actually useful.”

What is Knowledge Management?

Generally speaking, knowledge management (henceforth KM) is about managing the information within an organization, wherever it may reside (databases, documents, e-mail, people’s heads), and distributing that information to wherever it can provide the greatest advantage. For example, a data warehouse that stores information on how your prospects navigate your site could allow sales managers to run reports that help them target pitches at these prospects and turn them into booking customers.

You can break KM into two main pieces. The first piece, which deals with data warehouses, data mining, performance, metrics and other hardware/software issues, is what most people think about when someone mentions KM. Although there are many technical issues around building or buying a KM system, this is generally regarded as the easiest step in implementing KM at an organization.

The other half of KM involves building a knowledge-oriented culture and changing the attitudes of employees who view knowledge and information as symbols of status—and therefore, targets for hoarding. In some sense, this part of KM is more like social anthropology or organizational psychology.

What kinds of information does KM target? Anything that resides in a document (support notes, white papers, meeting notes), in someone’s head (an undocumented shortcut for using a Java API), or in a business process (workflow surrounding the resolution of a customer trouble ticket), for starters.

So what is knowledge then? Knowledge is something that a person experiences when they come in contact with information or data and which leads to action. For example, just reading about how to use XML is not knowledge, it’s just reading. Taking that information and actually creating an XML document is knowledge. Only when information is made actionable can it become knowledge.

(Notice that I said that knowledge is something only a person can experience. Computers and databases cannot be knowledgeable about anything. They are merely repositories.)

So in essence, the path to knowledgeable action goes something like this:

Information > Knowledge > Action

The last step, action, is based on a person’s prior experiences, personal and corporate values, and any business rules that govern their particular circumstance. You could say that action is a filter or frame for what becomes knowledge in your organization.

When effectively combined, technical issues, such as a data warehouse, and cultural issues, like a dynamic, knowledge-centric organization, can reap massive rewards in many areas, such as competitive intelligence and customer care.

What’s the Problem?

Achieving KM transcendence is pretty challenging, if not impossible. Information is hard to identify and even harder to draw out, centralize, and deliver to others. Information may reside in legal contracts, white papers, support databases, people’s heads, and even people’s bodies (think about the biomechanics involved in the construction trades—this too is information). It may also reside in how a salesperson reads the facial expressions and body language of prospects, or in the one-to-one relationships between business development specialists and partners.

Furthermore, in some organizations, it may be difficult to get employees to record what they know into KM systems such as groupware or databases. Employees may be distrustful (”if I put everything I know into this system, then you are free to lay me off”) or resentful (”I already work 60+ hours a week, why should I spend more time entering data into a database?”). They may not have the time, or they may not have the skill to recognize what they do as knowledge. Even if they do create some information, there’s no guarantee that what they set down will actually be understandable by another person, if that other person even finds the information.

In short, the path from information to knowledge is fraught with obstacles and a lack of guarantees. To make things even more interesting, information and knowledge are both quickly depreciating assets. For example, a best practices white paper may never get updated to ensure that, when circumstances or markets change, it will still be useful to others in the new business reality.

And then there are the bean counters. You see, only some benefits of KM are perceived as beneficial to an organization’s bottom line. Other benefits are harder to quantify. An intranet that allows employees to access HR forms and update their contact data may make them more efficient, thus making the savings measurable. But a team room environment that allows employees to work together regardless of work style, continent, and department may be harder to measure.

Because these cultural and organizational issues are so difficult to deal with, many vendors either ignore or downplay them. Vendors want to sell products, not get ensnared in lengthy and politically charged KM consulting gigs.

What to Do

If you need to kickoff a KM project at your enterprise (or untangle the one you already have), you need to start worrying about your users and your business goals first. All the geeky stuff, like database installs and hardware configurations, should grow out of the original requirements.

Here are some other points to remember:

It’s about people. People have jobs to do. They’re busy talking to customers, fixing problems, going to meetings, and writing code. If you don’t address their needs and pain points, then guess what? They won’t use the KM system.

Businesses require measurement for success. You need to track how the system is being used, how often the information in it is being accessed, where and when it is being used, who updates it and how often, plus a myriad other data points. It would also be useful to track how a troubleshooting tip about a 15-cent light bulb saves the company thousands of dollars in service repairs, for example. Sit down with your users to flesh out these requirements.

Information depreciates quickly. Just because someone entered a best practices note into your knowledge base doesn’t mean that it’ll still be valid 6 months from now, especially not if your market or product changes radically. Build systems that allow users to easily validate and update information.

Information tends toward balkanization. Information gets tucked away in different departments, data repositories, access areas, and file formats. If you’re not careful, users searching in one database won’t be able to find related items in other databases (they may not even know there are other databases). Centralize, centralize, centralize. And if you can’t easily centralize, then allow systems to look at each other’s data (XML is a good bet
here).

People respond to design better than they respond to rules. A good design can channel the behavior you want, whereas rules will just make people skeptical and irritated. For example, at a company I worked for 10 years ago, executive management had rolled out a vast KM program. Their approach, however, was pretty dogmatic. “All employees must enter their job functions into the system. All employees must provide details on their work tasks.” Problem was, this rollout came in the wake of a substantial layoff. The general reaction
to this was, “I put my information in the system, then I get canned.”

On the other hand, a good design, such as a system that rewarded users with prize-redeemable points every time they browsed the system, created information, or validated someone else’s information, may have fostered some trust.

Information delivery is the killer application of the knowledge economy. Most websites and other information sources either deliver too much information or not enough. Search engines return 10,000 hits or nothing at all, it seems. Users need the right information at the right time in the right context in order to be effective. Lean on your usability and content teams to create smarter search results based on smart document metadata (again, XML is a good bet).