Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
  • CMS
Denis Potschien 20. Juli 2010

Wikis fürs Informationsmanagement im Unternehmen nutzen

Es gibt zahl­rei­che kom­mer­zi­el­le Angebote für Intranetlösungen, die mit zahl­rei­chen Funktionen – zum Beispiel zum Versenden von Rundschreiben sowie zum Verwalten von Projekten und Terminen – punk­ten. Manchmal reicht es jedoch eine Nummer klei­ner. Mit einem eige­nen inter­nen Unternehmens-Wiki las­sen sich zudem neue Möglichkeiten des inter­nen Informationsaustauschs schöp­fen.

Der gro­ße Vorteil eines Unternehmens-Wikis ist die dezen­tra­le Verwaltung. Jeder kann sei­nen Beitrag leis­ten und für sei­nen Bereich die Inhalte des Wikis pfle­gen. Wenn es um die Bereitstellung von Informationen, um die gemein­schaft­li­che Entwicklung von Konzepten und das Sammeln von Ideen und Vorschlägen geht, bie­tet sich ein Wiki an. Wenn dar­über hin­aus spe­zi­el­le Funktionen wie Terminverwaltung oder E-Mail-Versand von Bedeutung sind, dann wird dies mit einem Wiki kaum umsetz­bar sein.

Auch für Vereine und Parteien bie­tet sich ein sol­ches Wiki an. Gerade bei Parteien kann ein Wiki der Meinungsbildung und der gemein­schaft­li­chen Programmdebatte die­nen.

Vom Wiki zum Unternehmens-Wiki

Die bekann­tes­te Software für Wikis ist das MediaWiki, das auch von Wikipedia ein­ge­setzt wird. MediaWiki gibt es kos­ten­los; es ist ein­fach zu instal­lie­ren und zu bedie­nen. Daher wird die Installation hier nicht wei­ter erklärt. Wie vie­le ande­re Content-Management-Systeme braucht es PHP und eine MySQL-Datenbank.

Hauptseite eines frisch installierten Wikis

Hauptseite eines frisch instal­lier­ten Wikis

Standardmäßig ist ein neu instal­lier­tes Wiki für alle offen zugäng­lich. Jeder kann Artikel lesen, bear­bei­ten und anle­gen. Da Intranets oft­mals auch an das Internet ange­bun­den sind und damit auch Externe Zugriff dar­auf haben, soll­te das Wiki so ein­ge­stellt wer­den, dass ein Zugriff auf das Wiki nur für ange­mel­de­te Benutzer mög­lich ist.

Benutzerverwaltung an Firmenbedürfnisse anpassen

Ebenfalls soll­te eine Benutzeregistrierung her, bei der neue Benutzer erst durch einen Administrator frei­ge­schal­tet wer­den müs­sen. Standardmäßig ist das nicht der Fall; jeder kann ein Konto anle­gen und sich damit sofort anmel­den.

Alle Einstellungen, die zur Anpassung vor­ge­nom­men wer­den müs­sen, wer­den in die Wiki-Konfigurationsdatei LocalSettings.php geschrie­ben. Diese Datei soll­te sich nach der Installation des Wikis im Hauptverzeichnis befin­den.

Zunächst wird der Lese- und Schreibzugriff für alle ver­bo­ten und anschlie­ßend für ange­mel­de­te Benutzer erlaubt. Dazu ans Ende der Konfigurationsdatei fol­gen­de Zeilen ein­fü­gen:

$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['read'] = true;
$wgGroupPermissions['user']['edit'] = true;

Jetzt ist der Zugriff auf das Wiki nur für ange­mel­de­te Benutzer mög­lich. Da jetzt aller­dings alle Seiten nur mit Anmeldung zugäng­lich sind, ist auch die Anmeldeseite sel­ber („Spezial:Anmelden“) nicht auf­ruf­bar. Deshalb muss min­des­tens die Anmeldeseite von der Zugriffsbeschränung aus­ge­nom­men wer­den. Dazu lässt sich in der Konfigurationsdatei eine Ausnahmeliste („White List“) anle­gen:

$wgWhitelistRead = array("Spezial:Anmelden");

In dem Array kön­nen alle Seiten ange­ge­ben wer­den, die immer (auch für nicht Angemeldete) auf­ruf­bar sein sol­len.

Bleibt noch das Problem, dass sich trotz Zugriffsbeschränkung jeder ein Benutzerkonto anle­gen und damit anmel­den kann. Dank der Erweiterung ConfirmAccount lässt sich die­ses Problem lösen. Nach der Installation und Konfiguration der Erweiterung müs­sen neu ange­leg­te Benutzerkonten erst durch einen Administrator frei­ge­schal­tet wer­den.

Ebenso ist die Bestätigung von E-Mail-Adressen durch Bestätigungslink, der an die neu­en Benutzer geschickt wird, Bestandteil der Erweiterung.

