Eine Knowledge Base strukturieren

Per default regelt die MediaWiki-Software den Zugriff auf Dokumente über die in Teil IV angesprochenen Namensräume – was beispielsweise sicherstellt, dass Guidelines nur von berechtigten Personen bearbeitet werden können.

Doch das Konzept passt nicht immer. Es ist damit beispielsweise nur schwer möglich, alle Dokumente einer Abteilung zu schützen. Daher entscheiden sich viele Organisationen, die Berechtigungen für ihr MediaWiki genau anders herum aufzubauen: Dort reservieren Administratoren die Namensräume für Teams und Arbeitsgruppen und markieren mit den Kategorien die Dokumententypen.

Auch dieser Ansatz mag nachvollziehbar und machbar sein, er hat aber gravierende Nachteile – Namensräume in MediaWiki sind gut, um etwa einer Gruppe einen Raum einzurichten, aber das Konzept skaliert nicht. Sobald ein Wiki über viele Gruppen verfügt, wird die Verwaltung der Zugriffsrechte auf die Namensräume extrem aufwändig, womit nicht zuletzt auch die Gefahr von Fehlern steigt.

Auch wenn das passende Berechtigungskonzept immer auch vom individuellen Use Case abhängt, wollen die meisten Knowledge Bases doch primär Inhalte zum Teilen bereitstellen, nicht sie wegsperren. Genau hier erweisen sich flache Berechtigungskonzepte als vorteilhafter, vor allem in der langfristigen Perspektive. Um den nötigen Berechtigungsschutz für sensible Team- oder Abteilungsinhalte zu gewinnen, bieten sich separate (Unter-)Wikis an (siehe Abbildung 1)

Abbildung 1: Innerhalb der zentralen Knowledge Base lassen sich Inhalte in separate Unterwikis aufteilen, für die verschiedene Zugriffsregelungen gelten

So können Mitarbeiter der Personalabteilung in einem separaten Wiki arbeiten, ohne Rücksicht nehmen zu müssen, dass Sie beispielsweise aus Versehen Protokolle oder andere interne Informationen aus dem Bewerbungsmanagement an nicht-berechtigte Nutzer freigeben. Im zentralen Wiki mit der internen Knowledge Base veröffentlichen Sie nur noch die Inhalte, die für alle wichtig sind, beispielsweise das Mitarbeiterhandbuch, Urlaubsregelungen, Fortbildungsmaßnahmen, und so weiter. Auch das Wiki der Geschäftsführung ist sauber getrennt von den Informationen, die die meisten Mitarbeiter für die tägliche Arbeit brauchen.

Die Grundstruktur des Wikis bleibt auch im Unterwiki erhalten: Namensräume für Dokumenttypen und die Kategorien für Themengruppen können auf Teamebene anders sein, sie müssen es aber nicht. Die „Themengruppen“ sollten Sie vermeiden so lange es geht – damit fügen sie eine weitere Komplexitätsstufe hinzu, die in den meisten Fällen nicht benötigt wird. Halten Sie alles so schlank wie möglich.

Die Einrichtung eines neuen Wikis muss zentral und nach definierten Kriterien erfolgen, sonst droht das, was Wissensmanager den „Confluence-Effekt“ nennen. Auch Atlassians Wiki-Software Confluence setzt primär auf sogenannte „Spaces“ (Räume), um Inhalte zu organisieren. Jeder Benutzer kann mit wenigen Mausklicks Spaces anlegen, was sie für die Arbeit im Team sehr attraktiv macht.

Allerdings erweisen sie sich schnell als Schrecken der Administratoren: Die finden schnell unzählige, schnell verwaiste Spaces vor und sehen sich so mit dem Gegenteil einer kollaborativen Knowledge Base konfrontiert. Das Ziel, gemeinsam an Inhalten und strukturierten Themen zu arbeiten, wird durch das massive Wachstum der Wissenssilos konterkariert.

Anders bei BlueSpice farm: Hier erhalten sie das Beste aus beiden Welten. Einen zentralen Marktplatz für das Wissen und dort, wo es nötig ist Séparées in Unterwikis, die ohne großen Aufwand eingerichtet werden können.

Die Hallo Welt! GmbH ist das Unternehmen hinter der Open-Source Enterprise-Wiki-Software BlueSpice, die mit über 1 Mio. Downloads in mehr als 160 Ländern verbreitet ist. Das Regensburger Unternehmen baut seit 2007 kollaborative Software für Wissensmanagement und Online-Dokumentationen.