Das Wissensportal DRAKE: Vom Kundenprojekt zur öffentlichen Drupal-Distribution

Als die helpworx GmbH vor 2 Jahren eine Wissensdatenbank für ein großes Call Center suchte, hatte der Kunde noch ein Wiki im Sinn. Mittlerweile ist daraus die Drupal-Distribution „DRAKE“ entstanden…

Am Anfang: Viel Leidensdruck & ein Wiki-Irrtum.

Alles begann im Dezember 2007: Unser Auftraggeber, ein großes, versicherungsnahes Call Center in Köln, war unzufrieden mit dem aktuellen operativen Wissensmanagement. Die projektbezogenen Informationen waren auf viele verschiedene Systeme verteilt und es gab keine einheitliche Organisation der Inhalte, weder im Frontend noch ‚hinter den Kulissen‘. Vor allem dauerte es zu lange, im Kundengespräch oder während der Fallbearbeitung die korrekte Fachinformation zu finden.

Soweit nichts Besonderes, denn diese Grundsituation treffen wir in unseren Beratungs-Projekten häufig an. Auch die funktionalen Anforderungen klangen zunächst nach einer Standard-Lösung, denn die Pflege über den Browser, eine Versionierung der Inhalte oder die Zugriffsbeschränkung einzelner Inhalte etc. beherrscht mittlerweile jedes webbasierte CMS.

In den weiteren Gesprächen entpuppte sich diese erste Einschätzung aber als Trugschluss, denn was sich uns bei der näheren Analyse bot, war schon beeindruckend: Es ging hier um viele tausend Artikel, verteilt auf hunderte von Projekten, Produkten, Leistungsarten und Teams. Und diese Einsortierung war keineswegs eindeutig oder linear, denn Produkt A konnte durchaus auch für Team Z relevant sein, Produkt B wiederum auch für die Gesellschaft Y angeboten werden, allerdings nicht im Team X und so weiter. Ein echter gordischer Knoten, der unmittelbare Auswirkung auf die Wahl des Systems hat, denn wie will man diese Flexibilität auf die Navigation übertragen? Doch dazu später mehr.

Ein großer Kritikpunkt an der bisherigen Lösung des Auftraggebers war zudem, dass die Pflege der Inhalte zu kompliziert war und unter anderem deshalb zentral von einer Abteilung vorgenommen wurde. Dies wiederum stellte ein organisatorisches Nadelöhr dar. In Zukunft sollte es daher einfach möglich sein, auch einzelnen Teams die autonome Pflege von Inhalten zu ermöglichen, ohne wieder technische Insellösungen zu schaffen.

Entsprechend lag es nahe, dass der Auftraggeber zunächst auch eine Wiki-Lösung in Erwägung zog. Ohne an dieser Stelle eine Grundsatzdiskussion anregen zu wollen: Wenn es um den Einsatz als Wissensdatenbank in Unternehmen geht, stehen wir Wikis mehr als kritisch gegenüber. Die Erfahrung zeigt einfach, dass ein klassisches Wiki hierfür nur sehr bedingt und nur unter speziellen Voraussetzungen geeignet ist. Die technische Einfachheit, die ein Wiki qua Definition von Haus aus mitbringt, vor allem aber der kollaborative Ansatz („Jeder darf alles“ oder zumindest „Viele dürfen viel“) mögen am Anfang verlockend klingen, weichen aber in vielen Fällen schnell einer großen Ernüchterung. Zum einen, weil auf Mitarbeiterseite der erträumte „Perpetuum Mobile Effekt“ ausbleibt (in diesem Kontext ist gerne vom „Wikipedia-Irrtum“ die Rede) und zum anderen, weil auf der technischen Seite die Limitierungen eines Wikis zum Problem werden, sobald die Anforderungen sich ändern, und das tun sie im Unternehmensumfeld schnell. Gerade hinsichtlich der Zugriffsbeschränkung, dem Veröffentlichungsprozess (4-Augen-Prinzip) oder speziell der Navigationsvielfalt kann ein Wiki oft einfach zu wenig.

Also war klar: Der Kunde braucht ein skalierbares, möglichst einfach anzupassendes, webbasiertes Content Management System. Davon gibt es viele, aber aus all den hinlänglich bekannten Gründen schnitt Drupal im internen Ranking von Anfang an ziemlich gut ab. Nun muss man sagen, dass vor 2 ½ Jahren Drupal (damals noch in der Version 5) in Deutschland noch nicht annähernd so populär und medial gut repräsentiert war wie heute. Es galt noch als ‚Geheimtipp‘, und das ist nicht unbedingt das beste Argument vor Auftraggeber. Und so standen auch wir anfänglich Drupal durchaus skeptisch gegenüber.

