|
Making Knowledge Management Work
By Jack Gordon
Now that they know what NOT to do, clever companies are finding ways to capitalize on the promise of KM. Knowledge management came out of the starting gate hard and fast as a hot concept of the 1990s, but faded in the backstretch. To many organizations, knowledge management (KM) began to look like one of those grandiose business panaceas that sounds great on paper but doesn't work in practice.
The driving idea behind KM really does sound wonderful: Identify not just the key knowledge that an organization has captured in formal documents but also the "tacit" wisdom and expertise that exists in the heads of individual employees—the 80 percent of every company's know-how that walks out the door at the end of each workday. Then organize it, classify it, and make it easily accessible to other employees who need that knowledge to perform their jobs well.
Stripped to its bones, says Hillsborough, N.J., performance consultant Marc Rosenberg, the goal of knowledge management is to create "an environment that allows people working on a task to ask, 'Does anybody know how to do X?' and get a quick, reliable answer"—preferably the best answer from the company's best expert.
According to people who head successful KM efforts today, the concept was hobbled from the start by a fundamental misconception: KM was perceived by major organizations as a multi-million-dollar software application that a company buys from a supplier and then stuffs full of an abstract substance called knowledge. "Consultants went into big organizations and sold KM software as a killer app," says Melinda Bickerstaff, vice president of knowledge management for pharmaceutical giant Bristol-Myers Squibb. "In essence, they said, 'This application will move knowledge around your company where you need it. All you have to do is fill it with the knowledge.'"
Bickerstaff refers to that approach as "leading with technology." When a KM effort leads with technology, she says, "you almost guarantee failure." Technology only enables good KM solutions; it is not, in itself, a solution to anything. Indeed, it was technology that created the "plethora of information" that KM now is attempting to manage.
Leading with technology is the first great mistake that leads directly to the second, which Bickerstaff calls "trying to boil the ocean." Forget the notion that the point of a KM effort should be to collect and disseminate every last scrap of corporate knowledge that might be useful to somebody, somewhere, she says. Successful KM initiatives begin with a specific business problem you're trying to solve, not with the intention to address all of your company's information-sharing needs. "Knowledge management has to be perceived as a business problem solver, not as an abstract concept," she says. "That way, nobody says, 'What's this KM stuff all about?'"
Why would people say such a thing? When a KM system is "overbuilt" as a giant data repository that is supposed to contain all of a company's intellectual capital, "one of the top pitfalls is that you get into a document-management framework," says Cedric Coco, senior director of engineering excellence for Redmond, Wash.-based Microsoft Corp. From an employee's perspective, contributing good ideas or best practices to the system turns into a matter of filling out a standardized form every time they sneeze. Participation in the effort becomes one more brick added to a heavy workload—a time-consuming chore with little visible payoff.
Instead, Coco says, "I need a format that lets a software engineer contribute knowledge easily." And the know-how should exist in the form most useful to other engineers, not just the form most convenient to the computer application that stores it.
If you're going to spend millions of dollars on a KM initiative, Coco says, "spend the millions to develop content, not on the fancy system."
Share what with whom?
Leading with technology and attempting to boil the ocean are not the only snags that have bedeviled KM efforts. Knowledge management is fundamentally about collaboration, and that raises corporate-cultural issues that have nothing to do with computers. "People have chosen to collaborate or not since the beginning of time," says Rosenberg, whose book, Beyond E-Learning: Approaches and Technologies to Enhance Organizational Knowledge, Learning and Performance, will be published by Pfeiffer this fall. Whether you're dipping into an electronic repository or talking to the person in the next cubicle, he says, "Technology doesn't get around the fundamental issue, which is, 'Why should I bother? What's in it for me? And if I share my best ideas with you, will you use them to beat me out in the next performance evaluation?'"
Another sensitive issue: In all this sharing and disseminating of the company's knowledge, what's to stop crucial intellectual property from escaping into the hands of competitors? Kathy Harris, an analyst with research firm Gartner in Stamford, Conn., is part of a research team studying the tension between KM and intellectual property concerns. "It's a balancing act that takes a lot of analysis," Harris says. "A company needs to look at its people, their jobs and the information they need, and then build the right 'views' for them to get that information." At the same time, the company must "look at the level of security it needs for various types of information." However, she says, the goal should be to "have a few things strictly protected vs. most things to which people are given access….If you spend more on fear and mistrust than on sharing, that's backwards."
Technology does allow you to control who gets to see what—but not if the knowledge-management system is designed as a single, giant data repository with only one point of access. At KLA-Tencor, a San Jose, Calif., process-control company, each employee accesses the KM system via a personal Web portal that recognizes the individual and knows what information he or she is authorized to receive. "Knowledge management is as much about editing and funneling information as it is about sharing it," says the system's principal designer, Efren Lopez, KLA-Tencor's senior director of learning and knowledge services.
Those are some general lessons learned about how to make knowledge management work. Here is how they apply at three companies that are making it work well.
Bristol-Myers Squibb: Telling the Whole Story
When Melinda Bickerstaff signed on in 2001 to head up a formal KM effort for Bristol-Myers Squibb (BMS), she began by looking for specific business issues to address. Where could the company save money or improve its success rates or shave time off the process of developing new drugs by giving certain employees easier, faster access to good ideas or the right information?
One early finding was that BMS scientists spent an average of nine hours a week—18 percent of their workweek—looking for information in support of their research. For instance, Bickerstaff says, "A scientist in one of our labs would go into a patent database, then might have to go to five or 10 other databases to find out whether someone already had a patent on a molecule [the scientist] wanted to develop." In that case, a strictly technological solution suggested itself: "Maybe we need to integrate these databases into one so that a single click gives you access to the whole thing, and you don't have to spend a week doing the search."
Another KM initiative was less straightforward, requiring what Bickerstaff calls a low-tech approach. To get a new drug approved by the U. S. Food and Drug Administration (FDA), a company often must take it through the FDA's advisory committee review process. This is notoriously difficult. Suppose BMS probed the development teams with the best records in front of advisory committees, uncovered their key secrets (i.e., their best practices), and shared those practices with other teams that would go in front of FDA committees in months or years to come?
Here is where asking people to fill out standardized "share your knowledge" forms would have been fruitless, Bickerstaff says. "If you say, 'We'll send you a form to complete,' or 'Write down what you just did,' people won't do it. They're too busy. But if you say, 'Let me interview you about lessons learned from what you did,' they'll say yes. People aren't motivated to fill out forms, but they are motivated to tell their stories."
A good interview, with good questions, will produce a story that contains far richer information than any boxes on a form will provide, Bickerstaff says. And that's only half of it, she continues, because if you then share the information with others in the form of a story, as opposed to a fact sheet or a set of PowerPoint bullets, the people who receive it will find it far more useful—not to mention more interesting.
BMS conducted lessons-learned sessions with teams with the best success records at gaining approval from FDA advisory committees. The findings that emerged about their best practices were written up as stories that read more like articles in Fortune or Business Week than like standard corporate documents. Those stories were then made available online to other BMS teams—with impressive results.
"Ordinarily you're lucky if you can get through a committee review with a simple majority vote," Bickerstaff says. "In the past 30 months, we've had four drugs [gain approval], two with unanimous votes—15-0 and 18-0. That's practically unheard of."
KLA-Tencor
KLA-Tencor has two KM efforts underway, according to chief learning officer Lynne Stasi. She calls one the "people-side" initiative. Headed by Brent Bloom, senior director of the corporate learning center, it seeks to identify individual expertise in the 5,000-employee company with an eye toward "bringing together the best brainstorming groups for particular projects."
The other effort, headed by Efren Lopez, involves what many training professionals might call a top-end electronic performance support system. ("The more knowledge management is integrated into an actual job, the more it looks like performance support," notes consultant Rosenberg. "Maybe we'd be better off if we didn't try to make distinctions.")
The first phase of Lopez's initiative focused on a particular group of employees—support engineers who go into customers' manufacturing plants to diagnose and fix problems with KLA-Tencor's "tools." These tools actually are complex and expensive pieces of machinery used by microchip makers (Intel, Texas Instruments, etc.) to inspect chips and wafers for defects. "If something malfunctions on our equipment," Stasi says, "a customer can lose millions of dollars a day. So our field engineers are under immense pressure to fix the problem as quickly as possible."
That was the critical business issue with which to begin. Lopez's solution is a knowledge portal that an engineer in the field can access from a laptop computer. "The [system] knows who they are, what they're doing, what case has been opened for them, and what the customer's problem is," he says. "We can then push information to them to help them diagnose and fix the problem."
That online help includes not just schematics and such, but simulations that allow the engineer to try various fixes. "You use the simulation to help troubleshoot the problem," he says. "If your fix in the simulation works, then you duplicate it with the actual equipment."
A system called iSupport extends similar online diagnostic help directly to KLA-Tencor's customers. Suppose a plant technician is working a late shift and a problem develops with a KLA-Tencor tool, Lopez explains: "It's night. No customer-support engineers are around. You can open a case online and have a tech-support person from KLA-Tencor help you diagnose the problem remotely."
Microsoft: How can we help?
Like Lopez's model, Microsoft's version of knowledge management looks a lot like electronic performance support. "We have hundreds of products being developed at the same time," says Cedric Coco. "We solve the same problems again and again every day. Thousands of engineers are writing code, making products and editing features. The more we can integrate the lessons they learn into the work system and make them transparent, the more we stay ahead of the game."
Coco adheres to the performance-technology (also known as the performance engineering or "systems") school of thought, which holds that "training usually should be the last intervention you try, not the first. When I need to get a task done, I don't have time to go take a training course. If I can borrow the information from somewhere else in the company, just in time, that's great."
Accordingly, the KM system for Microsoft engineers is designed to provide maximum on-the-job help in minimum time. Suppose an engineer has to write a specification document. "What we want to do," Coco says, "is give them an example, a template, and then expose them to a best-in-class document they can leverage."
Or suppose the engineer has to do a threat model analysis against the code he has written. Because this is something he might do only a few times a year, the procedures he learned in a formal training course may be fading memories. "He can go immediately into the system," Coco says. "The system knows who he is, what his team works on, and the procedure they follow. So it can say, 'OK, here's the procedure your team wants you to follow. And by the way, here are some methods other teams have found useful as well."
If you want people to contribute ideas to such a system, Coco says, the trick is to design the beast so that people run it instead of it running them. Don't ask busy employees to spend half their time filling out standardized forms. "We use some templates and some formatting, but it's minimal," he says. "You can share a good idea without a lot of extra work."
As a way both to recognize contributors and to control the quality of information entered into the KM system, Coco allows it to operate at the team level: "The peers on your team decide which of your ideas goes into the system. So they can say, 'Hey, Sally did something good. We'll put that into our engineering handbook." That means that Sally's idea goes into the searchable repository for other teams to use.
In his plan to design a system that employees would embrace, Coco began with what almost seems an unfair advantage over companies that have tried to impose KM as a brilliant idea handed down from the executive suite: He actually asked the users what they would find useful. In 2004, when Microsoft decided it wanted to build this electronic infrastructure, Microsoft started by convening a series of focus groups. According to Coco, the basic question put to the engineers last year continues to be asked as the system is refined: Not, "What would it be nice to know?" but, "How can we help make you more productive?"
Reprinted from Training magazine, VNU Publications
Jack Gordon is editor-at-large for Training. edit@trainingmag.com
|