As companies continue to initiate new knowledge management projects, new knowledge manager jobs continue to be advertised, and virtually every major software vendor (including IBM and Microsoft) continues to offer and advertise knowledge management technologies. Knowledge management is headed toward becoming a permanent fixture in the business landscape.
So if it's going to be around for a while, it might be useful to think about what the next wave of knowledge management will be. But first I'd like to describe what I think the first round was all about. That way, if you don't find my thoughts credible, you can simply skip to another article about message-oriented middleware or whatever.
In Round One, companies managed their knowledge assets in the same way they managed their physical assets: capture the asset and put it in one place so that it can be easily accessed. For physical goods, the storage point was the warehouse; for the intellectual equivalent, it was the knowledge repository.
Today, in many companies, the knowledge warehouse is full. In fact, one company I know has more than 3600 databases and millions of "knowledge objects". Its shelves are overflowing, and seekers of knowledge are having a difficult time finding what they need.
When companies realised they had too many physical assets in the warehouse, they began thinking about supply chain management or closely matching the supply of goods with demand and reducing inventories to what was actually needed for production processes. Companies that warehouse knowledge are beginning to need the equivalent of supply chain management. I'm pretty confident about that one.
So what, in Round Two of knowledge management, will companies do when they realise they have too many knowledge assets in the warehouse? It's a question that raises two concerns. The first is about the second round of knowledge management (whereas my second concern is about the first round).
Those who have followed my intellectual interests closely won't be surprised to hear that the answer involves knowledge work process improvement. If we're going to fit the supply of knowledge to the demand for it, we need to start tinkering with how knowledge workers do their jobs. Let's assume, for example, that our objective is to improve the performance of the new-product development process within the organisation and to inject knowledge into it at appropriate points. We think that researchers, engineers and marketers who work in the process should capture more of what they learn, share the knowledge they gain with other new product development teams, and use internally and externally derived knowledge more effectively to avoid mistakes and employ best marketing practices. Seems simple enough, yes?
In KM Round One, we would have built a Web or Notes repository for marketing information and instructed the new product developers to go at it. If it were possible to do Round One again, we'd do the same thing, except we'd call it the "New-Product Development Portal".
The problem with Round Two is that the people who develop new products probably already have demanding jobs. Asking them to record the lessons they've learned during a hard day's work, or to spend extra time searching through an extensive repository before undertaking an important task, is unlikely to meet with a great deal of success. Instead, knowledge management has to be "baked into" the job. It's got to be part of the fabric of the work to import knowledge when it's needed and export it to the rest of the organisation when it's created or acquired.
But the only way that knowledge activities will be part of the fabric of the job is to design the job from scratch, putting knowledge in and taking out activities that are no longer as critical. The tricky thing, however, is that knowledge workers don't really like other people telling them how to do their jobs. Autonomy is a key objective of many knowledge workers; it's one of the main reasons they work so hard to become one. So redesigning knowledge work can't be like re-engineering -- top down doesn't cut it. Come to think of it, totally top-down re-engineering probably doesn't work very well for any kind of job.
Avoid Snap Judgements
There are a couple of ways to give knowledge workers more confidence in the results of a job redesign. The most important thing is to have them participate in the design process. Of course, that's a bit difficult if you are working on processes performed by thousands of workers. But regardless of the number, you'd better have a very strong representation by the people who actually do the work on your redesign task force (or whatever you want to call it).
You may feel that such representation will limit the degree of change you can bring about in the new process. You're probably right, but you have to live with it. If all your targeted knowledge workers resign because they don't like the new way you want them to work, the CEO will probably be peeved. At you.
The second way to build trust among knowledge workers and show them that you really understand their jobs is to have the process analysts actually hang out with the workers in question. It means analysts sitting next to workers, going to their meetings, getting to know them and their problems, even videotaping their work steps for later study.
That fraternisation prevents the analysts from coming to any snap judgements about the process that would not fit with the skills, backgrounds or preferences of the knowledge workers. Again you may be asking, "Why should they have to like their jobs?" The answer is that, if they don't like their jobs, they walk. And replacing knowledge workers today is as hard as getting your first choice in the Olympic ticket lottery.
Find Key Workers
Now you can't redesign every knowledge job in your organisation. So which ones should you go after first? I've found that there are usually one or two key knowledge jobs in an organisation that are the focal point of any attempt to use knowledge more effectively. If the workers in this key job create, use or share knowledge, the rest of the organisation will benefit greatly.
At a semiconductor equipment company, for example, it was obvious that if the project managers who led the development of new models wrote down or otherwise shared what they learned with other project managers, the overall process would improve at a rapid rate.
It was also apparent that the incumbents of the job spent most of their time fighting fires, had little interest in sharing or using stored knowledge, and had no process orientation at all. It would certainly be a challenge to redesign their jobs, but it was easier than redesigning a lot of different jobs, and the status quo was no picnic, either.
So what did the company do? Last I heard, they had continued to wimp out and leave the project managers alone. It's not the first time a client has ignored my consulting insights, and it won't be the last.
Those of you who are still paying close attention will recall that I said I would address two concerns about knowledge management in this column. While I was quite confident dealing with the first, with the second I have some doubts about the right course of action. What worries me is that knowledge management as a concept grows broader by the day, and I am afraid that it will eventually collapse of its own weight.
Define KM Concepts
Knowledge management started in most companies as the creation and use of electronic repositories, with a healthy dose of human issues like having a knowledge-oriented culture and structure. Since then, however, it has grown amoeba-like to swallow a variety of other topics. Organisational learning, for example, is increasingly being drawn into the KM fold, as are other variations on the learning theme (distance learning, performance support and so on). Business intelligence, which I define as the art of turning data into knowledge, is now often discussed as a branch of knowledge management. Competitive intelligence is moving in the same direction.
Is it a problem that knowledge management is an ever-growing collection of stuff? One positive side of the agglomeration is that all of the different components do have something in common, that is, a goal of using knowledge to achieve some business objective, the combination of human and technological enablers of change, and a focus on capturing and disseminating knowledge. With all these shared ideas, perhaps knowledge management is a perfectly acceptable label for the "umbrella" that covers all the concepts.
But the drift and accretion of knowledge management surely has a downside. In referring to so many different ideas, the concept will probably lose focus, and knowledge management initiatives may try to do too much. As happened with business-process re-engineering, expectations may get too high about what can be accomplished through the wonders of KM. Further, the increasing number of knowledge-management-related concepts may lead to scepticism and cynicism about the entire undertaking. As one manager related to me several years ago, "Whenever I have a project I want to get funded, I call it re-engineering'." We wouldn't want the same thing to happen with knowledge management.
I guess I'm a conceptual conservative. My recommendation would be to try to keep some of these knowledge-related ideas separate from each other, each with its own identity. It might even be worth creating an official definition of each of these concepts within your organisation. If the glossary is accepted, it would greatly ease the process of discussing the topics. Defining knowledge-oriented concepts may seem to be a somewhat academic exercise. But if you're working primarily with knowledge, it makes sense to clarify what different types of knowledge mean.
Thomas H Davenport is a professor of management information systems at Boston University School of Management and director of the Andersen Consulting Institute for Strategic Change. He can be reached via e-mail at firstname.lastname@example.org
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.