Beiträge

Themengruppen

Recherche

• Alle Schlagworte
• Alle Beiträge

Service

• Was ist Wissensmangement?
• Open Journal of Knowledge Management
• Artikel-Guidelines
• Newsletter
• Kalender
• Wissensmanagement-Anbieter
• Partner
• Mediadaten

Community

• Autoren
• Wir über uns
• Login/Registrierung
• Blog zur Community of Knowledge

Sponsoren

"Keep It Simple, Stupid" - Leichtgewichtiges Wissensmanagement mit Wikis

16. Juli 2007 von Peter Rubarth

"The term KISS is an acronym of the phrase 'Keep It Simple, Stupid', and the KISS principle states that simplicity in design should be a key goal." [1] Wiki-Systeme bereiten einen Weg, dieses Prinzip bei der Dokumentation von Wissen umzusetzen. Wikis sind einfach zu benutzen und bieten eine hohe Flexibilität bei der Organisation von Inhalten. Dadurch ermöglichen sie den schrittweisen Aufbau eines Wissensmanagements bei knappen Ressourcen. Durch die geringen Einstiegshürden und vorhandene Funktionalitäten zur Kontrolle tragen Wikis dazu bei klassische Probleme der Dokumentation von Wissen, wie beispielsweise mangelnde Aktualität und fehlende Zeit bei der Erstellung zu reduzieren.

Theorie und Praxis

So gut wie jeder Text zum Thema Software-Entwicklung betont die Bedeutung einer guten Dokumentation. Auf den ersten Blick scheint es deshalb verwunderlich, dass in der Praxis die Dokumentation oft ganz fehlt oder den Namen nicht verdient.

Bei näherer Betrachtung der alltäglichen Rahmenbedingungen der Software-Entwicklung, wird dieser Zustand erklärbarer. Die Arbeit erfolgt oft unter großem Zeitdruck mit unklaren und wechselnden Anforderungen. D.h. vor der Fertigstellung einer Version werden Veränderungen und zusätzliche Funktionalitäten eingefordert.

Alle Beteiligten sind sich über die Notwendigkeit einer ausführlichen Dokumentation grundsätzlich einig. Meist wird für die erste Version der Anwendung auch noch ein Dokument erstellt. Bei den folgenden Anpassungen fehlt für eine Aktualisierung der Dokumentation oft die Disziplin. Nach kurzer Zeit sind Realität und Dokumentation bereits so weit auseinander gelaufen, dass der Aufwand für die notwendigen Anpassungen den der ursprünglichen Erstellung übersteigt. Das Resultat ist eine untaugliche, weil veraltete und mangelhafte Dokumentation. Für die Arbeit an der Anwendung stellt sie keine Hilfe dar. Im schlimmsten Fall ist sie sogar kontraproduktiv, weil die Arbeit auf überholten Angaben aufsetzt.

Wechselt dann überraschend die Verantwortlichkeit für die Anwendung, sieht sich der neue Entwickler erst einmal mit einer - wenig erfreulichen - Aufgabe konfrontiert, die noch dazu wenig mit dem Ideal der Software-Entwicklung zu tun hat: Er muss anhand der fehlerhaften Dokumentation und des Quellcodes die bestehende Anwendung analysieren, um Sie selbst entsprechend den neuen Anforderungen zu modifizieren. Aus einer ählichen Situation wie dieser entstand der Wunsch nach einer Lösung für dieses Dilemma.

Das Projekt "Berlin will es Wissen" bot forium.de, einer unabhängigen Berliner Finanzredaktion, dabei eine willkommene Unterstützung. Das bereits begonnene interne Projekt einer begleitenden Dokumentation sollte mit weiterer Fachkompetenz aus dem Bereich des Wissensmanagements bereichert werden. Der objektive Blick eines externen Partners hat im Projektverlauf geholfen, Ungereimtheiten aufzudecken und verschiedene Konzepte bei der Entwicklung eines strukturierten Wisssensmanagements zu optimieren.

Kanonen und Spatzen

Ein Umstand begleitet speziell bei kleineren und mittelständischen Unternehmen (KMU) derartige, nicht unmittelbar wertschöpfende Projekte. Es gibt Zustimmung zur Analyse der Ist-Situation und eine Verbesserung ist gern gesehen. Es stehen allerdings keine zusätzlichen Ressourcen für das Projekt zur Verfügung. Die Durchführung muss "nebenbei" erfolgen. Wertschöpfende Prozesse haben dabei immer Vorrang.

Diese "unternehmerischen" Gegebenheiten verurteilen aus Sicht des Autors bei KMUs viele Ansätze mit großen, alles umfassenden Wissensmanagement-Lösungen fast zwangsläufig zum Scheitern.

Der Konzeptions-, Installations- und Wartungsaufwand steht zudem in keinem angemessenen Verhältnis zur eigentlichen Zielsetzung eines einfach und schnell zu bedienenden Systems.

Viel wichtiger ist jedoch, dass die Unmenge von Funktionalität leicht erdrückend auf potentielle Nutzer wirkt, wobei letztendlich nur ein minimaler Anteil tatsächlich benötigt wird.