Nachdem die Erweiterung ins Extensions-Verzeichnis kopiert wur­de, muss fol­gen­de Zeile in die Konfigurationsdatei ein­ge­fügt wer­den:

require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

Mit die­ser Zeile wird die Erweiterung ein­ge­bun­den und steht zur Verfügung. Es las­sen sich über die Konfigurationsdatei wei­te­re Einstellungen für die Erweiterung vor­neh­men:

$wgConfirmAccountContact = "webmaster@mail.de";

In der Variablen „$wgConfirmAccountContact“ kann eine E-Mail-Adresse ange­ben wer­den, an die E-Mails über neu ange­leg­te Benutzerkonten geschickt wer­den sol­len. Es gibt noch eine gan­ze Reihe wei­te­rer Einstellungen, die man vor­neh­men kann.

Außerdem müs­sen eini­ge SQL-Befehle aus­ge­führt wer­den, um in der Datenbank eini­ge Anpassungen für die Erweiterungen vor­zu­neh­men. Die Befehle sind in einer SQL-Datei zu fin­den und kön­nen kopiert und mit­tels phpMyAdmin auf der Datenbank aus­ge­führt wer­den.

Wer anschlie­ßend auf die Anmeldeseite des Wikis geht, sieht, dass sich das Formular geän­dert hat. Aus dem Link „Neues Benutzerkonto anle­gen“ ist der Link „Beantragen“ gewor­den.

Formular zum Beantragen eines Benutzerkontos

Formular zum Beantragen eines Benutzerkontos

Jetzt muss die neue Registrierungsseite („Spezial:Benutzerkonto_beantragen“) noch der Ausnahmeliste $wgWhitelistRead hin­zu­ge­fügt wer­den. Die Seite, die bei erfolg­rei­cher E-Mail-Bestätigung ange­zeigt wird („Spezial:E-Mail_bestaetigen“), soll­te eben­falls der Ausnahmeliste hin­zu­ge­fügt wer­den.

Nachdem ein Konto bean­tragt wur­de, wird eine E-Mail an die in der Konfigurationsdatei ange­ge­be­ne E-Mail-Adresse geschickt. Außerdem erhal­ten Administratoren ein klei­nes Hinweisfenster im Wiki, das sie auf neue Anträge hin­weist. Anträge kön­nen bestä­tigt, abge­lehnt oder als „abwar­ten“ mar­kiert wer­den.

Der Antragsteller erhält eine Bestätigungsmail, die ihn infor­miert, ob sein Konto bestä­tigt oder abge­lehnt wur­de. Es gibt jedoch auch die Möglichkeit, einen Antrag als Spam zu behan­deln. Dann wird er abge­lehnt, an den Antragsteller jedoch kei­ne E-Mail ver­sandt.

ss

Offene Benutzerkonto-Anträge

Fazit

Wer ein Intranet möch­te, in dem jeder mit­ar­bei­ten kann und in dem es kaum Hierarchien gibt, ist mit einem Wiki gut bedient. Wer mehr Kontrolle über Inhalte und jene, die die­se bear­bei­ten, haben möch­te, wird mit einem Wiki als Intranetlösung wenig Freude haben. Da in einem Wiki kei­ne Benutzergruppen frei defi­niert wer­den kön­nen und der Lese- und Schreibzugriff auf bestimm­te Inhalte nicht defi­niert wer­den kann, ist eine indi­vi­du­el­le Benutzer- und Gruppenverwaltung nicht mög­lich.

Verschiedene Unternehmen set­zen auf eige­ne Wikis, so zum Beispiel die Fraport AG, die mit dem „Skywiki“ ein Unternehmens-Wiki ein­ge­rich­tet hat. Auch die sprd.net AG – bes­ser bekannt als Spreadshirt – hat mit „Space“ ein eige­nes Unternehmens-Wiki, wäh­rend SEIBERT MEDIA mit “Confluence” ein so genann­tes Corporate Wiki zum Kauf anbie­tet.

Voraussetzung für ein gut funk­tio­nie­ren­des Unternehmens-Wiki ist, dass sich alle Beteiligten auf bestimm­te Regeln, wie sie auch Wikipedia for­mu­liert hat, eini­gen. Dann steht einem erfolg­rei­chen Wiki nichts mehr im Wege.

(mm), (tm), (sl)

Denis Potschien

Denis Potschien

Denis Potschien ist seit 2005 freiberuflich als Kommunikationsdesigner tätig, seit Anfang 2010 im Kreativkonsulat in Iserlohn, einem Büro für Gestaltung und Kommunikation. Dort betreut er kleine und mittelständische Unternehmen ebenso wie kommunale Körperschaften und Organisationen aus Südwestfalen und dem Ruhrgebiet. Als Webdesigner und -entwickler gehören HTML5 und CSS3 zu seinen Kernthemen, weshalb er dazu 2013 ein Buch geschrieben hat. „Pure HTML5 und CSS3“ richtet sich an alle, die Vorkenntnisse haben, sich aber bisher mit HTML5 und CSS3 nicht oder nur am Rande beschäftigt haben.

