I've been going through some of my old University papers, and had completely forgotten that I'd wrote one on knowledge management systems. I have some thoughts on what I was taught and how I've unintentionally tried to apply it in my work.
It's a little funny, looking at the optimism of both the course material and myself at that time. The way KMs are presented is one where they are simultaneously the Library of Alexandria and a complete necessity to even the smallest of businesses.
I suppose in a sense that's true. Businesses need processes and procedures. But most small businesses (I'd expect) use the collective experience of staff as their KM, rather than some ITIL-approved software package. It isn't really debatable which is better - you can't easily index, search, back up, or restore experience. But not doing that and leaving it up to the experience of your staff is free. It's easy. And you don't need to pay a penny. Which is why in the real world, businesses often forgo KM.
But yes; the material was very much written for a perfect world. Of which we are not occupying.
My views on how best to implement a knowledge management system have changed a bit. I'm jaded and cynical. Or if I'm being nice to myself - I've mellowed. Whereas ten years ago, I'd argue for an organisation-wide push where each and every user is also a contributor - these days I'd go a different route.
Consider a wiki - not difficult to set up and manage. Everyone can use it. You have complete buy-in from management who have directed other teams to contribute.
And then you read some of the articles contributed by other teams. They skip details here and there. The articles are perhaps untagged. Some pages are stubs that say "Ask Dave". Inaccuracies abound. Hell, some pages link off to another KMS that team had been running for a while. The value of those contributions is debatable.
This isn't about shitting on people who have more important things to do than documentation, or even people that dislike documentation. It's more about recognising that quality of output is variable. That the intention behind the documentation is relative to the team the author works within, or how the author understands the requirements given. That sharing a language doesn't mean sharing terminology or priorities.
Academically, these properties should be handled in some sort of process prior to writing the article. In practice, that's not how it works. The amount of time it would take to define the minutia can be unfathomable - and that time costs money. So instead, steps are skipped, priorities shift, and islands of endemic knowledge begin to form. The KMS is usable but vocabularies differ. A 'RURI' is an 'internal reference', 'DDI', and 'IAX ID'.
I don't think top-down direction, or working-groups, or a one-man-team to go-it-alone can solve that problem. Businesses change contantly; teams adapt and fine their own place, and their own language, in the new business context. The solution needs to be ongoing and regular (this is in fact what ITIL is about). At least not for the small business. If you're IBM, then of course you can of course afford an entire department implementing top-down direction.
Thus, I think the solution for the small player is to (1) accept that their teams are islands, and (2) to instead encourage trade as a means to improve-but-not-perfect. That has a few elements - which I'll cover below:
I do not, to be clear, exist under an illusion that this is some sort of axiom. That I've cracked the problem. I'm just an idiot that's set up KMS' and gotten a tad annoyed about article quality and consistent language. So don't blame me if any of the suggestions on this page burn your house down.