© David Maska, 123RF.com

Verstreut auf dem Fileserver liegende Dokumente skalieren schlecht, wenn der Admin am Helpdesk Probleme lösen muss. Freie Knowledge-Base-Komponenten bündeln Wissen und sorgen für mehr Überblick.

Helpdesks sind die Aushängeschilder von Unternehmen. Ihre technisch geschulten Mitarbeiter sollen höflich und zielorientiert Probleme bearbeiten. Das gilt auch und gerade für den IT-Bereich, in dem Admins und Entwickler die Softwarebugs ihrer Kunden beheben. Sie notieren nicht nur die wichtigsten Daten zu einem Problem und füttern das Ticketsystem damit, sondern sie lösen das Problem am besten gleich am Telefon oder per E-Mail. Im Idealfall beantworten sie 80 bis 90 Prozent aller Anfragen selbst und reichen nur die Härtefälle an Spezialisten weiter.

Die Erfolgsquote hängt unter anderem davon ab, ob die Firma eine Kultur fördert, die das Sammeln und Dokumentieren von Wissen begünstigt und ob sie einen klaren Workflow für die Problembearbeitung schafft. Die Helpdesk-Mitarbeiter fischen regelmäßig im Trüben, wenn wichtige Informationen breit verteilt auf PDFs, Wikis, IRC-Logs und Bugreports im Intranet schlummern. Eine Wissensdatenbank, auf englisch Knowledge Base genannt, soll Abhilfe schaffen, indem sie die Know-how-Fragmente zusammenführt und zugänglich macht.

Abhängig von den Ansprüchen der Firma fallen die Anforderungen an die Knowledge Base unterschiedlich aus. Zwar existieren alleinstehende Knowledge-Base-Anwendungen, aber meist ist die Datenbank Bestandteil eines größeren Systems zur Arbeitsorganisation, etwa einer Produktionsmanagementsoftware (PMS) oder eines ITIL-konformen IT-Service-Management (ITSM). Der Artikel stellt freie Knowledge-Base-Komponenten vor, angefangen bei Wikis über Projektmanagement- bis hin zu ITIL-Tools.

Help, I need some Wiki!

In kleinen Firmen, Start-ups oder Unternehmen ohne Helpdesk besitzt die Organisation des Wissens häufig eine recht geringe Priorität. Meist existiert eine mehr oder weniger logische Ordnerstruktur auf dem Dateiserver, in der sich auch Hilfedokumente und Anleitungen verstecken. Zusätzlich lagert das Wissen in persönlichen E-Mails und im Gedächtnis der Admins, wodurch wertvolles Know-how verloren geht, sobald ein Mitarbeiter die Firma verlässt.

Als Erste-Hilfe-Maßnahme kommt meist ein Wiki zum Einsatz, oder jemand begradigt die wild gewachsene Ordnerstruktur. Auch FAQs im Intranet gelten als beliebtes Mittel, um Wissen in der Firma verfügbar zu machen.

Drinnen und Draußen

Generell lässt sich in einer Firma zwischen Wissen für den internen und externen Gebrauch unterscheiden. Webhoster machen zum Beispiel technisches Wissen für ihre Kunden in FAQs oder Howtos online verfügbar. Kundenfragen lassen sich in diesem Fall mit Verweis auf das Wiki oder die FAQ beantworten, was aber voraussetzt, dass jemand diese Dokumente ständig pflegt.

Größere Unternehmen setzen in jüngster Zeit auch auf Stack-Exchange-Plattformen wie Stack Overflow [1]. Interessierte Nutzer dürfen Fragen formulieren und dann unter vielen Antworten anderer User die beste heraussuchen. Der Fragesteller selbst und die Community bewerten die ualität der Antworten und sorgen so für Relevanz. Gute Stack Exchanges funktionieren aber nur, wenn jemand die Fragen permanent in eine verständliche Form bringt, unangemessene und doppelte Inhalte löscht und Tags zuweist.

Zwei freie Plattformen dieser Stoßrichtung heißen Open Source Q&A [2] und Shapado [3] und sind unter der GPL respektive der AGPL lizenziert.

Wikimania

Geht es um die interne Firmenkommunikation, steht nach wie vor das Mediawiki hoch im Kurs, für das die Statistikwebseite Ohloh fast 200 Codezuträger zählt [4]. Es setzt aktuell einen installierten PHP-Server ab Version 5.3.2 voraus sowie eine damit verknüpfte MySQL-, PostgreSQL- oder SQLite-Datenbank. Mit Hilfe einer LDAP-Extension [5] sorgt der Admin dafür, dass sich die Mitarbeiter vor dem Erstellen von Einträgen identifizieren. So ist später klar, von wem ein Eintrag stammt.

