[lars@catsandcoffee.org ] [catsandcoffee.org — Home ] [lars@trash.net ] [mail me] [EXIT ]

Wissensmanagement

Ansätze zum Wissensmanagement

Zusätzlich zum normalen "Arbeitswissen" eines Mitarbeiters eines Unternehmens fällt im täglichen Arbeitsablauf immer ein für diesen Arbeitsablauf spezifisches Wissen an. Dies umfaßt unter anderem die Standardprozeduren zur Abarbeitung immer wiederkehrender Vorgänge, spezifische Besonderheiten der Unternehmenskunden, erprobte Problemlösungen und vieles mehr. Dieses Wissen ist oftmals nur im Kopf sowie den Notizen der entsprechenden Mitarbeiter "gespeichert" und selten an geeigneter Stelle zentral hinterlegt.

Typische Gründe dafür sind meist:

• "das sind doch nur Kleinigkeiten, die weiß man";
• die altbekannte Unlust am Schreiben von Dokumentation;
• keine Zeit zum Schreiben von Dokumentationen.

Selbst wenn für den Mitarbeiter dieses angesammelte Wissen immer in vollem Umfang abrufbar ist — eine angesichts normaler menschlicher Schwächen eher kühne Annahme — so führt dies spätestens beim Verlust der Verfügbarkeit des entsprechenden Mitarbeiters (nicht erreichbar, hat Firma verlassen, ist krank, ...) unter Umständen zu erheblichen Problemen.

Auch aus grundsätzlichen Erwägungen heraus ist es vorteilhaft angesammeltes Wissen, bewährte Problemlösungen etc.pp. abteilungsübergreifend bzw. unternehmensweit zur Verfügung zu stellen. Hierdurch ergeben sich nicht zu unterschätzende Synergieeffekte die verhindern, "daß das Rad jedesmal neu erfunden wird". (Wenn Abteilung A ein bewährtes Verfahren zu Lösung eines Problems entwickelt hat, dann ist es absurd, wenn Abteilung B Zeit & Geld in eine weitere Lösung des gleichen Problems investiert. Vorraussetzung für die Übernahme — und ggfls. Weiterentwicklung — von A ist allerdings, das B von A weiß. Das klingt banal; dennoch sind in der Praxis Parallelentwicklungen keine Seltenheit und verschwenden Resourcen in erheblichem Umfang.) Das betrifft natürlich hauptsächlich Wissen von allgemeinem Interesse; aber alleine die Grenzziehung "was ist von allgemeinem Interesse und was nicht" fällt schwer. Typisch ist auch, daß Unternehmen, die einen gewissen Schwellwert in ihrer Größe überschritten haben, eher unter mangelnder Kommunikation als unter übermäßiger Kommunikation der Bereiche untereinander leiden. Hierarchische Strukturen mit festgelegten Verantwortlichkeiten und Geschäftsabläufen lösen dieses Problem nicht; sie verschärfen es ungewollt nur allzu oft. Der "Dienstweg" ist voller Stolpersteine; "Korpsgeist" einzelner Bereiche, "Rivalität" von Bereichen untereinander sowie "Revierverhalten" mancher Vorgesetzer sind weitere Bremsen einer effektiven abteilungsübergreifenden Kommunikation. Im Zweifel scheint es deswegen angebracht zu sein, lieber "zu viel" als "zu wenig" abteilungsübergreifend bzw. unternehmensweit zu veröffentlichen. Einschränkungen ergeben sich primär nur aus rechtlichen bzw. betrieblichen Erwägungen bzgl. der Vertraulichkeit mancher Informationen.

Es ist notwendig, frühzeitig mit der Implementierung geeigneter Lösungen zur Erschließung und Nutzbarmachung des im Unternehmen anfallenden Wissen zu beginnen. Es ist gerade das im Laufe der Zeit angesammelte Know-How, welches erfolgreiche von erfolglosen Unternehmen unterscheidet und Vorsprung gegenüber den Wettbewerbern sichert. Mag das bei'm Handwerksmeister Nubelnuschkin nicht so kritisch sein, so ist es für (stark) technologiebehaftete Unternehmen geradezu existentiell!

Für stark technologiebehaftete Unternehmungen ist es außerdem unbedingt erforderlich den Wettbewerb sowie allgemeine Entwicklungen, z.Bsp. in Lehre & Forschung, außerhalb des Unternehmens zu beobachten. Dies ermöglicht frühzeitiges Reagieren auf veränderte Marktlagen etc.pp. Auch das hier anfallende Wissen muß für den schnellen Zugriff aufbereitet werden.