13 Kommentare

  1. Danke für die Erwähnung. Tatsächlich favo­ri­sie­ren wir Confluence und Foswiki für den Unternehmenseinsatz. Ich wer­de hier gele­gent­lich noch ein paar Links mit Vergleichen zu MediaWiki pos­ten.

  2. Schade, dass gera­de zum Aspekt Unternehmenswiki nur das media­wi­ki erklärt wird. Mir geht’s wie den ande­ren Kommentaren ich zie­he ein­deu­tig doku­wi­ki vor. Ein Hauptgrund für die­se Wahl war die Berechtigungsstruktur.
    In doku­wi­ki kann ich ver­schie­de­ne Bereiche für unter­schied­li­che Nutzergruppen frei­schal­ten. So kann ein Teil offen für alle sein, ein ande­rer Bereich für Kunden zugäng­lich, einer für Mitarbeiter usw. Das alles mit einem Wiki und einer Installation.

  3. Wie schon eini­ge vor­her anmerk­ten, ist MediaWiki wirk­lich nicht der Standard für Enterprise-Wikis (und will es auch gar nicht sein). Daher ist es scha­de, dass der Artikel sich auf das tech­ni­sche Vorgehen bei MediaWiki beschränkt, wo doch die Analyse der Situation und die Auswahl der Plattform viel wich­ti­ger ist – und vor­her statt­fin­den muss. Wir haben für die Einführung eine Checkliste erstellt: http://www.cosmocode.de/_media/de/wiki/wiki_im_unternehmen.pdf. Sowas hät­te ich eher erwar­tet.

  4. @AlexPlus: Für Dokuwiki gibt es das klas­si­che Wikipedia Template (Monobook), als auch das Aktuelle (Vector).

  5. Gerade für Unternehmens-Wikis sind Aspekte wie das Rechtemanagement, die Anpassbarkeit an das Unternehmens-Design oder auch die Möglichkeit, leicht Backups erstel­len zu kön­nen beson­ders rele­vant. MediaWiki ist da nicht gera­de der Platzhirsch. Foswiki, Dokuwiki (oder das kos­ten­pflich­ti­ge Confluence) spie­len da in einer ganz ande­ren Liga.

    Zum Vergleich der ver­schie­de­nen Software-Systeme kann ich die http://www.wikimatrix.org/ emp­feh­len.

  6. Schade, dass gera­de zum Aspekt Unternehmenswiki nur das media­wi­ki erklärt wird. Mir geht’s wie den ande­ren Kommentaren ich zie­he ein­deu­tig doku­wi­ki vor. Ein Hauptgrund für die­se Wahl war die Berechtigungsstruktur.

    In doku­wi­ki kann ich ver­schie­de­ne Bereiche für unter­schied­li­che Nutzergruppen frei­schal­ten. So kann ein Teil offen für alle sein, ein ande­rer Bereich für Kunden zugäng­lich, einer für Mitarbeiter usw. Das alles mit einem Wiki und einer Installation…

  7. nur kurz zur info als ergän­zung:
    wir haben unser spre­ad­wi­ki (=media­wi­ki) vor gerau­mer zeit auch zuguns­ten von con­flu­ence abge­löst (die “spaces” bezeich­nen eben die unter/wikis ver­schie­de­ner abtei­lun­gen). wir sind sehr zufrie­den damit. con­flu­ence stammt übri­gens von der “atlas­si­an group” (http://www.atlassian.com).

  8. Ich war selbst mal an der Einrichtung eines Intranet-Wikis in einem mit­tel­stän­di­schen Unternehmen betei­ligt. Das Ass im Ärmel hat­te Mediawiki, weil vie­le das Standard-Frontend durch Wikipedia ken­nen und es äußerst unwahr­schein­lich ist, dass die Entwicklung die­ses Wikis in den nächs­ten 20 Jahren ein­ge­stellt wird.

    Mein per­sön­li­cher Favorit war jedoch wie bei @fwolf DokuWiki, weil es etwas ein­fa­cher in der Handhabung ist.

    Die o.g. Matrix hat bei der Auswahl wirk­lich sehr gute Dienste geleis­tet, vor allem bei der enge­ren Auswahl.

    lg

    Alex

  9. MediaWiki ist ein PITA. Für Einsteiger als auch Fortgeschrittene emp­fiehlt sich daher eher Dokuwiki. Hat für Admins einen wei­te­ren Vorteil: Keine DB – Backup is done in a flash! ;)

    Prinzipiell kann man sich aber das Wiki sei­ner Wahl bei WikiMatrix</a< raus­su­chen ;)

    cu, w0lf.

  10. Sehr inter­es­sant zu die­sem Thema ist das Wiki Confluence.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.