Eine Knowledge Base strukturieren

Teil V – Zugriffsberechtigungen: Wer darf die Informationen sehen?

16. Dezember 2022

Die in den ersten vier Teilen gewählten Konzepte und Strukturen haben Auswirkungen auf die mögliche Nutzung des Wikis – und somit auch auf die notwendige Konfiguration, beispielsweise rund um erlaubte und nicht gestattete Zugriffe. Nur in seltenen Fällen darf schließlich jeder Mitarbeiter alle Daten des Unternehmens einsehen, meist sind dedizierte Berechtigungen zu vergeben.

Mediawiki-Default: Zugriffsrechte via Namensräume

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.

Effizientere Lösung: Flache Berechtigungskonzepte in (Unter-)Wikis

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 denn eine Organisation entlang von Namensräumen oder Kategorien, 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 Knowledgebase 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.

Unterwikis helfen, Themengruppen vermeiden!

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.

Planung versus Wildwuchs: Spaces und Unterwikis

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.

Best of both worlds: BlueSpice farm

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.

zurück zu Teil IV
vor zu Teil VI

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.

Autoren: RH/MF

Teilen Sie diesen Beitrag!

Sofern nicht anders angegeben, sind die News auf dieser Website lizensiert unter Creative Commons Attribution 4.0 International Lizenz.

Weitere BlueSpice News

  • Kleine Pause über die Feiertage

    19. Dezember 2022

    Die Hallo Welt! GmbH befindet sich von 24. Dezember 2022 bis einschließlich 1. Januar 2023 im Betriebsurlaub. Sie wollen uns trotzdem kontaktieren?

    Weiterlesen

    +
  • Zugriffsberechtigungen – Wer darf die Informationen sehen?

    16. Dezember 2022

    Teil fünf der Serie klärt die Frage, wie Zugriffsrechte sinnvoll realisiert werden können. Durch Namensräume oder (Unter-)Wikis?

    Weiterlesen

    +
  • Kategorien, Dokumententypen und Namensräume

    9. Dezember 2022

    Im vierten Teil bringen wir Struktur ins Unternehmen und ordnen Themengruppen und Dokumententypen den passenden Kategorien und Namensräumen zu. Dieser Ansatz ist flexibel und anpassungsfähig.

    Weiterlesen

    +