Is it "KM" or Just "K": Splitting Hair in the Knowledge Age

"Our customers believe they have a knowledge problem. They just don't see it as a knowledge management problem." Eric Stevens, director of research and strategy at Hummingbird, has just identified the key challenge facing the entire knowledgebased economy...including the users and the marketplace that serves them: Everyone knows intuitively that we would be better off if we could instantly "know everything we should know." But the problem is: how to accomplish it.

Many KM systems (whether they were called that or not) have been undertaken based on pretty iffy assumptions. One assumption is that organizational transformation is easy, or at least do-able, if you give everyone a tool and make them use it. Let's standardize on this portal dashboard, and we'll get everyone to populate our knowledgebase."

Well, that's stupid on many counts. But the problem is not only the difficulty in changing corporate cultures and working habits, but the multifaceted nature of organizations themselves. What's valuable information in that competitors' annual report to the financial officer means little or nothing to the product management team. How would you summarize a Wall Street Journal article in such a way that would make it relevant to both a product marketing team and the human resources officer? And yet, many KM systems have been sold under the assumption that can do just that.

Another mistaken assumption is that separate class of workers will emerge whose job it is to "gather" and "organize" corporate knowledge. There is ample precedent for this; the role of "information professional" is alive in many organizations. But that role is typically most useful as after-the-fact researcher—the corporate librarian. Only recently has that person been elevated to the role of creating logical and systematic taxonomy for capture of information in the first place. This is good, but the problem is that taxonomies are inherently flawed; assumption one makes about the content of a document based on its "expected" value can mask its "unexpected" value. Question: "How do you know your taxonomy is finished?"Answer: "Trick question; it's never finished.")

So when people think about their business problems, they usually determine pretty quickly they could solve them if knew the right answers all the time. Duh! That's bleedin' obvious. The mistake sometimes make is to assume that a system can be designed to completely automate the information transaction—all the person has to do is hit the right keys.

"This is one of the dirty little secrets of the search-engine business," says Paul Sonderegger, whose enviable title is "chief evangelist" for Endeca. "There's no machine that can assess relevance the way a human being does. That's not because the technology doesn't exist; it's just that ‘relevance' is naturally ‘relevant to' what the person is trying to accomplish that day. And no machine can know that. Relevance can only be judged by the human being in question. The machine's job is to provide the best evidence to support those judgments. You have to provide functionality (through automation) that lets people who are searching for something they can't name make the most of what little they know."

And so it's easy to see how a "knowledge" problem can quickly (and incorrectly) be identified as a "knowledge management" —or worse—a technology problem. I think it's in our 21st century DNA to expect that technology can come to the rescue.

Send in the Cavalry
Nowhere is the schism between "knowledge" and "knowledge management" more clearly outlined than in the emergence of corporate IT as a significant player in KM initiatives. "Proactive IT departments are asking directly for ‘knowledge management' and ‘enterprise content management' solutions," says Hummingbird's Eric Stevens. "IT people want to apply technology to solve business problems. But when we talk to business senior executives, we don't hear those keywords. What we hear instead is: ‘I have an issue around information.'"

Sonderegger agrees: "There are two categories: there are people in organizations who say ‘we have a knowledge management problem,' and they immediately look to buy infrastructure that, they hope, will help other lines of business at the same time. These are IT folks. They consider themselves tasked with finding information access tools in order to support a line of business, but they themselves do not believe that better information productivity will follow—there is no ROI calculation you can do for them that will change their minds. IT people, typically, are separated from the business process that automation might support, so they often are not convinced that greater productivity will come," Sonderegger says.

"But then there's another category: the people who have a business problem, such as ‘I can't figure out where to drill for oil.' In their case, the solution is posed as a lineof- business discovery...finding out how people all around the world find oil, how they conquered the same challenges, how to communicate that experience."

Put in this light, it's possible to imagine knowledge management as a matter of degree. There are levels. At one level, there's your basic "information delivery automation" that, as a part of an automated workflow, gathers up the kind of documents that are typically associated with the type of job at hand, and any other content that might be deemed "related" by the system, thereby saving the knowledge worker some grunt work.

To be blunt, that's about all the best technology can do for you today. Oh, sure, there are spectacular search technologies that can text-mine for implicit, non-obvious relationships that certain documents might have with one another, and do a pretty good job of imitating a sentient being by anticipating the kind of information you might need...if you knew it was there.

