Regular readers should know by now how I indulge myself by taking samples of text and unpacking them to figure out whether they make any sense and whether the sense they make is the one the author actually intended. Some may recall that back in January I decided to do this for CRM, my point being that, as far as the technology products were concerned, all three of the "components nouns"—"customer," "relationship," and "management"—had been (in bowdlerized form) fouled up beyond all recognition. By the time I came to the final noun, I had built up enough evidence to argue "that technology providers have no idea what they are managing or why they are managing it."
Today Lou Paglia wrote a post for his CoRrElate blog about how knowledge management is still a "pain point." It should be no surprise that my argument about "management" in CRM is just as valid when it comes to knowledge management. The difference is that, now that knowledge management is on the down-side of the Gartner hype curve, its failure to address the two questions Lou used to lead his post is now generally recognized! Those questions were:
- What are people trying to solve?
- What is their pain point?
To some extent the "knowledge management mess" was a product of technology providers getting hung up on the word knowledge when they should have been worrying about talking about it in productive ways. Part (but hardly all) of the blame can be laid on Nonaka and Takeuchi, whose introductory chapter about "knowledge" is so shot through with holes that even a "gentleman's C" college freshman can find some of them! However, a more important problem probably resided with all the different researchers who saw knowledge management as an opportunity to promote a personal agenda, whether it involved better data bases, communities of practice, Socratic dialogue, Marxist emancipation, or Heideggerian phenomenology. At least, in the old joke, the elephant only had three blind men groping at it!
So, if we carve off all of this fat, is there any meat left on the bone? One important fact that may still need to be recognized is that, for all of their promotion, Google and Wikipedia are not "solutions to the knowledge problem" and are as much part of the fat as the more elevated disciplines I cited in the preceding paragraph. I tried to explore this observation back in February in my response to the announcement the Middlebury College history college would not accept Wikipedia as an "acceptable citation." The title of that post was "Research is not about the Answers!;" and neither is knowledge management.
Let me try to reinforce this claim by going back to Lou's first question: What are people trying to solve? As I see it, every organization, whatever its size, is a collection of people who know things. If we then take, as a premise, that the "business" of the organization is to satisfy one or more goals, then the most important problem in managing the organization is to conduct day-to-day operations in such a way that the people who know things are contributing to satisfying the goals. (I know that sounds simplistic, but that's what happens when you start carving off the fat!) The very phrase "knowledge management" disclosed the problem that this was not happening: The things that people were doing were not always leveraging what they knew; and the organization was paying for it with unsatisfied or poorly satisfied goals. Now I am too much of an anti-positivist to accept this as the whole story; but at least it provides a framework in which the broader story can be told.
One part of that broader story that is missing is that whole question of "knowledge sharing," which became a focal point of knowledge management technology and ultimately led many to ask whether or not Google (and/or Wikipedia) was doing a better job. This is where positivism loses its punch, because sharing is something that takes place among human agents and therefore belongs in the social world, rather than the objective world. Personally, I subscribe to a motto coined by one of my former colleagues who is now teaching philosophy at San Jose State: Knowledge cannot be shared, but it can be made sharable. It is not a question of whether or not knowledge is being "poured" into repositories such as databases or even Web pages crawled by search engines. It is a question of the social engagements that take place within the organization and the ways in which those engagements facilitate or impede the "flow" of knowledge. In other words it is all about "talk" (which can take place through digital, as well as physical, channels); and, if we read our Plato better than Nonaka and Takeuchi did, we discover very quickly that much of that talk is ultimately descriptive in nature. It is through such descriptive talk that the scope of who knows what "diffuses" (a favorite work in knowledge management circles) through the organization; and often that descriptive talk is best reinforced in contexts of demonstrably effective actions. In other words it's all about both what you say and what you do!
At this point we can loop back to the sentence Lou used to wrap up his post:
KM solutions must help people find relevant information, help people find where to look, help people find respective experts in the organization, help people discover relevant information that they wouldn’t know to look for and help people so they spend their time doing their jobs, not searching.
I would argue that, once you couple people doing things that lead to satisfying goals with a social climate that encourages descriptive talk reinforced by demonstrably effective actions, you have a KM solution! I apologize if this was a long trip; but, to paraphrase the old saw, there is no "royal road" to knowledge management. Personally, I still feel that knowledge management has more to offer than CRM does, but only because it has the potential to honor the human side of doing business much better than CRM, in its current incarnation, ever can.
4 comments:
Completely agree that KM is just as much about retrieving the information as it is about the use cases of the found information. Classic "means versus the ends" scenario.
Stephen, your analogy of KM and CRM is a very interesting one. In fact, I think think there is a real place for the merging point between KM and CRM.
At Factiva, we launched Factiva SalesWorks to assist users in corporations to find and manage their information on both their prospects and their current customers. Just recently, our SalesWorks team integrated into Salesforce.com to bring the solution even closer to the need.
Suffice it to say, there is a tie between many information respositories such as CRM and KM principles. Does a sales person have to search on their own to find relevant sales records to a key prospect? Would KM principles not assist (if executed properly) to assist a salesperson in accessing the relevant information?
The fundamental shift is for many to get over the stereotype that KM is simply "making a request of a central organization" for the answer. You bring this point to the fore quite well in your post.
Lou, this may sound too much like a linguistic game; but I personally try to draw a distinction between "principles" and "technologies." One may lead to the other; and, while it is more likely that principles will lead to technologies, I suspect that the flow can go both ways. However, there is still a distinction that needs to be recognized. Let me try to illustrate with an example with which I had direct experience.
The great "knowledge success story" at Xerox addressed the problem of knowledge diffusion among service technicians. This was a serious problem, because there were too many machine malfunctions that were not covered adequately by documentation (such as repair manuals). However, anthropological field work revealed that the technicians had evolved a work practice to diffuse undocumented repair knowledge. That practice was the exchange of war stories after work in some social setting. I would call the discovery that knowledge could be diffused through the exchange of war stories a "KM principle."
This "principle," in turn, led to a new "technology" in response to a question obvious to any large organization: Could a war story shared after work in Denver also be shared with technician in (say) San Diego? The result was Eureka, a very lightweight piece of technology through which technicians could submit war stories that (unlike Wikipedia) would then go through an editing process of validation. Once approved, the story would go into a repository endowed with a search engine (also very lightweight and equipped to handle the error codes displayed on the equipment). The resulting system fit on the laptop that technicians took on their service calls. The laptop, in turn, could be connected to the Xerox network to receive new stories and distribute updates to the repository.
The distinction between the principle and the technology was brought home to me when I learned of a customer with a totally different need (diagnosing breakdowns on a chip fabrication line) asked a local Xerox sales representative what the price was for a "shrink-wrap Eureka!" No such beast existed, and there may still be debate over whether or not it could have existed. From my point of view, the service "solution" was a principle: making knowledge sharable through the exchange of stories. If the chip-maker could not put that principle into practice, there would be no benefit in any shrink-wrap software; and, because this particular chip-maker had a relatively small and localized operation, there was no need for the scale-up that Eureka software provided to enhance the underlying principle.
There is another question: Will a solution for customer service work for some other aspect of operations? I know of some settings, for example, where there is very little socialization among sales representatives, because the "work culture" cultivates the feeling that they are competing with each other. On the other hand a Monday-morning quarterback might suggest that this kind of story-sharing might have helped the intelligence community "connect the dots" in the period of time between the two attacks on the World Trade Center.
In any case I would argue that my capsule "definition" of a KM solution still holds. However, I might want to amend it to deal with addressing how much of that solution is principle and how much is technology. If we could all do that, then KM might finally be able to shed its snake-oil skin (if you will forgive such a bizarre mixed metaphor)!
"anthropological field work"? I must say, that is the first time I've that term! I am going to have to use that, perhaps the next time I try to justify the cost of a focus group!
You make your point on the difference between principle and technology. And I would agree that principles should drive the creation and use of technologies, not the other way around. So your wife is correct.
And your post also does not only hit on the elements of KM needs but also sheds light on the key drivers of why I believe Enterprise 2.0 solutions will be successful.
Anthropology has been directed more at workplaces than at customer analysis, so I would not advise confusing workplace anthropology with focus groups! However, there is now a very rich literature in workplace anthropology (which also makes for a great source of anecdotes). The field work behind Eureka has been published in a book, Talking about Machines, by Julian Orr; and the book has an entire chapter on war stories.
Post a Comment