For many organisations, knowledge is the most critical asset, and in modern work environments that might be spread across geographically diverse regions or organised into virtual teams, managing knowledge is growing more difficult. The formalised practice of Knowledge Management has been the subject of research and corporate application for more than two decades now, but many of the initiatives have not delivered the promised business improvements because of their complexity and their focus on technology rather than human aspects of knowledge.
Today's wiki software has matured to a point where the technology 'just works'. The concepts are simple and developers have put a great deal of attention into the usability and social aspects to make wikis fun and easy to use. Even though wikis are not traditionally described as 'Knowledge Management' tools, they are now in a position where they can deliver many of the long awaited benefits of Knowledge management.
The knowledge management benefits are actually a side effect of using a wiki. A wiki site is usually installed for reasons other than knowledge management, such as as a intranet, a project management tool, a collaborative working tool or as a solution to some other important business function. The knowledge management features of a wiki site can emerge from its usage as users incorporate wiki work methods into their day to day work processes. The key knowledge management processes of capturing tacit knowledge and disseminating explicit knowledge can happen automatically without any extra effort from users. Features such as recent changes, document history through version control, comments and simple hyperlinks can turn a simple page from a container of information into a source of knowledge.
The open nature of wiki software encourages communication and collaboration and capture of information about the organisation that remains as a permanent and accessible knowledge base. The low entry barrier to wiki usage promotes its use and further more, the dynamic nature of a wiki site allows it to change and grow with the organisation and its people.
As a wiki consultant, I find that the knowledge management aspects of wiki installations are one of their great selling points for enterprise adoption.
In many situations where wikis were initially installed as an experiment, usage grows beyond expectations and starts to address a range of unexpected needs. Wikipedia, for instance was initially setup as a side project to help collect information for Jimmy Wales and Larry Sanger's Nupedia project, but Wikipedia grew beyond expectations and eclipsed Nupedia.
In my experience in setting up wikis for various organisations, I have seen wikis grow to be used in all sorts of creative and unexpected ways. A few examples are as a file server, a training manual, for keeping timesheets, an asset register, an organisation's classifieds, and so on.
One of the more interesting areas that wikis are encroaching on is the content management system space. CMS Software, like wiki software, can be broadly defined as applications to manage web pages, but they become very difficult to define more precisely when you start looking at the nuts and bolts. An appreciation of how diverse and complex the CMS and wiki application space has become can be seen from the contents of the CMS matrix and the wiki matrix sites. CMS Matrix is tracking hundreds of applications with about 150 features compared, and the wiki matrix site is tracking about 30 applications with about the same number of features compared.
So according to the two matrix sites, Wiki and CMS software have about the same number of features and a deeper analysis shows that many of the most important features area actually common to both. So it is more interesting to look at the differences than the similarities. For me, the difference that tells the most about two applications is workflow. Wikis are typically weak in workflow and CMS are typically strong. Some see this as a weakness in wiki software, but to me the lack of workflow support in wikis is symptomatic of the way they work, developers have not bothered to add much workflow to wikis for the simple reason that there is little demand for it. After you have worked with a wiki for a while, you soon find that you just don't need workflow. Features such as version control, favourite pages, recent changes and the advantage of a low barrier to entry make workflow redundant in most situations.
So if you are making a decision about using a wiki or a CMS application for your web site, and you feel that workflow is important, then you need to analyse why you need workflow.
If you think you need workflow because the process of publishing stuff on your web site is so onerous and painful that you don't want to go through the process more than necessary, then think again. It is so easy to publish in a wiki that you don't even need a 'webmaster' to do it for you. You don't need a workflow process to hold your hand and make sure you don't forget anything along the way. With a wiki, just go to the page and edit it! If you make a mistake, revert to a prevision version, or just edit it again!
If you think you need workflow because you want to control the content, then think again. The collaboration features that are fundamental to a wiki lend themselves to content control. Because a wiki is so easy to use, the responsibility for publication of content can be in the hands of the people who are responsible for the content itself. Wiki software gives users many tools that allow them to take this control, for instance, you can subscribe to get notified of changes to a particular page, you can check the recent changes or get a daily digest of any changes to the whole site. At an organisational level, perhaps you could assign someone to review all recent changes once a day and give feedback to authors. You will find that your staff will not vandalise the site and the correction of mistakes and errors can be managed to provide a positive learning process.
Other than restricting anonymous or public access, I don't like adding permissions to a wiki, but if necessary, it is possible to restrict edit and/or read permissions of sensitive content to just the people who control the content (many enterprise wiki software applications can do this).
When considering workflow and CMS, consider using a wiki instead. Ask yourself, is there a significant risk that a bad page might be visible to the readers for a short time? How likely is it and how bad could it really be? Balance that against the advantages of content that is alive and updated regularly.
I see a CMS as a way of putting content on the web, but a wiki is that and more. A wiki is a place to get things done.