Weniger computeraffine Nutzer unterstützt ein Wysiwyg-Editor [6] oder zumindest ein Hilfe-Link auf die Wiki-Syntax. Die Struktur der Wiki-Einträge sollte einigermaßen logisch, die Titel der Beiträge möglichst aussagekräftig sein, damit die integrierte Suchfunktion sie gut findet. Zudem nutzt es, Einträge mit Dateien verknüpfen zu können, etwa mit Bildern, PDFs oder Dokumenten.

Zum populären Mediawiki gibt es zahlreiche Alternativen, unter anderem Doku-Wiki [8], Moin Moin [9], Tiki Wiki [10], aber auch Twiki [11], Foswiki [12] und Xwiki [13]. Die letzten drei orientieren sich vornehmlich an Unternehmensanforderungen. Sie bringen aufgeräumte Oberflächen mit, integrieren standardmäßig einen Wysiwyg-Editor, bieten RSS-Feeds an, und bei Bedarf helfen kommerzielle Dienstleister beim Einrichten. Einige Wikis sind fast Projektmanagement-Tools, so etwa das Tiki Wiki (Abbildung 1), das die Macher entsprechend als “Tiki Wiki CMS Groupware” titulieren.

Abbildung 1: Das mit Features gespickte Tiki Wiki überschreitet die Grenze zur Groupware.

Projekte, Projekte

Häufig läuft der Hase aber auch in die andere Richtung: Neben PMS integrieren auch einige Bugtracker Wikis als Knowledge-Base-Komponente. Diese auf Softwarefehler abonnierten Ticketsysteme, zu denen etwa Mantis BT [14] und Roundup [15] gehören, erlauben Wiki-Engines einzubinden, was mitunter aber einen gewissen Aufwand erfordert. Andere Bugtracker wie Bugzilla [16] verzichten auf eine Knowledge-Base-Komponente und bringen Zusatzinformationen in Freitextfeldern unter.

Im Vergleich mit Wikis eignet sich Projektmanagementsoftware wesentlich besser für Helpdesk-Arbeiter. Sie bringt als zentrale Komponente einen Issue Tracker mit, der anders als ein Bugtracker auch Probleme verwaltet, die nichts mit Software zu tun haben. Klemmt in der Firma die Eingangstür oder müssen neue Mülleimer her, kann ein Mitarbeiter ein Ticket öffnen – ein reines Bugreport-Tool eignet sich dafür schlecht. Zum Öffnen eines Tickets sendet der Mitarbeiter eine E-Mail an eine bestimmte Adresse. Die PMS generiert aus dem Inhalt (“Hey, wir brauchen neue Mülleimer!”) automatisch ein Ticket. Anrufe von Kunden wandeln die Helpdesk-Mitarbeiter hingegen direkt am Telefon in Tickets um.

Die Probleme erhalten so eine individuell verfolgbare Nummer. Ihr ordnet der Ticketbetreuer dann diverse (Meta)-Informationen zu, wie etwa den Absender und Bearbeiter des Tickets, das Datum sowie den aktuellen Bearbeitungsstatus. Auch Inhalte aus der Knowledge Base oder einer FAQ kann ein Ticket aufnehmen, beispielsweise PDF-Dokumente, Artikel oder Links.

Die meisten PMS arbeiten webbasiert, nicht selten kommt als Knowledge-Base-Komponente ein Wiki zum Einsatz. Das wirft die Frage auf, was eine Wissensdatenbank eigentlich leisten muss.

Spreu vom Weizen

In erster Linie soll eine Knowledge Base es ermöglichen, Wissensressourcen in Form von Artikeln und Dateien anzulegen und sie anderen möglichst jederzeit und schnell verfügbar zu machen. Eine intelligente Kategorisierung über Hierarchien, Metadaten und Tags hilft, Informationen zu einem Thema später möglichst schnell wiederzufinden. Noch wichtiger ist eine gute Suchmaschine, welche die Daten – auch die der Attachments – nicht nur schnell durchsucht, sondern zudem relevante Ergebnisse liefert.

Die Wissensdatenbank sollte so in den Helpdesk integriert sein, dass es wenig Umstände macht, neue Artikel anzulegen, sie einem Ticket zuzuordnen oder bestehende Artikel zu ändern und zu löschen. Dienen E-Mails, Wiki-Einträge und Dokumente im PDF-Format als Datenquellen für Wissen, sollte das System auch ihre Inhalte in die Wissensdatenbank übertragen und die Suchmaschine diese indexieren. Idealerweise muss auch ein Nicht-Admin nach einer Einarbeitungszeit in der Lage sein, den Helpdesk und die damit verbundene Knowledge Base sicher zu bedienen.