Notwendig sind Lösungen, die einerseits gut skalieren und damit den wachsenden Anforderungen Rechnung tragen und die andererseits möglichst einfach und effizient in der Anwendung sind. Nichtskalierende Lösungen stoßen recht bald an ihre Grenzen und verursachen dann mehr Probleme als sie lösen; Anwendungen, die in ihrer Benutzung zu kompliziert sind, stoßen auf mangelnde Akzeptanz der Benutzer und verfehlen damit ihr Ziel.

Grundsätzliche Überlegungen

Wenn man davon ausgeht, daß die grundsätzlichen Konzepte und Zusammenhänge der täglichen Arbeit als fachspezifisches Grundwissen zu betrachten sind, dann ergeben sich für das Management des dabei anfallenden Wissens zwei unterschiedliche Ansätze:

• Wissensniederlegung als umfassende Dokumentation und
• Wissensniederlegung als Speicherung spezifischer Details.

Keiner der beiden Ansätze ist wirklich in der Lage, alle Anforderungen abzudecken und so wird man normalerweise beide im Einsatz finden, wenn auch in sehr variierender Ausprägung. Beide Ansätze eignen sich für die Lösung unterschiedlicher Probleme des Wissensmanagements.

Dokumentation

Der klassische Ansatz zur Verwaltung von fachspezifischem Wissen im Bereich der Technik ist das Schreiben von Dokumentationen. Dabei wird üblicherweise ein zu einem bestimmten Zeitpunkt aktueller Zustand eines Systems — eine Art "Schnappschuß" — dokumentiert. Neben den fachlichen Kenntnissen des Autors über das zu dokumentierende System sowie seiner Beteiligung daran hängen Umfang und Qualität der Dokumentation auch sehr stark von der zu ihrer Erstellung zur Verfügung stehenden Zeit ab. Eine, in Form eines festen Textes geschriebene, Dokumention hat erfahrungsgemäß das Problem nur selten aktualisiert zu werden und dadurch gerade bei sehr dynamischem Dokumentationsgegenstand zu schnell zu veralten und damit unbrauchbar zu werden.

Ein weiteres, oft auftretendes Problem besteht darin, daß nur selten der für eine wirklich gute und umfassende Dokumentation eines Systems notwendige Aufwand investiert wird.

Knowledgebase

Ein bekanntes und schon zu den Standardwerkzeugen zählendes Mittel zum Management von umfangreichem, jedoch gleichzeitig inhaltlich sehr weit gestreutem, oftmals nur auszugweisem Wissen ist das Mittel der Knowlegdebase. Dabei handelt es sich üblicherweise um eine Sammlung zahlreicher, meist eher kurzer Artikel zu einem ganz spezifischen Problem, die durch ein Recherche-, Schlagwort- und Indexsystem miteinander verknüpft und meist in Form einer Datenbank gespeichert sind. Einer der wohl bekanntesten Vertreter dafür ist die Microsoft Knowledgebase. Mit ihrem umfangreichen Bestand an schlaglichtartig ein ganz bestimmmtes Thema behandelnden Artikeln, den Verknüpfungen der Artikel untereinander, dem System der Verschlagwortung, dem integrierten Recherchesystem und der Präsentation als Webanwendung stellt die Microsoft Knowledge Base ein typisches Beispiel für dieses Konzept des Wissensmanagements dar.

Ein Nachteil dieses Ansatzes ist die üblicherweise flache Organisation einer Knowledgebase.

Mit der Verschlagwortung als einzigem Strukturmittel kann die Suche nach spezifischen Informationen, wenn man nicht die richtigen Schlagworte trifft, zu einer "Odysee im Schlagwortwald" werden. Ein information-overkill tritt ein: Der Benutzer erhält nicht zu wenig Information sondern viel zu viel und muß Zeit darauf anwenden, Relevantes von Irrelevantem zu trennen. Eine Einbindung der einzelnen Artikel in eine zusätzliche, tiefe hierarchische Struktur, könnte diese Situation zwar entschärfen, erfordert jedoch — gerade bei umfangreichen Wissensbeständen — einen nicht unerheblichen redaktionellen Aufwand durch fachkundiges Personal.