"That's the evolution of knowledge management," says Stevens. "The proactive delivery of information related to a business process. It's not so much the ‘management' of it, and where it goes and all the other relationships to it; it's the automation of the predictable parts, saving the person the time and effort and avoiding the potential for mistakes. We look at knowledge management as the ‘finding' of information you need to do your job. Some of that information may be in someone's head, and we may not be able to get all that experience out. But we try to help figure out how to get the most possible information automatically, so the person can concentrate on higher value tasks," Stevens says.

But that's typical information automation; it doesn't rise to the level of "knowledge management"...does it? For many of the industry's vendors, it does just fine. As Bob Macdonald, chief marketing officer for Inquira, puts it: "KM runs the gamut. There's KM for specific processes, like contract negotiation, where all the related documents are more or less in the same repository. Then there's the ad hoc kind of repository, where, if we don't find the answer in our normal repositories, we have a way to find the answer and capture that new information. That's what happens in CRM systems. They promise a closed-loop scenario where everything can happen within the CRM environment. But the knowledgebases aren't nearly comprehensive enough to answer all the CRM questions, so agents jump out of the CRM system, go into multiple other existing systems, do parallel queries and then manually look at the results for an answer." Resulting in, as Macdonald accurately calls it, "a huge productivity sink.

" Besides putting productivity in the crapper, it can deeply and fundamentally harm the ability of knowledge workers to apply their most valuable resource. "Because most people's time is spent looking around for documents and information, they get stuck on the idea that ‘this is what I do...'" says Stevens. "...as opposed to taking information provided by the system, and using that great pattern recognition engine that sits between their ears to figure out why it's important, and what has to be done for the business. These are not trivial activities, and we cannot automate them very easily."

Since this is a "Best Practices" white paper, after all, I suppose it's time for me to get a little more helpful, and suggest a course of action that will be helpful to readers. Paul Sonderegger does that for me: "You need to think about the objectives you're trying to reach by buying this kind of solution; then talk with the target users about the goals they try to accomplish and the obstacles they will face; then how the tool will overcome those obstacles and achieve those goals. This gives the customer a ‘line of sight' toward how this tool will actually move the needle on achieving business objectives."

Not the What, But the How
The most famous definition of knowledge management says it's all about "people, process and technology." We've mentioned the people aspect, we've touched on the technology piece...what's all this about process?

"More important than the raw document is the process knowledge," says Stevens. "We know how to handle files... it's capturing the process side that is becoming more important, and more difficult. The company needs to ask: ‘What has to be done with the data or document in order to achieve a business result?' So for us, KM is more than just information management —it's information management plus process management."

 "For me, knowledge management is the group of products that create knowledgebases and also has the processes in place to grab ad hoc information in an expert organization," says Macdonald. "This is the information you capture during the process of helping a customer, for example, so that it can be replicated and used again. You need something to capture that. That's when it becomes a knowledge management initiative."

In Eric Steven's view, the very act of automating the automatable parts of a process paves the way for the ultimate goal—knowledge management. "As we take control of the movement of information in an automated process, more and more intellectual capital comes out. Better still, more and more of the capabilities of people come out, because they're relieved of the chore of moving things around.

"Once you've examined the typical process," Stevens continues, "you can predetermine what set of ‘things' the user will need. Once you start a process, you may not know which documents will be related, but you know you'll need a collaborative space—a deal room, for example—where you can put all the current relevant documents.

"Another example is anti-money-laundering. When the system identifies a suspicious case, it automatically creates an investigative collaboration space. It grabs all the documents related to that individual —recent transaction statements, etc.

Right now, investigators do that manually, using ‘knowledge management' to search for it all. The next generation: we do it all automatically. There's no need for an investigator to do that; we already know what we'll be looking for. The investigators who come to the case's collaborative space can be assured that everything they need is available. It may be more than they need, but it's all there. A person doing a search may not do the right search; a system is sure to retrieve everything necessary.

" This sounds like the absolute surrender of the process to the machine, does it not? "No, not at all," counters Stevens. "It doesn't mean the person can't do additional research—an Internet search, for example, which is not something we'd do automatically. It really depends on the organization and the person. But the point is: we can offload the part of the process that is automatable, leaving the person to fill in the blanks."

