[This article also appeared in the online newsletter CRMAdvocate.]
We management consultants love to draw attention to our enterprise-scale experience. But we all work with smaller teams — departmental units within large companies, and small to midsize businesses. This surely is the case in Knowledge Management. Even at a mammoth multinational, the first beachhead for KM is likely to be a small functional group responsible for a specific type of work, such as an IT Service Desk.
Once, there were a range of effective KM solutions for small service desks — a reasonably stable low end of the market. But the low-end vendors have been swallowed by enterprise solution suppliers and moved up-market. At one pharmaceutical company I’ve assisted, a small, cost-center functional team needed a KM solution and sent its RFP to the usual suspects, only to see two of the household name vendors decline to respond because the budget for the license was under a quarter million dollars.
I have a couple of questions for my friends in the software space. With all due respect, guys…are you having a good time, in the present economy, explaining to people who run departmental service desks where they’re going to find $250,000 in defensible value in a problem resolution tool? 
I mean, of course, before the cost of integrating this tool with the incident management system effectively doubles that investment?
Oh, and have you noticed the 800-pound gorilla in the room? His name is Web 2.0.
You’ve heard of Web 2.0. What you may or may not have gathered is that it isn’t a new generation of technology. It’s a mindset. What it signifies is that the value to the business that your applications generate comes not from the designed-in features, but from the contributions of the end users — especially the content, but to an increasing degree the user-modifiable attributes of the software.
In fact, users are generating some of today’s most interesting software. The Open Source Community, driven by a geeky but grand ethic that software ingenuity is meant to be shared for little or no cost, has spawned thousands of useful applications, including many that look and act a lot like KM systems.
Guys, who’s really your competition in the problem resolution space? Heh…you’re all looking at each other. Have you seen what wikis can do?
In case you’ve never tried one, a wiki is basically a user-editable web site. The most famous example is, of course, Wikipedia, the user-generated, living encyclopedia. You don’t like the entry on your favorite rugby team, Iranian movie director or management fad? Just register, and you can go in and change it. It’s the wisdom of crowds, on steroids. It’s fast becoming the way knowledge proliferates across the globe. And you can now buy the technology that makes this possible.
The service desk world has begun to notice wikis in a big way — and to ask a really interesting question about them: What does a “conventional” knowledge management tool do that you can’t do with a wiki?
What is a knowledge management tool, really? It has three fundamental components:
- A repository for “solutions” — essentially a document management system;
- A means for retrieving solutions based on specific queries — generally some variant on search; and
- A workflow engine to manage the authoring, review, approval, publishing and eventual retirement of solutions.
There are service desks whose knowledge requirements are such that they cannot depend solely on search for quick and specific knowledge retrieval. These situations are very choice opportunities for KM vendors…but they’re rare. Most knowledge bases are small and narrow in scope, and, given the comfort nearly everyone has now with Google and its brethren, search tends to suffice.
A wiki will, in general, satisfy the content management and search requirements. Try a few — the web site WikiMatrix lists 80-odd wiki platforms, many of which provide at least trial access free. What they lack, by design, is the authoring workflow engine.
Orthodox KM proposes that the workflow be thoughtful, carefully designed to insure that all knowledge content is fully vetted for accuracy and style, and that the tool enforce or at least facilitate this process. So that’s a point of differentiation for the commercial problem resolution tools. (Actually, it might be a rather compelling point if the content and the process for generating it are subject to compliance audits.)
But, how much differentiation? Is it $250,000 worth? Or, conversely, would having to manage this workflow manually, without help from the tool, be okay if it saved $250,000 in license fee? Because, while some of the wiki platforms are marketed and priced like enterprise KM tools, there are quite capable little wiki platforms that can be had for as little as $50 a year. A few are actually free.
Could a service desk design a KM process that engineers around the limitations of wiki technology so that it actually meets its problem resolution needs? I suspect a growing number of them are going to try.
Peter W. Dorfman 
I concur – we could not convince our management to spend the $250,000 to upgrade our 1997 Service Desk and Self-Service KM implementation. Since we already have Microsoft SharePoint Services – we are converting our IT Support KM to MOSS. Not a wiki by definition – but it functions much the same. It gives us the three main components you list . I am excited about the possibilities we will have with our new site/tools.