Typisch für dieses Phänomen sind z.Bsp. auch Web-Suchmaschinen: Trifft man nicht auf Anhieb die richtigen Suchbegriffe, so wird man von der Menge der gebotenen Informationen regelrecht erschlagen. Erschwerend kommt hier noch dazu, das ein nicht geringer Teil der Informationen aus höchst zweifelhaften Quellen stammt. Der Web-Rechercheur muß also auch Kompetenz besitzen, die Qualität der Quelle zu beurteilen. Erfolgreiche Web-Suchmaschinen arbeiten aus diesem Grund mit Web-Katalogen zusammen, in die Einträge redaktionell eingepflegt werden. Es liegt in der Natur der Sache, daß diese Kataloge zwar sehr hilfreich aber zwangsläufig nicht immer aktuell sein können.

Webbasierte, teamorientierte Dokumentationssysteme

Ein sich zunehmender Beliebheit erfreuender Ansatz zum Wissensmanagement ist das Konzept webbasierter, teamorientierter Dokumentationssysteme, speziell in der als »Wiki Wiki Web« bekanntgewordenen Ausprägung. Die Grundidee des Wiki Wiki Web — üblicherweise kurz als "Wiki" bezeichnet — ist relativ einfach: eine Website, die von ihren Nutzern editiert wird. Jeder Nutzer kann vorhandene Seiten editieren (und löschen) sowie neue Seiten hinzufügen. Das einzige Interface, welches der Nutzer eines Wikis benötigt, ist ein Webbrowser.

Die Verwendung eines Wikis ist komplett webbasiert, von der Recherche über das Editieren bis hin zur (soweit von der jeweiligen Wiki-Implementation unterstützt) Administration des Wiki. Aufgrund des freien Zugriffs auch für Änderungen, vermeiden Wikis das "ein Webmaster Problem" [1] und fördern ein dynamisches Arbeiten mit dem System, was wiederum eine sehr hohe Aktualität ermöglicht.

Damit scheinen Wiki Wiki Webs hervorragend als Teamwerkzeug, da jedes Teammitglied mit minimalem Aufwand zu Inhalt, Struktur und Gestaltung des Wikis beitragen kann, geeignet zu sein. Für Wiki Wiki Webs spricht gerade ihre Einfachheit, die Schulungsaufwand für die Benutzer praktisch nicht entstehen läßt; eine kurze Einweisung dürfte allermeistens ausreichend sein, die Nutzung eines "guten" Wikis ist praktisch selbsterklärend.

Wikis werden dementsprechend auch mit großem Erfolg als teamorientierte Werkzeuge eingesetzt und dienen unter anderem als:

• Kommunikationsplattform innerhalb von Teams,
• Wissensbasis ("Knowledgebase"),
• fortlaufend aktualisierte Dokumentation,
• dynamische Intranets.

Einige kurze, ausgewählte Beispiele für die erfolgreiche Einführung von Wikis in Firmen finden sich in:

• Peter Thoeny, TWiki Success Story of Wind River, Juli 2002,
• Michael Sparks, TWiki Success Story of Inktomi, Juni 2002,
• Peter Thoeny, TWiki Success Story at TakeFive Software, Mai 2000.

Troubleticket-Systeme

Die Mitarbeiter bekommen tagtäglich Anfragen und Anforderungen von verschiedenen Seiten, von eigenen Mitarbeitern, von Kunden, ebenso von Lieferanten usw., die bearbeitet und beantwortet werden wollen. Eine effiziente Organisation diese "Tagesgeschäftes" sorgt für eine zügige Abarbeitung und für eine Vermeidung von "Reibungsverlusten". Eine flotte Abarbeitung von Kundenanfragen sorgt für Zufriedenheit bei diesen und verstärkt deren Bindung an's Unternehmen. Der Einsatz eines Troubleticket-Systems zur Verwaltung dieser Anfragen ist unbedingt zu empfehlen.

Anfragen und Anforderungen werden als Troubletickets gespeichert und ihr aktueller Status sowie ihre Bearbeitung werden dadurch abfrag- und nachvollziehbar. Unter der Vorraussetzung, daß das Troubleticket-System die geschlossenen — also erfolgreich bearbeiteten — Troubletickets mit allen angefallenden Informationen (EMail-Korrespondenz, Notizen, ...) archiviert, sammelt sich im Laufe der Benutzung eines solchen Troubleticket-Systems im System problembezogenes Wissen von erheblichem Umfang an. Dies kann damit auch als Wissensbasis genutzt werden indem z.B. beim erneuten Auftreten bereits erfolgreich bearbeiteter Probleme, der zuständige Bearbeiter auf die bereits vorhandenen Information im Troubleticket-System zurückgreift.

Verschiedene Systeme im Test