Neben den technischen spielen auch soziale Komponenten eine tragende Rolle: Die Geschäftsführung einer Firma muss den Aufbau der Knowledge Base aktiv mit Ressourcen unterstützen und die Mitarbeiter im Umgang damit schulen, um sie zu motivieren, an der allgemeinen Wissenssammlung teilzunehmen.

Ticket to Ride

Weil es freie und kommerzielle PMS wie Sand am Meer gibt, stellt dieser Artikel exemplarisch einige Wissensdatenbanken bekannter Open-Source-Systeme vor. Bei der Suche nach verbreiteten Projektmanagement-Systemen half die Webseite Ohloh [17], die nicht nur die Aktivität in solchen Projekten verfolgt, sondern auch die Zahl der Nutzer und vor allem der beteiligten Entwickler einschätzt.

Trac

Trac 1.0 [18] ist in Python geschrieben, steht unter der 3-Klausel-BSD-Lizenz, bringt unter anderem ein eigenes Ticketsystem, ein Subversion-Interface sowie ein Journal mit Timeline- und Milestone-Support mit. Die Software setzt auf dem Server Python 2.5 voraus und als Datenbank wahlweise auf MySQL, PostgreSQL oder SQLite. Trac lässt sich mit etwas Aufwand auch für mehrere Projekte einsetzen.

Auf der Webseite steht: “Wiki-Markup ist eine Kernfunktion von Trac”. Dem folgend nutzen viele Bereiche die Wiki-Syntax, bei Bedarf auch über einen Wysiwyg-Editor. Das Trac-Wiki fungiert hier als Knowledge Base, die Einträge verlinkt der Admin über Trac-Links direkt mit Tickets und Kommentaren (Abbildung 2).

Abbildung 2: Erstellt der Admin in Trac ein Ticket, kann er Texte, Wiki-Inhalte und Attachments anhängen.

Bindet der Admin zudem Tickets über Trac-Notifications an Mailadressen, verschickt Trac bei Ticketänderungen E-Mails. Umgekehrt konvertiert das Plugin Email2trac eingehende Mails in Tickets oder aktualisiert vorhandene Tickets. Das klappt auch, wenn es sich um HTML-E-Mails handelt, die Attachments mitbringen.

Redmine

Redmine [19] steht unter der GPL, basiert auf Ruby on Rails, und die Installation setzt ein Ruby ab Version 1.87 voraus, Rails in Version 3.2.13 sowie die gleichen Datenbanken wie Trac. Auch Redmine hat einen Bugtracker an Bord und kann auf verschiedene Versionskontrollsysteme zugreifen (Subversion, CVS, Git und weitere).

Obwohl Redmine ein Wiki im Gepäck hat, fehlt im Unterschied zu Trac der Wiki-Look mit den eher irritierenden Binnenmajuskeln in Links und Texten. Es ähnelt vom Look & Feel einem klassischen CMS (Abbildung 3) und verwendet mit Textile eine leichtgewichtige Markup-Sprache. Im Umgang mit mehreren Projekten legt es auf Wunsch für jedes Subprojekt Wikis und Foren an.

Abbildung 3: Über das Administrationsinterface von Redmine lassen sich Plugins einbinden und konfigurieren.

Auch Redmine erlaubt es seit Version 0.8.0, Tickets, aber auch Kommentare, per E-Mail zu erzeugen und zu aktualisieren. Dazu ist wahlweise ein eigener E-Mail-Server nötig oder ein Cronjob, der E-Mails über IMAP und POP3 abholt [20]. Umgekehrt erhalten die Ticketverwalter E-Mails, wenn es Änderungen an einem Ticket gibt. Aktiviert ein Redmine-Anwender die so genannten Watcher im Wiki, empfängt er E-Mails, wenn sich Wiki-Einträge ändern oder wenn ein Anwender neue Artikel, Dokumente, Dateien oder Wiki-Einträge einstellt.

Neben dem Wiki steht als Plugin auch eine klassische Knowledge Base bereit [21], nach deren Installation ein entsprechender Eintrag im Navigationsmenü erscheint. Der Redmine-User kann nun nicht nur Artikel schreiben, bearbeiten und löschen, sondern auch Kategorien und Subkategorien anlegen, Artikel bewerten, kommentieren, taggen und mit Dateianhängen versehen. Ein Dashboard zeigt die jüngst angelegten, beliebtesten und bestbewerteten Artikel an.