The People Part
What happens when the person IS part of the problem?

 "The expert operation required by many KM systems is a weakness," says Macdonald. "In order to store something, the user has to go through an intellectual exercise to determine ‘how will this be found later?'" The success of the "find" capability in these systems is reliant on that expert knowledge person to determine how to index, or tag it.

 "The problem is," Macdonald continues, "when that ‘nugget' of information is tagged, it's related (by the so-called knowledge expert) to whatever problem it was created to solve only. BUT there can be other facets of value to that information." So the tagging can be a diversion, and lead to incorrect and incomplete information resources. For example, in a multi-paragraph description, part of the content might be about "how to turn it on" and part of it might be about "how to keep it running." A manual tag might identify the description with one, not the other.

This, says Macdonald, is one way in which new KM systems are sometimes misrepresented...or at least, well-hyped. A certain misalignment of expectations can occur, he says, leading quite possibly to today's current miscommunication between the users of knowledge technologies and the IT departments that buy them and the vendors that sell them. "A lot of times, demos are presented in an optimal way. ‘Look at how beautiful this KM system will be,' they say, IF you put knowledge experts in place and IF they make all the right decisions regarding how to tag everything. But in normal use, everything degrades. In the sales process, you never demo in real-world scenarios. It looks great at first, but in the natural degradation of normal work, the darn thing gets killed. They don't get the percentage of ‘better answers faster' that they hoped for. That's where the frustration comes in. If the system depends on all the input being perfect, well...it won't be. So the customer is unhappy and regrets the investment."

Macdonald continues: "If you eliminate the need for a group of knowledge experts tagging your documentation, then you can use those people to write more and better documentation! And that's means a multiplicity of uses occurs...you get better documentation, and you get more fodder for your customer service agents to answer a customer's problem on the phone."

Eric Stevens agrees: "The classic problem with metadata and taxonomies is deciding how to categorize all the information coming in. We know that as technologists, there's a lot we can do to assist in that." And Endeca's Sonderegger adds "One of the ways to do that is to make it more evident what kind of information the machine contains, rather than make the user guess."

Paying the Bill
From a strict cost-benefit calculation, KM is a hard egg to sell. It's expensive, it's disruptive and the value is not immediately apparent, even though we seem to know intuitively it's the right thing to do. "There is certainly a class of buyer that believes there is all kinds of time wasted in their organizations, looking for information, and either failing to find or simply taking too long to find it. But there's another kind of person who believes there are opportunities to be tapped, and that better decisions could be made, if only there were better information available," concludes Sonderegger. That sounds right, and may be true, but he adds an interesting caveat: "Better information is a contributor to better decision making, but it's not a guarantee."

"The degree to which any company needs to implement major knowledge management initiatives depends on how effective its current search tools are," insists Inquira's Macdonald. "If search isn't working, companies tend to take on major KM plans that require information to be cut up into bite-sized chucks that then get tagged in some way so the user can find documents more easily under fire when they're trying to help a customer."

"The companies making the largest investment in KM do not see it as a costreduction tool, but as an organizational enhancement tool leading to additional services or capabilities they can provide to their customers, and as a significant competitive advantage," insists Hummingbird's Stevens. "In government, they are applying these technologies not to cut costs, but to deliver better information to their constituents in a more effective manner. It may reduce the costs of doing their jobs, but their primary intention is to speed response."

So, the saga continues. On one hand, knowledge management continues to be a line-of-business priority. On the other, information technology departments are all over it like white on rice. On another hand, KM technologies can bring information to users and provide a decision-support mechanism like the world has never seen. On yet another hand, KM tools have been accused of being overly restrictive, requiring an information SWAT team that has a shaky grasp of the final intent of the very business information it captures. And on the fifth hand (what is this, a giant technological squid?) the only remaining assessors of the value of the system seem to be...you guessed it...the human beings who have to use it. I wish this were an easier question to answer. I suspect that the following essays will help, by virtue of parsing the question into manageable subsets that can be absorbed, one at a time. But the challenge of taking on the entire KM universe? I'll leave that up to you. •

---

Andy Moore is a 25-year publishing professional, editor and writer who concentrates on business process improvement through document and content management. As a publication editor, Moore most recently was editor-in-chief and co-publisher of KMWorld Magazine. He is now publisher of KMWorld Magazine and its related online publications.

Moore acts as chair for the "KMWorld Best Practices White Papers", overseeing editorial content, conducting market research and writing the opening essays for each of the white papers in the series.

He has been fortunate enough to cover emerging areas of applied technology for much of his career, ranging from telecom and networking through to information management. In this role, he has been pleased to witness first-hand the decade's most significant business and organizational revolution: the drive to leverage organizational knowledge assets (documents, records, information and object repositories) to improve performance and improve lives.

 Moore is based in Camden, Maine, and can be reached at andy_moore@verizon.net