Es wurden verschiedene Systeme betrachtet. Aufgrund der großen Varianz der Software in Bezug auf Entwicklungsstand, Leistungsumfang und Zielrichtung, sowie der großen Anzahl der Systeme soll jedoch auf eine detaillierte Erwähnung aller betrachteten Systeme verzichtet werden. In den folgenden Abschnitten sollen lediglich die als empfehlenswert betrachteten Softwaresysteme beschrieben werden.

Request Tracker

Troubleticket-System lassen sich in 3 Gruppen einteilen:

• kommerzielle Produkte,
• spezialisiert auf bestimmte Anwendungsbereiche, z.B. als Troubleticket-System für ISPs, für Webhoster, ...,
• nicht hinreichend ausgereift (dies traf für den überwiegenden Teil der betrachteten Systeme zu).

Aus dem Vergleich der verschiedenen Softwarepakete geht Request Tracker als die beste Universallösung hervor, auf eine detaillierte Behandlung der anderen Systeme soll deshalb an dieser Stelle verzichtet werden.

Request Tracker (Best Practical Solutions, LLC. Request Tracker, 2002, <URL:http://www.bestpractical.com/rt/>) ist ein Troubleticket-System, welches für kleinere bis mittlere Unternehmen konzipiert wurde. Es kann u.a. für Kundensupport, Bugtracking, Troubleticket- Verwaltung verwendet werden. Derzeit ist es weltweit in über 1000 Installationen im Einsatz.

Eine kurze Übersicht über die Merkmale von Request Tracker:

• Nutzung via EMail, Web und Kommandozeile,
• Webinterface für Endnutzer zur schnellen Statusabfrage ihrer Troubletickets,
• SQL-Datenbank als Datenspeicher,
• feingranulare Zugriffssteuerung,
• flexibles Schlagwortsystem,
• umfangreiches System zur Verlinkung innerhalb des Systems sowie zu externen URLs,
• einfache Erweiterbarkeit,
• lizensiert unter der GNU GPL.

Request Tracker benötigt als Installationsvoraussetzungen:

• Perl,
• eine Datenbank (derzeit werden MySQL, PostgreSQL und Oracle unterstützt, der Einsatz von Oracle ist aber laut Dokumentation problematisch),
• ein Webserver mit Perl-Unterstützung, empfohlen wird Apache 1.3 mit mod perl.

Der Arbeitsablauf für den Einsatz von Request Tracker entspricht den üblichen Gepflogenheiten für Troubleticket-Systeme:

1. Per EMail an help@example.com wird ein Problem berichtet.
2. Request Tracker erzeugt daraus ein neues Troubleticket.
3. Request Tracker leitet die EMail an die Gruppe der eingetragenen Mitarbeiter weiter.
4. Einer der Mitarbeiter übernimmt die Bearbeitung des Troubletickets.
5. Nach erfolgreicher Bearbeitung des Troubletickets wird es geschlossen.

Dabei speichert Request Tracker nicht nur den gesamten, über Request Tracker abgewickelten EMail-Verkehr, sondern auch zusätzliche Notizen, Kommentare und Attachments dazu. Weiterhin können Zusammenhänge zwischen Troubletickets eingetragen und dargestellt werden:

• Abhängigkeiten (Darstellung beider Richtungen),
• Verweise (ebenfalls Darstellung beider Richtungen),
• Eltern-/Kind-Beziehungen zwischen Troubletickets.

Request Tracker erweist sich als sehr leistungsfähiges und umfangreiches Troubleticket-System, welches bereits u.a. auch in Tom Limoncelli, Christine Hogan The Practice of System and Network Administration, Addison-Wesley Pub Co, 2001. ISBN 0-201-70271-1, empfohlen wird. Im Bereich der TU Chemnitz ist Request Tracker als Troubleticket-System des Chemnitzer Studentennetzes CSN (Chemnitzer Studentennetz CSN. CSN — Chemnitzer StudentenNetz, 2002, <URL:http://www.csn.tu-chemnitz.de/>) erfolgreich im Einsatz.

TWiki

Aufgrund der großen Popularität von Wikis entwickelte sich auch eine breite Palette an sogenannten Wikiclones (anderen Implementationen des Wiki-Konzeptes). Die verfügbare Palette an Wikiclones ist relativ umfangreich, allein das "The Open Source Development Network (OSDN)", freshmeat.net, 2002, <URL:http://freshmeat.net/> listet unter dem Suchbegriff "Wiki" 27 Treffer (bei denen es sich auch überwiegend um Wikiclones handelt) und auf den "Wiki-WikiClone"- Seiten (Ward Cunningham, Wiki Wiki Web, August 2002, <URL:http://c2.com/cgi/wiki?WikiWikiWeb>) finden sich noch wesentlich mehr verlinkt.

Als ein Mitglied dieser Softwarefamilie soll an dieser Stelle TWiki (Peter Thoeny, TWiki™— A Web Based Collaboration Platform, August 2002, <URL:http://www.twiki.org/>) beschrieben werden, da es die Anforderungen an ein Werkzeug zur Wissensverwaltung unter anderem im Bereich der Systemadministration sehr gut erfüllt.

Übersicht über die Merkmale von TWiki:

• Versionsmanagement — TWiki versioniert alle Wikis, was ein Nachverfolgen von Änderungen (wer/wann/was) ermöglicht,
• eigene Nutzerverwaltung — dieses optionale Feature beseitigt bei Bedarf das Problem der anonymen Änderungen des klassischen WikiWikiWeb,
• Rechteverwaltung — bei Bedarf können damit die Rechte dem Einsatzzweck entsprechend gesteuert werden um z.B. nur bestimmten Nutzern Schreibzugriff auf bestimmte Bereiche zu gewähren,
• File Attachments — in Wikiseiten können downloadbare Dateien eingebunden werden,
• Benachrichtigung per EMail — es ist möglich, sich von Änderungen an Wikis automatisch per EMail benachrichtigen zu lassen,
• weiterhin verfügt TWiki natürlich über die für Wikis üblichen Eigenschaften.

TWiki ist als ein Satz aus Templates, Dokumentation und in Perl geschriebenen CGI-Programmen implementiert. Als Speichersystem für die in den durch TWiki bereitgestellten Wikis wird das "Revision Control System" RCS verwendet — auf diese Weise implementiert TWiki die Versionierung der Wikis. Die Nutzerverwaltung wird über den .htaccess Mechanismus gelöst, die Rechteverwaltung ist im TWiki selbst implementiert.

Der Autor (Alexander Schreiber) verwendet TWiki im Rahmen seiner derzeitigen Tätigkeit als Sysadmin zur zentralen Bereitstellung administrativen Wissens. Dabei hat sich die Unterstützung von TWiki für Attachments als sehr hilfreich erwiesen, da auf diese Weise Patches, Konfigurationsdateien und ähnliches leicht den dokumentierenden Wikiseiten beizulegen sind und nicht an anderer Stelle extern gespeichert werden müssen. TWiki hat sich im Einsatz als Wissenspeicher für die Systemadministration gut bewährt.

unixops

Systeme nach dem Muster einer Knowledgebase — also nach Schlagworten und Eintragsnummern indizierte Wissensspeicher — lassen sich mit relativ geringem Aufwand lokal selbst implementieren. unixops (<URL:http://unixops.no-ip.org/>) wird hier als ein einfaches Beispiel eines Knowledgebase-Systems betrachtet. Die Struktur von unixops ist relativ simpel: es werden Artikel (Texte für die Knowledgebase) und Inventareinträge verwaltet. Dabei dienen eine Suche über den Volltext der Artikel und Inventareinträge sowie ein verlinktes Inhaltsverzeichnis der Einträge der beiden Kategorien als Navigationsmittel. Dieser Ansatz mag für sehr einfache Systeme durchaus verwendbar sein, aber bereits bei einer größeren Anzahl von Einträgen geht bei diesem System die Übersicht verloren. Das Problem der Navigation ist allerdings kein spezifisches Problem dieser Lösung, sondern ein grundlegendes Problem des Konzepts einer flachen Knowledgebase — darauf wurde bereits weiter oben hingewiesen. Der einzig erkennbare Vorteil dieses Konzepts ist der sehr geringe Implementations- und Pflegeaufwand. Dafür müssen allerdings erhebliche Abstriche bei der Benutzbarkeit des Systems in Kauf genommen werden.

Schlußfolgerungen zum Wissensmanagement

Ausgehend von den Betrachtungen und Analysen im Rahmen dieser Arbeit wird als Werkzeug zum Wissensmanagement das Konzept der Wikis, speziell in der Implementation TWiki empfohlen.

Im Vergleich zu anderen Ansätzen bietet das Wiki-Konzept die größtmögliche Flexibilität und einfache Anwendbarkeit.

[1] nur eine bzw. wenige berechtigte Personen können zentrale Webseiten aktualisieren und werden somit zum Flaschenhals

[lars@catsandcoffee.org ] [catsandcoffee.org — Home ] [lars@trash.net ] [mail me] [EXIT ]