Request Tracker

Unter anderem eingesetzt von der Free Software Foundation, Nasa, Wikia und der University of Camebridge existiert der in Perl verfasste und unter GPL stehende Request Tracker [22] bereits seit 1999. Die Firma dahinter heißt Best Practical Solutions und bietet Support an. Aktuell ist die Version 4.2, die Installation setzt einen Apache mit »mod_perl« oder Fast-CGI sowie Perl 5.10.1 aufwärts voraus. Neben den drei üblichen Verdächtigen unterstützt Request Tracker (kurz RT) auch Oracles Datenbank ab 9iR2.

Die PMS bringt ein übersichtliches Dashboard mit, ermöglicht eine LDAP- und Active-Directory-Anbindung, zeigt im Ticketsystem Relationen zwischen Tickets grafisch an und hat ein Time-Tracking-Modul im Gepäck.

Bis zur Version 4.0 existierte die Knowledge Base als alleinstehendes Modul mit dem schönen Namen RTFM (hier für “RT FAQ Manager”), nun ist sie fester Bestandteil von RT und lässt sich über den Menüpunkt »Articles« erreichen (Abbildung 4). Hier kann der Nutzer Artikel anlegen, ändern, suchen, nach Klassen und Topics organisieren oder global verfügbar machen. Für Artikel definiert der Nutzer auf Wunsch spezielle Felder, die er einer Klasse zuweist. Zugriffe lassen sich auf bestimmte Benutzergruppen einschränken. Nicht zuletzt gibt es aus Kompatibilitätsgründen ein Archiv mit alten Versionen von Artikeln.

Abbildung 4: Das RTFM-Modul ist seit Version 4.0 fest in Request Tracker integriert und erlaubt das Erstellen und Klassifizieren von Artikeln. Diese lassen sich dann auch mit Tickets kombinieren.

Aktiviert der Admin die Option »ArticleOnTicketCreate« in »/etc/RT_Config.pm« , kann er eine »Article Hotlist« in Form eines Drop-down-Menüs in den »Create-Ticket« -Dialog einbauen. Knowledge-Base-Artikel lassen sich zudem über die Antwort- und Kommentarfunktion in Tickets integrieren, wahlweise mit oder ohne Verweise auf die Quelle. Umgekehrt wandelt der Benutzer über »Extract to article« Tickets in RTFM-Artikel um. Die Inhalte des Tickets kann er bestimmten Feldern einer Artikelklasse zuordnen.

ITIL inside

ITIL, die IT Infrastructure Library, stellt einen international akzeptierten De-facto-Standard für die Organisation der Unternehmens-IT (IT Service Management) dar und kommt meist in größeren (IT)-Firmen zum Einsatz. Eine Reihe von Büchern beschreibt Best Practices, die dabei helfen, im Unternehmen eine optimale IT-Infrastruktur aufzubauen, wobei der ITIL-Jünger nicht sämtliche Details umsetzen muss. In den Publikationen zu ITIL 3, der aktuellen Variante von ITIL, spielt im Bereich Service Transition erstmals auch das Knowledge Management eine Rolle [23].

Zwar lassen sich Softwarelösungen nicht nach ITIL zertifizieren, doch gibt es freie Service-Management Lösungen, die eigene Knowledge-Base-Komponenten mitbringen und von sich behaupten, ITIL-konform zu sein. Im Helpdesk-Bereich gehören Itop [24] und das OTRS-Framework [25, 26] (Open Ticket Request System) dazu.

OTRS

OTRS ITSM ist die ITSM-Komponente des Open-Source-Stack der Open Source Business Alliance (OSBA), steht unter der AGPL und ist in Version 3.3.2 erhältlich. Programmiert in Perl und ausgestattet mit einer Javascript-Weboberfläche, setzt es einen Apache-2-Server mit »mod_perl2« und Perl ab Version 5.10.0 voraus. Es unterstützt mit MySQL, PostgreSQL, Oracle 10g, Microsoft SQL 2005 und DB2 ein beachtliches Spektrum an Datenbanken, kennt mehrere Authentifizierungsmethoden (LDAP, Radius, HTTP-Auth) und lässt sich mit Monitoring-Tools und externen Kundendatenbanken verknüpfen. Es ist dank integrierter Historie revisionssicher, gilt als gut anpassbar [27] und bietet eine umfangreiche Liste an Features [28].

