|With all its talk of tacit knowledge and transformation, knowledge management too often appears to be a dark art, a form of magic more appropriate to Hogwarts School than the IT department.|
In fact, the opposite is the truth. Knowledge management is increasingly understood to be the solid foundation on which all significant IT projects must be built if they are to have any chance of success. When information technology expands beyond the limits of automating entrenched business processes it must address the creativity, experience and collective wisdom of the people whose work it is supposed to enhance.
We should have learnt by now that IT systems that don't take the human dimension into account are bound to fail. And, when it comes down to cases, knowledge is the human dimension - 'information,' as Thomas Davenport and Donald A Marchand put it, 'within people's minds'. Knowledge management is the art of extracting this information and usefully employing it.
More than anyone else, Davenport and Marchand are responsible for introducing the concept of knowledge management, so I guess we ought to listen to them. And when we do, this is what we hear: knowledge management is all about bringing technology and people closer together in order to achieve business objectives.
Inevitably, when the business objective is survival - as it is these days all too often - knowledge management becomes even more fundamental.
It is now more than ten years since Peter Drucker - the man who practically invented the concept of management consultancy - argued that knowledge would soon sideline capital and labour to become the only factor of production that matters. 'Value,' said Drucker in the Harvard Business Review (November/December 1991), ' is now created by "productivity" and "innovation" - both applications of knowledge to work.'
There are lots of ways to apply knowledge to work - learning about your customers rather than fitting them into some predetermined box, taking a thoroughgoing approach to training and staff development, investing in expensive data warehouses, encouraging staff to meet and exchange ideas and information in an informal setting, building a corporate intranet.
These have all been tried, under the banner of knowledge management, by different businesses at different times. Indeed, the variety of apparent KM applications - from Xerox's 'distributed coffee pot' to BP-Amoco's in-house multimedia network - can cause confusion among technologists and lay people alike.
In fact, many organisations - and the individuals within them - are uncomfortable with the ideas of knowledge and knowledge management in a business context. When even the experts don't seem able to come up with an agreed definition of knowledge, how can they expect ordinary people to understand? And what people don't understand often frightens them.
IT departments themselves, whose job it should be to implement knowledge management techniques and systems, are often as fazed as everyone else. Perhaps more so, because their own power and authority might seem to depend on not sharing their knowledge, on keeping it buried inside their own minds.
For example, I was recently involved in a consultancy exercise for a major corporation. Our objective was to help the IT department decrease its costs and increase the rate at which it delivered applications to users. The first thing my colleagues and I noted was how little the project team seemed to know about their department's own operations - which, if any, applications development methodologies they employed; how much they were spending on support and maintenance; how many printers they had in each of their different sites.
The information existed somewhere within the organisation, but nobody had much idea of how to find it. Even worse, nobody had much desire to do anything about this situation.
There were a number of reasons for this.
Sometimes, members of the project team would say that it was not their responsibility to know the details of activities outside their areas of immediate concern. At other times, people would suggest that any attempt to discover information would involve confessing their own ignorance. Often these reasons were thinly disguised excuses for mistrust or lack of understanding. At no time did the team seem to think that sharing knowledge might actually help them fulfil their task.
To us, what seemed at first like a simple cost-effectiveness exercise rapidly became a matter of knowledge management - getting at knowledge and putting it to work.
In our case, the solution was obvious. We needed to encourage the flow of information within the IT department as an essential precursor to the introduction of effective change. An intranet was already in place, so we recommended that it be upgraded and enhanced. Nothing could proceed without a rigorous inventory of skills and systems, and the information thus obtained should be open to all within the IT department.
Once these two ingredients were in place, the project team could seriously turn its attention to rationalisation and the exploitation of existing resources. The hard part was persuading people that an open culture, shared knowledge and easy communications were nothing to be frightened of.
There is a lesson of general applicability to be drawn from this.
Any project involving change within an organisation - from a corporate merger to an office move - is likely to involve the discovery and application of knowledge. Knowledge management is a critical aspect of almost every significant development within an enterprise. But it is, as Davenport and Marchand have observed, 'as much about managing people as it is about managing information and IT'.