Von der Mondrakete zum Fahrrad

Wiki-Systeme stellen einen faszinierenden Ausweg für das Dilemma zwischen minimalen Ressourcen auf der einen und unangemessen komplexen Systemen auf der anderen Seite dar.

Ursprünglich wurden sie für gemeinschaftliches Schreiben im Web entwickelt. Das nicht-kommerzielle Projekt Wikipedia ist das beeindruckende Ergebnis dieser Bemühungen.

Der unaufdringliche Charme der Wiki-Systeme liegt in der Verbindung aus fast intuitiver, simpler Benutzbarkeit und minimalem Lernaufwand verbunden mit mächtigen Fähigkeiten zur Auszeichnung und Organisation von Inhalten.

Eine weitere, wesentliche Stärke - insbesondere bei Mediawiki [2], der Software hinter Wikipedia - ist die intensive Weiterentwicklung des "quelloffenen" Systems basierend auf dem unmittelbaren Feedback der Nutzerschaft.

Das Fehlen kommerzieller Interessen hilft dabei die Anwendung an den tatsächlichen Interessen der Nutzer auszurichten.

Im konkreten Anwendungsfall entschied sich das Team von forium.de für Mediawiki [2], weil dadurch die schrittweise Entwicklung eines Wissensmanagement-Systems ermöglicht wird. Die Vorbereitung für den Einsatz des Systems konnte mit einem minimalen Initialaufwand und ohne Erfahrung mit derartigen Projekten bewerkstelligt werden.

Weitere Pluspunkte der Mediawiki [2]-Lösung sind die aktive Weiterentwicklung und eine daraus resultierende hohe Systemstabilität. Die einfachen Administrationsmöglichkeiten spielen ebenfalls eine wichtige Rolle bei der Systemauswahl.

Sofware-Dokumentation als Testballon

Der Einstieg erfolgte bei forium.de mit einem Pilotprojekt. Aufgabe war, die aktuellste Version einer intern erstellten Software so zu dokumentieren, dass die Administration der Anwendung auf Grundlage dieser Anleitung erfolgen kann.

Bei den Vorüberlegungen wurde klar, dass der Start nicht "auf der grünen Wiese", also ohne Richtschnur für die Strukturierung der Inhalte, erfolgen konnte. Für die Festlegung der Ausgangsstruktur kam "Card-Sorting" [2] als Verfahren zum Einsatz. Diese Moderations-Technik ermöglichte eine unkomplizierte Entwicklung der Kategorien für das Pilotprojekt.

Exkurs Card Sorting

Als "Card-Sorting" wird ein charmant simples, intuitiv einzusetzendes Verfahren bezeichnet, um Informationsstrukturen festzulegen [3].

Die Schlagworte des abzubildenden Informationsraums werden einzeln auf Karteikarten notiert. Diese Karten werden dann beispielsweise auf einem Tisch in Gruppen geordnet, die aus Sicht der Beteiligten eine logische Ordnung abbilden.

Die Sortierung kann dabei einfach verändert werden, bis ein zufriedenstellendes Ergebnis hergestellt ist. Das Ergebnis wird dann entsprechend dokumentiert. Ein einfacher Weg dafür ist das Abfotografieren der ausgelegten Karteikarten.

Card-Sorting kann mit mehreren Testpersonen einzeln angewendet werden, um die in der Testgruppe vorhandenen Ordnungsschemata in der Fachdomäne zu ermitteln. Im konkreten Fall wurde die Sortierung von den Projektteilnehmern gemeinsam durchgeführt, um so eine erstes "Inhaltsverzeichnis" für das Wiki zu erstellen.

Die Vorteile von "Card-Sorting" sind, dass das Verfahren nur minimaler Erklärung und einfachster Hilfsmittel bedarf. Das gemeinsame Sortieren ist damit besser zu bewerkstelligen, als mit jeder Software. Das Ergebnis wird nur insofern eingeschränkt, als es sich auf einem Tisch darstellen lässt (sogar dreidimensionale Strukturen lassen sich einfach abbilden).

Es ist gegebenenfalls spontan einsetzbar, wenn im Rahmen eines Projekts der Bedarf erkennbar wird.

Erfahrungen aus dem Pilot

Die Ergebnisse des ersten Projektes waren sehr ermutigend. Es zeigte sich, dass die Erwartungen hinsichtlich der Einfachheit von Mediawiki [2] erfüllt wurden. Die Übersetzung der auf Karteikarten fest gehaltenden Struktur in Wiki-Inhalte durch technisch nicht affine Anwender funktionierte nach einer Einführung von knapp 15 Minuten. Die Hoffnungen hinsichtlich des geringen Administrationsaufwands erfüllten sich ebenfalls.

Daneben ergaben sich weitere Erkenntnisse, die für die Ausweitung des Einsatzes hilfreich waren.

1. Keine flachen Hierarchien

