Structure a knowledge base
Part VI – More use cases
Articles I to V in this series presented the background knowledge needed for the basic concept of an internal knowledge base and for team wikis. But knowledge management and wikis can do much more.
The fact that the possible applications in corporate contexts are almost limitless becomes evident again and again in the daily work with customers of Hallo Welt! Classic examples of the use of wiki-based solutions in the professional environment are:
- Process management (processes, work instructions, roles, charts of organizational structures, audits, roles)
- Documents that are legally binding or required,
- Documentation (IT, technical, customer),
- Organization manuals,
- event management,
- risk management,
- directories, catalogs – any kind of lists with metadata.
Namespace or separate wiki?
It makes sense to logically continue the structural concept described so far: Process descriptions, for example, could be given their own namespace “Process”. But the decision as to whether a namespace should be set up and what should be found there should be made as pragmatically as possible – after all, employees have to work with it every day and should be able to find content quickly.
In all the use cases described here, there may well be criteria that justify separate (sub)wikis. Scope, logical structure and access authorizations are also usually the determining factors here.
User acceptance is the benchmark
The generic structure concept described in this series of articles can almost always be perfectly adapted to requirements, but also offers you room for your own, deviating organizational forms at any time.
Again, no one is served if a new system is purely doctrinal and implements knowledge management perfectly, but is not embraced by employees. The benchmark for successful knowledge management solutions (besides openness and sustainability) is, in particular, usability and the quick retrieval of desired information – in everyday work.
Solutions that don’t meet this fail to gain acceptance – regardless of the technology used.
Is multilingualism worth the effort?
A special case is the problem of multilingualism. Due to the complexity, this series of articles can only touch on that.
In the simplest case, language variants end up on subpages created with a template and linked with a plugin like the “Language Switcher”. This allows readers to switch between language versions with one click – represented by a flag icon, for example. However, when planning, it should be kept in mind that subpages are actually intended for in-depth information.
In the age of online tools such as DeepL or Google Translate, employees have good translation tools at their disposal. This is certainly another reason why fewer and fewer companies are taking it upon themselves to maintain multiple languages and thus almost double the effort. In the long run, it only makes sense to have multiple languages in a wiki in very few cases.
However, those who are forced to maintain information in different language versions, for example for compliance reasons or in favor of accessibility, should consider adopting the Wikipedia strategy with separate, stand-alone wikis for each language. However, keeping content in sync is a separate, extensive topic.
To learn more about the possibilities BlueSpice offers in terms of content translation, check out our post from BlueSpice Product Day 2022 here on YouTube.
Would you like to receive this series of articles as a complete PDF?
Just send a message!
Hallo Welt! GmbH is the company behind the open-source enterprise wiki software BlueSpice, which is distributed in more than 160 countries with over 1 million downloads. The Regensburg-based company builds collaborative software for knowledge management and online documentation since 2007.