Als Knowledge Base arbeitet ein FAQ-Modul, das der Admin separat über einen integrierten Paketmanager installiert. Anschließend lässt sich das Modul für den internen, neuerdings auch für den externen Einsatz (über Generic Interface, das Webservice-Framework) konfigurieren. Mit den FAQ-Einträgen lassen sich neben Artikeln auch Tickets und Items der Configuration Management Database (CMDB) verlinken. Die Artikelverlinkung klappt seit Version 2.2.x auch über Kategorienamen.

Das FAQ-Modul besteht aus mehreren Komponenten, der FAQ-Explorer lässt den Admin durch die Wissenssammlung navigieren. Will er anschließend einen Artikel erstellen, steht ihm ein Wysiwyg-Editor zur Seite, Artikel lassen sich dabei mit verschiedenen Attributen verknüpfen. Diese signalisieren etwa, ob der Artikel ein Symptom schildert oder ein Problem löst. Titel, Sprache und Kategorie kann der Admin ebenso festlegen wie anklickbare Schlagwörter. Auch gängige Metadaten wie der Status, das Erstell- und Modifikationsdatum fehlen nicht.

Artikel lassen sich mit Attachements und Bildern versehen sowie mit Objekten wie Tickets und Antworten verbinden. Eine Volltextsuche sowie eine Schnellsuche finden rasch relevante Ergebnisse. Ranking- und Abstimmfunktionen erleichtern das Einordnen der Artikel, eine Übersicht der Top-10-Artikel sowie der zuletzt angelegten und geänderten gibt es auch.

E-Mails verschickt das System auf Wunsch über den eigenen Server (Sendmail, Postfix, Exim), die Konfiguration läuft über eine Weboberfläche. Fehlt der eigene Mailserver, tun es auch die sicheren oder unsicheren Varianten der Protokolle SMTP, IMAP und POP3. E-Mails lassen sich dabei auch über PGP oder S/MIME verschlüsseln und signieren. Über die Postmaster-Module kann der Admin zudem Mails mit einem X-OTRS-Header versehen, den OTRS dazu verwendet, Aktionen auszuführen. Es ändert die Priorität eines Tickets oder ordnet es einem bestimmten Kunden zu.

Breites Spektrum

Das Spektrum der freien Knowledge-Datenbanken ist groß und reicht von simplen Wikis und Webseiten über PMS bis hin zu ITIL-konformen Alleskönnern.

ITSM-Lösungen wie OTRS und Itop kommen vor allem für Firmen in Frage, in denen die Admins in einem Aufwasch gleich die Rechnerfarm inventarisieren und das Patchmanagement erledigen möchten. Sie gehen über durchschnittliche Helpdesk-Anforderungen hinaus und in den administrativen Bereich hinein.

Kleineren und mittelgroßen Unternehmen genügt häufig schon ein übersichtlicher Helpdesk mit Ticketsystem und angeschlossener Knowledge Base. Hierfür dürften kleinere Lösungen wie Redmine, Trac und Request Tracker eine gute Wahl sein, wobei letzteres auch schon in Richtung ITSM geht.

Wichtig ist, dass sich die Knowledge Base gut in die Ticketverwaltung integriert. Wer Wikis aufgrund ihrer Neigung zur Entropie und der Syntax nicht mag, greift in Sachen Knowledge Base am Besten zu RT oder dem erwähnten Redmine-Plugin. Wiki-Freunde dürften hingegen mit dem beliebten Trac gut fahren.

Am Ende steht aber meist ein Feature-Vergleich: Dann entscheidet sich, wie gut die Software dokumentiert und wie benutzbar das Web-GUI ist oder ob sich die Tools gut mit der PMS verstehen.

Weil einige Hersteller Demo-Installationen im Netz anbieten, lassen sich die in einer Firma auftretenden Fälle am lebenden Objekt durchexerzieren, wobei sich dann auch die Stärken und Schwächen einer Software zeigen. Geht es nur um Bugreports im Rahmen eines Softwareprojekts, tun es auch Bugtracker wie Mantis und Bugzilla.

Reine Wikis eignen sich nur als Wissensspeicher, ihnen fehlen gut integrierte Ticketsysteme. Das muss kein Hinderniss sein, falls eine Firma lediglich das interne Wissen organisieren möchte und ist um Längen besser, als eine Sammelsurium von Dokumenten, die verstreut auf dem Fileserver liegen. Für den Wiki-Einsatz im Unternehmensbereich bieten sich Spezialplattformen wie Twiki, Foswiki oder Xwiki an. Letztlich hängt diese Entscheidung aber auch von der eingesetzten Programmiersprache, der Benutzbarkeit des Editors oder der Suchfunktion ab.