Die meisten Anwender haben eine starke Neigung, Inhalte hierarchisch zu strukturieren. Hypertext als Strukturierungsmodell ist für viele ungewohnt und wird als "unhandlich" empfunden.
Die Organisation des Wikis orientiert sich deshalb auch stark an Hierarchien, auch wenn das System flexiblere Modelle ermöglicht.

2. Verwechslungsgefahr

Das Wikisystem nutzt Kategorien zur Strukturierung von Inhalten. Zwar lassen sich darüber Hierarchien abbilden. Trotzdem ist allein der Name eines Artikel das entscheidende Organisationskriterium. Das hat zur Folge, dass der Name im System eindeutig sein muss und nur einmal vorkommen darf.
Im Pilotprojekt kam verschiedentlich das Problem auf, dass verschiedene Artikel denselben Arkikelnamen erhalten hatten, da darin unterschiedliche Aspekte behandelt wurden.
Da die Zusammenfassung in einen Artikel sachlich und inhaltlich keine gangbare Lösung darstellte, wurde die Einführung von "Namensräumen" - vergleichbar mit Packagestrukturen bei Softwarequellen - beschlossen.
Die Namensräume bestehen aus einem Buchstabenkürzel, das in Klammern an das Ende des Artikelnamens gestellt wird und sich aus dem Namen der nächsthöheren Kategorie ableitet. Die Kürzel werden bei erstmaliger Verwendung festgelegt und auf der Kategorieseite dokumentiert. Dieses Verfahren bedarf zwar einer gewissen Erläuterung und Kontrolle. Es ermöglicht aber die Unterscheidung sonst identischer Bezeichnungen mit minimalem Aufwand. Die alphabetische Sortierung der Artikelnamen bleibt trotz Namensräumen erhalten.

3. Zugriffsrechte

Ein Manko von Mediawiki [2] - zumindest in der verwendeten Version: Im Gegensatz zu anderen Systemen bietet es keine Möglichkeit, den Zugriff auf bestimmte Artikel abhängig von der festgelegten Rolle eines Benutzers zu reglementieren. Jeder Nutzer hat daher immer das Recht auch jeden Artikel zu lesen.
Da sich die Rollen im Unternehmen recht klar unterscheiden ließen, wurde dieses Problem durch die Einrichtung separater Wikis - je nach Anwendergruppe - gelöst.

Ausbau Ausbau

Im Anschluss an das Pilotprojekt erfolgte eine schrittweise Einbeziehung aller Mitarbeiter und Bereiche. Aktuell läuft die Übertragung bestehender, als Einzeldokumente vorliegender Anleitungen in das Wiki.

Fazit

Ein Wiki als leichtgewichtiges Wissensmanagementsystem hat sich bewährt. Die Einstiegshürden sind bedeutend niedriger als bei klassischen Lösungen und ermöglichen einen schrittweisen Einstieg mit geringem Administrationsaufwand.

Die Organisation der Inhalte im laufenden Betrieb funktioniert am besten mit einer Ausgangsstruktur als Basis. Eine gewisse hierarchische Ordnung kommt der Herangehensweise der Anwender entgegen.

Die wesentlichen Problemstellen (Zeitaufwand und Aktualität) bleiben allerdings auch mit einem Wiki-System bestehen. Die einfache Nutzung sowie die schnelle Erlernbarkeit verbunden mit effektiven Kontrollfunktionen helfen diese Hindernisse zu umgehen.

Ausblick

Das beschriebene Projekt fungierte in gewisser Weise als Türöffner für den Einsatz kollaborativer Web-Anwendungen.

Zwischenzeitlich wurde ein firmeninternes Blog eingerichtet und kurz darauf ein eigenes öffentliches Weblog unter www.geld-kompakt.de gestartet. Die Erfahrungen mit diesem System sind derart positiv, dass mittelfristig alle redaktionellen Arbeiten über das Blog-System abgewickelt werden sollen.

Im IT Bereich wird gegenwärtig "trac" als Issue-Tracking System eingeführt. trac ist eine leichtgewichtige Kombination aus Issue-Tracker, Wiki und Projektplanungs-Anwendung. Insbesondere bei Projekten mit kleinen Entwicklerteams und vielen Änderungen im Verlauf ist trac eine sympathische Lösung für den Einstieg in eine strukturierte Planung der Ressourcen und Funktionalitäten.

Exkurs Issue-Tracking

Issue oder Bug-Tracker [4] bezeichnen Anwendungen, die im Bereich der Softwareentwicklung eingesetzt werden, um aufgetretene Fehler oder anstehende Modifikationen bzw. sonstige Aufgaben zu erfassen, zuzuweisen und nachzuverfolgen.

Referenzen

[1] en.wikipedia.org/wiki/KISS_principle
[2] www.mediawiki.org/wiki/MediaWiki
[3] www.boxesandarrows.com/view/card_sorting_a_definitive_guide; Donna Maurer und Todd Warfel ; 07.04.2004
[4] de.wikipedia.org/wiki/Bug-Tracker



Lizenziert unter einer Creative-Commmons Lizenz