Do you agree with these two KM assumptions?

A recent paper from the Gartner group seems to contain two basic assumptions about knowledge management which I think are worth addressing. See what you think.

The Gartner paper is entitled Automate Knowledge Management With Data Science to Enable the Learning Organization, and contains the following blocks of text:

“The capture of expertise and experiential knowledge diverts experts and skilled professionals away from productive work. Project managers, software engineers, product developers, hiring managers or customer support agents may be asked to document their work; to participate in peer-to-peer communities to capture and share expertise; to work in more open and transparent ways to encourage serendipitous connections and information flows across an organization; or to shadow peers and learn from observation. But for every minute they do this, it is a minute taken away from doing what they are supposed to be doing”.

“Although still relatively immature, and requiring much manual fine-tuning with domain as well as technical expertise, the “body of knowledge” that powers smart machine movers, sages and doers is extracted automatically by analyzing, classifying, labelling and correlating volumes of structured and unstructured data, including free-form text”.

Now these two chunks of text seem to me to be based on two assumptions. Let’s look at these one by one.

The first assumption is that “knowledge management is not real work”. Note how they say “diverts away from productive work – taken away from what they are supposed be doing”.  So they do not see KM as productive, nor do they see it as something a knowledge worker should be doing.

But KM is productive – it may not produce a tangible object which can be sold to a customer, but it produces knowledge which can be used to improve processes or innovate new products in the future, and so adds value to the business. In some cases, such as R&D, knowledge is the only value. In Pharma, for example, the success rate of R&D projects in delivering a successful product is only 2% or 3%, and in every other case knowledge is the only product. And as the development manager at Toyota said (and I paraphrase); “In Toyota NPD our job is not to produce cars but to produce knowledge, and from that knowledge great cars will emerge”. Producing knowledge is an investment in the future; producing products gives value in the immediate term while producing knowledge gives value in the longer term. KM is productive work.

And maybe KM is something that everyone should be doing, or at least contributing to. Who else should contribute if not the knowledge workers? And you cannot say that the job of the engineer is only engineering, the job of the salesperson is only to sell, or the job of the IT coder is only to write code. All of these people have other things to consider – they need to bear finances in mind, and safety, and quality, to name just three. They can’t say “I don’t want anything to be involved in quality or in safety – just let me do my real job”. The real job needs to be done within a number of contexts, and knowledge management is one of them.  Imagine an airline pilot saying “I am not going to take part in this lessons meeting about my recent near miss, because this is a day taken away from what I am supposed to be doing”. That airline pilot would not keep their job for very long, because the aviation industry knows very well the value of knowledge and of knowledge work, and knows that KM is something pilots need to contribute to.

But if there is pressure to balance the demands on the knowledge worker, between their short-term delivery of product and their long-term delivery of knowledge, can smart machines take up the slack?  The answer to this depends very much as to how much knowledge you think lives in the “volumes of structured and unstructured data, including free-form text”.

Personally I don’t think there is much knowledge in there at all.

The vast majority of structured and unstructured data and documents are work products – the outcome of knowledge work, but not containing the knowledge itself. For example:

• A CAD drawing may show you a design for a product, but does not help you know understand the process of design, nor how best to design the next product;
• A bid document tells you how a bid was constructed, but does not contain knowledge of why the bid was won or how to improve bid success;
• A project plan tells you how a project was planned, but contains nothing about project best practices.

Knowledge is not created through work, it is created through reflection on work, and it is captured not in work products, but in knowledge products such as lessons learned, best practices, guidelines and checklists. If those knowledge products are not created by the knowledge workers, because “that would be a minute taken away from doing what they are supposed to be doing” then the machines will have no knowledge to find.