Das Zünglein an der Waage: Faceted Search

Die eingangs erwähnte Masse an Artikeln, vor allem jedoch deren inhaltliche Verflechtung untereinander war von Anfang an die zentrale Herausforderung und nahm unmittelbar Einfluss auf die Evaluation der geeigneten Plattform.

Die klassische Baumstruktur versagte bereits bei den System-Vorgängern an der Menge und komplexen Beziehungen der Inhalte: Zu tief verschachtelt, zu umständlich, zu zeitraubend, vor allem aber: Zu wenig eindeutig, denn oft wäre ein und derselbe Artikel in X verschiedenen Kapiteln richtig einsortiert gewesen. Diesen Fehler durften wir nicht wiederholen.

Eine reine Freitextsuche als einzige „Navigations“methode hingegen schied aus, denn die Inhalte sollten schon ontologisch organisiert sein, was letztlich auch eine Voraussetzung für die flexible Zugriffsbeschränkung einzelner Themenkomplexe war.

Bei unserer Suche nach neuen Wegen in der Navigation stießen wir schnell auf den Ansatz von „Faceted Search“ – und damit an das entsprechende Modul für Drupal. Letztlich gab dieses Modul den Ausschlag dafür, die Umsetzung mit Drupal zu wagen. Und so starteten wir vor ziemlich genau 2 Jahren mit dem Aufbau und der Anpassung des ersten Vorgängers von DRAKE.

Drupal und seine Module: Lego für Fortgeschrittene

Der modulare Aufbau von Drupal ist eine große Stärke dieses Systems und sicher einer der wesentlichen Gründe für den Erfolg dieser Plattform. Gerade bei kommerziellen Projekten wie diesem steckt in der Modul-Architektur auch ein organisatorisches Potential, wird es dadurch doch einfacher, Teile der Entwicklung zu separieren und so die Entwicklungsarbeit ganz oder teilweise auszulagern, oder (wie in unserem Falle) im Laufe der Zeit mit unterschiedlichen Drupal Agenturen und Freelancern zusammenzuarbeiten. An dieser Stelle seien die beiden Agenturen mdwp* und erdfisch genannt, die in unterschiedlichen Projektphasen an dem Projekt beteiligt waren. An der Programmierung der Module haben die erdfische einen Löwenanteil gehabt, dafür an dieser Stelle ein dickes Lob!!

Die Vielzahl der bereits verfügbaren Module ist übrigens Segen und Fluch zugleich: Einerseits bietet sich einem ein schier unendlicher Fundus an Bauklötzen, aus denen man sich seine individuelle Drupal-Instanz zusammenbasteln kann. Andererseits ist es ein Trugschluss anzunehmen, man könne sich einen Drupal-Maßanzug „mal eben zusammenklicken“. Das Sichten, Verstehen und Prüfen von Modulen frisst wahnsinnig viel Zeit – ein Faktor, denn wir als Drupal-Neulinge ganz klar unterschätzt haben. Denn wie bei jedem Open Source Projekt schwanken Qualität, Pulsschlag oder Dokumentation dieser einzelnen „Drupal-Teilprojekte“ ganz enorm, und auch ungewollte Wechselwirkungen zwischen zwei Modulen sind nicht auszuschließen.

Rückblickend lässt sich heute sagen, dass uns das Suchen, Ausprobieren, Testen und Verwerfen von Modulen deutlich mehr Zeit (und Geld) gekostet haben, als die Entwicklung eigener Module durch die externen Entwickler. Letztlich liegt der große Reiz von Drupal in der Kombination von beidem, also der Verfügbarkeit zahlreicher ausgereifter Module einerseits und der Gewissheit, dass fehlende Funktionen mit relativ überschaubarem Aufwand nachgerüstet werden können.

Das Ergebnis: Was genau macht DRAKE?

DRAKE ist als Wissensportal für Unternehmen und Organisationen konzipiert. Im ursprünglichen Kundenprojekt ging es konkret um die ‚Versorgung‘ der Service-Agenten und Sachbearbeiter einer großen deutschen Assistance-Gesellschaft mit versicherungsrelevanten Informationen. Die wichtigsten Eigenschaften:

• Der in DRAKE hinterlegte Content kann in verschiedene Hauptbereiche unterteilt werden, zur groben Unterteilung des Inhaltes. Jedem Hauptbereich kann eine eigene Farbe, ein eigener Inhaltstyp sowie eine eigene Navigationsmethode zugewiesen werden.
• Derzeit stehen 3 alternative Navigationsmethoden zur Verfügung: Die geführte Suche, ein alphabetischer Index sowie eine klassische Baumstruktur.
• Die geführte Suche ermöglicht eine intuitive, schnelle Navigation– auch bei sehr großen Informationsmengen. Denn an Stelle von starren, hierarchischen Baumstrukturen nutzt sie ein flexibles Filtersystem, welches wiederum auf die ureigene Taxonomie von Drupal zurückgreift. Mehr dazu im nächsten Absatz.
• Über persönliche Favoriten kann jeder Anwender Lesezeichen anlegen, nicht nur für einzelne Seiten oder Artikel, sondern auch für jede beliebige Filterkonstellation innerhalb der geführten Suche.
• Für ausgewählte Artikel kann eine Bestätigungsfunktion aktiviert werden. Diese erfragt von jedem Anwender eine persönliche Bestätigung des Artikels, nach dem Motto „Gelesen und verstanden“. Dies kann im hektischen Alltag, speziell in der Kundenbetreuung, ein wichtiges Instrument sein, um wichtige, aktuelle Projektinformationen nicht nur passiv „anzubieten“, sondern verbindlich zu steuern.
• Über farbige Status-Symbole wird jedem Anwender in der View angezeigt, welche Artikel neu sind, seit dem letzten Besuch aktualisiert wurden oder einer persönlichen Bestätigung bedürfen. Zusätzlich kann Artikeln noch der Status „Wichtig“ zugewiesen werden. Diese wichtigen Artikel können, in Ergänzung zur geführten Suche, zusätzlich gefiltert werden. So kann ein Anwender z.B. nach längerer Abwesenheit die wesentlichen Änderungen mit einem Klick selektieren.
• Das in Drupal integrierte Rollen- und Rechtekonzept wurde mit Hilfe des Moduls „Tac Lite“ so erweitert, sodass es nun neben den klassischen Rollen, die bestimmen was man sehen oder machen darf, zusätzliche Rollen angelegt werden können, über die man steuert, wo ein User dies darf. Wir reden in diesem Zusammenhang von Hauptrollen (was) und Nebenrollen (wo). Der Clou: Die Nebenrollen korrespondieren mit den Filterkriterien, die jedem Artikel zugewiesen werden. Auf diese Weise hat man bei minimalen Administrationsaufwand maximale Flexibilität, was die team- oder skillbezogene Steuerung von Inhalten oder Funktionen angeht.

Hier führt jeder Weg zum Ziel: Die geführte Suche

Einen besonderen Stellenwert im gesamten DRAKE-Projekt hat die „Geführte Suche“, eine Navigationsmethode, die komplett auf hierarchische Baumstrukturen verzichtet und stattdessen auf flexible Filter zur thematischen Eingrenzung der Artikel setzt. Doch wie kam es dazu?

Wie bereits oben erwähnt, gab es im Kundenprojekt besondere Herausforderungen, was die Menge der Artikel und ihre semantische Verflechtung miteinander angeht. Die herkömmliche, hierarchisch aufgebaute Baumstruktur war hier bereits an ihre Grenzen gestoßen. Dies ist auch bei anderen Wissens-Projekten der Fall, denn hierarchische Strukturen werden stetig wachsenden Informationsmengen oft nicht gerecht, weil mit zunehmendem Wachstum der Inhalte die Struktur dieser Systeme zwangsläufig immer komplexer und verschachtelter wird. Darunter leidet die Bedienerfreundlichkeit – auf beiden Seiten: für die Autoren wird es immer schwieriger, für jedes Thema einen eindeutigen Platz in der Baumstruktur zu finden, und für die Anwender wird der Gliederungsbaum immer unübersichtlicher und uneindeutiger, je mehr Ebenen aufgeklappt sind.

Die der geführten Suche zugrundeliegende Technologie geht hier neue Wege. Sie ermöglicht dem Nutzer, seinen Suchweg frei zu definieren. „Faceted Search“, wörtlich übersetzt mit „Facettenreiche Suche“, verzichtet gänzlich auf feste, hierarchische Strukturen. Denn anstatt einen Artikel innerhalb einer hierarchischen Struktur einzuordnen, weist der Autor dem Artikel beliebig viele (zuvor festgelegte) Filterkriterien zu. Die folgende Abbildung zeigt die Navigation aus Anwendersicht am Beispiel eines Demo-Systems:

Der Anwender wiederum navigiert zum gewünschten Artikel, indem er aus den zur Verfügung stehenden Kriterien seine „Wunschauswahl“ trifft (1). Diese Kriterien sind zwar in Ihrer Gesamtheit vorgegeben, vom Anwender aber in beliebiger Reihenfolge und Konstellation auswählbar. Der Weg, den der Anwender im System geht, folgt also konsequent dem persönlichen Verständnis des Sachverhaltes, und nicht einer starren, vorgegebenen Logik. Die Anzeige der Artikel ändert sich simultan zur Auswahl der Filter (2). Besonders hilfreich: Durch das System werden zu jedem Zeitpunkt nur die verbleibenden Auswahlkriterien angeboten, für die auch Inhalte vorliegen (3). Somit führt auch bei zunehmender „Verfeinerung“ der Filter-Auswahl keine Suche ins Leere. Daher der Name „Geführte Suche“.

Übrigens: Bei der ‚klassischen‘ Implementierung von Faceted Search beginnt der Navigationsprozess mit einer Freitextsuche, deren (zahlreichen) Resultate anschließend mit Hilfe von Filterkriterien eingegrenzt werden. Einige Systeme erzeugen diese Filterkriterien sogar maschinell anhand semantischer Kriterien. Die geführte Suche in DRAKE geht hier praktisch den umgekehrten Weg, denn hier stehen zu jedem Zeitpunkt die (redaktionell gepflegten) Filter im Vordergrund. Eher ergänzend können Stichwörter frei eingegeben werden, um die Ergebnisse weiter einzugrenzen. Der Flexibilität des Anwenders tut die redaktionelle Vorgabe der Filter keinen Abbruch, allerdings kann die Genauigkeit (und Schnelligkeit) der Navigation auf diese Weise günstig beeinflusst werden. Mit anderen Worten: Wir haben die menschliche Intelligenz der künstlichen vorgezogen.

Unter der Motorhaube: Diese Module nutzt DRAKE

Die einzelnen Bestandteile von DRAKE en Detail zu erklären, würde den Rahmen dieses Artikels mehr als sprengen. Daher in aller Kürze hier eine Auflistung der wichtigsten Module, die DRAKE in seiner aktuellen Version nutzt:

Fazit und Ausblick: Drupal rockt! DRAKE auch!

Mittlerweile ist das Kundensystem, aus dem DRAKE (mit einigen Änderungen) als eigenständige Distribution hervorgegangen ist, seit 1 Jahr im Einsatz. Bis zu 500 Mitarbeiter nutzen das System, hinterlegt sind bisher knapp 7.000 Artikel, Tendenz 10.000. Seit der ersten Beta wurden viele strukturelle und funktionale Änderungen vorgenommen, immer anhand konkreter Praxiserfahrungen und –anforderungen. Das Kundensystem in seiner Gesamtheit ist also maßgeschneidert, obwohl viele Einzelbestandteile für sich betrachtet „Standard“ sind.

Für uns ist mit DRAKE nicht nur eine eigene Distribution aus diesem Projekt hervor gegangen, sondern die Erfahrung, dass Drupal ein echter Tausendsassa ist. Der Spruch „Wenn es überhaupt geht, dann geht es mit Drupal“ ist im Laufe des Projektes zu einem echten Mantra für uns geworden.

An DRAKE beeindruckt uns insbesondere die geführte Suche. Der Zugewinn an Flexibilität und Geschwindigkeit bei der Navigation im Vergleich zur klassischen Baumstruktur ist theoretisch kaum zu beschreiben, man muss es einfach mal im realen Einsatz gesehen haben. Zugegeben, diese Art der Navigation erschließt sich nicht jedem Nutzer auf Anhieb von alleine. So bemerkten wir in der Anfangszeit immer wieder, dass Anwender die Stichwort- oder Volltextsuche zuerst benutzen. Interessanterweise geschah dies nicht, weil es bessere Ergebnisse geliefert hätte, sondern weil die Anwender schlicht ans „Googeln“ gewöhnt waren. Die Macht der Gewohnheit eben.

Die Webseite zu DRAKE ist noch ganz frisch und unter www.rapid-knowledge.de zu erreichen. Wir freuen uns über Feedback und Erfahrungsaustausch, denn wir haben mit DRAKE noch viel vor. Ganz oben auf unserer Roadmap stehen z.B. Office-Import, zusätzliche Themes und eine verbesserte Teaser-Darstellung.

Über helpworx:

helpworx bietet Unternehmen Beratung, Training und Systemunterstützung rund um das operative Wissensmanagement im Kundendialog und unterstützt z.B. Service Center, Helpdesks oder Projektteams aus den unterschiedlichsten Branchen dabei, ihre Informationen optimal zu strukturieren und verfügbar zu machen. Mehr unter www.helpworx.com.