Der Permission Manager: Rechteverwaltung in BlueSpice pro

Aber sollen mithilfe eines Wikis nicht Wissenssilos aufgebrochen und das Firmenwissen zentral vorgehalten werden?

Korrekt. Aber zentral ist nicht gleich zentral. Unsere Kunden wissen in der Regel, wo die Flaschenhälse und Fallstricke beim Zugang zu einer firmenweiten Wissensdatenbank liegen. Zwischen den beiden Konzepten „Jeder darf alles“ und „Alles liegt bei einem oder wenigen Mitarbeiter/n“ gibt es eine große Spielwiese, die wir mit unserem Permission Manager bedienen.

Kannst Du das etwas genauer erläutern?

Klar. Auf der inhaltlichen Ebene ist es zum Beispiel so, dass oft individuelle Rechte für Abteilungen, Arbeitsgruppen oder Projektteams benötigt werden, zum Beispiel für das Verändern von Artikeln. Anderes Beispiel: die Geschäftsführung. Hier gibt es in der Regel eigene Bereiche (Namensräume), die mit einem Sichtschutz versehen sind. Schließlich werden hier auch sensible Informationen ausgetauscht.

Ist ein Business-Wiki öffentlich oder teilöffentlich, sind auch hier meist ausgefeilte Regelungen nötig, um Missbrauch zu verhindern. Und dann ist da noch die technisch-funktionale Ebene: Stell Dir vor jeder Wiki-Nutzer hätte Admin-Rechte und könnte zentrale Einstellungen verändern. Da wäre das Chaos vorprogrammiert. Deswegen gibt es für entsprechend qualifizierte Mitarbeiter oder IT-Administratoren auch erweiterte Rechte.

Mit BlueSpice 3 wurde die Rechtevergabe überarbeitet. Warum?

Es hat sich herausgestellt, dass die Rechtevergabe in BlueSpice 2 wenig intuitiv und für viele Kunden zu komplex in der Anwendung war. Da nahezu jede Funktion im Wiki mit einem Recht verbunden ist, konnten seinerzeit mehr als 200 Einzelrechte individuell vergeben werden. Mit dem Launch von BlueSpice 3 haben wir deshalb das sogenannte Rollensystem eingeführt. Hauptziel war es, die Rechtevergabe deutlich zu vereinfachen. A propos kompliziert: Während bei MediaWiki die Rechtevergabe über eine auf dem Server liegende Datei erfolgt, bietet BlueSpice eine eine grafische Oberfläche, mithilfe derer sich Rechte durch das Setzen weniger Häkchen einfach und schnell vergeben bzw. anpassen lassen.

Das klingt gut. Aber wie genau funktioniert denn nun die Rechtevergabe?

Hier gilt es zunächst zwischen Benutzern, Gruppen, Rollen und Rechten zu unterscheiden. Ferner wird grundsätzlich unterschieden zwischen anonymen Wiki-Besuchern ohne Account und angemeldeten Wiki-Benutzer mit Account. Zunächst erfolgt die Verknüpfung einer bereits im System bestehenden oder vom Kunden selbst angelegten Gruppe mit einzelnen Wiki-Nutzern, meist Mitarbeitern. Diese werden also einer Gruppe zugewiesen.

Die Gruppen werden dann Mithilfe der sogenannten Rollen mit Rechtepaketen ausgestattet. Einzelne Rollen bündeln hierbei zahlreiche Einzelrechte unter einem sinnvollen Dach. Die Rechte können wikiweit oder für einzelne Namensräume vergeben werden (z.B. unterschiedliche Rechte für Mitarbeiter in verschiedenen Abteilungen des Unternehmens).

Typische Rollen sind:

• Leser: dürfen Inhalte lesen und kommentieren
• Editor: wie oben, dürfen zusätzlich Inhalte bearbeiten
• Reviewer: wie oben, dürfen zusätzlich Inhalte freigeben
• Administrator: wie oben, darf zusätzlich Einstellungen am Wiki vornehme

OK, verstanden. Es ist also nicht ganz trivial ein Rechtesystem aufzusetzen, oder?

Da stimme ich Dir zu. Da die Rechtevergabe in vielen Unternehmen eine zentrale Rolle spielt, sollte besonderes Augenmerk auf die Planung und Konfiguration gelegt werden. Auch wenn ein Wiki im Kern eine offene und transparente Anwendung ist, gibt es in vielen Unternehmen rechtliche Anforderungen und interne Regelwerke, die eine Zugangsbeschränkung notwendig machen. Dies gilt für das Lesen, vor allem aber für das Verändern von Informationen.

Und wie stellt ihr dann sicher, dass das Rechtesystem korrekt eingerichtet wird?

Wir bieten unseren Kunden den „Rights Management Workshop“ an. Dabei analysieren und spezifizieren wir gemeinsam die individuelle Rechtestruktur des Firmenwikis und vergeben z. B. Gruppen-, Lese- und Schreibrechte oder das Recht auf Seitenlöschung. Die Ergebnisse des Workshops werden in einer Rechtematrix systematisch dokumentiert, das Kundenwiki im Anschluss durch unsere IT-Experten entsprechend der Vorgaben konfiguriert. Schließlich wollen wir, dass unsere Kunden mit einem Wiki starten, dass genau ihren Vorstellungen entspricht. Rechteverwaltung inklusive.

Let’s Wiki together!