Open Source Knowledge Management

Xpert.press Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie u...

Author: Georg Hüttenegger

49 downloads 1942 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Georg Hüttenegger

Open Source Knowledge Management Mit 10 Abbildungen und 9 Tabellen

123

Georg Hüttenegger Khekgasse 39/4 1230 Wien, Österreich [email protected]

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1439-5428 ISBN-10 3-540-33076-3 Springer Berlin Heidelberg New York ISBN-13 978-3-540-33076-9 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten durch den Autor Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3100 YL – 5 4 3 2 1 0

Vorwort und Leitfaden

Die vielf¨ altigen M¨ oglichkeiten von Open Source Software zur Unterst¨ utzung von Knowledge Management (KM) beziehungsweise Wissensmanagement werden mit dem vorliegenden Buch aufgezeigt. Bei zwei so großen Gebieten ist dabei nur eine umfassende Betrachtungsweise sinnvoll. Daher bietet der Text einerseits die Grundlage f¨ ur eine umfassende Betrachtung von KM und andererseits Analysen von konkreten Open Source Produkten und liefert Entscheidungskriterien sowie Anleitungen zu einem m¨ oglichen Vorgehen. In der Vergangenheit haben sich die allermeisten KM Initiativen auf kommerzielle Software gest¨ utzt. Dadurch waren zwar relativ viele Funktionen verf¨ ugbar aber die Kosten wurden in schwindelerregende Höhen getrieben und es blieben nur noch wenige Ressourcen f¨ ur die entscheidenden Aspekte abseits der Technik. Die Folge waren eine ganze Reihe von Fehlschlägen, die KM selbst in ein schlechtes Licht r¨ uckten. Gerade hier bietet Open Source und der in diesem Buch vorgeschlagene schrittweise Ansatz eine Lösung. Der Fokus wird klar auf die organisatorischen Aspekte gelegt und gleichzeitig kann man Schritt f¨ ur Schritt die Unterst¨ utzung durch IT ausbauen. Damit ist eine viel h¨ ohere Wahrscheinlichkeit f¨ ur Erfolg gegeben, auch wenn man eventuell auf die eine oder andere technische Funktion verzichten muss (die aber vielleicht sowieso niemand verwendet h¨ atte). In diesem Zusammenhang muss man sich auch vor Augen halten, dass es nicht ein ultimatives KM System f¨ ur alle Organisationen gibt. Die einzig mögliche Schlussfolgerung ist ein Eingehen auf die individuelle Organisation und ein entsprechend angepasstes KM System. Die unverzichtbare Basis daf¨ ur ist ein Verst¨ andnis f¨ ur KM im Allgemeinen und die prinzipiellen Möglichkeiten, die dadurch offen stehen. Damit ist eigentlich auch schon der Aufbau dieses Buches erklärt. Zuerst gibt es zwei Kapitel, die einerseits in das Thema einleiten und andererseits Anforderungen und Voraussetzungen von KM analysieren sowie die Vorstellung eines umfassenden KM Systems auf theoretischer Ebene. F¨ ur den reinen Praktiker (und eventuell Techniker) k¨ onnte sich dieser Text als schwierig (oder auch als Durststrecke“) erweisen. In solchen Fällen macht es sicher ”

VI


Sinn, gleich zu Kapitel 3 zu springen. F¨ ur eine komplette Sichtweise sollte man aber unbedingt vor Kapitel 5 zu den einleitenden Kapiteln zur¨ uckkehren. Mit Kapitel 3 werden dann die wichtigsten Kategorien von Open Source Software vorgestellt sowie entsprechende Produkte besprochen. Daran schließt das Kapitel 4 mit u ¨ berwiegend (aber nicht nur) technischen Aspekten an, die man sich grunds¨ atzlich vor Einf¨ uhrung eines KM Systems u ¨berlegen sollte. Insbesondere Kapitel 4 (aber auch Kapitel 3) könnte sich als schwer verständlich f¨ ur einen reinen Organisator oder Manager entpuppen. Daher kann hier ruhigen Gewissens empfohlen werden, Kapitel 4 zu u ¨berfliegen, wenn man nicht f¨ ur entsprechende Aspekte verantwortlich ist. Die folgenden Kapitel behandeln dann die Einf¨ uhrung eines KM Systems basierend auf Groupware, Content Management und Document Management Systemen. Diese Basis ist f¨ ur viele Organisationen geeignet und bietet die wichtigsten Funktionen f¨ ur KM an. Nat¨ urlich ist das keine Rocket ” Science“ sondern stellt ganz im Gegenteil die Anwendung und Verwendung breitest eingef¨ uhrter Technologien dar. Je nach den konkreten Zielen der KM Initiative k¨ onnte so ein KM System aber durchaus schon mehr als ausreichend sein und insbesondere mit entsprechenden organisatorischen Maßnahmen ei¨ ne Organisation deutlich nach vorne bringen. Uberhaupt gibt es eine ganze Reihe organisatorischer und wirtschaftlicher Fragen, die zusammen mit den technischen Aspekten einer Analyse bed¨ urfen und entsprechend besprochen werden. Nur so kann eine KM Initiative wirklich erfolgreich sein. Im vorletzten Kapitel werden dann mögliche Erweiterungen des davor pr¨ asentierten (individuellen) KM Systems vorgestellt und analysiert. Die Wichtigkeit und Notwendigkeit von so spannenden Themen wie Topic Maps, Ontologien, des Semantic Web, eLearning, K¨ unstlicher Intelligenz oder die Erweiterung“ um simplere“ Dinge wie einen Workflow, Business Software ” ” beziehungsweise interessanten Randsystemen (etwa ein Wiki oder ein Ticket Request System) kann dabei nicht generell beantwortet werden. Hier liefert der Text wieder eine Analyse und diskutiert, welche Punkte eine konkrete KM Initiative ber¨ ucksichtigen muss, um zu einer guten Entscheidung zu kommen. Gleichzeitig zeigt dieses Kapitel auch das Potenzial eines KM Systems auf Open Source Basis auf: Es gibt kaum einen Bereich, der nicht abgedeckt werden kann. Im letzten Kapitel gibt es dann nach einer kurzen Zusammenfassung vor allem noch einen Abschluss sowie einen Ausblick. Der Abschluss zeigt einen Kreislauf zur Einf¨ uhrung und Verbesserung eines KM Systems und diskutiert die Eckpfeiler und Grundlagen von KM und einem KM System. Damit wird auch noch einmal darauf eingegangen, dass ein reines IT System keine L¨ osung ist. Der Ausblick besch¨ aftigt sich dann mit wichtigen Trends f¨ ur KM im Allgemeinen und KM Systeme im Speziellen. Diese Darstellung des Inhalts zeigt auch schon, welchen Nutzen ein Leser aus einer durchgehenden Lekt¨ ure ziehen kann. Ausgehend von theoreti” ¨ schen“ und grunds¨ atzlichen Uberlegungen zu KM und KM Systemen geht es u ¨ ber konkrete Open Source Systeme und grundlegende technische Erwägun-


VII

gen zu der Einf¨ uhrung eines KM Systems und dem möglichen Ausbau. Damit bekommt der Leser eine umfassende Sicht auf alle relevanten Themen, Technologien und Systeme. Insbesondere kann man viele Teile des Buches auch als Referenz und bis zu einem gewissen Grad sogar Nachschlagewerk nutzen. F¨ ur diesen Zweck gibt es neben dem Index auch ein umfangreiches Glossar. So eine Herangehensweise ist vor allem dann sinnvoll, wenn man sich mit den behandelten Themen schon intensiv auseinander gesetzt hat oder nur an bestimmten Aspekten einer KM Initiative Interesse hat. Damit ist auch klar, welche Personengruppen am meisten von der Lekt¨ ure profitieren k¨ onnen. Jeder, der ein umfassendes Interesse an KM Systemen und vor allem auch KM selbst hat. Dazu gehören sicher IT Manager, f¨ ur KM Initiativen oder Systeme verantwortliche Projektleiter und ITArchitekten oder etwa auch Organisatoren. Einem reinen Softwareentwickler, Anwender oder Entscheider, der kein Verständnis f¨ ur technische Details braucht, werden dagegen einige Inhalte nichts sagen. Trotzdem kann auch die letztgenannte Gruppe von der Lekt¨ ure profitieren, wenn sie das zuvor angesprochene umfassende Interesse an KM hat. Anders gesagt: Jemand der KM und KM Systeme mit Open Source Software interessant findet, sollte hier eine Menge Informationen und Anregungen finden. Prinzipiell eignen sich die beschriebenen Ansätze und Produkte f¨ ur Organisationen aller Art und jeder Gr¨ oße (beziehungsweise wird zum Teil explizit auf solche Punkte eingegangen). Gleichzeitig wird es umso schwieriger, den beschriebenen Ansatz umzusetzen, je mehr Systeme schon im Einsatz sind und je mehr Anwender diese nutzen. Daher passen“ die dargestellten ” Ans¨ atze besser f¨ ur kleinere Organisationen als f¨ ur größere. Das soll aber niemanden abhalten, eine entsprechende Analyse durchzuf¨ uhren und konsequent in Richtung einer reinen oder gemischten Open Source Lösung zu gehen. Ein ganz anderes Thema muss auch unbedingt noch angesprochen werden. N¨ amlich, dass sich sicher trotz einer sorgf¨ altigen Analyse der eine oder andere Fehler beziehungsweise die eine oder andere Ungenauigkeit eingeschlichen hat. Genau wie bei etwaigen Rechtschreibfehlern liegt die Verantwortung ausschließlich bei mir pers¨ onlich und ich m¨ ochte mich schon vorab f¨ ur jeden Fehler entschuldigen. Insbesondere m¨ ochte ich auch darauf hinweisen, dass die jeweilige Beurteilung eines Open Source Systems unter einem speziellen Blickwinkel entstand und keine allgemeine Bewertung darstellt. Alle aufgenommenen Systeme stellen eine Bereicherung dar und alle, die dabei mithelfen, haben eine tolle Arbeit geleistet. Wichtig ist in diesem Zusammenhang auch noch die Tatsache, dass dieses Buch grob den Stand von Februar 2006 wiedergibt und eine entsprechende Momentaufnahme ist. Aufgrund der F¨ ulle an vorhandenen Open Source Systemen und angesichts der Tatsache, dass extrem viele einen Beitrag f¨ ur KM leisten können, war leider eine Auswahl notwendig. Soweit machbar wurden alle wichtigen Systeme ber¨ ucksichtigt. Gleichzeitig hat sich eine gewisse Willk¨ ur nicht vermeiden las-

VIII


sen. Daher illustriert das Fehlen eines Systems eher mein Nichtwissen als dass es eine Wertung darstellt. Beim Literaturverzeichnis dieses Buches handelt es sich um eine Mischung zweier Aspekte. Einerseits repr¨ asentiert es die wichtigsten verwendeten Unterlagen. Andererseits enth¨ alt es auch eine Reihe von Literaturhinweisen. Das hat sich aus der Tatsache ergeben, dass ich das Meiste auf Englisch gelesen habe und gleichzeitig m¨ oglichst viele sinnvolle deutsche Referenzen angeben wollte. Man sieht, dass es sich um spannendes und herausforderndes Thema handelt. Aufgrund der bisherigen Fehlschl¨ age und der aktuellen Entwicklungen im Feld KM scheint ein umfassender Ansatz der einzig sinnvolle. Dabei soll dieses Buch helfen, ein wenig Licht in die verf¨ ugbare Open Source Basis zu bringen, und illustrieren, wie man sie sinnvoll f¨ ur KM einsetzen kann. Im Ergebnis können alle Beteiligten nur gewinnen, da die Organisationen wettbewerbsfähiger werden, die Open Source Produkte noch mehr Anwender gewinnen können und damit wieder besser werden. Als Letztes m¨ ochte ich mich noch recht herzlich bei allen beteiligten Pro” belesern“, Kritikern und meiner Familie f¨ ur die Unterst¨ utzung meiner Arbeit an diesem Buch bedanken. Insbesondere Dr. Christa Chorherr hat neben Dr. Gerhard Budin und Karin Robinek wertvolle Hinweise geliefert. Dar¨ uber hinaus war noch mein Freund Mark-René Uchida eine unschätzbare Hilfe. Ohne ihn w¨ are dieses Buch nicht entstanden. Danke! Nat¨ urlich bin ich an Kritik, Anmerkungen, Anregungen oder ganz allgemein R¨ uckmeldungen interessiert (am besten per E-Mail: [email protected]). Damit bleibt mir nur noch dem geneigten Leser eine interessante Lekt¨ ure zu w¨ unschen.

Wien, M¨ arz 2006

Dr. Georg H¨ uttenegger

Inhaltsverzeichnis

1

2

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Definitionen (Knowledge, Knowledge Management, Open Source, . . . ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Definition von Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Definition von Knowledge Management . . . . . . . . . . . . . . 1.1.3 Das Verh¨ altnis von Knowledge Management zu IT . . . . . 1.1.4 Definition von Open Source . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 H¨ aufige Fragen bei Open Source . . . . . . . . . . . . . . . . . . . . . 1.2 Verwandte Gebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Der Fokus des Buches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2 3 3 4 5 7 8

Vision eines KM Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Ziele von KM (inklusive eLearning) . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 eLearning Ziele und der Zusammenhang mit KM . . . . . . 2.2 Voraussetzungen und Grundlagen von und f¨ ur KM . . . . . . . . . . . 2.2.1 Der Wille zu KM und das Wissen u ¨ber das Warum . . . . 2.2.2 Eine Kultur des Teilens und der Zusammenarbeit . . . . . 2.2.3 Intrinsische versus Extrinsische Motivation . . . . . . . . . . . 2.2.4 Wahrhaftigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Ziele f¨ ur KM setzen und u ufen . . . . . . . . . . . . . . . . . ¨ berpr¨ 2.2.6 KM und Innovation/Kreativität . . . . . . . . . . . . . . . . . . . . . 2.2.7 Barrieren und Hindernisse: Entfernen und Errichten . . . 2.2.8 Zeit, Geld, Strukturen und Traditionen . . . . . . . . . . . . . . . 2.2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Was muss ein vollst¨ andiges KM System adressieren . . . . . . . . . . 2.3.1 Erfassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 (Technisch) Integrieren und Einbinden (Verbinden) . . . . 2.3.3 Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Speicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Flexibles & Adaptierbares Berechtigungssystem . . . . . . . 2.3.6 Leute miteinander verbinden . . . . . . . . . . . . . . . . . . . . . . . .

11 11 12 13 13 13 14 14 15 15 16 16 17 17 17 18 18 19 19 20

X

Inhaltsverzeichnis

2.3.7 K¨ unstliche Intelligenz/Data Mining/Knowledge Discovery in Databases/Maschinelles Lernen . . . . . . . . . . 2.3.8 Erfassung, Verwaltung & Pr¨ asentation von Kontext, Links & Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.9 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.10 Suchen, Finden und Zugreifen . . . . . . . . . . . . . . . . . . . . . . . 2.3.11 Einbettung in den normalen Arbeitsablauf . . . . . . . . . . . . 2.3.12 Transparenz und Nachvollziehbarkeit . . . . . . . . . . . . . . . . 2.3.13 Unverzichtbare Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 2.3.14 Uberblick ........................................ 3

Vorhandene Open Source Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 3.1 Uberblick u ¨ber Kategorien und Technologien . . . . . . . . . . . . . . . . 3.1.1 Wichtige Kategorien von Softwareprodukten . . . . . . . . . . 3.1.2 Wichtige Basistechnologien . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Abschließend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Groupware Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 OpenGroupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Open-Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Kolab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 PHProjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Tiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 PhpGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Content Management Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 elevateIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 OpenCMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 JBOSS Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Mambo/Joomla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.7 PHP-Nuke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.8 Typo3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.9 Xaraya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.10 XOOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.11 phpWebSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.12 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Document Management Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 docman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 KnowledgeTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 NO-SOD: eDMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 OpenDocMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.6 Paper Harbour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.7 xinco-DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 21 21 22 23 23 24 24 27 27 28 29 29 30 31 32 33 34 35 35 37 37 40 41 41 42 43 44 45 46 46 46 47 48 53 53 54 54 55 55 56 56

Inhaltsverzeichnis

3.4.8 jLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Wichtige Technologien (Portale, Semantische Informationen, KI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Portale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Topic Maps & Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 K¨ unstliche Intelligenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Weitere verf¨ ugbare Open Source Software . . . . . . . . . . . .

XI

57 58 60 63 64 65 66 67

4

Technische Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.1 Einbeziehung vorhandener Datenbestände/Systeme . . . . . . . . . . 77 4.1.1 Groupware Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.1.2 CMS/DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.1.3 Datenbanken/best¨ ande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.1.4 Business Software (ERP, CRM, etc.) . . . . . . . . . . . . . . . . . 82 4.1.5 Portale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.1.6 Diverses“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 ” 4.1.7 Individualsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.1.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.2 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.2.1 Offenheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.2.2 Verf¨ ugbarkeit/Zuverl¨ assigkeit . . . . . . . . . . . . . . . . . . . . . . . 87 4.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.3 Entscheidung u ¨ber Basistechnologien . . . . . . . . . . . . . . . . . . . . . . . 88 4.3.1 Know-how & Grundlagen einer Evaluierung . . . . . . . . . . . 88 4.3.2 Know-how Felder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.3.3 Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.4 Connectivity – Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.3.5 Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.4 Basis Portal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.4.1 Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.4.2 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.5 Bild eines umfassenden KM Systems . . . . . . . . . . . . . . . . . . . . . . . 101

5

Start mit einem Groupware System . . . . . . . . . . . . . . . . . . . . . . . . 105 5.1 Einf¨ uhren oder Weiterverwenden . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.1.1 Einf¨ uhrung eines Groupware Systems . . . . . . . . . . . . . . . . 107 5.1.2 Abl¨ ose eines Groupware Systems . . . . . . . . . . . . . . . . . . . . 109 5.2 Punkte f¨ ur die Integration eines bestehenden System . . . . . . . . . 111 5.3 Entscheidungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.3.1 Die Art der Einbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.3.2 Argumente f¨ ur den Start mit einem Groupware System . 116 5.4 Umsetzungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

XII

Inhaltsverzeichnis

5.4.1 Geplanter Umfang des KM Systems . . . . . . . . . . . . . . . . . 118 5.4.2 Externe oder interne Entwicklung und Betrieb . . . . . . . . 119 5.4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.5 Vorhandene Open Source Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.5.1 Diskussion der Groupware Systeme . . . . . . . . . . . . . . . . . . 121 5.5.2 Integration einer vorhandenen Groupware . . . . . . . . . . . . 123 5.5.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6

Alternativ Start mit einem Content Management System . . 125 6.1 Potenzielle Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6.1.1 Ziele der KM Initiative/des KM Systems . . . . . . . . . . . . . 126 6.1.2 Vorhandene Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.1.3 Argumente f¨ ur den Start mit einem CMS System . . . . . . 128 6.2 Entscheidung f¨ ur ein Gebiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.2.1 Entscheidungsgrundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.2.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6.3 Entscheidung f¨ ur ein System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6.3.1 Diskussion der CMS Systeme . . . . . . . . . . . . . . . . . . . . . . . 135 6.3.2 Hilfestellung f¨ ur die Systemauswahl . . . . . . . . . . . . . . . . . . 142 6.4 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.4.1 Organisatorische Punkte . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.4.2 Technische Punkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6.4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7

Einbinden Groupware oder CMS bzw. Erweitern um DMS 149 7.1 Erweitern um ein Content Management System . . . . . . . . . . . . . 149 7.1.1 Integration oder Nebeneinander . . . . . . . . . . . . . . . . . . . . . 150 7.1.2 Entscheidung(skriterien) . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.1.3 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.2 Erweitern um ein Groupware System . . . . . . . . . . . . . . . . . . . . . . . 158 7.2.1 Integration oder Nebeneinander . . . . . . . . . . . . . . . . . . . . . 159 7.2.2 Umsetzungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 7.3 Wichtigkeit und Anwendungsgebiete DMS . . . . . . . . . . . . . . . . . . 162 7.3.1 Wichtigkeit von DMS Funktionen . . . . . . . . . . . . . . . . . . . 162 7.3.2 Anwendungsgebiete von DMS Funktionen . . . . . . . . . . . . 163 7.3.3 Volltextsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 7.3.4 Entscheidungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 7.3.5 Vorhandenes bzw. Integration . . . . . . . . . . . . . . . . . . . . . . . 169 7.3.6 Diskussion der DMS Systeme . . . . . . . . . . . . . . . . . . . . . . . 171 7.3.7 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Inhaltsverzeichnis

8

XIII

Weiterer Ausbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 8.1 Einbeziehung von Topic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 8.1.1 Taxonomien und Onotologien . . . . . . . . . . . . . . . . . . . . . . . 182 8.1.2 Topic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.1.3 Generelle Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8.1.4 Vorhandene Open Source Basis . . . . . . . . . . . . . . . . . . . . . . 190 8.1.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 8.2 Verwendung von Semantic Web Technologien (OWL, RDF, . . . )193 8.2.1 Semantic Web Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.2.2 Semantic Web & KM Systeme . . . . . . . . . . . . . . . . . . . . . . 196 8.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 8.3 (Weitere) Integration von Drittsystemen/Datenquellen . . . . . . . 199 8.3.1 ERP/CRM Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 8.3.2 Digital Library: Greenstone . . . . . . . . . . . . . . . . . . . . . . . . . 202 8.3.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.4 Exemplarische Erweiterungsm¨ oglichkeiten . . . . . . . . . . . . . . . . . . 204 8.4.1 Bulletin Board System (BBS): phpBB . . . . . . . . . . . . . . . 204 8.4.2 Kalenderapplikation: WebCalender . . . . . . . . . . . . . . . . . . 205 8.4.3 Wikimodule wie etwa phpWiki . . . . . . . . . . . . . . . . . . . . . . 205 8.4.4 Open Ticket Request Systeme (OTRS) . . . . . . . . . . . . . . . 206 8.4.5 Visualisierungssysteme wie etwa der Matrixbrowser . . . . 206 8.4.6 E-Mailklassifizierung wie etwa mit POPFile . . . . . . . . . . . 207 8.4.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 8.5 Erg¨ anzung von Workflowfunktionen . . . . . . . . . . . . . . . . . . . . . . . . 209 8.5.1 Spannungsfeld: Workflows & KM . . . . . . . . . . . . . . . . . . . . 209 8.5.2 Workflows als Teil einer KM Initiative . . . . . . . . . . . . . . . 210 8.5.3 Workflows mit einer gewissen Nähe zur KM Initiative . . 211 8.5.4 Workflows f¨ ur die allgemeine Arbeit . . . . . . . . . . . . . . . . . 212 8.5.5 Vorgehen bez¨ uglich Workflows & KM . . . . . . . . . . . . . . . . 213 8.5.6 Vorhandene Open Source Basis . . . . . . . . . . . . . . . . . . . . . . 215 8.5.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 8.6 Eingehen auf spezielle eLearning Anforderungen . . . . . . . . . . . . . 218 8.6.1 eLearning Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 ¨ 8.6.2 Interessante Uberschneidungen von eLearning mit KM . 220 8.6.3 eLearning- Angebot“ von schon vorgestellten Systemen 223 ” 8.6.4 M¨ ogliche Erweiterungen von eLearning Funktionen . . . . 225 8.6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 8.7 Nutzbarmachen der verf¨ ugbaren Informationen . . . . . . . . . . . . . . 227 8.7.1 Nutzung der Informationen ohne KI . . . . . . . . . . . . . . . . . 228 8.7.2 Verwendung von KI und semantischen Informationen . . 231 8.7.3 M¨ oglichkeiten und Einsatzzwecke von KI . . . . . . . . . . . . . 232 8.7.4 Die Bedeutung semantischer Informationen . . . . . . . . . . . 234 8.7.5 Praktische Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 8.7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

XIV

9

Inhaltsverzeichnis

Zusammenfassung, Abschluss und Ausblick . . . . . . . . . . . . . . . . 245 9.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.1.2 Vision eines KM-Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.1.3 Vorhandene Open Source Basis . . . . . . . . . . . . . . . . . . . . . . 248 9.1.4 Technische Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 9.1.5 Start mit einem Groupware System . . . . . . . . . . . . . . . . . . 250 9.1.6 Alternativ Start mit einem Content Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 9.1.7 Einbinden Groupware oder CMS bzw. Erweitern um DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.1.8 Weiterer Ausbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 9.2 Abschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.2.1 Von der Idee KM zum KM System . . . . . . . . . . . . . . . . . . 256 9.2.2 Der Schl¨ ussel“ zum Erfolg . . . . . . . . . . . . . . . . . . . . . . . . . 259 ” 9.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 9.3.1 Wichtige Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 9.3.2 Schl¨ usselfelder f¨ ur KM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

1 Einleitung

Knowledge Management (KM) – Wissensmanagement – wird den meisten Lesern ein Begriff sein und besch¨ aftigt sich mit Wissensprozessen aller Art. Open Source ist ein ebenfalls oft geh¨ orter Begriff und wird daher auch den allermeisten Lesern bekannt sein. Gleichzeitig ist es nötig hier kurz darauf einzugehen, wie und in welcher Art diese beiden Begriffe in diesem Buch ¨ verwendet werden, da es sich in beiden F¨ allen eigentlich um Uberbegriffe und keine scharf umrissenen Gebiete handelt. Zuerst ist es aber wichtig, sich grunds¨ atzlich zu u ¨berlegen, was ”KM und Open Source“ u ¨ berhaupt heißen kann und welchen Sinn das Ganze u ¨ berhaupt macht: KM hat in den vergangenen Jahren viele Hoffnungen enttäuscht. Trotz allem wird die prinzipielle Notwendigkeit, sich besser und effizienter um das Ph¨ anomen Wissen zu k¨ ummern, nicht bezweifelt. Aktuell wird auch des ¨ Ofteren von Intelligence anstelle von Wissen gesprochen (bis zu einem gewissen Grad um den Begriff Management in den Hintergrund zu drängen). Viele der schon umgesetzten KM-Projekte waren IT lastig“ und ha” ben trotz enorm hoher Investitionen nicht annähernd das gew¨ unschte Ergebnis geliefert. Dieses Faktum nehmen viele Kritiker zum Anlass, um der IT die Schuld zu geben, wobei diese Argumentation nicht vollständig entkräftet werden kann – sie geht aber am Kern des Problems vorbei. Prinzipiell betrachtet braucht man keine IT, um Knowledge Management umzusetzen. Ein KM-Projekt kann aus rein organisatorischen Maßnahmen bestehen und beachtliche Erfolge erzielen. Gleichzeitig werden in fast allen Firmen immer mehr Aktivit¨ aten mithilfe des Computers erledigt. Daraus folgt, dass ein umfassend angelegtes KM-Projekt sich sehr wohl mit IT auseinander setzen muss, um die wichtigen und notwendigen organisatorischen Veränderungen abbilden und unterst¨ utzen zu k¨ onnen. Daraus ergibt sich die Notwendigkeit bei fast allen KM-Projekten, zuerst die organisatorische Seite zu betrachten und danach sehr wohl auch die IT einzubeziehen. Der Einsatz eines der vielen kommerziell angebotenen KM-Systeme ist aber eine sehr kostspielige Angelegenheit. Daher stellt sich die Frage, welche Bereiche von KM-Systemen man mit kostenlosen Produkten abdecken kann.

2

1 Einleitung

Da es bei KM-Projekten sehr stark um die Individualisierung und Anpassung geht, kommen eigentlich prim¨ ar Open Source Produkte in Frage. Man sieht also, dass sich das Thema KM und Open Source“ ganz ” nat¨ urlich ergibt und eine sehr interessante Frage darstellt. Bevor es aber weiter um diesen Zusammenhang geht, ist es wichtig ein paar grundsätzliche Definitionen vorzustellen, die einerseits das Verständnis des Autors bez¨ uglich der behandelten Themen zeigen und gleichzeitig eine Basis f¨ ur den Rest des Buches sind.

1.1 Definitionen (Knowledge, Knowledge Management, Open Source, . . . ) Wenn man Knowledge Management definieren will, stolpert man sofort u ¨ ber den Begriff: Knowledge – Wissen. Dieser Begriff ist leider (wie in Folge auch KM) nicht eindeutig definiert und es gibt auch kein gemeinsames Verständnis zwischen den verschiedenen KM-Richtungen u ¨ ber die Definition dieses Begriffs. 1.1.1 Definition von Knowledge Daher bleibt nur u ¨ brig sich der Sache soweit als notwendig anzunähern und den Leser zu bitten, diese Sichtweise bei der weiteren Lekt¨ ure im Hinterkopf zu halten. Einer der relativ pragmatischen KM-Forscher (seit 1994 im KM Umfeld aktiv und einer der aktivsten Teilnehmer der KMCI Liste [26]) ist dabei Denham Grey und daher wird hier folgende Definition von ihm zitiert: Context-relevant, validated information clusters that emerge when people somehow deal/interact with information elements/people. Man sieht sofort, dass es wie auch in klassischen Definitionen von Wissen, um die u ufte Information geht, wobei im Kontext von KM auch ¨ berpr¨ sehr stark auf die Kontextkomponente und die Interaktion von Personen mit Informationen und untereinander eingegangen wird. Im Kontext dieser Definition muss man noch kurz auf den Begriff Information eingehen (der ja wie Knowledge selbst sehr viele Bedeutungen hat – zum Beispiel den Informationsbegriff nach Shannon in der Informatik). Ohne auf die Debatten um diesen Begriff n¨ aher einzugehen, soll noch eine weitere Definition angef¨ uhrt werden, die im KM-Umfeld gerne genommen wird und Information als: data endowed ” with relevance and purpose“ sieht (siehe Drucker, P.E. (1995): The Post Ca” pitalistic Executive.“ in P.E. Drucker (ed.): Management in a Time of Great Change, New York: Penguin.). Wenn man KM-Literatur liest, wird man viele andere Definitionen der ¨ Begriffe Information und Knowledge finden (f¨ ur eine Ubersicht bietet sich eine sehr gute Arbeit von Alavi und Leidner an [1]). Gleichzeitig gibt es dabei

1.1 Definitionen (Knowledge, Knowledge Management, Open Source, . . . )

3

¨ viele Ubereinstimmungen – Knowledge wird meistens als personalisierte (individualisierte) Information gesehen. Ein wichtiger Schluss aus dieser Definition ist, dass man Knowledge nicht elektronisch speichern kann. Insgesamt m¨ ochte sich der Autor der Meinung vieler seiner Kollegen anschließen, dass es ganz sicher kein Knowledge darstellt, wenn man Unmengen an Information elektronisch gespeichert hat. Hier liegt auch die Erklärung warum rein IT lastige“ Initiativen scheitern mussten und nur geringe Ergeb” nisse bei hohen Kosten geliefert haben (wenn man es genau betrachtet, gab es ¨ ahnliche Ans¨ atze im eLearning und es ergaben sich ähnliche Probleme). 1.1.2 Definition von Knowledge Management Da es keine klare Definition von Knowledge gibt, ist es sinnlos nach einer eindeutigen Definition von Knowledge Management zu suchen. Daher wird noch einmal Denham Gray zitiert, der Knowledge Management folgendermaßen charakterisiert: Broad-based discipline: mine (analyze) data; capture, create, store, catalog, validate, transform, and disseminate/share information; capture, emerge, store, catalog, and disseminate/share knowledge. Kurz gesagt, Knowledge Management umfasst alle Aktivitäten, die sich mit Daten, Informationen und Knowledge beschäftigen (was größtenteils auch von Informationsmanagement geleistet wird). Die Schwierigkeit der Abgrenzung von Knowledge Management und anderen Gebieten wird damit auch deutlich und man kann sagen: Knowledge Management ist alles oder nichts. Auf so einer Basis l¨ asst sich nat¨ urlich nicht allzu viel feststellen. Daher soll noch auf Abschnitt 2.1 verwiesen werden, der sich mit konkreten Zielen von KM besch¨ aftigt. Zusammen mit der groben Definition wird das im Weiteren als Basis f¨ ur dieses Buch verwendet. 1.1.3 Das Verh¨ altnis von Knowledge Management zu IT Nach diesen Definitionen und Beschreibungen stellt sich die Frage, ob KM u angt. Wie schon kurz diskutiert, ist KM ¨ berhaupt direkt mit IT zusammenh¨ prinzipiell von IT unabh¨ angig und man kann sich durchaus KM-Projekte vorstellen, die nur aus organisatorischen Maßnahmen bestehen. Je umfassender allerdings eine KM-Initiative wird und je st¨ arker eine Organisation ihre Prozesse mit IT Systemen unterst¨ utzt, desto notwendiger ist eine Einbeziehung von IT. Insgesamt ist eine umfassende KM-Initiative ohne IT Unterst¨ utzung kaum mehr denkbar. Gleichzeitig nimmt auch der Anteil von IT an allen Unternehmungen und Prozessen immer mehr zu. Es bleiben selbstverständlich noch genug M¨ oglichkeiten, KM-Ans¨ atze ohne IT einzubringen. Diese sind – wie auch der Titel zeigt – nicht Gegenstand dieses Buches (und es gibt eine große Menge an guten und passenden B¨ uchern zu diesem Thema).

4

1 Einleitung

1.1.4 Definition von Open Source Obwohl Open Source an sich ein Begriff der IT ist, hat auch er keine eindeutige Definition, sondern stellt eine Art Oberbegriff dar. Generell geht es darum, dass der Quellcode (Source) eines Produkts zugänglich ist. Bei den Details“ ” gibt es aber deutliche Unterschiede. Prinzipiell kann der Quellcode von Software zug¨ anglich sein, ohne dass man etwas damit tun d¨ urfte (außer nat¨ urlich ansehen). Die meisten Vertreter von Open Source versuchen den Begriff aber nur auf Software anzuwenden, bei denen eine Ver¨ anderung und Weitergabe des veränderten Source Codes möglich ist. Im Weiteren wird prim¨ ar auf solche Software eingegangen und explizit darauf hingewiesen, wenn es sich um Software handeln sollte, die ohne Source Code verf¨ ugbar ist beziehungsweise bei der man den Source Code nicht andern darf. ¨ Wenn man sich also die engere Definition von Open Source ansieht, dann geht es darum, die Modifizierbarkeit des gelieferten Sources zu garantieren. Es gibt dazu eine entsprechend benannte Initiative namens OSI (Open Source Initiative: http://www.opensource.org/). Auf der entsprechenden Homepage findet man eine Menge von Informationen u ¨ber Open Source und eine Auflistung aller relevanten Lizenzen, die die Kriterien erf¨ ullen. Neben dem Begriff Open Source gibt es auch noch den eng verwandten Begriff Free Software. Wie auch bei Open Source, gibt es Verwechslungsgefahr (in diesem Fall mit Software, die kostenlos ist, aber keinen Source Code mitbringt oder dieser nicht ver¨ andert werden darf). F¨ ur dieses Buch ist die Kategorie von kostenloser Software ohne Quellcode nicht interessant (weil bei KM meist zu hoher Anpassungsbedarf besteht, als dass man ohne den Source Code auskommen k¨ onnte). Der Evangelist“ der f¨ ur dieses Buch interessan” ten Free Software Definition ist Richard Stallman mit seiner Free Software Foundation. Auf ihrer Homepage (http://www.fsf.org) findet man neben einer Menge Hintergrundinformation auch die beiden wichtigsten Open Source/Free Software Lizenzen, die GPL (General Public License) und die LGPL (Lesser General Public License). Wenn man sich die Statistiken auf einer der größten Open Source Sammlungen ansieht (http://freshmeat.net/stats/) ist auf den ersten Blick offensichtlich, dass die GPL aktuell dominiert. Besonders interessant f¨ ur manchen Leser mag vielleicht noch der relativ hohe Anteil der Projekte mit BSD (Berkeley Software Distribution) Lizenz sein (zum Zeitpunkt des Verfassens dieses Buches ca. 5%). Bei dieser Lizenz kann man eine ver¨ anderte Version kommerziell vertreiben. Bei der zum Zeitpunkt der Drucklegung gr¨ oßten Open Source Sammlung (http://sourceforge.net) sind ca. 96% der Projekte mit einer OSI Approved“ License (also wo man wirklich von ” Open Source sprechen kann). Davon wiederum haben ca. 7% die BSD Lizenz (die meisten unterliegen der GPL/LGPL). Allerdings hatten nur 2/3 der Projekte eine eindeutig zuordenbare Lizenz. Eine nähere Betrachtung von Open Source im Allgemeinen und auch der Lizenzthematik gerade auch bei zum Teil kommerzieller Verwendung findet sich zum Beispiel im Buch Open-Source”

1.1 Definitionen (Knowledge, Knowledge Management, Open Source, . . . )

5

Software“ von Heinz Sauerburger [52] oder einem Werk mit gleichem Titel von Bernd Br¨ ugge, Dietmar Harhoff und Arnold Picot [7]. Insgesamt ist Open Source vor allem in zweierlei Hinsicht f¨ ur eine KMImplementierung interessant: 1. Es gibt keine (hohen) Lizenzkosten. 2. Man kann die Software beliebig ¨ andern. Aus Sicht der Open Source Vertreter kommt noch dazu, dass der vorhandene Source Code erweitert und verbessert wird und man damit der Gemeinschaft auch wieder zur¨ uckgibt (anstatt nur zu nehmen). Deshalb wird hier die Kurzfassung der Definition von Open Source zitiert (von http: //www.opensource.org): Open source promotes software reliability and quality by supporting independent peer review and rapid evolution of source code. Besonders interessant wird KM durch die Tatsache, dass es kaum mehr einen Bereich der IT ohne gute Produkte gibt. In manchen Nischen gibt es sicher noch Defizite und bei Neuentwicklungen kann es manchmal etwas dauern, aber generell gibt es fast alles in einer Open Source Variante und der Abstand“ zu den kommerziellen Systemen wird in jeder Hinsicht geringer ” (aktuell sind zum Teil noch mehr Funktionen vorhanden). Auch benötigen KM Systeme u ¨ berwiegend grundlegende oder breit eingesetzte (Mainstream-) Technologien, sodass es hier kaum nennenswerte Schwierigkeiten gibt. Das ist das vielleicht schlagendste Argument, warum das vorliegende Buch Sinn macht. 1.1.5 H¨ aufige Fragen bei Open Source Im Zusammenhang mit Open Source/Free Software gibt es eine Reihe von Unterschieden zu konventioneller, kommerzieller Software. Das f¨ uhrt einerseits zu Unsicherheiten bei potenziellen Anwendern und bedeutet andererseits, dass man auf bestimmte (andere) Dinge acht geben muss. Die wichtigsten Aspekte sind dabei folgende: Unterst¨ utzung/ Support“ durch den Hersteller: Die ist bei Open Source in ” anderer Form und in sehr unterschiedlicher Qualität gegeben (wie ja auch bei kommerzieller Software). In vielen F¨ allen gibt es sehr aktive Commu” nities“ und bem¨ uhte Entwickler zu einem Produkt. In anderen Fällen gibt es vielleicht nur sehr wenige Personen mit dem notwendigen Know-how und es wird versucht, die Kosten der Entwicklung mit kostenpflichtigem Support abzudecken (etwa bei dem Application Server JBOSS). Daraus ergibt sich die Schlussfolgerung, dass man auch bei Open Source f¨ ur kritische EDV Anwendungen f¨ ur die notwendige Unterst¨ utzung etwas bezahlen muss. Die Freiheit, die man hat, besteht darin, den besten und kosteng¨ unstigsten Dienstleister zu beauftragen. Vor allem kann das selbst

6

1 Einleitung

bei einer Vielzahl von Produkten ein einziger externer Partner mit relativ geringen Kosten sein. Jedenfalls muss man dieses Thema auch bei einem Open Source System diskutieren und eine Lösung finden. Fehlende Weiterentwicklung: Ein relativ beliebtes Argument gegen den Einsatz von Open Source ist das Risiko, dass eine Software nicht mehr gewartet oder weiterentwickelt wird. Vergessen“ wird darauf hinzuweisen, ” dass so etwas bei kommerzieller Software genauso vorkommt und dort die Auswirkungen viel dramatischer sind, weil kein Dritter einspringen kann (da kein Source Code und keine Rechte vorhanden). Das Risiko, dass so etwas passiert, ist bei Open Source Applikationen vielleicht etwas höher als bei einer Firma. Gleichzeitig reden wir hier von einem quantitativen und keinem qualitativen Unterschied. Wenn man sich generell gegen dieses Risiko absichern will, muss man sich f¨ ur eine breit eingesetzte Lösung entscheiden. Nur so ist garantiert“, dass ein Produkt bei Problemen von ” anderer Seite weitergef¨ uhrt wird. Das gilt genauso f¨ ur kommerzielle wie f¨ ur Open Source Software. Rechtliche Aspekte: Ebenfalls gerne vorgebracht wird die fehlende Rechtssicherheit bei Open Source. Eine fundierte Darstellung und Analyse dieser Thematik kann leider nur von Experten vorgenommen werden. Generell ist diese Thematik in Europa weniger kritisch als in den USA, weil es noch keine Software Patente gibt. Weiters sind viele der angef¨ uhrten Probleme nicht Open Source spezifisch. Auch eine kommerzielle Software kann diverse Rechte Dritter verletzen und prinzipiell kann auch hier ein Anwender verklagt und verurteilt werden. Hier wird sich allerdings meist die Herstellerfirma damit befassen (m¨ ussen) und sich auch darum k¨ ummern, solange es sie noch gibt. Eine Unsicherheit bleibt hier aber auf jeden Fall, da es noch praktisch keine Pr¨ azedenzf¨ alle gibt. Damit wird aber auch aufgezeigt, dass es relativ unwahrscheinlich ist, u ¨ berhaupt verklagt zu werden (unabh¨ angig von der Frage eines Verschuldens). Damit ist das Risiko eines internen Open Source Einsatzes zumindest relativ gering. Trotzdem sollte man Augen und Ohren offen halten, um neue Erkenntnisse oder Ver¨ anderungen in der zugrunde liegenden Situation mitzubekommen. Seit ca. 2005 gibt es zu dieser Thematik auch B¨ ucher im deutschen Sprachraum. So wird etwa im Text Die GPL kommentiert und erklärt“ des ” Instituts f¨ ur Rechtsfragen der Freien und Open Source Software [21] auf die am h¨ aufigsten eingesetzte Open Source Lizenz näher eingegangen. Eine allgemeinere Darstellung findet man bei Spindler [57]. Im englischen Sprachraum gibt es dagegen wesentlich mehr Texte, die zum Teil auch schon deutlich l¨ anger erh¨ altlich sind. Insbesondere, wenn man sich f¨ ur die Unterschiede der verschiedenen Lizenzen interessiert, ist das Werk von Laurent [30] interessant.

1.2 Verwandte Gebiete

7

1.2 Verwandte Gebiete Wenn man sich KM ansieht, dann gibt es eine Menge von verwandten Gebieten und Feldern. Wie ja schon aufgezeigt wurde, gibt es keine klare Definition von KM und damit nat¨ urlich auch keine klare Abgrenzung zu anderen Feldern. Das macht verst¨ andlicherweise Schwierigkeiten bei der Zuordnung von einzelnen Methoden, Software, etc., ist aber eigentlich kein großes Problem, solange es um das Erreichen von definierten Zielen geht. Das bedeutet vor allem, dass es praktisch unmöglich ist, einzelne Anwendungsfelder oder Produkte eindeutig zuzuordnen. Generell basiert dieses Buch auf einer eher weiteren Auslegung des Begriffs KM und vieles wird man auch unter einem anderen Namen verkauft“ bekommen. ” Insbesondere trifft dies auf die Begriffe Informationsmanagement und Groupware im Kontext von IT zu. Dabei wird Informationsmanagement oft ¨ (aber keineswegs ausschließlich) als Uberbegriff f¨ ur Management Informati” on System (MIS)“, Decision Support System (DSS)“ oder Expert Systems ” ” (ES)“ verwendet. Groupware auf der anderen Seite versucht das Zusammenarbeiten von Gruppen zu unterst¨ utzen und stellt meist eine Kommunikationsplattform aufbauend auf E-Mail, geteiltem Kalender und einem globalen Adressbuch dar. Wenn man sich die Definition und Zielsetzung von KM ansieht, erkennt man sofort, dass diese Softwarekategorien wichtige Teile f¨ ur eine KM Lösung darstellen. Es geht sogar noch weiter: Eine KM Initiative kann häufig mit einer der genannten L¨ osungen auskommen. Dann kann man diese unterst¨ utzende Software nat¨ urlich KM Tool oder KM System nennen, während sie gar nicht als solche benannt wurde (genauso gut kann es auch umgekehrt sein – nicht jedes Produkt, das sich heute KM System nennt, ist besonders gut geeignet, um KM Initiativen zu unterst¨ utzen, w¨ ahrend es andere Aufgabenstellungen sehr gut bew¨ altigt). Unter anderen verwandten Systemkategorien sind zwei besonders wichtig. Einerseits Unternehmenssoftware (Enterprise Resource Planning – ERP – ist am prominentesten; Business Intelligence ein aktueller Begriff in diesem Umfeld) wie sie von SAP, PeopleWare (der Hersteller gehört inzwischen zu Oracle) oder den entsprechenden Oracle Produkten geliefert wird. Diese Kategorie besch¨ aftigt sich mit der Unterst¨ utzung von insbesondere administrativen Aspekten (Inventar, Personal, . . . ). Die Produkte sind in der Zwischenzeit sehr m¨ achtig und teilweise auch in Richtung KM erweitert worden (es gibt etwa ein entsprechendes Produkt von SAP). Aus einer Open Source Sicht kommen diese Systeme nicht als integraler Bestandteil in Frage (sehr wohl muss man sich aber um die Datenintegration k¨ ummern). Daher wird im Weiteren auf Open Source Alternativen (zum Beispiel Compiere) eingegangen werden. Die zweite relevante Kategorie ist Customer Relationship Management (CRM). Diese Produktgruppe ist wesentlich j¨ unger als ERP und dementsprechend sind der Markt und auch die angebotenen Produkte sehr

8

1 Einleitung

uneinheitlich. Teilweise wurden oder werden diese Produkte in Richtung KM erweitert. In jedem Fall sind sie wichtige Datenquellen, die es ein KM System zu integrieren sind. Nat¨ urlich gilt auch hier wieder, dass sich dieses Buch auf die Open Source Alternativen konzentriert (wie openCRX, SugarCRM oder Compiere). Weiters wird noch auf eine wichtige Grundlagentechnologie eingegangen, nämlich K¨ unstliche Intelligenz (KI) oder Artificial Intelligence (AI). Diese Technologie ermöglicht es Computern, nicht offensichtliche Zusammenhänge aufzudecken und generell schlau“ auszusehen. Von wirklicher Intelligenz kann ” beim aktuellen Stand der Technik aber leider keine Rede sein und die meisten Forscher halten das Ziel auch f¨ ur nicht bald erreichbar (wenn u ¨ berhaupt). Wichtig ist diese Technologie deshalb, weil sie den Hintergrund von vielen besonders KM relevanten Funktionen darstellt (und konsequenterweise auch entsprechend in den schon angesprochenen Produktgruppen eingesetzt wird). Abschließend soll noch kurz angesprochen werden, dass es nat¨ urlich eine Vielzahl von weiteren relevanten und teilweise verwandten Gebieten und Bereichen der IT gibt. Insbesondere Taxonomien, Ontologien, Topic Maps oder das Semantic Web“ als Abl¨ ose“ des heutigen World Wide Web zeigen inter” ” essante und wichtige Konzepte auf (alle drei Begriffe finden sich im Glossar). Soweit diese schon unmittelbar Sinn machen oder man sie zumindest ber¨ ucksichtigen sollte, geschieht dies im weiteren Text.

1.3 Der Fokus des Buches Nachdem der grobe Aufbau und Inhalt dieses Buches schon im Vorwort und Leitfaden pr¨ asentiert wurden, geht es an dieser Stelle hauptsächlich um eine Konkretisierung des Fokus. Ganz wichtig ist dabei der Bogen von den Grundlagen und der Vision von KM zu einem potenziell umfassenden KM System. Genau in diesem Zusammenhang m¨ ussen die Beschreibungen von Systemen, grunds¨ atzlichen technischen Entscheidungen und Fragen der Einf¨ uhrung/Umsetzung verstanden werden. In diesem Zusammenhang soll noch einmal auf die Wichtigkeit von Kapitel 2 verwiesen werden. Dabei ist der Schwerpunkt einerseits eine Basis f¨ ur eher technisch orientierte Leser zu bieten und andererseits das Verständnis des Autors von KM und KM Systemen zu pr¨ asentieren. F¨ ur einen gesamthaften Ansatz und angesichts der verschiedenen Ansichten zu KM ist das einfach eine Voraussetzung, die aber gleichzeitig m¨ oglichst kompakt gehalten ist und nicht zu“ stark auf die Theorie eingeht. ” Im engeren Sinne k¨ onnte man sagen, dass das Ziel dieses Buches ist, eine mittelfristige Entscheidung f¨ ur das KM System einer kleineren oder mittelgroßen Organisation zu erm¨ oglichen. Damit ist nicht gemeint, dass nicht auch gr¨ oßere Organisationen den Ansatz analog verwenden oder gar direkt umsetzen k¨ onnen. Allerdings kann die oft vorhandene organisatorische und

1.3 Der Fokus des Buches

9

technische Komplexit¨ at im Rahmen dieses Buches nicht detailliert genug behandelt werden. Beim zweiten Aspekt, der fundierten technischen Entscheidung, stellt das Buch einerseits entsprechende Technologien und Open Source Systeme vor und andererseits wird analysiert, wie eine schrittweise Einf¨ uhrung funktionieren kann und was das bedeutet. In diesem Zusammenhang wird nat¨ urlich auf die st¨ andige Weiterentwicklung hingewiesen, die gerade im Open Source Umfeld sehr schnell vonstatten gehen kann. Gleichzeitig werden aktuelle Trends und Ausbaupl¨ ane im Text schon mitber¨ ucksichtigt. Auf dieser Basis ist eine tragf¨ ahige mittelfristige Entscheidung m¨ oglich und genau darauf arbeitet dieser Text hin. Das ist auch ein wichtiger Grund f¨ ur die Präsentation einer Reihe von Erweiterungsm¨ oglichkeiten, die nur selten unmittelbar im Fokus einer KM Initiative sein werden. Der gesamthafte Blickwinkel wiederum ist vor allem f¨ ur die organisatorischen Fragen der Einf¨ uhrung und Erweiterung eines KM Systems notwendig. Nur auf dieser Basis kann eine KM Initiative erfolgreich sein und die Wettbewerbsf¨ ahigkeit der Organisation entscheidend verbessern. Dar¨ uber hinaus zeigt der Ausblick des generellen Feldes KM und relevanter Technologien, dass nur eine Integration der Anstrengungen auf vielen Bereichen wesentliche Verbesserungen erm¨ oglichen wird.

2 Vision eines KM Systems

Der wichtigste Punkt einer KM Initiative ist es, sich u ¨ ber die angestrebten Ziele klar zu werden. Im Hinblick auf die Unterst¨ utzung durch IT heißt das, eine Vision des zuk¨ unftigen Systems zu entwickeln. Es ist dabei nicht wichtig, ob man diese Vision je erreichen wird, sonder darum, ein Ziel zu haben, auf das man hinarbeitet. Gleichzeitig sollte man immer daran denken, dass KM auch ohne IT möglich ist und daher die Vision entsprechend anlegen. Es geht nicht darum, alles und jedes mit IT zu l¨ osen, sondern zu identifizieren wo und wie man effektiv IT einsetzen kann, um die aktuellen und angestrebten Prozesse, Strukturen und Arbeitsweisen zu unterst¨ utzen. Diese Aspekte bedeuten zusammengenommen, dass man sich Gedanken dar¨ uber machen muss, wie weit man unmittelbar gehen kann, wie sich die Organisation verändern wird oder soll und welches Endsystem“ man ger” ne h¨ atte. Ganz wichtig ist dabei, eine tragf¨ ahige Vision zu entwickeln, die den Leuten bei anstehenden Entscheidungen hilft. Zusätzlich muss dieses Ziel auch flexibel genug sein, um es regelm¨ aßig anzupassen. Dieser Aspekt ergibt sich einfach aus der Tatsache, dass sich Organisationen heute immer schneller ver¨ andern und die Welt der Technologie weiterhin einem ständigen Wandel unterliegt, der nat¨ urlich ber¨ ucksichtigt werden muss.

2.1 Ziele von KM (inklusive eLearning) Ganz grob gesagt hat KM nur ein Ziel: Einen nachhaltigen Wettbewerbsvorteil f¨ ur die jeweilige Organisation zu schaffen. Klarerweise kann man dieses Ziel nicht direkt ansteuern und muss daher konkretere Punkte anvisieren. Folgende Auflistung folgt prim¨ ar zwei Analysen von KPMG, die Anfang 1998 und Ende 1999 durchgef¨ uhrt wurden (siehe [27] und [28]). Man erkennt dabei sofort, dass es sich um sehr unterschiedliche Themen handelt, beginnend beim Shareholder Value“ bis zur Erh¨ ohung des Innovationspotenzials. ”

12

• • • • • • • • • • • • • • • • • • • • • • •


Verbesserung von Entscheidungen/Entscheidungsprozessen Schnellere Reaktionszeiten Wissenstransfer unterst¨ utzen Wachstum beschleunigen Neue Wissensgebiete entdecken Kernkompetenzen st¨ arken/Marktanteile verteidigen Kosten reduzieren/Gewinne erh¨ ohen Produktqualit¨ at erh¨ ohen Kundenbeziehungen verbessern/Kundenservice erhöhen Durchlaufzeiten verringern Projektzeiten verringern Das Innovationspotenzial erh¨ ohen/Neue Geschäftschancen kreieren Teamwork unterst¨ utzen Konkurrenzf¨ ahigkeit erh¨ ohen/Marktanteile vergrößern Wissen im Unternehmen halten/Mitarbeiterfluktuation verringern Prozesse verbessern/Neue Arbeitsmethoden finden Produktivit¨ at erh¨ ohen L¨ osungen wieder verwenden/ Best Practices“ verwenden/verbreiten ” Ressourcennutzung verbessern Interne Kommunikation unterst¨ utzen Wissen verf¨ ugbar machen Kreativit¨ at unterst¨ utzen Den Aktienkurs erh¨ ohen

Man sieht also, dass es bei KM um eine Vielzahl von Zielen geht, die sich auch nicht einfach einordnen lassen. Insbesondere wenn es sich nicht um eine umfassende KM Initiative handelt, wird man sicher nur einen kleineren Teil dieser Ziele adressieren (wollen). Je kleiner“ eine KM Initiative angelegt ” ist, desto wichtiger ist es, entsprechende Prioritäten und Ziele zu definieren. Gleichzeitig sollte man aber den umfassenden Charakter der KM Idee nicht ur aus den Augen verlieren, weil er aufzeigt, in welche Richtung eine Vision f¨ ein KM System gehen sollte. Im Prinzip geht es darum, die Arbeitsweise einer Organisation m¨ oglichst effizient zu unterst¨ utzen (mit einem Fokus auf den im besonderen Brennpunkt stehenden Aspekt Wissen). 2.1.1 eLearning Ziele und der Zusammenhang mit KM Ein anderes Thema, das immer wichtiger wird, steht in engem Zusammenhang mit KM. Es geht um eLearning, das sich ebenso wie KM um die Aspekte des Teilens (Transferierens) von Wissen und des Lernens (als der Basis von Wissen) k¨ ummert. Es gibt unterschiedliche Meinungen zu der Frage, ob eLearning ein Teil von KM ist oder nicht. Insbesondere da viele Organisationen kein (eigenes) eLearning System brauchen, wird es in diesem Buch separat gesehen und behandelt. Praktisch gibt es sowieso nur wenige technische Auswirkungen dieser Frage. Es geht also prim¨ ar darum, dass eine Organisation die Frage

2.2 Voraussetzungen und Grundlagen von und f¨ ur KM

13

beantworten muss, ob sie eLearning braucht. Wenn dies der Fall ist, sollte man die eLearning Funktionalit¨ aten in das KM System integrieren (da es viele Gemeinsamkeiten gibt und eine gegenseitige Nutzung der Daten sinnvoll ist). Ein wichtiger Punkt des eLearning ist die Klärung didaktischer Fragen und die Sicherstellung, dass nur gr¨ undliche vorbereitete Kurse ins Angebot aufgenommen werden. Bei den Inhalten kann die IT leider kaum unterst¨ utzen. Bei der Administration von eLearning dagegen sehr stark (zum Beispiel Lehrpl¨ ane, Informationen u ¨ ber besuchte Kurse, . . . ). Gleichzeitig erkennt man an diesem Einwurf schon die beiden wichtigsten Punkte die in einem allgemeinen KM System ohne eLearning-Unterst¨ utzung nicht oder kaum ber¨ ucksichtigt werden m¨ ussen.

2.2 Voraussetzungen und Grundlagen von und fu ¨r KM Dieser Abschnitt stellt bis zu einem gewissen Grad eine notwendige Abschweifung vom prim¨ aren Inhalt dieses Buches dar. Gleichzeitig geht es hier um eines der wirklichen Kernthemen von KM und auch darum, weshalb viele KM Initiativen scheitern. Dabei ist jeder einzelne Punkt wichtig, aber nicht zwangsläufig Voraussetzung f¨ ur einen Erfolg. 2.2.1 Der Wille zu KM und das Wissen u ¨ber das Warum F¨ ur einen Erfolg von KM ist es absolut notwendig, dass alle relevanten Kräfte – also alle Managementebenen bis hin zu den einzelnen Mitgliedern – einer Organisation die Wichtigkeit und Vorteile von KM kennen und es leben wollen. Ohne eine solche Basis wird man keinen durchschlagenden Erfolg erzielen k¨ onnen. Eine wichtige Grundlage ist dabei eine gemeinsame Vision ergänzt um den Zweck und die Richtlinien der KM Initiative. Diese Vision muss nat¨ urlich ihren Niederschlag bei jedem einzelnen Mitarbeiter finden und dient dann als Motivation die hilft, Probleme bei der Umsetzung und der Anwendung zu u ¨ berwinden. 2.2.2 Eine Kultur des Teilens und der Zusammenarbeit Im Prinzip sollte der Wille zu KM schon ausreichen, damit die einzelnen Mitglieder einer Organisation die Wichtigkeit des Teilens (insbesondere von Wissen und Information) einsehen. Leider gibt es auch starke Motivationen, wie die aktuell verbreitete Unsicherheit was den eigenen Job betrifft, nicht mitzutun. Gerade dieser Aspekt wird selten wirklich adressiert, was die Sache aber nur noch schlimmer macht. Nur wenn man auf die mehr oder weniger starken ¨ Angste der einzelnen Mitarbeiter der Organisation eine Antwort hat, wird man eine Kultur des Teilens und der Zusammenarbeit wirklich etablieren können.

14


Es l¨ auft darauf hinaus, dass KM ein hohes Maß an Vertrauen voraussetzt, das nicht immer gegeben ist. Ein IT System kann hier nicht wirklich helfen. Diese Aspekte muss man auf einer organisatorischen Ebene adressieren und soziale Aspekte (wie etwa auch Zonen der Begegnung – die Gemeinschaftsk¨ uche, . . . ) ber¨ ucksichtigen. 2.2.3 Intrinsische versus Extrinsische Motivation Trotz der komplizierten Termini geht es hier eigentlich um ein sehr einfaches Thema, n¨ amlich Motivation. H¨ aufig ist das Problem nicht, motivierte Mitarbeiter zu bekommen, sondern daf¨ ur zu sorgen, dass sie nicht demotiviert werden. Dabei ist die sogenannte extrinsische Motivation von außerhalb kommend, w¨ ahrend die intrinsische Motivation von innerhalb jedes Menschen kommt. Daher geh¨ oren zur ersten Kategorie etwa Anreize wie Boni oder auch die Angst vor Bestrafung und zur zweiten Kategorie etwa von anderen akzeptiert zu werden. Gerade bei Aufgaben die Kreativität erfordern sind beide Arten der Motivation von enormer Bedeutung. Problematisch ist dagegen opportunistisches Verhalten der Mitarbeiter, da es genau das Gegenteil von echter Motivation darstellt. Ein ganz wichtiger Punkt ist auch noch, dass negative Motivation (die Angst vor Bestrafung, etc.) nur kurzfristig wirkt, während positive Motivation (insbesondere Anerkennung) langfristig wirkt. Monetäre Anreize sind in dieser Hinsicht zwar positiv, fordern aber einerseits opportunistisches Verhalten heraus und wirken andererseits nur relativ kurzfristig (daher m¨ ussen sie u aßig angepasst werden). Gerade deshalb sind sie aber ¨ berwacht und regelm¨ gut zum Anstoßen“ einer KM Initiative geeignet. ” 2.2.4 Wahrhaftigkeit Es handelt sich hier um einen relativ hochtrabenden Begriff f¨ ur die Wichtigkeit von Ehrlichkeit, die sowieso u berwiegend f¨ u r gegeben angenommen wird (oder ¨ es wird stillschweigend u ber diese Frage hinweggegangen). Nat¨ u rlich geht es ¨ hier (wie auch bei anderen Punkten) um ein generelles Problem, nämlich wie man an korrekte und zeitgerecht gelieferte Information kommt. Der vielleicht wichtigste Punkt dabei ist, dass die Mitarbeiter einer Organisation die Gewissheit haben m¨ ussen, dass die gelieferten Informationen nicht gegen sie verwendet werden (auch nicht zur unerw¨ unschten Hilfestellung). Viele Organisationen bestrafen“ eine schonungslose“ Wahrhaftigkeit in der Praxis ” ” (obwohl es selbstverst¨ andlich offiziell ganz anders ist) und die Mitglieder verhalten sich dementsprechend. F¨ ur ein KM System ist so ein Verhalten ein Desaster. Ein Computer versteht den Inhalt von Dokumenten nicht und erst recht kann er nicht feststellen, ob die Informationen l¨ uckenhaft oder gar irref¨ uhrend sind. Daher ist es f¨ ur ein KM System einfach eine Voraussetzung, ein m¨ oglichst hohes Maß an Wahrhaftigkeit zu haben. Jede Organisation sollte

2.2 Voraussetzungen und Grundlagen von und f¨ ur KM

15

sich hier genau pr¨ ufen und die Mehrheit wird Schritte zu einer Verbesserung der Situation unternehmen m¨ ussen, wenn sie ernsthaft an KM interessiert ist. Anders gesagt geht es darum, ob wirkliche Offenheit Nachteile mit sich bringt oder gef¨ ordert wird. Typischerweise wird man keine Fehler zugeben wollen und Probleme oder Risiken erst m¨ oglichst spät eingestehen (eine sehr menschliche Eigenschaft). Daher wird bei jeder Information u ¨ berlegt, ob sie negativ ausgelegt werden k¨ onnte, und generell möglichst wenig weitergegeben, um nicht angreifbar zu sein. H¨ aufig ist dieses Problem in kleineren Organisationen nicht so ausgepr¨ agt, da es eine funktionierende informelle Kommunikation gibt. Je gr¨ oßer jedoch eine Organisation wird, desto schlimmer kann dieses Problem werden. Im normalen Betrieb“ mag das gar nicht besonders ” negativ auffallen, aber f¨ ur eine m¨ oglichst effektive Nutzung des vorhandenen Know-hows oder gar ein KM System ist das ein Riesenproblem. Daher sollte hier jede Organisation sehr gut u ur Offen¨ berlegen, welche Anreize sie f¨ heit schafft und vor allem auch welche offenen und versteckten Mechanismen Ehrlichkeit verhindern. (Ein Beispiel k¨ onnten etwa regelmäßige Statusreports sein, wo schon ein Status Gelb das Management auf den Plan ruft und der Projektleiter und sein Team danach mehr Arbeit als vorher haben – etwa f¨ ur detaillierte Berichte und Besprechungen dazu. In so einem Fall wird nat¨ urlich der Status so lange wie irgend m¨ oglich auf Gr¨ un belassen und erst im Notfall“ ” das Gelb zugegeben“.) ” 2.2.5 Ziele f¨ ur KM setzen und u ufen ¨ berpr¨ Eine KM Initiative muss wie jede andere Aktivität einer Organisation ihre Kosten rechtfertigen k¨ onnen. Die Auswirkungen sind dabei sehr komplex und ¨ häufig langfristig angelegt, daher ist es sehr schwierig, so eine Uberpr¨ ufung durchzuf¨ uhren. Praktisch betrachtet sollte man möglichst viele Kennzahlen identifizieren, die beeinflusst werden sollten (die meisten aber nicht unbedingt alle in positiver Richtung), und eine regelm¨ aßige Messung durchf¨ uhren. Beiuber Umfragen), k¨ urzere spiele könnten dabei etwa die Kundenzufriedenheit (¨ Durchlaufzeiten oder k¨ urzere Projektlaufzeiten sein. Eine konkrete Antwort muss hier jede KM Initiative f¨ ur die jeweilige Organisation selbst finden. 2.2.6 KM und Innovation/Kreativit¨ at Zwischen KM und den Themenbereichen Innovation und Kreativität gibt es ¨ eine Reihe von Uberschneidungen aber auch Gegensätze. Ein Argument dabei ist, dass die (Wieder-)Verwendung des kompletten Wissens einer Organisation Innovation sogar direkt behindert. Insbesondere revolutionären“ Verände” rungen wird so kaum eine Chance gegeben (evolutionäre sind wahrscheinlicher und einfacher). Das ist eigentlich einfach erkl¨ arbar, da ein effektives KM System Zeit und Aufmerksamkeit kostet sowie den Fokus auf vorhandene Vorgangsweisen und Technologien lenkt. Gleichzeitig ist auch das Schaffen neuen

16


Wissens ein Ziel von KM, sodass man hier nicht von einem kompletten Widerspruch reden kann. Eine konkrete Aktivit¨ at zum Verringern des Problems könnte eine Art konstante Bewertung“ jeder einzelnen gespeicherten Information sein (etwa ” aufgrund von Bewertungen der Nutzer oder der Zugriffshäufigkeit – in Folge könnte man weniger relevante“ Informationen auf ein langsameres und billi” geres Speichermedium auslagern). Weiters hat man hier eine (weitere) Motivation f¨ ur eine m¨ oglichst einfache, schnelle und umfassende Suchmöglichkeit in einem KM System. So kann man die Zeit und Aufmerksamkeit, die vorhandenen Informationen gewidmet werden, minimieren und auf die relevanten Dokumente konzentrieren. Insgesamt gibt es kein Patentrezept aber zumindest Anhaltspunkte, wie man die vorhandenen Gegensätze und Widerspr¨ uche zwischen KM und Innovation/Kreativit¨ at entschärfen kann. 2.2.7 Barrieren und Hindernisse: Entfernen und Errichten Man kann fast von einem Konsens der Forscher sprechen, wenn es um die Wichtigkeit des Entfernens (etwa durch technische Systeme oder organisatorische Maßnahmen) von Barrieren und Hindernissen geht. Dabei gibt es gleichzeitig auch Barrieren und Hindernisse, die eine Schutzfunktion haben und den Informationsfluss nicht behindern (etwa eine Richtlinie f¨ ur Aussendungen an Gruppenpostk¨ orbe oder auch generell an viele Adressaten). Daher sollten sie auch nicht entfernt werden. Damit ist das richtige Herangehen an diese Problematik, vorhandene Barrieren und Hindernisse zu untersuchen und im Endeffekt eine neue Landschaft“ vorzuschlagen. Dabei geht es dar” um, wichtige und notwendige Schutzfunktionen abzudecken (zum Beispiel vor einer Informations¨ uberflutung oder der Einmischung von berufenen“ Kol” legen) und gleichzeitig den Informationsfluss möglichst effektiv zu gestalten (etwa mittels zeitnaher Aussendung von neuen Informationen und direkten Kommunikationswegen ohne reine – zum Beispiel hierarchische – Durchlaufstellen). F¨ ur die dazu notwendige Analyse sollte man in alle Richtungen offen sein und etwa auch das Stellen der falschen Fragen (um ein relativ ausgefallenes Beispiel zu nehmen) als vorhandenes Hindernis f¨ ur einen effektiven Informationsfluss erkennen k¨ onnen. 2.2.8 Zeit, Geld, Strukturen und Traditionen Von den vielen organisatorischen Aspekten im Hinblick auf KM gibt es ein paar besonders wichtige, die dieser Abschnitt kurz behandeln soll. Ein ganz großes Problem ist etwa fehlende Zeit und fehlendes Budget f¨ ur KM insbesondere nach der Einf¨ uhrung (die meistens noch ausreichend abgedeckt ist). Gerade sogenannte schlanke“ Organisationen haben nicht einmal mehr die not” wendige Mannschaft“, um Wissen effektiv auszutauschen. In solchen Fällen ” wird KM zwangsl¨ aufig scheitern m¨ ussen und man kann sich das Geld und die Zeit f¨ ur die KM Initiative gleich sparen.

2.3 Was muss ein vollst¨ andiges KM System adressieren

17

Eine weitere wichtige Frage ist, welche organisatorischen Strukturen am besten geeignet sind, um Leute effektiv miteinander arbeiten zu lassen. Aktuelle Forschungsergebnisse deuten hier auf Gemeinschaften hin (etwa auch in der Form von virtuellen Gemeinschaften, wie sie ein KM System unterst¨ utzen kann). Ein ganz anderer Aspekt ist dagegen das Respektieren von Traditionen und der aktuellen Struktur einer Organisation. Es geht dabei nicht darum, keine Ver¨ anderungen vorzunehmen, sondern auf der vorhandenen Basis aufzubauen und die Leute einzubeziehen. 2.2.9 Zusammenfassung Dieser Abschnitt besch¨ aftigt sich mit den Voraussetzungen und Grundlagen von KM im Generellen und KM Systemen im Speziellen. Dabei muss man je nach angepeiltem Ziel und abh¨ angig von der Ausgangsposition sicher nicht jeden einzelnen Aspekt komplett ber¨ ucksichtigen. Gleichzeitig sollte klar sein, dass eine umfassende KM Initiative mit dem Ignorieren jedes einzelnen Punktes ein Risiko eingeht. Das ist auch gar nicht u ¨ berraschend, da es um Dinge geht wie den Willen KM wirklich zu leben, sich Gedanken u ¨ ber die Motivation und die absolut notwendige Wahrhaftigkeit zu machen. Daher kann die Wichtigkeit dieses Abschnitts gar nicht u ¨ berbetont werden.

2.3 Was muss ein vollst¨ andiges KM System adressieren Im Hinblick auf die Ziele von KM ist es wichtig, die daraus folgenden Anforderungen an ein KM System zu analysieren. Dabei kann nur ein integriertes Gesamtsystem die vielf¨ altigen Anforderungen und Ziele adäquat abdecken, sodass sich dieser Aspekt der Vision einfach ergibt“. Damit ist auch klar, ” dass es eine Schicht f¨ ur die Speicherung und Umwandlung von Daten geben muss und selbstverst¨ andlich auch eine Benutzerschnittstelle mit allen ihren Facetten notwendig ist. Dar¨ uber hinaus stellen auch Integrationsaspekte und ein durchg¨ angiges Berechtigungskonzept eine Voraussetzung dar. Die folgenden Abschnitte werden die gerade aufgeworfenen und weitere wichtige und unverzichtbare Aspekte n¨ aher beleuchten. 2.3.1 Erfassen Bei dem Erfassen handelt es sich um eine ganz zentrale Aufgabe eines KM Systems, da es um das Hinzuf¨ ugen von Information zu einem (idealen und zuk¨ unftigen) KM System geht. Dazu geh¨ oren etwa das sinnvolle Behandeln von verschiedenen Dateiformaten, der Kontext der erfassten Information, Qualifikationen, etc. Weiters sollte das KM System auch noch möglichst viele Informationen automatisch erfassen, insbesondere soweit möglich Kontext (zum Beispiel das dazugehörige Projekt), Historie (insbesondere Inhaltsveränderungen)

18


und alle Arten von unstrukturierten Informationen, die zum Erfassungszeitpunkt zur Verf¨ ugung stehen. Wichtig sind dabei eine möglichst weitgehende Automation beziehungsweise Felder vorauszuf¨ ullen (mit Alternativen, wenn mehrere Werte m¨ oglich sind). 2.3.2 (Technisch) Integrieren und Einbinden (Verbinden) Praktisch alle Organisationen haben heutzutage eine F¨ ulle von IT Systemen mit relevanten Daten und Informationen. Ein vollständiges“ KM System ” muss kompletten Zugriff auf die Daten und eine Integration der relevanten Funktionalit¨ aten bieten. Insbesondere geht es darum, zu nicht integrierten Systemen eine bidirektionale Verbindung zu schaffen, da es ohne eine solche wieder zu Doppelgleisigkeiten und anderen Problemen kommt. Gleichzeitig wird man in einer eingeschr¨ ankten KM Initiative die Frage beantworten m¨ ussen, welche Integrations- und Verbindungsschritte essenziell f¨ ur die angestrebten Ziele sind. Die nicht finanzierbaren Aspekte sollten aber trotzdem in die Vision des KM Systems integriert werden. Der wichtigste Effekt, den man mit einer Integration und Verbindung erzielt, ist, dass es geringere Durchlaufzeiten (von Projekten, Anfragen, Fehlerbehebungen, Abl¨ aufen, etc.) gibt und vor allem das Problem von Missverst¨ andnissen deutlich verringert wird. (Das Problem wird am besten durch das Spiel: Stille Post“ dargestellt. Was am Ende einer Weitergabekette steht, ” hat oft kaum mehr etwas mit der urspr¨ unglichen Nachricht zu tun.) Kandidaten f¨ ur eine Integration beziehungsweise Einbindung sind die schon genannten verwandten Softwarefelder (insbesondere ERP, CRM, . . . ). Ganz besonders hervorzuheben ist auch der Aspekt, dass eine KM Lösung durch die zus¨ atzlichen Informationen und Funktionalitäten im Endeffekt deutlich mehr anbieten kann, als es anders m¨ oglich wäre. 2.3.3 Transformationen Es gibt zwei große Probleme f¨ ur ein KM System, die durch Transformationen gel¨ ost werden k¨ onnen: 1. Informationen und Daten so aufzubereiten, dass das KM System effizient zugreifen kann. 2. Daten und Informationen so zu ver¨ andern, dass sie in den eigentlichen Datenspeicher des KM Systems eingef¨ ugt werden können. Daraus folgt, dass Transformationen einerseits f¨ ur bidirektionale Verbindungen und andererseits f¨ ur einmalige oder regelmäßige Imports von externen Datenquellen (wenn es nicht anders geht) notwendig sind. Insbesondere Daten von externen Quellen wie Universit¨ aten, Consulting Firmen, Zulieferern, onnen. Soweit machbar . . . wird man meist nur per Datenimport einbinden k¨ kann man so auch die Abl¨ ose von Altsystemen regeln.


19

Ein anderes Beispiel f¨ ur Transformationen findet man in Data Warehou” ses“ (Systemen, die die wesentlichen Daten der operativen Datenbanken f¨ ur Auswertungen, Analysen, etc. bereitstellen). Gleichzeitig bieten sie hochqualitative Informationen und Funktionen, die man soweit möglich integrieren sollte. Insbesondere kann man sicher auf viele operative Datenbanken und Systeme verzichten, wenn man die entsprechenden Informationen und Funktionalit¨ aten eines Data Warehouse einbinden kann. In diesem Zusammenhang sollte man aber auf jeden Fall vermeiden weitere Daten anzuhäufen“, wenn ” der Zweck und die Sinnhaftigkeit nicht wirklich klar sind. Während alles Vorhandene auf jeden Fall integriert werden sollte, muss man neue Datensammlungen gut u ¨ berlegen. 2.3.4 Speicherung Speicherung ist eine derartig grunds¨ atzliche Funktionalität, dass sie von den meisten IT Systemen in der einen oder anderen Form angeboten oder verwendet wird. Dementsprechend haben auch die meisten Organisationen schon diverse Systeme beziehungsweise Systemteile im Einsatz. Besonders wichtige Beispiele sind Datenbanksysteme (DBMS), die explizit f¨ ur die Speicherung von u ¨ berwiegend relationalen Daten ausgelegt sind, und Document Manage” ment Systeme“ (DMS), die sich um Dokumente meist in der Form von Dateien k¨ ummern. Ein vollst¨ andiges KM System muss bestimmte Funktionalitäten wie An¨ merkungen, Versionskontrolle und Anderungsprotokolle f¨ ur alle verwalteten Elemente anbieten und unterst¨ utzen (wobei es kein Ziel ist, auch die entsprechenden Daten im KM System direkt zu speichern). Solche zusätzlichen Informationen sind essenziell, um ein entsprechend intelligentes“ System mit ” maximalem Nutzen f¨ ur den User zu bekommen. Generell sollte man immer darauf achten, Redundanzen zu vermeiden und vorhandene Informationen nur in Ausnahmef¨ allen zu duplizieren. Dieser Punkt ist zusammen mit den Aspekten der Transformation sowie Integration und Einbinden f¨ ur einen transparenten und effizienten Zugriff der anderen Funktionen des KM Systems verantwortlich. Ein Versagen in diesem Teilbereich w¨ urde das ganze System in Frage stellen, beziehungsweise zumindest den Nutzen der KM Initiative deutlich reduzieren. 2.3.5 Flexibles & Adaptierbares Berechtigungssystem Wenn man sich vor Augen h¨ alt, dass ein vollständiges KM System alle Informationen einer Firma integriert und elektronisch zur Verf¨ ugung stellt (aber nicht zusammen speichert), ist sofort offensichtlich, dass man ein mächtiges, flexibles und anpassbares Berechtigungssystem benötigt. Ein Eckstein ist dabei sicherlich, Vertraulichkeit (der Daten) zu garantieren und gesetzlichen Anforderungen gerecht zu werden. Gleichzeitig muss man den legitimen Nutzern

20


m¨ oglichst viele Informationen zur Verf¨ ugung stellen, um Ihnen die Möglichkeit zu geben, die gesamte verf¨ ugbare Informationsbasis einer Organisation zu ihrem Wohl einzusetzen. Weiters ist ein solches Berechtigungssystem auch wichtig, um limitierte Sichten und Zugriffe von außerhalb zu erlauben. Damit kann man viel leichter organisations¨ ubergreifende Vorhaben durchf¨ uhren (heutzutage typischerweise mit so genannten Extranets oder gar einem abgesicherten Teil der eigentlichen Homepage der Organisation unterst¨ utzt). Die am besten geeignete Basis f¨ ur ein Berechtigungssystem ist eine zentrale Benutzerdatenbank, wie sie zum Beispiel ein Directory Service“ anbietet ” (typischerweise mit Erg¨ anzungen wie einem Single Sign-On, dass mehrfaches Einloggen in verschiedene Systeme unn¨ otig macht). Dabei ist das Ziel entweder das Nutzen einer vorhandenen Infrastruktur oder das Schaffen einer solchen. So etwas sollte aber nicht selbst Teil des KM Systems sein. Dar¨ uber hinaus sind M¨ oglichkeiten eines eingeschr¨ ankten Zugriffs, wie etwa eines Nur ” Zeigens“ mit Microsoft NetMeeting oder Einschränkungen von Benutzerrechten in einer PDF Datei (nicht druckbar, . . . ), wichtige Ergänzungen. 2.3.6 Leute miteinander verbinden Bei diesem Aspekt geht es darum Teams, Organisationen, Gruppen, etc. dabei zu unterst¨ utzen, miteinander zu kommunizieren. Obwohl die zwischenmenschliche Kommunikation als typischerweise unstrukturierte Information nur schlecht automatisch zug¨ anglich gemacht werden kann, ist es möglich, die resultierenden Daten (zum Beispiel Gespr¨ achsmitschnitte) in anderen Systemteilen zu nutzen, um bessere Ergebnisse liefern zu können (von der Themen Protokollierung und Nachvollziehbarkeit ganz abgesehen). Damit kann dieser Aspekt zum Beispiel mit E-Mail, elektronischen Diskussionsforen, Chatrooms“, Telefon und/oder Videokonferenzen (diese bei” den Informationsquellen kann man mit Speech Mining“, also der Verwendung ” von Spracherkennung und Methoden zur Erschließung unstrukturierter Texte, zug¨ anglich machen). Als Bonus kann ein vollständiges KM System auf vorhandene Experten, Urlaube und Krankheiten hinweisen und damit Kommunikation effizienter gestalten. 2.3.7 K¨ unstliche Intelligenz/Data Mining/Knowledge Discovery in Databases/Maschinelles Lernen Die technisch fortschrittlichsten und modernsten Funktionalitäten eines vollst¨ andigen KM Systems basieren u ¨ berwiegend auf den genannten Technologien (mit den Abk¨ urzungen: KI/DM/KDD/ML). Sie ermöglichen neue Informationen zu generieren, die den Benutzern neue Sichtweisen und Einsichten ermöglichen, was anders gar nicht oder nur schwer möglich gewesen wäre. Damit gehen insbesondere entsprechende Funktionalitäten eines KM Systems eindeutig u ¨ ber Informationsmanagement hinaus (durch die Erzeugung neuer Information).


21

Es gibt bereits zahlreiche erfolgreiche Anwendungen dieser Technologien in verschiedenen Feldern und entsprechende Systeme können damit den Eindruk von Intelligenz erwecken. Weiters hat ein vollst¨ andiges KM System eine Reihe weiterer Funktionen wie etwa Wissenslandkarten (Knowledge Maps), das Finden ¨ ahnlicher Dokumente, das Erkennen von Affinitäten zwischen Personen und Wissensgebieten, etc. die auf KI/DM/KDD/ML Technologie beruhen. Damit wird deutlich untermauert, warum diese Techniken eines der wichtigsten Fundamente eines vollst¨ andigen KM Systems u ¨ berhaupt sind. An dieser Stelle kann und soll aber nicht weiter auf diese komplexen Thematiken eingegangen werden, da das zu weit f¨ uhren w¨ urde (nähere Informationen findet man insbesondere in Abschnitt 8.7.2). 2.3.8 Erfassung, Verwaltung & Pr¨ asentation von Kontext, Links & Historie W¨ ahrend typische DMS Systeme gewisse Funktionalitäten bieten, um Kontext, Links und eine Historie von Dokumenten oder Dateien zu verwalten, muss ein vollst¨ andiges KM System diese Funktionen f¨ ur jedes verwaltete St¨ uck Information mit gr¨ oßtm¨ oglicher Flexibilit¨ at anbieten. Das bedeutet zum Beispiel, dass Benutzer die M¨ oglichkeit haben sollten, Links manuell anzulegen (etwa um Informationen mit einem Projekt zu verkn¨ upfen), während das System gleichzeitig solche Verkn¨ upfungen auch unter Verwendung des Kontexts, der Historie und des Inhalts eines Elements automatisch erzeugt. Gleich wichtig ist die Unterst¨ utzung von Mehrdeutigkeit, eine Anforderung die in verschiedenen Schichten eines KM Systems unterst¨ utzt werden muss. Das kann etwa bedeuten Elemente zu mehreren Begriffen (Ordner, andere Elemente, . . . ) aus mehreren Hierarchien zu verlinken. Insgesamt ist es notwendig, die beschriebene Funktionalit¨ at als integralen Teil des KM Systems und damit u ur andere Systemteile wie den ¨ berall wo es Sinn macht (f¨ Benutzer) anzubieten. 2.3.9 Automation W¨ ahrend Automation der Schl¨ ussel f¨ ur viele anspruchsvolle Funktionen eines KM Systems ist, hilft sie auch Benutzer von Routineaufgaben zu befreien. H¨ aufig basieren solche Funktionalit¨ aten auf KI/DM/KDD/ML Technologien, um hochqualitative Resultate sicherzustellen. Eine weitere simple Basisfunkaßig anzustoßen oder durchgehend tionalit¨ at ist, notwendige Aktionen regelm¨ mitlaufen zu lassen. Wichtige Beispiele f¨ ur zu automatisierende Aufgaben sind: •

Eine Expertendatenbank (Skills Database) aktualisieren (unter Verwendung von Informationen wie Autorenschaft, Mitgliedschaft in einem Projektteam, etc.)

22

• • • • •


Automatische Klassifikation von Nachrichten (eingehende und interne EMails, Briefe, etc.) Prozesse durch Analysieren von Benutzeraktivitäten identifizieren (um zum Beispiel Abl¨ aufe zu verbessern oder mittels Workflowunterst¨ utzung zu automatisieren) Benutzer automatisch u ¨ ber neue Informationen aufgrund von aktuellen Aufgaben, langfristigen Interessen, etc. in Kenntnis setzen Vorschl¨ age f¨ ur das Hinzuf¨ ugen/Entfernen von Interessen aus einem Benutzerprofil St¨ andig einen berechneten Wert jedes einzelnen St¨ ucks Information zu ermitteln (um auf Anfragen prim¨ ar die hoch bewerteten Elemente zu liefern)

2.3.10 Suchen, Finden und Zugreifen Aus der Benutzerperspektive ist der Aspekt des Suchens, Findens und Zugreifens einer der sichtbarsten und wichtigsten Funktionen eine KM Systems. Obwohl es nur durch die Verwendung und Kombination einer Vielzahl von Funktionalit¨ aten des KM Systems m¨ oglich ist, diesen Aspekt zu adressieren, muss das Ergebnis trotzdem eine simples, m¨ achtiges und konsistentes Benutzerinterface sein. Daraus folgt, dass ein Suchmechanismus Zugriff auf jedes einzelne St¨ uck Information, das wie auch immer (direkt gespeichert, u ¨ ber eine integrierte Informationsquelle oder generiert) f¨ ur das KM System verf¨ ugbar ist, bieten muss. Gleichzeitig m¨ ussen die Suchergebnisse auf die Benutzerinteressen (das Ziel sind dabei seine Bed¨ urfnisse und Interessen), den berechneten Wert von passenden Elementen, Zusammenh¨ ange zwischen Elementen oder die Kosten eines Zugriffs (zum Beispiel bei Integration kostenpflichtiger externer Quellen) abgestimmt sein (und nat¨ urlich die Berechtigungen des Benutzers ber¨ ucksichtigt werden). Ein weiterer sehr wichtiger Punkt f¨ ur das Design und die Implementierung eines KM Systems ist zu u ¨ berlegen, ob Offline Funktionalität, Zugriffsgeräte mit eingeschr¨ ankten F¨ ahigkeiten (wie PDAs) oder langsame beziehungsweise unzuverl¨ assige Netzwerkverbindungen ber¨ ucksichtigt werden m¨ ussen. Des weiteren sollte sich das System auch soweit sinnvoll und notwendig der Arbeitsweise sowie den aktuellen Aufgaben und Interessen einzelner Benutzer und den verf¨ ugbaren F¨ ahigkeiten des Ausgabegerätes anpassen und trotzdem m¨ oglichst viel Funktionalit¨ at zur Verf¨ ugung stellen. Schlussendlich muss das System den Inhalt und die Funktionalit¨ aten so anbieten, dass auch verschiedene Lerntypen (visuelle Typen werden eher Grafiken brauchen während etwa motorische Typen besonders schwer zu unterst¨ utzen sind) gut damit arbeiten k¨ onnen. Diese Punkte sind nat¨ urlich auch f¨ ur Abschnitt 2.3.1 u ¨ ber das Erfassen relevant.


23

2.3.11 Einbettung in den normalen Arbeitsablauf Zwar ist die Einbettung eines KM Systems in den normalen Arbeitsablauf aus einer rein theoretischen Sichtweise nicht notwendig, es gibt aber u ¨ berwältigende Gr¨ unde es zu tun. Die beiden Wichtigsten sind: 1. Unterschiedliche Systeme (vom Benutzerinterface her gesehen) stellen eine zus¨ atzliche Arbeit dar und werden daher oft ignoriert. 2. Nur integrierte Systeme sind in der Lage, automatisch Kontextinformationen zu erfassen und k¨ onnen damit mehr Informationen zur Verf¨ ugung stellen, als der Benutzer direkt eingibt. Ein damit eng zusammenh¨ angender Aspekt ist, dass man KM Systeme unbedingt in Zusammenarbeit mit zuk¨ unftigen Nutzern entwickeln sollte (meist Participatory Design genannt). Diese beiden Aspekte zusammengenommen sind der Schl¨ ussel zur Akzeptanz und hoher Datenqualität eines KM Systems. Zusammenfassend kann man sagen, dass KM Systeme in die tägliche Arbeit integriert werden m¨ ussen, damit alle notwendigen Informationen in das KM System eingegeben werden ohne den Benutzern zusätzliche Arbeit (durch ein Separatsystem) aufzub¨ urden. 2.3.12 Transparenz und Nachvollziehbarkeit Neben den beschriebenen prim¨ aren Aspekten gibt es noch zwei etwas weniger wichtige Punkte, die aber trotzdem eine gewisse Relevanz haben. Daher werden sie im Folgenden kurz diskutiert. Transparenz Obwohl viele der schon beschriebenen Anforderungen an ein KM System die Transparenz in Organisationen erh¨ ohen, rechtfertigt die Wichtigkeit dieses Punkts einen eigenen Abschnitt. Kurz gesagt ist Transparenz einer der Schl¨ usselfaktoren von KM und muss daher sowohl mit organisatorischen als auch technologischen Maßnahmen adressiert werden. Insgesamt geht es darum, allen Mitgliedern einer Organisation den Kontext von Informationselementen, getroffenen Entscheidungen, etc. zugreifbar zu machen. Das illustriert auch die Notwendigkeit aus einer rein organisatorischen Perspektive und ein KM System muss diese Anforderung entsprechend technologisch umsetzen. Nachvollziehbarkeit W¨ ahrend die Notwendigkeit einer Historie f¨ ur Informationselemente bereits beschrieben wurde (siehe Abschnitt 2.3.8), geht es mit Nachvollziehbarkeit um ein komplexeres Konzept, das eng mit Transparenz, einer Historie und vielen anderen Dingen verbunden ist. Der Grundsatz ist, Benutzern die nötigen Informationen zu geben, damit sie verstehen und nachvollziehen können, was mit einem bestimmten Informationselement und damit zusammenhängenden Punkten geschehen ist (zum Beispiel innerhalb des Kontextes eines Projekts).

24


2.3.13 Unverzichtbare Basis Obwohl nichtfunktionale Anforderungen oft ignoriert beziehungsweise erst angegangen werden, wenn es ernste Probleme gibt, ist es extrem wichtig, diese Aspekte von Anfang an zu ber¨ ucksichtigen. Die Notwendigkeit ist offensichtlich, wenn man bedenkt, dass die beiden wichtigsten Anforderungen Geschwindigkeit und einfache Bedienung sind. Geschwindigkeit: Ein KM System muss in der Lage sein, alle häufig genutzten Informationen rasch und zuverl¨ assig liefern zu können. Nur wenn dies gegeben ist, werden die Benutzer das System akzeptieren und auch effektiv nutzen k¨ onnen. Einfache Bedienung: Eigentlich ist es selbstverständlich, dass ein System einfach zu bedienen sein muss. Die Schwierigkeit besteht meist darin, alle M¨ oglichkeiten anzubieten und dennoch eine einfache Benutzeroberfläche zu haben. Im Regelfall wird man hier Kompromisse eingehen und sehr genau aufpassen m¨ ussen, dass sowohl erfahrene als auch weniger erfahrene und unregelm¨ aßige Nutzer eine gute und angepasste Benutzerf¨ uhrung vorfinden. Wenn man diese Punkte nicht ausreichend ber¨ ucksichtigt, riskiert man ein komplettes Scheitern des KM Systems und damit potenziell der KM Initiative. Nur ein einfach zu bedienendes System, das gute Antwortzeiten liefert, wird verwendet werden. Umgekehrt heißt das: Ein System ohne diese Eigenschaften wird nicht verwendet werden! ¨ 2.3.14 Uberblick Zusammengenommen beschreiben die aufgef¨ uhrten Anforderungen, welche Punkte ein vollständiges KM System adressieren muss. Während f¨ ur eine KM Initiative sehr viele organisatorische Gesichtspunkte neben den technischen Fragen des IT Systems behandelt werden m¨ ussen, sind nur solche Aspekte detaillierter beschrieben worden, die einen nennenswerten Einfluss auf ein KM System haben. Abbildung 2.1 zeigt die identifizierten Anforderungen und soll helfen, ein besseres Verst¨ andnis f¨ ur die Zusammenh¨ ange zwischen den verschiedenen Aspekten zu bekommen. Wichtig ist dabei, dass manche Punkte sicher an mehr als einen Platz in der Grafik passen w¨ urden. In diesen Fällen wurde einfach der am besten geeignete benutzt, um ein möglichst sinnvolles Gesamtbild zu erreichen. Weiters gibt es auch zwei Anforderungen, die keinen richtigen“ ” Platz in der Grafik finden konnten, und daher an jeweils einem Rand positioniert wurden ( Automation“ und Leute miteinander verbinden“). Diese ” ” beiden Aspekte m¨ ussen auf allen Ebenen und möglichst umfassend und flexibel beachtet werden.


Erfassen

Automat ion

Leute miteinander verbinden

Suchen/Finden/ Zugreifen

Berechtigungssystem

KI/DM/ KDD/ML

Transformationen

Kontext/ Links/Historie

Speicherung/ DB

Integrieren/ Einbinden

Abb. 2.1. Gruppierte Darstellung der Anforderungen eines KM Systems

25

3 Vorhandene Open Source Basis

Nach der Analyse der Anforderungen eines vollständigen KM Systems stellt sich als N¨ achstes die Frage nach verf¨ ugbarer Software. Im kommerziellen Umfeld gibt es zahlreiche teure KM L¨ osungen, die laut Prospekt“ praktisch al” les k¨ onnen. Im Detail gibt es dann doch teilweise gravierende Schwächen und spätestens bei den Preisvorstellungen stellt man häufig fest, dass man sich so etwas gar nicht leisten kann (oder der Nutzen zu gering ist). Zum Gl¨ uck gibt es f¨ ur fast alle notwendigen Bestandteile einer KM Lösung entsprechende Open Source Software. Wenn man auf Open Source aufbaut, muss einem klar sein, dass es keine so komplett integrierten L¨ osungen gibt, wie man sie teilweise bei Kaufsoftware findet. Gleichzeitig hat man damit den Vorteil, dass man das System besser auf die eigene Organisation zuschneiden kann. Ein besonders interessanter Punkt ist dabei, dass man f¨ ur kleinere KM Initiativen schon durch die Verwendung weniger Open Source Produkte mit nur ein wenig Anpassung eine brauchbare IT Unterst¨ utzung bekommen kann. Damit kann man die Vorteile der Idee zeigen und im Idealfall einen weiteren Ausbau zum selbstragenden System anstossen (wenn die Benutzer die Vorteile sehen, sind sie stark motiviert und bereit ein wenig in Vorleistung“ bei ” Erweiterungen zu gehen, die zum Teil eine gewisse Anlaufzeit haben).

¨ 3.1 Uberblick u ¨ ber Kategorien und Technologien Wenn man sich ein wenig im Open Source Umfeld umsieht, wird man bald feststellen, dass es f¨ ur praktisch jede h¨ aufig verwendete Produktkategorie eine Reihe von Systemen gibt. Aus KM Sicht sind die prominentesten Kategorien Groupware Systeme, Content Management Systeme (CMS) und Document Management Systeme (DMS). Bei Groupware Systemen geht es um das Unterst¨ utzen von Kommunikation und Zusammenarbeit in Teams. Bei CMS geht es um das generelle Verwalten von sehr unterschiedlichen Inhalten, meist allerdings um so genanntes Web-CMS also das Verwalten der

28


Inhalte einer Inter- oder Intranet Homepage. Bei DMS geht es ebenfalls um das Verwalten von Inhalten, allerdings mit einem Fokus auf mächtigen Verwaltungsfunktionen und eher auf firmeninterne Kommunikation ausgerichtet. 3.1.1 Wichtige Kategorien von Softwareprodukten Schon bei den drei wichtigsten Kategorien sieht man, dass diese Funktionen in enger Verbindung stehen. Konsequenterweise gibt es daher in den meisten entsprechenden Produkten Funktionen, die in Richtung einer der anderen beiden Kategorien gehen. Ein einfaches Beispiel ist die Möglichkeit einer Diskussion zu einem Dokument in einem DMS. So eine Funktionalität w¨ urde man eher einer Groupware zuordnen als einem DMS. Gleichzeitig geht es bei Dokumenten h¨ aufig um Teamarbeit und daher gibt es entsprechende Erweiterungen. Andererseits k¨ onnen Groupware Systeme meistens auch Dateien verwalten. Typischerweise steht allerdings verglichen mit einem echten DMS nur ein deutlich eingeschr¨ ankter Funktionsumfang zur Verf¨ ugung. Neben den angesprochenen Hauptkategorien gibt es noch weitere interessante Open Source Software. Etwa das große Feld der Business Soft” ware“: Besonders wichtig sind hier Enterprise Resource Planning (ERP) und Customer Relationship Management (CRM) Systeme. Insbesondere ERP Systeme sind dabei in vielen Organisationen schon vorhanden und der typischerweise beste Ansatz ist, sie m¨ oglichst gut zu integrieren (da ein ERP System ¨ im Normalfall das zentralste System u ¨ berhaupt darstellt und eine Anderung daher ¨ außerst komplex und schwierig ist). Wenn dagegen noch kein ERP System vorhanden sein sollte, bietet es sich an, eines der Open Source Systeme zumindest konzeptionell in das KM System zu integrieren. Bei CRM Systemen kann man eher u ¨ berlegen, sie (bei Nichteignung im Kontext der KM Initiative) zu ersetzen. Prinzipiell geht es bei CRM-Systemen darum, alle Informationen zu einem Kunden zu vereinen und entsprechend zu nutzen. Ein Beispiel ist die Darstellung aller Kundenkontakte und aller damit in Zusammenhang stehenden Informationen (ausgetauschte E-Mails, Dateien, Telefonprotokolle, . . . ). Weiters geht es auch darum zu erkennen, welcher Kunde an welchen (zus¨ atzlichen) Produkten interessiert sein könnte. Man sieht schon an dieser kurzen Beschreibung, dass es hier um ganz wichtige Daten geht und zum Teil um die organisationsinterne Kommunikation (zur Beantwortung einer Kundenanfrage, . . . ). Im großen Feld der Business Software“ gibt es dazu noch eine ganze ” Reihe weiterer interessanter Kategorien (wie zum Beispiel Supply Chain Management [SCM] oder die so genannte Sales Force Automation [SFA]). Wenn solche Produkte schon im Einsatz sind, muss man genau analysieren, ob eine Integration der Daten und/oder von Funktionalitäten wichtig ist (das Endziel eines vollst¨ andigen KM Systems ist es in jedem Fall). Neben den bis jetzt angef¨ uhrten Produktkategorien gibt es eine Reihe weiterer, die je nach Einsatzgebiet des KM Systems eine gewisse Wichtigkeit bekommen k¨ onnen. Exemplarisch sollen hier nur noch Digital Libraries erwähnt

¨ 3.1 Uberblick u ¨ ber Kategorien und Technologien

29

werden, da es gerade in diesem Bereich mit dem Produkt Greenstone eine weit verbreitete und funktionell sehr gute L¨ osung gibt. Nat¨ urlich gibt es gewisse Grundfunktionen, die die beschriebenen Systeme typischerweise anbieten. Die Wichtigste ist dabei die Unterst¨ utzung von Mehrsprachigkeit. Sie ist vielleicht nicht f¨ ur jeden Einsatzzweck Voraussetzung, jedoch sind Systeme ohne diese Eigenschaft höchstwahrscheinlich nicht weit verbreitet und technisch problematisch. Grundfunktionen werden daher nur diskutiert, wenn sie besondere Eigenschaften aufweisen oder fehlen. Eine der Grundfunktionen ist das Berechtigungssystem. Da es hier jedoch sehr unterschiedliche Implementierungen gibt, wird im Folgenden meist kurz darauf eingegangen. 3.1.2 Wichtige Basistechnologien Neben den Softwareprodukten, die direkt f¨ ur Endanwender gedacht sind, gibt es eine Reihe von sehr wichtigen Basistechnologien. Einige der entsprechenden Produkte kann man auch ohne Modifikationen oder Erweiterungen einsetzen. Typischerweise sind sie daf¨ ur allerdings weniger gut geeignet. Entsprechende Kategorien und Technologien werden im Abschnitt 3.5 dieses Kapitels n¨ aher beschrieben. Dabei handelt es sich um Portaltechnologie (bekommt man meist mit kleinen Anwendungen so genannten Portlets“, die ” die Technologie demonstrieren sollen), Topic Maps (die man zwar auch einzeln einsetzen kann, im KM Umfeld aber primär integriert Sinn machen), Taxonomien und Ontologien (also Begriffshierarchien eventuell mit Zusammenh¨ angen; fast immer im Hintergrund einsetzt), Semantic Web (die 1998 von Sir Tim Berners-Lee vorgestellte Vision eines Webs, das es Algorithmen erm¨ oglicht, mit definierten Begriffen Webseiten Bedeutung zuordnen zu können und dementsprechend zu agieren) beziehungsweise generell K¨ unstlicher Intelligenz (als Technologie hinter vielen Funktionalitäten und auch alleine eine wichtige Anwendung). Neben diesen Punkten gibt es auch noch andere Aspekte, die man nicht außer Acht lassen sollte. Ganz besonders interessant sind dabei Workflow Engines. Mit solcher Software kann man komplizierte Abläufe modellieren und entsprechend automatisieren. Ein einfaches Beispiel ist die Einmeldung eines Fehlers, bei dem nach einer gewissen Zeit durch einen gewissen Personenkreis reagiert werden muss. Je nach Einsch¨ atzung können dann sehr verschiedene weitere Schritte angestoßen werden. Andererseits kann bei Nichteinhaltung der Zeitgrenze eine andere Aktion ausgel¨ ost werden. 3.1.3 Abschließend Was man bei all den Open Source Produkten (inklusive Implementierungen von wichtigen Technologien) nicht aus dem Auge verlieren sollte, ist die Tatsache, dass sehr unterschiedliche Technologien hinter verschiedenen Produkten stecken k¨ onnen. Im Einzelfall wird man daher abwägen m¨ ussen, welche Funktionalit¨ aten relevant sind. Einerseits will man sicherlich eine gewisse

30


Uniformit¨ at erreichen (um zum Beispiel Wartung und eventuell notwendiges Consulting nicht zu teuer werden zu lassen), andererseits gibt es vielleicht in der bevorzugten Programmiersprache manche Funktionalitäten nicht in der gew¨ unschten Detailtiefe. Mehr zu dieser Fragestellung gibt es im Abschnitt 4.3. Bevor im Folgenden f¨ ur die wichtigsten Kategorien prominente Softwareprodukte beschrieben werden, soll noch deutlich darauf hingewiesen werden, dass es sich um eine bis zu einem gewissen Grad willk¨ urliche Auswahl handelt. Es wurde selbstverst¨ andlich gr¨ oßtm¨ ogliche Sorgfalt aufgewendet, um keines der wichtigen Systeme zu vergessen. Gleichzeitig kann man einfach nicht alle Kandidaten untersuchen und vorstellen. Folglich wird man immer argumentieren k¨ onnen, dass ein relativ prominentes Produkt keine Aufnahme gefunden hat, w¨ ahrend ein unwichtiges System näher untersucht wurde. Wenn man noch die große Dynamik im Open Source Umfeld ber¨ ucksichtigt, wird offensichtlich, dass die Darstellung und Bewertung von konkreten Systemen nat¨ urlich nur eine Momentaufnahme ist. Konsequenterweise legt dieses Buch auch mehr Wert auf grunds¨ atzliche Fragen, als auf einzelne Details einer bestimmten Version eines Softwareprodukts.

3.2 Groupware Systeme Auch der Begriff Groupware ist wie viele andere nicht eindeutig definiert. Generell zeigt schon der Name, dass der wichtigste Aspekt das Zusammenarbeiten von Gruppen ist. Ein eng verwandter Begriff ist auch Computer ” Supported Cooperative Work“ (CSCW) und der relativ junge Begriff der Social Software“. Allen [2] beschreibt seine Sicht der Evolution der ge” ¨ nannten Begriffe von theoretischen Uberlegungen der 40er Jahre des letzten Jahrhunderts an. ¨ Uberwiegend werden Systeme wie Lotus Notes und Microsoft Exchange/Outlook als Groupware bezeichnet (unabhängig von der Korrektheit dieser Zuordnung). Hier liegt ganz klar der Fokus auf E-Mail, Kalender, Adressbuch sowie auf selbstgeschriebenen“ Applikationen (zum Beispiel Lo” tus Notes Datenbanken). Als Folge des Internetbooms und der Dominanz des WWW gehen die etablierten Systeme in Richtung Web und neue sind zum Teil gleich Intranetsysteme. Da eine Diskussion der Groupware Definition in diesem Buch weder sinnvoll noch notwendig ist, wird eine relativ weite Auslegung verwendet. Abgrenzungen gibt es vor allem zu den anderen vorgestellten Kategorien. Als Folge werden gleich zwei Systeme beschrieben, die sich eher an Lotus Notes beziehungsweise Microsoft Exchange orientieren. Diese klassischen“ Groupware Systeme – inzwischen als Open Source ” verf¨ ugbar – sind OpenGroupware (fr¨ uher kommerziell als Skyrix 4.1 vertrieben) und Open-Xchange (fr¨ uher als ComFire oder SuSE OpenExchange verkauft). Diese Systeme sind oft im Einsatz und werden auch teilweise verwen-

3.2 Groupware Systeme

31

det, um die Server einer Organisation auf Linux umzustellen. Eine mögliche Kombination ist Linux als Betriebssystem, Samba als Datei- und Druckserver, OpenLDAP als Authentifizierungssystem und eines der genannten Produkte als Groupware“ Server zu dem sich zum Beispiel Outlook als Client verbin” det. Diese Variante ist vorteilhaft, wenn man f¨ ur die normalen Benutzer weiter Windows einsetzt und m¨ oglichst wenig Umstellungs-/Schulungsaufwand will. Nat¨ urlich kann man auch komplett auf Linux umsteigen und zum Beispiel Evolution als Groupware Client verwenden (die Variante mit den meisten Einsparungen allerdings potenziell dem h¨ ochsten Migrationsaufwand). Neben den eigentlich aus der Client/Server Zeit stammenden Groupware Systemen gibt es auch eine Reihe wesentlich j¨ ungerer Systeme. Dabei sind die Grenzen insbesondere zu Content Management Systemen und/oder Portalen fließend. Die meisten dieser Systeme kann man eher den Portalen zuordnen (sogenannte Community-Portale) und werden daher etwas später präsentiert. Im Folgenden sollen drei Vertreter, die ganz oder u ¨ berwiegend in den Groupware Bereich passen, n¨ aher beschrieben werden. Bis zu einem gewissen Grad eine Ausnahmestellung hat die Kroupwa” re“ (mit dem Kolab Server“). Es handelt sich hierbei um das Ergebnis ei” ner in Deutschland finanzierten Groupware Entwicklung unter Verwendung möglichst vieler vorhandener Bestandteile. Das Ergebnis ist primär eine Alternative zu den gerade angesprochenen klassischen“ Groupware Systemen ” und wird in einem eigenen Abschnitt kurz vorgestellt. Bei den neueren Systemen wird einerseits PHProjekt vorgestellt. Dabei handelt es sich um eine web-basierte Groupwarelösung, die die wichtigsten Anforderungen erf¨ ullt. Daneben werden vor allem zwei nicht ganz einordenbare Zwittersysteme“ vorgestellt. Einerseits Tiki als CMS/Groupware- Zwitter“ ” ” mit einer interessanten Kombination von Funktionen. Andererseits ist auch PhpGroupWare (oder eGroupware) ein besonders gutes Beispiel f¨ ur diese Kategorie. Es wird bei den Groupwaresystemen eingeordnet, weil es explizit diesen Anspruch erhebt (schon durch den Namen) und die wichtigsten Funktionalit¨ aten anbietet. Ein weiteres System – Plone auf dem Python Applikationsserver Zope basierend – l¨ asst sich ebenfalls nicht eindeutig einordnen. Es bietet prinzipiell weniger Groupwarefunktionalit¨ at und wird auch nicht in diesem Abschnitt behandelt. Es ist an dieser Stelle erw¨ ahnt, um aufzuzeigen, dass auch eine ¨ reine Python L¨ osung eine Uberlegung wert sein kann. 3.2.1 OpenGroupware Technisch betrachtet basiert OpenGroupware auf der Programmiersprache Objective-C (Obj-C, einer objektorientierten Erweiterung von C ähnlich zu aufer“ des Smalltalk) und beruht auf NeXTStep a¨hnlichen Libraries (ein Vorl¨ ” aktuellen MacOS X). Skripts sind dagegen meist in Python geschrieben. Damit ist es bis zu einem gewissen Grad ein Außenseiter, was man auf jeden

32


Fall bedenken muss, bevor man es einsetzt. Wichtig f¨ ur Anbindungen ist daher das OpenGroupware XMLRPC API, dass man aus vielen Sprachen wie etwa auch Python oder Perl leicht aufrufen kann. F¨ ur Java, PHP und .NET gibt es dar¨ uber hinaus Wrapperklassen (namens JOGI“ f¨ ur Java, POGI“ ” ” f¨ ur PHP und noch in Entwicklung MOGI“ f¨ ur .NET). Im Fall von Java ist ” dar¨ uberhinaus geplant mit JIGS (siehe http://www.gnustep.it/jigs/), eine direkte Anbindung an das interne“ Obj-C API zu schaffen. Bei der Datenbank ” wurden PostgreSQL und FrontBase getestet. Andere Produkte sollten aber kein großes Problem darstellen. Die Benutzerschnittstelle ist web-basiert. Bei den Funktionen findet man neben Adressen, Kalender (mit Ressourcen und Konfliktbereinigung) und Mailing auch eine Projektverwaltung mit Aufgaben und Dokumenten. Weiters kann man Daten mit Palm PDAs synchronisieren, Benachrichtigungen per SMS oder E-Mail erhalten und bestimmte Datenmengen exportieren (zum Beispiel f¨ ur Serienbriefe). Insgesamt ist OpenGroupware eine gut integrierte Lösung mit vielen eingebauten Funktionalit¨ aten. Durch die enge Kopplung der Komponenten wirkt das Berechtigungssystem u ¨ bergreifend. Die integrierte Dokumentenverwaltung bietet die wichtigsten Funktionen (Versionskontrolle, Check-in, Check-out, hierarchische Einordnung und Links) bis auf eine Volltextsuche. Prinzipiell l¨ auft OpenGroupware auf vielen Betriebssystemen. Eine wichtige Einschr¨ ankung dabei ist Windows (wobei es Bem¨ uhungen gibt, diesen Umstand zu ¨ andern). Die E-Mail Funktionalit¨ at basiert im Hintergrund normalerweise auf einem SMTP sowie einem IMAP Server wie Cyrus IMAP (mit dem Outlook, etc. problemlos arbeiten kann). Generell gibt es Konnektoren f¨ ur Outlook, Evolution, etc. Diese sind zum Teil noch in Entwicklung und bieten nicht alle Funktionen. F¨ ur Outlook gibt es zus¨ atzlich ein kostenpflichtiges Plug-in. (Wenn man u ¨ berlegt, dass auch Outlook selbst kostenpflichtig ist, durchaus ein vern¨ unftiges Finanzierungsmodell f¨ ur Open Source.) Prinzipiell kann man OpenGroupware auch neben einem anderen Mailingsystem einsetzen. Das sollte aber gut u ur ¨berlegt sein, da damit eine Chance f¨ eine integrierte Applikation nicht genutzt wird (wobei etwa Outlook ja mehr als reines Mailing anbietet). Durch den Einsatz von Obj-C ist das primäre API nat¨ urlich in dieser Programmiersprache. Das besprochene XMLRPC API und die Java/PHP/(.NET) Anbindungen sind daher von entscheidender Bedeutung, wenn man OpenGroupware mit anderen Produkten effizient und ohne zu große Aufw¨ ande verbinden will. 3.2.2 Open-Xchange Im Prinzip ist Open-Xchange eine Java Webanwendung. Gleichzeitig wird st¨ arker als bei OpenGroupware darauf gesetzt, vorhandene Software einzubinden. So ist die Benutzerdatenbank prinzipiell in einem LDAP Verzeichnis (MS Active Directory ist geplant) und f¨ ur das Mailing werden (bevorzugt) Cyrus IMAP und Postfix verwendet. Interessanterweise ist gerade das Login


33

aber mit Perl abgebildet (und es gibt kleine Applikationsteile in C). Es gibt auch keine Festlegung auf eine bestimmte Datenbank (meist wird PostgreSQL eingesetzt). Von der Funktionalit¨ at her ist es recht ¨ ahnlich zu OpenGroupware mit dem Fokus auf Adressen (mit Import/Export oder einer Read-Only LDAP Anbindung), Kalender (auch mit Ressourcen und Konfliktbehandlung) und einer Projektverwaltung mit Rollen, Aufgaben, Meilensteinen, GANTT Charts und Dokumenten. Mailingfunktionalit¨ at wird als Webmail inklusive SMS und Fax angeboten. Externe Mailprogramme werden meist direkt mit dem Cyrus IMAP beziehungsweise Postfix Server umgehen können. Es gibt eine Reihe von kommerziellen Add-Ons (etwa den OXTender) f¨ ur die Verbindung zu Outlook, Palm PDA Devices und allgemein zu Ger¨ aten, die den SyncML Standard unterst¨ utzen. Auch eine Arbeitsplatzbenutzerverwaltung, Datei- und Druckersharing ist so m¨ oglich. Open-Xchange bietet auch einige eher communityorientierte“ Funktionen ” wie Foren (auch allein nutzbar etwa f¨ ur externe Partner in einem Projekt), eine pers¨ onliche Portalseite (nach dem Login), hierarchisch sortierte Bookmarks und ein Schwarzes Brett. Weiters gibt es hierarchisch eingeordnete Notiz” zettel“ als Wissensdatenbank“. Als Letztes soll hier noch die Möglichkeit ” bidirektionaler Links zwischen allen Elementen hervorgehoben werden. Gerade diese Funktionalit¨ at ist besonders wichtig, um Zusammenhänge flexibel abbilden zu k¨ onnen. Insgesamt kann man von einer relativ m¨ achtigen Lösung sprechen, die gut integriert ist und Einiges an communityorientierten“ Funktionen anbietet. ” Beim flexiblen Berechtigungssystem gibt es zum Beispiel die Möglichkeit von Vorlagen (also zusammengefassten Sets an Berechtigungen, um den Nutzern die Arbeit zu erleichtern). Durch die Basis Java ist man recht flexibel beim Einbinden von weiteren Funktionen und kann auf eine reichhaltige Softwarebasis f¨ ur viele Gebiete zur¨ uckgreifen. Weiters ist (wie auch noch im Kapitel 4 ausgef¨ uhrt wird) eine Java L¨ osung tendenziell besser wartbar und skalierbar als zum Beispiel eine PHP L¨ osung. Wobei es auch ein Visual Basic API (erlaubt aktuell den Zugriff auf den Kalender) und eine Jabber (eine offene Instant Messaging Lösung“; ” basierend auf den Internetstandards (RFCs) 3920 und 3921 mit einer Reihe von Implementierungen; Details: http://www.jabber.org) Integration gibt. 3.2.3 Kolab Die Kolab Groupware oder Kroupware ist bis zu einem gewissen Grad eine Demonstration, wie man mit Open Source Software ein komplexes und mächtiges System in kurzer Zeit schaffen kann. Die erste Version dieser Groupware wurde f¨ ur das Bundesamt f¨ ur Sicherheit in der Informationstechnik (BSI) in Deutschland entwickelt. Die wichtigsten Funktionalit¨ aten sind E-Mail, Gruppenkalender, Aufgaben, Notizen, Ressourcenverwaltung und Kontakte. Die Administration er-

34


folgt u ¨ber ein Webinterface und das System bietet offene Schnittstellen (POP3 und IMAP4) f¨ ur den Mailzugriff (inklusive Webmail). Eines der Hauptziele des Projekts ist die volle Funktionalit¨ at mittels eines lokalen Clients zur Verf¨ ugung zu stellen. Als Ergebnis gibt es KDE Kontact, das die beschriebenen Funktionalitäten zur Verf¨ ugung stellt (prim¨ ar f¨ ur Linux Desktops gedacht). Weiters gibt es auch ein Outlook Plugin und einen (zum Recherchezeitpunkt nicht kompletten/stabilen) Webclient. Interessant ist in diesem Zusammenhang die Möglichkeit, gemeinsame Ordner mit verschiedenen Clients nutzen zu können. Die Kroupware besteht nur aus relativ wenig neu entwickelter Funktionalit¨ at. Die Masse der Funktionen wird durch bekannte und weit verbreitete OSS Produkte zur Verf¨ ugung gestellt. Die Wichtigsten sind dabei: OpenLDAP, Postfix (Mailserver), Cyrus IMAP ( IMAP Mailserver“), Apache, ProFTPd ” und SASL (Authentication). Das Beispiel Kolab/Kroupware zeigt eigentlich zwei wichtige Sachen gleichzeitig. Einerseits, wie man durch eine geschickte Kombination und Kopplung von vorhandener Open Source Software komplexe Funktionalitäten sicher, skalierbar und zuverl¨ assig zur Verf¨ ugung stellen kann. Dabei bleiben die Kosten sehr gering, soweit man mit den aktuell vorhandenen Funktionen leben kann. Andererseits ist so ein System eher schlecht geeignet, um ein umfassendes KM System daraus zu machen. Damit eignet es sich eher, wenn man mit einer Groupware und anderen lose gekoppelten Systemen das Auslangen findet. 3.2.4 PHProjekt Bei PHProjekt handelt es sich um eine funktionell relativ komplette webbasierte Groupware (in PHP). Folgende Funktionen werden unterst¨ utzt: Adressen (Kontakte: mit Import/Export), Kalender (f¨ ur Gruppen mit E-Mail/SMS Benachrichtigungen, Rechten, Vertretern und Ressourcen), eine Projektverwaltung (mit GANTT-Chart und einer Zeiterfassung). Nat¨ urlich werden auch E-Mails, Ressourcen, Links, Dateien und Todo Listen (Aufgaben) unterst¨ utzt. Eine Outlook Synchronisation ist ebenfalls m¨ oglich (zum Recherchezeitpunkt war allerdings nur eine Beta verf¨ ugbar). Als Datenbank kommen etwa die SQLite, MySQL, PostegreSQL, Oracle, Informix oder der MS SQL Server in Frage. Neben diesen klassischen“ Funktionen gibt es noch Umfragen (Votings), ” ein Anfragesystem (Help Desk), Foren und Chat direkt in der Groupware. Insbesondere durch die Foren und Chatfunktionalität wird eine weitere wichtige Form der Zusammenarbeit direkt erm¨ oglicht. Dar¨ uber hinaus gibt es noch Zusatzmodule wie etwa eine Wiki Implementierung (Webseiten auf denen verschiedene Personen ein Thema zusammen beschreiben“ – wird auf Seite 75 ” ahnenswert sind auch die Anstrengungen bez¨ uglich n¨ aher beschrieben). Erw¨ Barrierefreiheit, die besonders relevant sind, weil es sich um ein integriertes altnism¨ aßig wenigen Modulen (die so ein Konzept oft wieder System mit verh¨ durchbrechen) handelt.


35

Insgesamt bietet die L¨ osung ein relativ komplettes Spektrum an Funktionen an (und dieses scheint gut integriert zu sein). Gleichzeitig sind die vorhandenen Funktionalit¨ aten im Vergleich zu anderen Lösungen relativ simpel gemacht. Damit kann es die Grundfunktionen abdecken und ist als Folge etwas einfacher zu benutzen. Unmittelbar erscheint es aber nicht besonders gut als Basis f¨ ur eine umfassende KM Initiative geeignet. 3.2.5 Tiki Tiki ist eine Mischung aus CMS und Groupware basierend auf PHP. Es bietet mit Webmail (POP3) und Kalenderfunktionalität (allerdings nur ein persönlicher) ein Grundger¨ ust aber zum Beispiel keine Projekt- oder u ¨ bergreifende Adressverwaltung (pro Benutzer ist sie vorhanden). Daf¨ ur bietet es eine ganze Reihe von weiteren Kommunikationsm¨ oglichkeiten. Insbesondere Foren, Newsletter, Blogs (Web-Logs), Wikis und Chats sind erwähnenswert. F¨ ur die Bereitstellung von Inhalten sind die Artikel- und FAQ Systeme noch besonders wichtig. Daneben gibt es noch Banner, Datei- und Bildergalerien, Kategorien, ein Linkverzeichnis, Umfragen (¨ uber simples MultipleChoice hinausgehend), Verzeichnisse und die Unterst¨ utzung von Zeichnungen. Weiters gibt es auch sogenannte Tracker, mit denen man unter anderem ein Help Desk oder Bug Reporting System haben kann. Technisch betrachtet steht hinter den verschiedenen Modulen ein Single Sign-On, dass mit einem LDAP Server gekoppelt sein kann. Zusätzlich gibt es noch die Integration einer Workflow Komponente (http://www.openflow.it/) f¨ ur sehr strukturierte Abl¨ aufe. Interessant ist auch die Möglichkeit, Daten zwischen verschiedenen Tiki Installationen hin- und herzuschicken. Insbesondere f¨ ur Wikiseiten ist das eine wertvolle Erg¨ anzung. Generell ist Tiki ein gutes Beispiel f¨ ur ein Zwittersystem“. Es deckt ” die allerwichtigsten Groupware Funktionen ab, geht aber schon relativ stark in Richtung CMS beziehungsweise Communityportal“. Wobei es im Gegen” satz zu den anderen Systemen keine Gruppenfunktionen f¨ ur Adressen und Kalender hat. Damit wird man typischerweise die Lösung noch in Richtung Groupware erweitern, bevor man Sie f¨ ur diese Zwecke einsetzt. 3.2.6 PhpGroupWare Wie schon kurz angerissen, handelt es sich bei PhpGroupWare um eine Webanwendung, die neben reinen Groupware Aspekten auch CMS und Portalfunktionen (Richtung: Community“) anbietet. Genau betrachtet handelt es ” sich einerseits um ein Framework f¨ ur Groupware Anwendungen in PHP und andererseits um eine Menge an Modulen, Erweiterungen, etc. Als Datenspeicher sind prinzipiell fast alle Datenbanken geeignet. Weit verbreitet ist der Einsatz von MySQL, PostgreSQL und des MS SQL Servers. Auch bei PhpGroupWare gibt es wieder Unterst¨ utzung f¨ ur Adressen (inklusive per SQL, LDAP oder MS Active Directory zugreifbarer; mit diversen

36


Import- und Exportm¨ oglichkeiten), Kalender (mit Vorschlägen, Import beziehungsweise Export, etc.) und eine Projektverwaltung. Erweitert wird das durch ein sogenanntes Infolog, mit dem man Notizen, Anrufe und Aufgaben verwalten kann (mit Links zu Adressen, Projekten, etc.). Auch ein Mailingsystem ist als Modul vorhanden. Damit k¨ onnen mehrere Benutzerkonten verwaltet werden. ¨ Uber diesen Funktionsblock hinausgehend gibt es eine Reihe weiterer ¨ Funktionen (meist als Erweiterungsmodul). Ahnlich zu Open-Xchange steht eine Knowledge Base“, die Fragen, Artikel, Dateien und Verlinkungen zu ver” schiedenen Kategorien verwaltet und suchbar macht, zur Verf¨ ugung. Weiters gibt es einen Bookmarkmanager f¨ ur eine hierarchische Verwaltung inklusive eines Netscape Plug-ins. In Richtung CMS sind entsprechende Erweiterungen wie JiNN oder SiteMgr, die CMS Funktionalitäten anbieten, vorhanden. In diese Ecke passt auch noch ein vorhandenes Artikel- und Headlinesystem, mit dem man Inhalte besser pflegen beziehungsweise einbinden kann. F¨ ur eine m¨ oglichst effiziente Unterst¨ utzung des Zusammenarbeitens gibt es Foren, Messenger Funktionalit¨ at (einfaches Nachrichtensystem), Umfragen (Multiple-Choice-Fragen) und vor allem ein Wiki System (mit WYSIWYG Editor). Zus¨ atzlich stehen noch zwei recht umfangreiche Module, die einerseits ein Trouble Ticket System und andererseits ein Produktionssystem f¨ ur elektronische Journale darstellen, zur Verf¨ ugung. Das Trouble Ticket System inkludiert ¨ selbstdefinierte Stati und Uberg¨ ange, E-Mail Unterst¨ utzung, Petrinetze und eine Historie. Von den wichtigen Aspekten fehlt primär die Möglichkeit, Dateien (zum Beispiel Screenshots) verwalten zu können. Das Modul f¨ ur elektronische Journale erm¨ oglicht die Pflege von Metadaten (in mehreren Sprachen), biografischen Informationen und der Produktion. Dabei kann man das OpenOffice Format (sowie Word mit einem kommerziellen Add-on) als Input und HTML beziehungsweise PDF als Output verwenden. Insgesamt bietet PhpGroupWare eine F¨ ulle von Funktionen (¨ uberwiegend durch Erweiterungsmodule von denen auch nur die wichtigsten vorgestellt wurden). Dadurch erkl¨ aren sich auch Schwächen durch eine nicht immer komplette Integration (zum Beispiel der Berechtigungssteuerung als ganz zentralem Thema). Gleichzeitig ist dieser Ansatz auch der Schl¨ ussel zu den vielen vorhandenen Modulen, die relativ billig“ und schnell entwickelt werden ” können. Man kann also feststellen, dass es sich um einen anderen Ansatz als bei den bis jetzt vorgestellten Systemen handelt. PhpGroupWare ist sozusagen ein Ergebnis der Internetrevolution mit dem intensiven aber gleichzeitig lockeren Zusammenarbeiten von unterschiedlichsten Gruppen an einem Projekt (wie es f¨ ur viele der im Weiteren vorgestellten Open Source Systeme ebenfalls typisch ist). An den St¨ arken und Schw¨ achen der PhpGroupWare sieht man, dass PHP wesentlich mehr Leute anregt, ein Zusatzmodul zu einem System zu schreiben. Damit ist es schwieriger, ein integriertes und konsistentes System zu haben, und die Wartung wird zumindest uneinheitlich. Je nach Aktivität und

3.3 Content Management Systeme

37

Interesse der einzelnen Modulentwickler kann dies positive oder negative Auswirkungen haben. 3.2.7 Zusammenfassung Bei den sechs Beschreibungen von Groupware Systemen kann man schon sehen, dass es sich bei relevanter Open Source Software u ¨ berwiegend um ehemalige kommerzielle Projekte beziehungsweise um eher junge“ Projekte, die ” häufig auf Skriptsprachen mit einem schnellen Entwicklungszyklus und größerer potenzieller Entwicklerzahl basieren, handelt. Die kurzen Abschnitte zu ¨ jedem System k¨ onnen nat¨ urlich nur einen groben Uberblick geben und sollen dem Leser helfen, eine Vorauswahl zu treffen. Die eigentliche Entscheidung h¨ angt zu sehr von individuellen Gegebenheiten ab, als dass es Sinn machen w¨ urde, sie in diesem Buch zu treffen. Um sozusagen eine Art Gegen¨ uberstellung zu haben, folgen zwei Tabellen (3.1 und 3.2) mit den Schl¨ usselbegriffen der L¨ osungen. Man sieht, dass es eine Menge Gemeinsamkeiten gibt, was es in vielen Fällen erlaubt aufgrund von anderen Aspekten zu entscheiden (zum Beispiel: Passt am besten zu vorhandenen Systemen). Weiters sind mehrere der Systeme in wichtigen Bereichen schon auf die Verbindung mit anderen Systemen vorbereitet (insbesondere LDAP f¨ ur Benutzerdaten und verschiedene Mailserver). Soweit es dabei nur“ um Aspekte zwischen Group” ware Servern und Clients geht, gibt es hier auch aktuelle Entwicklungen zu mehr Offenheit wie etwa durch die GroupDAV Initiative (siehe http://www. groupdav.org/) f¨ ur die Verbindung von klassischen“ Clients mit Groupwa” re Servern. Dagegen ist der CalDAV Standard (siehe http://ietfreport.isoc. org/idref/draft-dusseault-caldav/) darauf ausgerichtet Kalenderdaten online anzubieten (bei GroupDAV hat der Client im Prinzip eine Offline- Daten” bank“). Solche Standards sind insbesondere wichtig, wenn sie es erleichtern ein m¨ oglichst einheitliches KM System zu gestalten.

3.3 Content Management Systeme Wie schon kurz im Abschnitt u ¨ ber Groupware Systeme angedeutet, sind die meisten CMS Produkte mit mehr oder weniger vielen Groupware und Com” munity“ Funktionen ausgestattet. Ganz typisch ist ein Webmail Angebot sowie Unterst¨ utzung f¨ ur Foren, um je ein Beispiel zu nennen. Gleichzeitig ist diese Produktkategorie sehr heterogen, sowohl was die Technologie als auch den Funktionsumfang betrifft. Insbesondere sollte man nicht auf die schon vorgestellten Systeme Tiki beziehungsweise PhpGroupWare vergessen, die CMS Funktionen anbieten. Die meisten der vorgestellten Systeme basieren auf PHP, es gibt aber auch je zwei Vertreter von Java beziehungsweise Python/Zope basierten Systemen. Das spiegelt einerseits die hohe

38

3 Vorhandene Open Source Basis Tabelle 3.1. Groupwarevergleich 1/2

Kategorie Groupware“” Funktionen:

Wichtige Anbindungen:

Benutzerverwaltung: Extrafunktionen:

Bemerkung: Programmiersprache: Datenbank (getestet): URL:

Lizenz:

OpenGroupware Adressen, Kalender, Mailing, Projektverwaltung, DMS XMLRPC (Wrapper f¨ ur PHP und Java verf¨ ugbar, .NET in Entwicklung), Outlook, Evolution, etc. SQL/LDAP

Open-Xchange Adressen, Kalender, Mailing, Projektverwaltung, Dokumente WebDAV Interface, Visual Basic, Jabber Integration, Outlook/. . . (indirekt u ¨ ber Mailserver)

Kolab Adressen, Kalender, Mailing

LDAP

LDAP

Palm PDA Synch

Forum, Schwarzes Brett, Wissensda” tenbank“, bidirektionale Links Gut integrierte Gesamtl¨ osung prim¨ ar Java

Palm PDA Synch (KPilot)

Integration von Standardsoftware PHP/Perl/C++

PostgreSQL

- (indirekt)

Gut integrierte Gesamtl¨ osung prim¨ ar Obj-C PostgreSQL, FrontBase http://www. opengroupware. org/ GPL/LGPL

andere Kolab Server, Spamfilter, Antivirensoftware, KDE Kontact, Outlook, etc.

http://www. http://kolab.org/ open-xchange.org/ GPL

GPL/LGPL

Popularit¨ at von PHP bei Open Source Webentwicklern wieder und demonstriert andererseits, wie einfach es ist mit PHP entsprechende Funktionen zu entwickeln. Im Weiteren wird nur auf CMS Systeme f¨ ur das Internet beziehungsweise Intranets (sogenannte Web CMS Systeme) eingegangen. Generell gibt es auch eine Reihe anderer Systeme, die beanspruchen können, ein CMS System zu sein, ohne sich um Internetinhalte zu k¨ ummern. F¨ ur eine möglichst breite Unterst¨ utzung von KM durch Open Source Software sind aber solche CMS Systeme praktisch ohne Bedeutung. Daher wird im Weiteren der Begriff CMS gleichbedeutend mit Web CMS verwendet (was auch mit der häufigsten Verwendung des Namens u ¨ bereinstimmt). Besonders wichtig bei CMS Systemen ist, sich ihren Platz in einer IT Infrastruktur zu u ¨ berlegen. PHP basierte Systeme sind besonders attraktiv, wenn sie ein Extrasystem oder gar das Einzige darstellen. Java basierte Systeme haben besondere Vorteile, wenn man sehr viel integrieren will und


39

Tabelle 3.2. Groupwarevergleich 2/2 Kategorie Groupware“” Funktionen:


PHProjekt Adressen, Kalender, Mailing, Projektverwaltung, Dateien Outlook, div. Import & Export (PDF, XML, CSV, ...)

Benutzerverwaltung:

SQL/LDAP

Extrafunktionen:

Umfragen (Votings), Forum, Chat, Wiki, Fax

Bemerkung:

Beliebte PHPGesamtl¨ osung

Programmiersprache: Datenbank (getestet):

prim¨ ar PHP

URL: Lizenz:

SQLite, MySQL, PostgreSQL, Oracle, Informix, MS SQL Server http://www. phprojekt.com/ GPL

Tiki PhpGroupWare Kalender, Mailing, Adressen, Dokumente Kalender, Mailing, Projektverwaltung Kalender- bzw. indirekt (z.B. WikiMailserver) Import/Export (CSV/TXT), Blogger, XMLRPC SQL/LDAP SQL/LDAP (Authentifizierung: viele) CMS, CMS, Infolog, Knowledge Base“, Artikelsystem, ” Forum, Newsletter, Bookmarkmanager, Artikel- & Webblogs, Wiki, Headlinesystem, Verzeichnisse, Forum, Messenger, Umfragen, Umfragen, Wiki, Bannersystem, Trouble Ticket Chat, FAQs, System, Trackers Publizierung elektr. Journale Interessante PHP Viele Funktionen, L¨ osung, Integration nicht Groupwareteil u ¨berall gelungen schw¨ acher prim¨ ar PHP prim¨ ar PHP MySQL, PostgreSQL, Oracle, Sybase

MySQL, PostgreSQL, MS SQL Server

http: //tikiwiki.org/ LGPL

http://www. phpgroupware.org/ GPL/LGPL

sind typischerweise weniger flexibel (aufgrund der dahinterliegenden Komplexit¨ at/M¨ achtigkeit). Gleichzeitig darf man solche Ausf¨ uhrungen nat¨ urlich nicht verallgemeinern. Sie stellen nur eine Art Denkanstoß dar. Ebenfalls noch aufgef¨ uhrt sind zwei Python/Zope Systeme, die bis zu einem gewissen Grad eine eigene Welt darstellen. Die entsprechenden Systeme sind durchaus sehr interessant und man sollte sie auf keinen Fall von einer Untersuchung ausschließen.

40


Gleichzeitig muss eine Entscheidung gegen den Mainstream (im Open Source Webumfeld eben PHP und teilweise Java) gut u ¨berlegt sein. Klarerweise existieren insbesondere bei CMS Systemen (aber nicht nur in dieser Kategorie) noch eine Reihe weiterer spannender Entwicklungen. Auf der Basis der Skriptsprache Perl gibt es zum Beispiel ebenfalls eine enorme F¨ ulle an Systemen, die teilweise durchaus sinnvoll sein können. Daneben gibt es noch eine Unmenge weiterer Systeme, die schon aufgef¨ uhrte oder noch deutlich andere Technologien verwenden. Daher soll (auch an dieser Stelle) deutlich gesagt werden, dass dieses Buch versucht, die aus Sicht des Autors wichtigsten Open Source Produkte f¨ ur die Unterst¨ utzung von KM darzustellen. Einerseits wird sicher das eine oder andere wichtige Produkt u ¨ bersehen worden sein. Andererseits muss dieses Werk eine grobe Vorauswahl treffen, die zwangsläufig nicht immer gerecht sein kann, damit es u ¨berhaupt ein Ergebnis gibt. Ein relativ beliebtes nicht diskutiertes PHP System ist zum Beispiel PostNuke, das sich grob zwischen PHP-Nuke und XOOPS einordnet. Wenn also diese Systeme die attraktivsten sind, sollte man auch noch einen Blick auf PostNuke werfen. 3.3.1 Plone Plone ist ein m¨ achtiges CMS System, das auf dem Zope Application Server basiert, der wiederum der prominenteste Vertreter dieser Spezies“ in der ” Programmiersprache Python ist. Einige der beschriebenen Funktionen erbt“ ” Plone daher von Zope und kann auf ein umfassendes Fundament bauen. Als Ergebnis bietet Plone neben Versionierung und einer Bearbeitungshistorie auch ein durchg¨ angiges Undo f¨ ur alle Elemente. Ebenso gibt es eine u ur die Berech¨ bergreifende Suche, Templates, ACLs (Access Control Lists) f¨ tigungssteuerung, Workflowunterst¨ utzung, Import (inklusive Word, OpenOffice, Powerpoint, Excel und RTF) und Export sowie G¨ ultigkeitszeiträume f¨ ur jedes Element. Nat¨ urlich gibt es auch verschiedene WYSIWYG Editoren sowie die Einbindung von RSS-Inhalten und die Erzeugung von RSS durch Plone selbst. Weiters stehen f¨ ur die Verwaltung auch die Möglichkeiten HTTP, FTP und WebDAV zur Verf¨ ugung. Die Unterst¨ utzung f¨ ur Metadaten h¨ alt sich an den Dublin Core und somit ist f¨ ur eine gute Austauschbarkeit dieser Daten gesorgt. Die Authentifizierung ist mit einer Vielzahl von Mitteln m¨ oglich (SQL, LDAP, MS Active Directory, SMB, . . . ). Zur Speicherung verwendet Plone die Zope Datenbank. Gleichzeitig kann man aber auch Daten von einer Oracle, MS SQL Server, PostgreSQL, MySQL, InterBase und generell jeder ODBC kompatiblen Daur größere Installationen ist tenbank einbinden (Zugriff und Speicherung). F¨ uber hinaus m¨ oglich, mehrere Server zu verwenden. es dar¨ Funktionell hat Plone ebenfalls eine ganze Menge zu bieten. Es beginnt bei Themen, Dateien, Links, Verzeichnissen, Events, Foren. Dar¨ uber hinaus werden ein Issue Tracker, ein Chat & Instant Messaging System, Fotogalerien und ein Wiki angeboten. Erg¨ anzend gibt es die Möglichkeit, jede Seite als PDF


41

zu exportieren (zum Beispiel zum Drucken; verwendet allerdings ein kommerzielles Tool) und zu jedem einzelnen Element eine Diskussion zu ermöglichen. Durch Zusatzmodule gibt es eine ganze Reihe weiterer interessanter Funktionen wie etwa ein Webmail Modul, FAQ/HOWTO Unterst¨ utzung, ein ausgefeiltes Umfragensystem und so weiter. Plone wird von einer ganzen Reihe von Organisationen verwendet, wobei die Navy der USA sicher die prominenteste ist. Generell k¨ ummert sich die Plone Foundation um das Projekt und ist eine unabhängige Koordinationsstelle. Insgesamt stellt Plone eine interessante Alternative zu den Java und PHP Systemen dar. Es gibt unmittelbar eine F¨ ulle von Funktionen, mit denen man viele Anforderungen direkt abdecken kann. F¨ ur dar¨ uberhinausgehende Aspekte kann man auf eine Reihe von Firmen oder erfahrene Entwickler zur¨ uckgreifen. Man sollte sich aber dar¨ uber klar sein, dass man sich f¨ ur eine Nische entscheidet (wobei es eine der aktivsten Nischen im betrachteten Umfeld ist). 3.3.2 elevateIT elevateIT ist eine Erweiterung von Plone (beschrieben in Abschnitt 3.3.1). Daher gilt selbstverst¨ andlich alles, was f¨ ur Plone selbst gilt. Hinter elevateIT stehen aktuell prim¨ ar die Firma SYSLAB.COM GmbH und die Technische Universit¨ at M¨ unchen, denen Plone alleine noch nicht ausreichte. Wichtige eigene Funktionen sind Metadaten zu jedem Element (die bei der Suche ber¨ ucksichtigt werden), Personalisierung f¨ ur jeden Benutzer und ein verbesserter Workflow. Besonders hervorzuheben ist noch die Fähigkeit von elevateIT Servern, miteinander zu kommunizieren. Zusammenfassend stellt elevateIT eine interessante Erweiterung zu Plone dar. Man sollte vor einem Einsatz von Plone auf jeden Fall abwägen, ob man die Korrektur“ der Plone Schw¨ achen durch elevateIT wichtig genug fin” det, um vom Mainstream abzuweichen. Aus aktueller Sicht wäre das vor allem gerechtfertigt, wenn einem die elevateIT Funktionen so wie sie sind ausreichen. 3.3.3 OpenCMS OpenCMS ist ein Java basiertes CMS System, das u ¨ berwiegend von der deutschen Firma Alkacon Software entwickelt wird. Dieser Punkt ist Vor- und Nachteil zugleich. Einerseits kann man im deutschen Sprachraum relativ simpel Support einkaufen und neue Funktionen bestellen. Andererseits hat man keine typische Entwicklergemeinde und damit weniger Chancen auf interessante Entwicklungen von außen“. ” Vom System selbst her gibt es wieder die wichtigsten CMS Funktionen. Kurz aufgef¨ uhrt sind dies ein 2-stufiger Workflow, ein WYSIWYG Editor, ein ACL basierendes Berechtigungssystem, eine Bearbeitungshistorie mit Versiaume f¨ ur Beitr¨ age, ein Portalbaum f¨ ur die Inonskontrolle, G¨ ultigkeitszeitr¨ halte, Templates, Inplace Editing (also direkt in der Ansicht editieren), ein

42


¨ Aquivalent zu UNIX Hardlinks (also mehreren Verweisen auf ein und dasselbe Dokument unsichtbar f¨ ur die Benutzer), die Integration von JSPs und eine Voransicht. F¨ ur die Nutzer gibt es Artikel, Datei-, Bild- und HTML-Galerien und ein Projektsystem mit dazugeh¨ origen Aufgaben sowie automatischen Benachrichtigungen. Zus¨ atzlich gibt es noch eine existierende Integration von Apache Lucene f¨ ur die Volltextsuche in PDF, Word und Excel Dokumenten. Diese Funktionalität geht vielen Systemen ab, sollte sich aber relativ problemlos einbauen lassen. Weiters gibt es auch noch die M¨ oglichkeit, eine Installation in Form eines Clusters betreiben zu k¨ onnen. Obwohl OpenCMS ein dynamisches System ist, gibt es auch die M¨ oglichkeit statische Inhalte zu exportieren und per Webserver ausliefern zu lassen, um die Performance und Skalierbarkeit zu erh¨ ohen. Sowohl vom Hersteller“ als auch von anderen Entwicklern her gibt es noch ” interessante Zusatzmodule. Insbesondere erwähnenswert ist ein HTML Import, ein Mailing List Manager, RSS Integration und ein Fotoalbum. Zusätzlich f¨ ur den Kontext des Buches besonders wichtig sind ein Adressbuch und ein Kalendermodul, die als Basis f¨ ur Groupwarefunktionen dienen können. Wer sich weiter in das Thema OpenCMS vertiefen will, kann auch auf das Buch Building Websites with OpenCMS“ von Matt Bucher zur¨ uckgreifen (basiert ” auf Version 5.0.x). Generell kann man sagen, dass OpenCMS die wichtigsten CMS Funktionalit¨ aten bietet und auch dar¨ uber hinaus interessante Themen adressiert. Von den Modulen her kann es nicht ganz mit den extrem populären PHP Vertretern mithalten. Gleichzeitig ist es eines der wenigen relativ kompletten Open Source Java CMS Systeme. Schon alleine deshalb muss man es näher ins Auge fassen, wenn man ein gr¨ oßeres integriertes System auf Java Basis anstrebt. 3.3.4 JBOSS Portal Das zweite vorgestellte CMS“ auf Java Basis ist das JBOSS Portal (urspr¨ ung” lich NukesOnJBOSS). Von der urspr¨ unglichen Idee her handelt es sich um eine Art Implementierung des extrem beliebten PHP Portals“ PHP-Nuke auf der ” Basis Java unter Verwendung eines Application Servers (im Speziellen eben JBOSS). Dahinter steht prim¨ ar die JBOSS Group, die ihr Geld durch Consulting und Support des Open Source Application Servers JBOSS verdient. Inzwischen ist das Produkt allgemeiner positioniert und lässt sich am besten als Portal mit integriertem CMS beschreiben (daher auch die Darstellung in diesem Abschnitt). at her bietet es nat¨ urlich eine Benutzerverwaltung Von der Funktionalit¨ mit Berechtigungskonzept, das auch die Unterscheidung von Rolle und Gruppe kennt. Dar¨ uberhinaus steht eine Single Sign-On Funktion sowie ein standardisiertes Java API (das JAAS – Java Authentication and Authorization Service


43

– API von Sun Microsystems) zur Verf¨ ugung. Es gibt einen HTML WYSIWYG Editor und Personalisierung. Eine Reihe von Modulen werden gleich mitgeliefert. Dabei handelt es sich prim¨ ar um Artikel, Dateien, Foren, FAQs und Umfragen. Dar¨ uber hinaus gibt es auch ein Wiki Module names XWiki direkt von der JBOSS Group. Sehr interessant ist die Tatsache, dass alle gespeicherten Informationen versioniert werden. Wichtige Spezifikationen wie der Java Portlet Standard (JSR 168) oder der Content Repository Standard (JSR 170) werden unmittelbar unterst¨ utzt und an einer WSRP (siehe Glossar) Anbindung wird gearbeitet. Ebenfalls noch nicht fertig ist ein Workflow f¨ ur die CMS Funktionalit¨ at. Von der technischen Basis her beruht JBOSS Portal unter anderem auf dem Datenbank Framework Hibernate (ebenfalls von der JBOSS Group), was gleichzeitig datenbankunabh¨ angigen Code bedeutet. Interessant ist auch die M¨ oglichkeit das Produkt als Cluster zu betreiben, um eine höhere Ausfallssicherheit zu erreichen. Wichtig ist noch die Unterst¨ utzung einer Reihe von Technologien zur Entwicklung von Applikationen. Dabei werden popul¨ are Frameworks und Technologien wie Java Server Faces (JSF; siehe http: //java.sun.com/j2ee/javaserverfaces/)/MyFaces, Struts oder Spring MVC unterst¨ utzt. Insgesamt betrachtet bietet JBOSS Portal alle CMS Grundfunktionen, eine Vielzahl von Portalfunktionen und wichtige DMS Funktionalitäten. Da es sich um ein relativ junges Produkt handelt (gerade in Hinblick auf den weiten Funktionsumfang) ist die Nutzergemeinde noch im Wachsen begriffen und es gibt viele Bereiche an und in“ denen gearbeitet wird. Besonders attrak” tiv ist dieses System daher, wenn es darum geht, eine größere Java basierte Architektur zu erstellen, die vorzugsweise mit JBOSS als Application Server arbeitet (beziehungsweise zumindest gut damit arbeiten kann). In diesem Kontext kann man sicher am meisten von JBOSS Portal profitieren. Rein von einer CMS Sicht her betrachtet bietet im Moment sicher OpenCMS mehr (besonders wichtig der Workflow) und wenn man dieses Mehr sinnvoll einsetzen kann, sollte man es tun. 3.3.5 Contenido Bei Contenido handelt es sich um eines der einfacheren (= eher reines) CMS Systeme auf PHP Basis. Es enth¨ alt die u ¨ blichen Funktionen wie einen WYSIWYG Editor, eine Zeitsteuerung und eine automatische Archivierung f¨ ur Beitr¨ age. Weiters gibt es Newsletter (auch mit RSS Unterst¨ utzung, Artikel, Dateien, Templates und Frageb¨ ogen. F¨ ur die Einordnung unterst¨ utzt es Kategorien und Metadaten. F¨ ur die Verwaltung bietet es Workflowunterst¨ utzung, Statistiken, einen Dateimanager, Todos und Wiedervorlage f¨ ur Redakteure. Weiters gibt es auch ein Benutzer und Gruppenmanagement. F¨ ur bestimmte Portalbereiche kann man eine Authentifizierung voraussetzen, der Rest ist ur mehrsprachige Hoanonym“ zug¨ anglich. Eine Synchronisierungsfunktion f¨ ”

44


mepages ist ebenfalls vorhanden. Erw¨ ahnenswert ist auch noch die Möglichkeit, Module zu importieren und exportieren. Insgesamt werden die Grundfunktionen eines CMS unterst¨ utzt. Gleichzeitig sind relativ wenige dar¨ uber hinausgehende Funktionalitäten vorhanden. Insbesondere fehlt ein Berechtigungskonzept f¨ ur einzelne Inhalte (ist geplant). Damit ist es unmittelbar f¨ ur Kollaborationszwecke nur schlecht einsetzbar. Einschr¨ ankend muss hinzugef¨ ugt werden, dass die aktive Benutzergemeinde st¨ andig Erweiterungen beziehungsweise Plug-ins veröffentlicht und dass man selbstverst¨ andlich verschiedene separate PHP Entwicklungen integrieren kann. 3.3.6 Mambo/Joomla Im Fall von Mambo hat man es mit einem populären PHP basierten CMS System zu tun. Es bietet schon im Kern“ eine Reihe von wichtigen Funktionen. ” Zu nennen sind insbesondere ein (simpler) Workflow, Online Hilfe, Dateimanagement, simple Umfragen, ein WYSIWYG Editor, ein Template System und G¨ ultigkeitsdaten eines Beitrags. Technisch betrachtet gibt es auch Unterst¨ utzung f¨ ur RSS, Caching, Statistiken und ein Berechtigungssystem mit Benutzern und Gruppen. F¨ ur den angestrebten Einsatzzweck eher unwichtig ist ein Verwaltungssystem f¨ ur Werbung. Die meisten Funktionen werden u ustet (ein rela¨ber Add-ons nachger¨ tiv typisches Vorgehen f¨ ur Systeme wie Mambo). Besonders erwähnenswert sind das LDAP Authentifizierungsmodul, Forumfunktionalität, Mediengalerien, Dokumentenmanager, Eventkalender, Templates und erweiterte Userprofile. Das Ergebnis einer Mambo Installation mit vielen Modulen ist ein mehr ¨ oder weniger mächtiges Communityportal“. Ahnlich wie Contenido stellt ” Mambo ein gut verwendbares CMS zur Verf¨ ugung. Gleichzeitig gibt es bei anderen Beispielen wesentlich mehr integrierte Funktionen und noch mehr Add-ons. Daher sollte man genau u ¨ berlegen, ob man mit den Mambofunktionalit¨ aten das Auslangen findet. Insbesondere wenn es um Kollaboration geht, ur die einzelnen Inhalte. Daher sollte man Mambo vor fehlen einem ACLs f¨ allem in Betracht ziehen, wenn man mit dieser Einschränkung leben kann und die vorhandenen Module den Bedarf ganz oder größtenteils abdecken. Im Zusammenhang mit Mambo ist Joomla ein ganz wichtiges Thema. Im Sommer 2005 f¨ uhrte ein Streit u ¨ ber Namensrechte und das Copyright zur Abspaltung eines Großteils der Kernentwickler. Die Hintergr¨ unde dieses Streits sind schwer zu durchschauen, da die Darstellungen beider Seiten keine abschließende Beurteilung zulassen. Jedenfalls haben die angesprochenen Entwickler basierend auf Mambo 4.5.2.3 Joomla 1.0 veröffentlicht. Als Folge ist Mambo 4.5 mit Joomla 1.0 kompatibel (und im Großen und Ganzen sogar identisch). Jedoch gibt es jetzt einerseits die Entwickler der Mambo Foundation (die inzwischen alle Rechte von der Firma Miro u ¨ bertragen bekommen hat) und unter dem bekannten Namen weitermachen sowie die Gruppe von


45

ehemaligen Mambo Entwicklern, die jetzt hinter Joomla stehen. Vermutlich wird die Kompatibilit¨ at der beiden Systeme mit Joomla 1.1 nur mehr eingeschr¨ ankt gegeben sein (geplant ist eine bessere Internationalisierung und die Unterst¨ utzung weiterer Datenbanken). Die Zukunft der beiden Systeme ist schwer vorherzusagen. F¨ ur Mambo spricht die installierte Basis, die keine großen Anreize hat auf Joomla umzusteigen. Das neu formierte Entwicklerteam scheint durchaus in der Lage, das Projekt weiterzuf¨ uhren. Es d¨ urfte also Zukunft haben. Bei Joomla steht unmittelbar auch eine aktive Gemeinschaft dahinter. Damit bestehen gute Chancen auf eine langfristige und erfolgreiche Weiterentwicklung. Gleichzeitig ist die installierte Basis noch klein und die Zukunft scheint unsicherer als bei Mambo zu sein. 3.3.7 PHP-Nuke Bei PHP-Nuke handelt es sich um eines der beliebtesten Web CMS im Open Source Umfeld. Es war auf jeden Fall eines der ersten erfolgreichen Systeme u ¨ berhaupt und ist bis heute weit verbreitet. Der Erfolg von PHP und PHPNuke im CMS Umfeld haben sich bis zu einem gewissen Grad wechselseitig ergeben. Im Kern bietet es ein Artikelsystem, Umfragen, Statistiken, Kommentare, Moderation, Banner, RSS und RDF Export, eine Suchmaschine, einen Dateimanager, FAQs, Downloads, Newsletter und Kategorien. Man sieht, dass es im Prinzip die wichtigsten Funktionen anbietet. Zusätzlich gibt es eine fast nicht u ¨berschaubare Anzahl von Zusatzmodulen. Diese decken fast alle vorstellbaren Felder ab und es macht keinen Sinn sie hier aufzuz¨ ahlen. Ein wichtiger Punkt bei PHP-Nuke ist, dass viele Leute u ¨ berzeugt sind, dass es Designschw¨ achen aufweist. Als Folge haben sich mehrere Projekte auf die Fahnen geschrieben, einen besseren Nachfolger zu implementieren. Die beiden Prominentesten sind PostNuke und XOOPS (letzteres wird noch vorgestellt). Zum Zeitpunkt der Recherche war auch immer nur die vorletzte Version zum freien Herunterladen verf¨ ugbar, f¨ ur die aktuelle Version muss man $10 bezahlen (wobei die Lizenz f¨ ur die frei verf¨ ugbare Version trotzdem die GPL ist). Generell kann man sagen, dass PHP-Nuke einen Großteil aller Anforderungen an ein Web CMS erf¨ ullt. Durch die verf¨ ugbaren Zusatzmodule kann man eine ganze Reihe von Zusatzanforderungen abdecken. Daher ist es sicher ein Kandidat, falls man mit den vorhandenen Funktionen das Auslangen findet. Wenn man an ein gr¨ oßeres System denkt beziehungsweise an Erweiterungen, sollte man sich eine entsprechende Entscheidung aber sehr genau u ¨ berlegen. Angesichts der vielen ernsthaften Bedenken hinsichtlich des Designs stellt es keine ausreichende Basis f¨ ur ein großangelegtes KM System dar.

46


3.3.8 Typo3 Typo3 ist ein sehr beliebtes PHP basiertes CMS, das immer wieder gut bewertet wird. Es ist dabei auf den Einsatz als CMS fokussiert und weniger als allgemeine Basis gedacht. Bei den Funktionen findet man die u ¨blichen Punkte wie Workflow, Statistiken, WYSIWYG Editor, Dateimanagement, Voransicht, kontextsensitive Hilfe, G¨ ultigkeitszeitr¨ aume, ein Versionsmanagement, ein Mailmodul ¨ und Newsletter. Uber typische Funktionalit¨ aten hinausgehend sind die Unterst¨ utzung einer Volltextsuche in Word und PDF Dateien, der Import von Word Dokumenten sowie ein Wizard f¨ ur die Erstellung von E-Mailformularen. Zum Zeitpunkt der Recherche waren auch noch eine LDAP Anbindung, Unterst¨ utzung f¨ ur eine Staging Umgebung, ein verbesserter Workflow und Datenbankunabh¨ angigkeit (von MySQL) geplant. Daran erkennt man auch die Stoßrichtung dieses Systems. Insgesamt scheint Typo3 ein besonders gut geeignetes PHP CMS System zu sein. Als Basis f¨ ur mehr ist es weniger gedacht, daf¨ ur fokussiert es sich sehr gut auf die reinen CMS Aspekte mit sinnvollen Erweiterungen. Damit ist es als CMS System empfehlenswert; eventuell auch parallel zu einer reinen Groupwarel¨ osung. Als Integrationsplattform ist es dagegen nicht gedacht. 3.3.9 Xaraya Xaraya ist ein weiteres PHP CMS mit interessanten Ansätzen. Es ist ein sehr junges System und hat damit noch einen relativ kleinen Benutzerkreis. Was bietet es? Es gibt ein Berechtigungssystem in der Basis. Es unterst¨ utzt eine Reihe von Inhaltstypen wie Artikel, Dokumente, Kritiken, FAQs, Bilder, Links, Zitate und Downloads. Dazu gibt es Kategorien und einen WYSIWYG Editor. Zum Zeitpunkt der Recherche waren auch noch eine Reihe weiterer wichtiger Funktionalit¨ aten und Erweiterungen in Entwicklung. Insbesondere Umfragen, ein Wiki und Druckunterst¨ utzung. Daraus folgt, dass Xaraya ein System ist, auf das man ruhig einen Blick werfen sollte (wenn ein PHP CMS in Frage kommt). Je nachdem, wie es sich weiterentwickelt, k¨ onnte es einer der wichtigen Mitspieler werden und man sollte das kurz verifizieren. So wie es sich im Moment darstellt, kann man es aber nicht f¨ ur die angedachten Einsatzszenarien empfehlen (außer man will sich in die Entwicklung einbringen). 3.3.10 XOOPS Im Unterschied zu den meisten beschriebenen Systemen ist XOOPS kein komplettes“ CMS. Es ist eher ein Portal mit CMS Funktionen. Gleichzeitig ” ist es aber vollst¨ andig genug, um einem Vergleich standzuhalten. Wie schon kurz beschrieben ist eines der Ziele von XOOPS, ein besseres PHP-Nuke zu


47

sein. Zus¨ atzlich soll es auch eine Plattform f¨ ur alle möglichen Entwicklungen darstellen. Da es auch eine recht aktive und große Entwicklergemeinde hat, findet man eine ganze Menge an Funktionen und Modulen. Zuerst jedoch zum Kern des Systems. Es gibt ein durchgezogenes Berechtigungskonzept, Artikel mit Kommentaren, Foren, Linklisten, Downloads, ¨ Umfragen, Uberschriften und RSS Syndizierung. Im Hinblick auf die Unterst¨ utzung von KM Prozessen gibt es noch Blogs, diverse Kalendermodule, Chatsysteme, WYSIWYG Editoren, Diskussionsmodule, ein Document Management System, Webmail Unterst¨ utzung, Bug Tracking, ein FAQ/ Know” ledgebase“ Module, einen Dateimanager, Bildergalerien, Newsletter, Avantgo Anbindung (f¨ ur WAP/WML2), Statistiken, Adressb¨ ucher, . . . Man sieht also, dass es eine F¨ ulle von Funktionalit¨ aten gibt. Bei der Menge an Funktionen sollte man nicht vergessen, dass insbesondere die verschiedenen Module h¨ aufig nicht optimal miteinander zusammenarbeiten. Je nach Bedarf kann hier also durchaus noch Anpassungsaufwand entstehen. Gleichzeitig kann man mit XOOPS und einer gut ausgewählten Menge an Modulen eine ganze Reihe von Anforderungen abdecken. Das reicht vom CMS u ¨ ber Communityfunktionen“ bis zu Groupwareaspekten. ” Wenn man daran denkt, eine Art Integrationsplattform zusammenzustellen ist XOOPS der vielleicht beste PHP Kandidat. Andere Systeme sind besser als reine CMS L¨ osungen haben aber Schwächen als Portal“. Konse” quenterweise ist es daher das einzig empfohlene System, wenn man eine PHP Integrationsplattform haben will (Ausnahmen bestätigen auch diese Regel). 3.3.11 phpWebSite Bei phpWebSite handelt es sich um ein weiteres relativ beliebtes CMS auf Basis PHP. Dabei hat die eigentliche Software einen relativ genau umrissenen Umfang. Gleichzeitig gibt es eine ganze Menge von Zusatzmodulen, was auch die Lebendigkeit der Entwicklergemeinde demonstriert. Urspr¨ unglich wurde das System von der Web Technology Group an der Appalachian State University implementiert. Jetzt k¨ ummert sich das phpWebSite Development Team um die Software (wobei immer noch ein starker Einfluss der Universität vorhanden ist). Bei den Kernfunktionen bietet es ein Artikelsystem, Dokumente, FAQs, Foren, einen Linkmanager, eine Fotogalerie, Umfragen, einen Eventkalender, Einbindung von RSS Feeds, Kommentare zu Artikeln, ein simples Nachrichtensystem und einen Generator f¨ ur Formulare. Nat¨ urlich gibt es wieder einen groben Workflow, eine Suchfunktion, eine kontextsensitive Hilfe sowie Kategorien f¨ ur alle Elemente. Generell unterst¨ utzt das System eine Art Benutzerkonzept (auch Benutzergruppen). Es ist allerdings nicht m¨ oglich einzelne Elemente auf Benutzer oder Gruppenebene zu berechtigen (nur anonyme Benutzer können am Zugriff ur viele Verwendungszwecke ein Problem dar. gehindert werden). Das stellt f¨

48


Einige fehlende Funktionen kann man u ¨ ber zusätzliche Module bekommen. Wichtige Beispiele sind Mailinglisten und eine Adressverwaltung. Weitere Module adressieren zum Beispiel Sportinhalte etwa mit einem Modul f¨ ur Teams oder Sportligen. Insgesamt ein relativ interessantes CMS System soweit keine Personalisierung notwendig ist. Hier liegt ein Problemfeld, wenn es um Kollaboration geht. Als Ergebnis wird man f¨ ur eine Unterst¨ utzung von vielen KM Prozessen andere Tools ben¨ otigen. Hintergrund ist zum Beispiel die Notwendigkeit, vertrauliche Dokumente auszutauschen sowie Groupware Funktionen sinnvoll integrieren zu k¨ onnen. 3.3.12 Zusammenfassung Wie schon eingangs beschrieben, ist die Gruppe der CMS Systeme recht uneinheitlich. Genau betrachtet sind f¨ ur generelle KM Zwecke die reinen CMS Produkte schlecht geeignet. Der wichtigste Problempunkt ist dabei das fehlende Berechtigungskonzept (eine klassische Homepage braucht so etwas nicht). Daraus folgt, dass einige der PHP Systeme f¨ ur eine Reihe von potenziellen Aufgaben nicht direkt eingesetzt werden k¨ onnen. Insbesondere bei vertraulichen Inhalten braucht man unbedingt ein System, dass diese Vertraulichkeit auch gew¨ ahrleisten kann. Gleichzeitig sollte man auch diese Systeme nicht ignorieren. Einerseits gibt es in jedem Fall zumindest ein rudiment¨ ares Konzept. Andererseits kann man das Manko zum Teil durch vorhandene Entwicklungen ausgleichen. Dies macht vor allem Sinn, wenn auch eine oder mehrere Homepages mit dem CMS System gepflegt werden sollen. Man sieht schnell, dass alle vorgestellten Systeme relativ jung sind. Wegweisend war f¨ ur viele Entwicklungen dabei das Beispiel PHP-Nuke. Obwohl das System selbst weniger zu empfehlen ist (von vielen Experten wird auf Designschw¨ achen hingewiesen, die einen Einsatz unattraktiv machen) haben zwei der vorgestellten Systeme es explizit als Vorbild (XOOPS und JBOSS Portal) und andere verwenden es als Inspiration. Die folgenden Tabellen (3.3, 3.4, 3.5 und 3.6) zeigen eine ganz grobe Gegen¨ uberstellung der Systeme und ¨ sollen helfen einen Uberblick zu gewinnen. Bis zu einem gewissen Grad abseits stehen Plone und elevateIT. Das liegt nat¨ urlich an der Basis Zope mit der Programmiersprache Python. Gleichzeitig bietet es eine m¨ achtige“ Basis und f¨ ur Plone gibt es eine Unzahl von ” Modulen. Diese Module sind dabei oft von entsprechenden (häufig PHP basierten) Beispielen inspiriert. Man kann diese Systeme also guten Gewissens einsetzen, wenn man sich vorher die Konsequenzen u ¨ berlegt hat. Insbesondere also, ob man mit einem etwas abseits“ gelegenen System nicht u ¨ ber kurz ” oder lang in Schwierigkeiten kommt oder hohe Folgekosten hat. Bei den PHP Systemen muss man sich primär zwischen den eher rei” nen“ CMS Systemen und solchen, die mehr oder weniger stark in Richtung Communityportal“ gehen, entscheiden. Die vielleicht idealsten Vertreter sind ”


49

Tabelle 3.3. CMS-Vergleich 1/4 Kategorie CMSFunktionen:

Wichtige Zusatzfunktionen:


Bemerkung:

Programmiersprache: URL: Lizenz:

Plone Themen, Dateien, Links, Verzeichnisse, Events, Workflow, Versionssystem, div. Import/Export, Templates, G¨ ultigkeitszeitraum, WYSIWYG Editoren, Metadaten lt. Dublin Core, Suche basiert“ auf Zope ” Application Server, Berechtigungen mit ACLs, Foren, Issue Tracker, Chat & Instant Messaging, Fotogalerien, Wiki, Webmail, Umfragen, FAQs/HOWTOs Einbindung div. DBMS, Authentifizierung per SQL, LDAP, Active Directory, SMB, . . . , RSS Import & Export m¨ achtiges CMS mit solider Application Server Basis und einer Menge an verf¨ ugbaren Zusatzmodulen; etwas abseits“ ” wegen Python Python http://plone.org/ Kern: ZPL (Zope Public License; GPL kompatibel)

elevateIT ahnlich Plone; ¨ Metadaten zu jedem Element, Personalisierung, verbesserter Workflow

OpenCMS Artikel, Dateien, Workflow, WYSIWYG Editor, Versionssystem, G¨ ultigkeitszeitraum, Templates

a ¨hnlich Plone

Foto- und HTML-Galerien, Projektsystem mit Aufgaben und Benachrichtigungen, Volltextsuche (PDF, Word, Excel), Kalendermodul, Adressbuch, Mailinglisten JSP Integration, ahnlich Plone; ¨ Kommunikation mit Installation als Cluster vorbereitet, anderen elevateIT HTML Import, RSS Servern Einbindung, ben¨ otigt MySQL oder Oracle etwas st¨ arker integriert als Plone; noch etwas mehr ” abseits“, da Zope/Plone die wichtigsten Python Systeme in diesem Bereich sind Python

m¨ achtiges Java CMS mit vielen relevanten Zusatzmodulen

Java

http: http://www. //www.elevateit.org/ opencms.org/ GPL LGPL

50

3 Vorhandene Open Source Basis Tabelle 3.4. CMS-Vergleich 2/4

Kategorie CMSFunktionen:

JBOSS Portal Artikel, Dateien, WYSIWYG Editor, Versionssystem


Personalisierung, Foren, FAQs, Umfragen, Wiki


implementiert Java Portlet Standard (JSR 168) und Java Content Repository Standard (JSR 170), basiert auf Java Application Server (bevorzugt JBOSS), Datenbank per Hibernate (flexibel) interessante Mischung aus CMS, DMS und Portal mit Schw¨ achen im CMS & DMS Bereich; Java zentriert“ ” Java

Bemerkung:

Programmiersprache: URL:

Lizenz:

Contenido Artikel, Dateien, Templates, WYSIWYG Editor, G¨ ultigkeitszeitraum, Kategorien, Metadaten, Workflow Umfragen (Frageb¨ ogen), Statistiken, Dateimanager, Todos f¨ ur Redakteure

Import & Export per XML, LDAP Anbindung, ben¨ otigt MySQL

eher reines“ CMS; ” keine ACLs daher f¨ ur Kollaboration schlecht geeignet

PHP

http: http://www. //www.jboss.org/ contenido.org/ products/jbossportal LGPL

GPL

Mambo/Joomla Artikel, Eventkalender, WYSIWYG Editor, Workflow, Templates, G¨ ultigkeitszeitraum Foren, Mediengalerien, Online Hilfe, Integration von RSS Inhalten, Dokumentenmanager, FAQs, Umfragen (Polls), Kalendermodul, Help Desk LDAP Anbindung, ben¨ otigt MySQL

CMS mit einer Reihe von Zusatzmodulen; allerdings keine ACLs daher f¨ ur Kollaboration schlecht geeignet PHP http://www. mamboserver.com/ bzw. http: //www.joomla.org/ GPL


51

Tabelle 3.5. CMS-Vergleich 3/4 Kategorie CMSFunktionen:



Bemerkung:


PHP-Nuke Artikel, Kommentare, Moderation, Banner, Suche, Kategorien, Workflow

Typo3 Artikel, Workflow, WYSIWYG Editor, Versionssystem, G¨ ultigkeitszeitraum, Volltextsuche (PDF, Word, Excel, Powerpoint, . . . ) Umfragen, Personalisierung, Statistiken, Statistiken, Dateimanager, kontextsensitive FAQs, Downloads, Hilfe, Newsletter und eine Dateimanagement, Unzahl an Mailmodul, Zusatzmodulen Newsletter, unterst¨ utzt Staging, Wizard f¨ ur E-Mailformulare RSS und RDF LDAP Anbindung Export; ben¨ otigt geplant; ben¨ otigt MySQL oder MySQL mSQL/PostgreSQL, ... Potenziell das sehr gutes reines“ ” beliebteste Open CMS; evtl. parallel Source Web CMS; zu Groupware; nicht Designschw¨ achen, als Integrationsplattdaher nur sinnvoll form gedacht wenn es alles Ben¨ otigte unmittelbar bietet PHP PHP

Xaraya Artikel, Dokumente, Kritiken, Bilder, Links, Zitate, Downloads, Kategorien

http://phpnuke.org/ http://typo3.de

http: //www.xaraya.com/ GPL

GPL

GPL

FAQs, Berechtigungssystem

ben¨ otigt MySQL, PostgreSQL oder SQLite

junges und aktuell noch nicht zu empfehlendes CMS; hat durchaus Potenzial zu mehr (evtl. u ufen) ¨ berpr¨

PHP

dabei einerseits Typo3 und andererseits XOOPS. Ersteres kann man unmittelbar als CMS System einsetzen und gleichzeitig mit vielen Modulen erweitern. Letzteres hat Schw¨ achen im CMS Bereich ist aber eigentlich schon ein Portal und damit eine Basis f¨ ur Module, von denen es ja auch schon eine Vielzahl gibt. Je nach Einsatzzweck kann selbstverst¨ andlich auch eines der anderen vorgestellten Produkte besser als die beiden herausgehobenen Systeme geeignet sein.

52

3 Vorhandene Open Source Basis Tabelle 3.6. CMS-Vergleich 4/4

Kategorie CMSFunktionen:


Wichtige Anbindungen: Bemerkung:


XOOPS Artikel mit Kommentaren, Downloads, Linklisten, WYSIWYG Editor, Workflow

phpWebSite Artikel mit Kommentaren, Dokumente, Linkmanager, Eventkalender, Workflow, Suche, Kategorien Personalisierung, Foren, FAQs, Foren, Fotogalerie, Umfragen (Polls), Blogs, Umfragen, Generator f¨ ur Kalender, Chat, DMS, Bug Formulare, kontextsensitive Tracking, FAQ, Dateimanager, Hilfe, Mailinglisten, Statistiken, Avantgo Adressverwaltung (WAP/WML2), Adressb¨ ucher, Bildergalerien Integration von RSS Inhalten; Integration von RSS Inhalten ben¨ otigt MySQL Eigentlich fast schon mehr ein CMS mit einer Reihe von Portal als ein CMS; in Folge Zusatzmodulen; allerdings keine guter Startpunkt f¨ ur eine ACLs daher f¨ ur Kollaboration Integration auf PHP Basis eher schlecht geeignet PHP PHP http://www.xoops.org/ GPL

http: //phpwebsite.appstate.edu/ GPL/LGPL

Wenn man schlussendlich zu den Java Systemen blickt, dann ist OpenCMS sicher der Platzhirsch und JBOSS Portal muss im CMS Bereich noch aufholen. Je nach der Weiterentwicklung des JBOSS Portals hat es das Zeug, OpenCMS zu u ugeln. Unmittelbar spricht aber mehr f¨ ur OpenCMS und ¨ berfl¨ auch die Weiterentwicklung dieses Systems scheint gut organisiert zu sein. Gleichzeitig ist JBOSS Portal die bessere Wahl, wenn man in Richtung Portal gehen will (noch mehr als bei PHP im Fall von XOOPS). Nat¨ urlich gibt es noch eine Reihe anderer Java basierter CMS Systeme und es werden auch immer mehr. So ist etwa das zuvor kommerzielle BaseCMP (siehe http://www.basecmp.de) im April 2005 als Open Source unter der GPL Lizenz ver¨ offentlicht worden. Ganz grob k¨ onnte man sagen, dass es ein ähnlich gutes CMS System wie Typo3 ist (sogar mit ACLs), jedoch aktuell keine große Verbreitung vorweisen kann (daher auch nicht näher analysiert wurde). Insgesamt demonstriert dieser Abschnitt wie viele interessante Open Source Systeme verf¨ ugbar sind und allgemein ist es sehr schwierig, eine Empfehlung zu geben. Im Einzelfall sollte man genau analysieren, welche Module man ben¨ otigt und wo die meisten Anforderungen abgedeckt sind. Gleichzeitig muss man auch noch die Integrierbarkeit der möglichen Kandidaten mit potenziellen anderen Systemen bedenken. Auch die technologische Basis (die so-

3.4 Document Management Systeme

53

wieso schon stark bei der Integrierbarkeit hineinspielt) ist ganz wesentlich und ¨ daher gibt es auch entsprechend detaillierte Uberlegungen in Abschnitt 4.3.

3.4 Document Management Systeme Im diesem Abschnitt werden Open Source Systeme beschrieben, die entweder reine DMS Systeme sind oder u ¨ berwiegend in diese Kategorie eingeordnet werden k¨ onnen. Daneben wurden ja schon mehrere Groupware und CMS Systeme pr¨ asentiert, die nebenbei“ DMS Funktionalität beinhalten. ” Generell muss man sagen, dass Open Source DMS Systeme u ¨ berwiegend als kleine standalone Systeme zu finden sind. Solche Vertreter sind damit nur schlecht geeignet, um in ein umfassendes“ KM System integriert zu werden. ” Einige der beschriebenen Produkte k¨ onnen daher eigentlich nur als zusätzliches standalone DMS System dienen, was von einem KM Standpunkt aus bestenfalls ein Zwischenschritt sein sollte (und auch nicht näher beleuchtet wird). Gleichzeitig gibt es aber auch das eine oder andere recht interessante System, das entweder direkt einige Zusatzfunktionen anbietet, leicht integrierbar ist oder einen innovativen Ansatz darstellt. Je nach unmittelbarem Bedarf sollte man daher die Entscheidung f¨ ur ein DMS Produkt von einer Gesamtstrategie abh¨ angig machen. Insbesondere da ja manche CMS beziehungsweise Groupware Systeme ein relativ brauchbares DMS mitbringen (beziehungsweise auch gr¨ oßere Systeme wie wir noch sehen werden). 3.4.1 docman docman ist im Prinzip ein gut 50 Tausend Zeilen langes PHP Skript. Es ist ein kleineres Projekt, das es schon l¨ angere Zeit gibt. Es verwendet eine Art ACL f¨ ur die Berechtigungssteuerung und erlaubt gleichzeitig anonymen Zugriff wenn gew¨ unscht. Das System ist leider nicht auf Mehrsprachigkeit vorbereitet und daher f¨ ur einen Einsatz im deutschen Sprachraum schlecht geeignet. Die Gruppierung der Dokumente erfolgt rein hierarchisch. Es gibt eine konfigurierbare Anzahl an alten Versionen (die wie die aktuelle im Dateisystem gehalten werden). Die Benutzerverwaltung ist recht flexibel gestaltet und erlaubt alternativ die Verwendung von .htuser, POP3/FTP User, LDAP oder eine Abfrage per PHP PEAR (PHP Extension and Add-on Repository) auf eine Datenbank mittels SQL. Weiters gibt es noch ein Check-in/out f¨ ur die ¨ Dateien, Benachrichtigungen u ber Anderungen und Notizen zu den Dokumen¨ ten. Insgesamt also ein simples DMS, das sich auf die Kernaufgaben beschr¨ ankt. Daher ist es vor allem geeignet, wenn man mit einem standalone System unmittelbar oder gar mittelfristig das Auslangen findet und eine englische Software kein Problem darstellt. Aus KM Sicht ist vor allem problematisch, dass man die gespeicherten Daten in jede gew¨ unschte Lösung einbinden

54


m¨ usste. Zwischen April 2004 und dem Zeitpunkt der Recherche hat es auch keine neue Version mehr gegeben. Anders gesagt ist mit Erweiterungen in absehbarer Zeit nicht zu rechnen. 3.4.2 KnowledgeTree Mit KnowledgeTree haben wir ein PHP basiertes DMS mit einem relativ abgerundeten Funktionsumfang vor uns. Die Daten werden in einer MySQL Datenbank gehalten, es gibt eine Versionskontrolle, ein Berechtigungssystem mit Gruppen, Rollen und Organisationseinheiten. Weiters gibt es einen Workflow f¨ ur das Publizieren, erweiterbare Metadaten und ein Archiv (manuell aber auch automatisch aufgrund eines Datums oder der [Nicht-]Verwendung). Operationen wie das Kopieren oder Bewegen von Ordnern können dabei in einer Art Transaktion durchgef¨ uhrt werden. F¨ ur den Zugriff hat man eine hierarchische Struktur und die Möglichkeit nach Kategorie beziehungsweise Dokumenttyp zuzugreifen. Zusätzlich gibt es virtuelle Ordner f¨ ur Dokumente, die bestimmten Kriterien entsprechen. Abschließend hat man auch ein pers¨ onliches Dashboard f¨ ur interessante, ausgecheckte oder auf die Freigabe wartende Dokumente. Zu den Dokumenten kann ¨ man Diskussionsforen einrichten und u benachrichtigt werden. ¨ ber Anderungen Ordnerhierarchien k¨ onnen sowohl exportiert als auch importiert werden. Zus¨ atzlich verwaltet das System auch noch Weblinks sowie Links zwischen Dokumenten und kann mit einem Add-on in einigen Dateitypen suchen. Problemlos funktioniert das mit Excel, PDF, Txt und HTML. Mit Einschränkungen geht es auch mit Word Dokumenten. Ein weiterer Zusatz ist die Möglichkeit, Dokumente aus dem System heraus an Gruppen oder auch Einzelpersonen per E-Mail zu versenden. Die Benutzerverwaltung arbeitet entweder u ¨ ber LDAP (auch MS Active Directory ist m¨ oglich) oder u ¨ber SQL. Aktuell ist das System noch nicht komplett mehrsprachig, wobei an einer italienischen Versi¨ on gearbeitet wird (f¨ ur Deutsch gibt es nur eine kommerzielle Ubersetzung). Insgesamt ein relativ komplettes DMS System, das alle wichtigen Funktionalit¨ aten anbietet und unterst¨ utzt. Durch die offene Datenbank (die Parser f¨ ur die Volltextsuche sind ein Add-on) ist eine lose Integration der Daten in ein anderes System sicher relativ leicht. Eine enge Integration m¨ usste man sich genauer anschauen. Kurz gesagt, ein als standalone System sicher gut geeignetes DMS beziehungsweise als Teil eines lose gekoppelten Systems gut vorstellbar. 3.4.3 NO-SOD: eDMS Auf der Basis des NO-SOD PHP Frameworks gibt es das efficient Document ” Management System“ (eDMS). Generell ein eher simples System mit der Speicherung in einer MySQL Datenbank (im Prinzip sind fast alle von ADOdb unterst¨ utzte Datenbanken m¨ oglich), wo sich auch die Benutzerverwaltung (inklusive Gruppen) befindet.


55

NO-SOD eDMS bietet einen konfigurierbaren Workflow f¨ ur die Freigabe von Dokumenten, der bei Bedarf E-Mails generieren kann. Bei der Erfassung gibt man weiters Schlagw¨ orter beziehungsweise Metadaten an, u ¨ber die man die Dokumente wieder finden kann. Sonst findet man die Dokumente in der zu pflegenden hierarchischen Struktur oder u ¨ber eine Volltextsuche, die Word und PDF Dateien durchsuchen kann. F¨ ur Dokumentenänderungen gibt es eine Versionierung mit Kommentaren sowie Check-in/out Funktionalität. Zusätzlich unterst¨ utzt das System noch einen G¨ ultigkeitszeitraum f¨ ur die verwalteten Objekte. Kurz gesagt ein simples DMS System, das nur die wichtigsten Funktionen unterst¨ utzt. Interessant vor allem durch die Basis des NO-SOD Frameworks. Damit gibt es noch weitere Funktionalit¨ aten, die eng integriert werden können. ¨ Trotzdem ist es bestenfalls eine Ubergangsl¨ osung, wenn man in Richtung einer umfassenden Unterst¨ utzung von KM denkt. 3.4.4 OpenDocMan OpenDocMan ist ein weiteres simples PHP basiertes DMS System. Es bietet die allerwichtigsten Funktionen, es scheint aber keine großen Erweiterungspl¨ ane zu geben. Erschwerend kommt hinzu, dass es keine Internationalisierung hat und damit f¨ ur einen Einsatz im deutschen Sprachraum kaum geeignet ist. Kurz zusammengefasst bietet OpenDocMan eine Speicherung in einer MySQL Datenbank an. Dabei gibt es Check-in/out, Versionskontrolle, einen simplen Workflow, eine Historie sowie Kommentare. Dokumente sind dabei Kategorien beziehungsweise Abteilungen zugeordnet (keiner Ordnerhierarchie) und es gibt alle sinnvollen Rechte (von verboten bis zu Administrationsrechten). Neben einer E-Mail-Benachrichtigung unterst¨ utzt das System noch ein Archiv und eine Suchfunktion. Insgesamt also ein relativ simples DMS, dem leider die f¨ ur den deutschen Sprachraum wichtige Internationalisierung fehlt. Da auch keine größeren Weiterentwicklungen geplant scheinen, kann man dieses System nicht empfehlen. 3.4.5 OWL OWL ist ein weiteres PHP basiertes DMS System. Es bietet die wichtigsten Funktionen an und ist hinsichtlich der notwendigen Datenbank sehr offen (getestet wurden MySQL, Oracle und PostgreSQL). F¨ ur den Zugriff gibt es einerseits eine hierarchische Struktur und andererseits virtuelle Ordner. Das System ist von der Idee her offen f¨ ur eine Selbstregistrierung (macht allerdings im betrachteten Umfeld sicher nur selten Sinn). Gleichzeitig ist auch eine Authentifizierung gegen ein LDAP Verzeichnis möglich. Prinzipiell verwaltet das System Dokumente, URLs und Notizen in einer hierarchischen Struktur. Dazu gibt es eine Versionskontrolle, Check-in/out Funktionalität ur einen Peer Review (also eine Art Workflow). Die und eine Möglichkeit f¨ Rechteverwaltung ist gruppenbasiert und kennt Read/Write/Delete/Download

56


(ACLs sind in Entwicklung). Man kann u ¨ ber Veränderungen wie neue Benutzer oder Dokument- beziehungsweise Ordneränderungen per E-Mail benachrichtigt werden. Eine eher selten umgesetzte Funktion ist die Möglichkeit f¨ ur Benutzer eine Maximalmenge an Speicherplatz festzulegen (eine Quota). Zus¨ atzlich gibt es noch die M¨ oglichkeit, den Inhalt von PDF, Word und ZipDateien in die Suche einzubeziehen (RTF ist in Entwicklung). Interessant ist auch noch die in Umsetzung befindliche M¨ oglichkeit ein Dokument mehreren Gruppen zuzuordnen. Generell handelt es sich bei OWL um ein halbwegs komplettes kleines DMS System. Damit ist es ein Kandidat f¨ ur eine schnelle“ DMS Lösung ” beziehungsweise als standalone Erg¨ anzung zu einem kleineren und lose gekoppelten KM-System“ denkbar. F¨ ur eine größere Lösung ist es dagegen ” schlecht geeignet und sollte in diesem Kontext nicht zum Einsatz kommen. 3.4.6 Paper Harbour Nach den PHP basierten L¨ osungen ist Paper Harbour die erste Java Lösung. Hinter dem System steht die Firma Supporting Technologies Nordic (http: //www.supportingtechnologies.com), die neben Consulting und Support auch die Dokumentation zum System kommerziell vertreibt. Im Gegensatz zu den bisherigen HTML L¨ osungen ist Paper Harbour eine Client/Server L¨ osung. Von der funktionalen Seite her bietet es ein Berechtigungssystem mit ACLs, einen simplen Workflow sowie Check-in/out, ¨ Versionskontrolle und eine Anderungshistorie (auch mit Audit Trail“). Es ” ist weiters m¨ oglich, die Daten verschl¨ usselt abzulegen und Benachrichtigun¨ gen u beziehungsweise auch Dokumente selbst per E-Mail zu ¨ ber Anderungen bekommen. Es wird ein Archiv unterst¨ utzt und man kann Dokumente per Filter, Links oder Suche wiederfinden. Interessant ist auch die Funktion, eine Referenz auf ein Dokument oder einen Ordner (Group genannt) an beliebige Stellen in der Struktur einf¨ ugen zu k¨ onnen. So kann man sicherstellen, dass immer nur eine Version eines Dokuments verwendet wird. Insgesamt eher als standalone Tool beziehungsweise zur losen Ergänzung anderer Systeme geeignet. Insbesondere durch die Geheimniskrämerei“ der ” unterst¨ utzenden Firma bestehen n¨ amlich Zweifel, ob man (selbst) Paper Harbour leicht und effizient in eine gr¨ oßere L¨ osung integrieren könnte. 3.4.7 xinco-DMS xinco-DMS ist das zweite Java basierende DMS System. Es ist das Ergebnis eines Universit¨ ats-Projekts in Deutschland (jetzt ist es ein blueCubs Projekt: http://www.bluecubs.com/). Das Produkt hat sich dabei bis Anfang 2005 sehr schnell entwickelt. Seitdem hat sich das Tempo verlangsamt. Auch xinco-DMS ist eine Client/Server L¨ osung die SOAP (siehe Glossar) als Schnittstelle verwendet. Prinzipiell hat man ein ACL basiertes Berechtigungssystem und dazu eine Versionskontrolle sowie Check-in/out. Mittels


57

des Clients (Explorers) kann man einzelne Dateien oder auch ganze Verzeichnishierarchien in einen xinco Server importieren. Das Wiederfinden geschieht dann u ¨ber Ordner, Dateninhalte, Links, etc. Eine wichtige Funktion ist dabei die Volltextsuche in PDF, Word, Excel, und Powerpoint Dateien. Weiters gibt es die M¨ oglichkeit, Dateien automatisch in ein Archiv verschieben zu lassen (mit entsprechenden Referenzen in xinco-DMS). Interessant ist auch die M¨ oglichkeit ¨ offentliche Ordner zu haben, wo ein Zugriff keine Authentifizierung erfordert. Aktuell ist eine Reihe von wichtigen Erweiterungen wie Diskussionen zu Objekten, ein Workflow, Anbindungen an ERP/. . . Systeme und in weiterer Folge auch ein Webclient sowie eine Mobile (PDA) Anbindung geplant. Damit kann man sagen, dass xinco-DMS mit den geplanten Erweiterungen eine brauchbare standalone L¨ osung darstellt. Aufgrund der verwendeten Technologien scheint eine Integration in ein größeres System durchaus denkbar. Daher sollte man vor einer Entscheidung den aktuellen Stand von xincoDMS u ufen. Je nach Entwicklungsstand und KM Plänen könnte man mit ¨ berpr¨ einem standalone xinco-DMS anfangen und später eine stärkere Integration durchf¨ uhren oder auch gleich in diese Richtung gehen. 3.4.8 jLibrary Eine weitere Alternative stellt das Java basierte jLibrary dar. Es ist (so wie die anderen beiden Java Produkte) eine Client/Server Lösung und stellt ein recht junges System dar. Wie xinco-DMS wird SOAP f¨ ur die Schnittstelle verwendet. Von der funktionalen Seite her bietet es eine Versionskontrolle, eine (eingeschr¨ anktes) Berechtigungssystem mit Gruppen und Rollen, Kategorien und Metadaten. Neben der f¨ ur dieses Buch primär relevanten Möglichkeit das Produkt als Client/Server L¨ osung einzusetzen, gibt es auch die Variante einer lokalen Verwendung, die es auch erm¨ oglicht Dokumente in einer Gruppe zu teilen. Technisch betrachtet basiert der Serverteil der Software auf dem Apache Jackrabbit Projekt (siehe http://incubator.apache.org/jackrabbit/, APL Lizenz), das den JSR 170 Standard implementiert. Damit ergibt sich eine saubere Trennung der beiden Systemteile und die jLibrary Repositories sind dadurch f¨ ur weitere Software offen. Die Datenspeicherung ist in einer Datenbank (die Dokumente k¨ onnen auch im Dateisystem sein) wobei eine Reihe von Systemen wie MySQL, PostgreSQL, Derby, Oracle oder auch IBM DB2 m¨ oglich sind. Dabei werden Dokumente in einer hierarchischen Struktur verwaltet. Weitere Funktionen umfassen die M¨ oglichkeit von Beziehungen/Links zwischen Dokumenten, einer Volltextsuche in PDF, Word, RTF und Powerpoint Dateien, Notizen zu Dokumenten, Import und Export von Hierarchien oder das Abspeichern eines Dokuments mit allen angehänten Ressourcen (etwa Stylesheets zu einer HTML Datei). Interessant ist auch die Möglichkeit eine Webseite mit allen Bestandteilen in das DMS zu u ¨ bernehmen.

58


F¨ ur den Zugriff wird prim¨ ar ein Eclipse (siehe Glossar) basierter Client (also eine Java Applikation) angeboten. Daneben gibt es ein WebDAV Interface, das Jackrabbit zur Verf¨ ugung stellt und den Möglichkeit eines HTML Exports. Das exportierte HTML bietet die Möglichkeit, Daten in der Form eines Extranets“ anbieten zu k¨ onnen. F¨ ur die nächsten Versionen sind wei” tere wichtige und relevante Funktionen wie ein Workflow, Erweiterungen der Volltextsuche, ein vollwertiger Web Client, Verschl¨ usselung und Clustering geplant. Eine abschließende Bewertung von jLibrary ist angesichts des Fehlens einer stabilen Erstversion schwierig. Es handelt sich um ein ambitioniertes Projekt, dass schon eine gewisse Aufmerksamkeit erregen konnte. Durch die Verwendung von Jackrabbit ist bald ein stabiles Backend zu erwarten. Wenn man eine Java L¨ osung integrieren will, ist es sicher einen zweiten Blick wert (insbesondere auch auf den aktuellen Status des Projekts). Besonders wichtig ist dabei die Fragestellung, ob sich eine nennenswerte Entwickler- und Nutzergemeinde herausbilden wird. 3.4.9 Zusammenfassung Insgesamt betrachtet sieht man, dass viele der vorgestellten Systeme einen eingeschr¨ ankten Funktionsumfang haben und/oder sich primär als standalone Lösung eignen. Das ist auch der Grund, warum DMS im weiteren Verlauf des Buches eher als eine Zusatzfunktion behandelt wird. Trotzdem sollte man sich u ¨ ber die Wichtigkeit eines DMS System im Klaren sein. In vielen Firmen ist es äußerst schwierig, Dokumente zu finden, vom Wiederfinden ganz zu schweigen. Das f¨ uhrt oft dazu, dass von veralteten Versionen ausgegangen wird. Generell gibt es also in der Kategorie DMS keine so u ¨berzeugenden Systeme wie bei den Groupware beziehungsweise CMS Systemen. Nichtsdestotrotz gibt es mehrere Systeme, die zumindest die wichtigsten Anforderungen erf¨ ullen und teilweise dar¨ uber hinausgehen. Zur besseren Darstellung gibt es wieder Vergleichstabellen (3.7, 3.8 und 3.9) mit den beschriebenen Systemen. Insgesamt sieht man, dass vor allem KnowledgeTree ein relativ passables DMS System darstellt. Wobei auch bei diesem Produkt die Fragestellung des generellen KM Zielsystems und der Integrierbarkeit von KnowledgeTree beantwortet werden muss. Weiters erscheint auch OWL als sinnvolles System auf PHP Basis, bei dem eine Integration in eine KM Lösung allerdings nicht besonders leicht werden d¨ urfte. Wenn man sich noch die Java Systeme anschaut, hat man gleichzeitig die drei Client/Server Systeme vor sich. Bei Paper Harbour sind die wichtigsten Funktionen vorhanden und ein standalone Einsatz erscheint durchaus eine M¨ oglichkeit, wenn es zum Gesamtkonzept passt. Bei den Möglichkeiten zur Integration sind aber deutliche Fragezeichen angebracht. Der zweite Kandidat, xinco-DMS, hat ein recht interessantes Konzept. Wenn die vorhandenen Ausbaupl¨ ane konsequent umgesetzt werden, d¨ urfte es verglichen mit Paper Harbour das interessantere System sein. Insbesondere m¨ usste es sich


59

Tabelle 3.7. DMS-Vergleich 1/3 Kategorie DMSFunktionen:

Benutzerverwaltung: Zusatzfunktionen:

Datenbanken (getestet): Bemerkung:


Lizenz:

docman Hierarchische Struktur, Versionen, Check-in/out, ACL Zugriffsschutz

KnowledgeTree Hierarchische Struktur & virtuelle Ordner, Versionen, rollen/gruppenbasierter Zugriffsschutz, Metadaten, Archiv, G¨ ultigkeitszeitraum, Workflow .htuser, POP3/FTP LDAP (inkl. User, LDAP oder ActiveDirectory), SQL SQL Notizen zu Diskussionsforen zu Dokumenten, Dokumenten, Benachrichtigungen Benachrichtigungen, Weblinks, Suche in Excel, PDF (und Word) N/A (Dateisystem) MySQL

NO-SOD: eDMS Hierarchische Struktur, Versionen, Check-in/out, ACL Zugriffsschutz, G¨ ultigkeitszeitraum, Workflow, Suche u orter ¨ber Schlagw¨

Simples DMS; nur als standalone L¨ osung eingeschr¨ ankt sinnvoll (auch keine Mehrsprachigkeit!)

Relativ komplettes DMS mit allen wichtigen Funktionen; eine lose Integration erscheint leicht (evtl. auch mehr) PHP

DMS mit den wichtigsten Funktionen; durch NO-SOD Framework als kleine L¨ osung eingeschr¨ ankt denkbar PHP

http://kt-dms. sourceforge.net/

http: //www.no-sod.org/

GPL

GPL/LGPL

PHP http://www.rot13. org/∼dpavlin/ docman.html GPL

SQL

Kommentare zu Dokumenten, Suche in Word und PDF

MySQL

relativ einfach integrieren lassen, da es von vornherein auf offene Standards und Entkoppelung ausgelegt ist (zum Beispiel auch durch die Idee mit unterschiedlichen Clients). Ganz ¨ ahnliches l¨ asst sich auch zu jLibrary sagen, das sich insbesondere durch die Verwendung des JSR 170 Standards hervorhebt. Bei diesen beiden Systemen ist es außerdem wichtig, den aktuellen Entwicklungsstand (auch hinsichtlich der Nutzergemeinde) zu u ufen. ¨berpr¨

60

3 Vorhandene Open Source Basis Tabelle 3.8. DMS-Vergleich 2/3

Kategorie DMSFunktionen:

OpenDocMan Versionen, Check-in/out, ACL Zugriffsschutz, Archiv, Workflow, Suche u ¨ ber Schlagw¨ orter


SQL und NIS/YP


MySQL


Lizenz:

Kommentare zu Dokumenten

Simples DMS ohne deutsche Version; keine gr¨ oßeren Entwicklungspl¨ ane daher nicht zu empfehlen

OWL Hierarchische Struktur & virtuelle Ordner, Versionen, Check-in/out, im Prinzip gruppenbasierter Zugriffsschutz, Workflow (Peer Review) SQL und LDAP

Paper Harbour Versionen, Check-in/out, ACL Zugriffsschutz, Archiv, Workflow, Suche

URLs, Notizen, Benachrichtigungen, Quotas, Selbstregistrierung m¨ oglich, unterst¨ utzt Zip-Dateien, Suche in PDF, Word und Excel MySQL, Oracle, PostgreSQL Kleines“ DMS; als ” schnelle bzw. standalone L¨ osung denkbar

Benachrichtigungen, Verschl¨ usselung, Filter zum Finden von Dateien

PHP

PHP

http://www. opendocman.com/

http://owl. sourceforge.net/

GPL

GPL

SQL

MySQL Kleines“ DMS; als ” schnelle bzw. standalone L¨ osung denkbar (allerdings Geheimniskr¨ amerei“ ” der unterst¨ utzenden Firma) Java http://www. supportingtechnologies. com/ LGPL

3.5 Wichtige Technologien (Portale, Semantische Informationen, KI) In den letzten drei Abschnitten dieses Kapitels wurden die drei wichtigsten Kategorien von Open Source Systemen f¨ ur die Unterst¨ utzung von KM vorgestellt. Sowohl im vorangegangenen Kapitel als auch in den letzten Abschnitten wird gleichzeitig auf andere wichtige Technologien hingewiesen. ¨ Die Uberschrift dieses Abschnitts nennt schon einige Vertreter. Unmittelbar am wichtigsten ist dabei sicher die Portaltechnologie. Im Gegensatz zu

3.5 Wichtige Technologien (Portale, Semantische Informationen, KI)

61

Tabelle 3.9. DMS-Vergleich 3/3 Kategorie DMSFunktionen:




xinco-DMS Hierarchische Struktur, Versionen, Check-in/out, ACL Zugriffsschutz, Archiv, Suche u ¨ber Ordner, Dateien und Links SQL

jLibrary Hierarchische Struktur, Versionen, Locking, ACL Zugriffsschutz, Volltextsuche, Metadaten SQL

Kontakte, URLs, Texte, Import von ganzen Ordnerhierarchien, SOAP als Protokoll zum Server, ¨ offentliche Ordner, Suche in PDF, Word, Excel und Powerpoint Dateien MySQL und PostgreSQL

Notizen und Beziehungen zu Dokumenten, lokaler Betrieb unterst¨ utzt, Import/Export von ganzen Ordnerhierarchien, SOAP/JSR 170 als Protokoll zum Server, Export in HTML MySQL, PostgreSQL, Derby, Oracle, DB2 Interessantes System mit Potenzial f¨ ur eine gute DMS Erweiterung oder standalone L¨ osung; Noch recht jung und nur kleine Entwickler- und Nutzergemeinde; der aktuelle Stand sollte mitbetrachtet werden Java

Mit geplanten Erweiterungen eine sinnvolle standalone L¨ osung, die auch relativ gut integrierbar scheint; je nach Weiterentwicklung evtl. als standalone System oder f¨ ur Integration in gr¨ oßere L¨ osung denkbar Java http://www.xinco.org APL

http://sourceforge.net/ projects/jlibrary BSD

den anderen Punkten repr¨ asentiert sie mehr einen Schl¨ ussel f¨ ur eine sinnvolle Umsetzung und ist per se u berhaupt nicht mit KM verbunden. ¨ Bei Topic Maps und Ontologien geht es dagegen mehr um Begriffe und ihre Zusammenh¨ ange. Entweder in Form von Verkn¨ upfungen oder gar als Begriffshierarchie. Solche Techniken sind zum Teil bei besonders anspruchsvollen Funktionen im Hintergrund und helfen, auf die Daten besser zugreifen zu k¨ onnen. Ein weiterer Begriff in diesem Zusammenhang sind Taxonomien. Dabei handelt es sich um Begriffshierarchien, die heutzutage automatisiert erstellt werden k¨ onnen. Ontologien gehen noch dar¨ uber hinaus. Zu jedem Begriff in der Hierarchie kennt die Ontologie auch die semantische Bedeutung (etwa Zusammenh¨ ange). In beiden F¨ allen ist es häufig notwendig mehrere Auspr¨ agungen gleichzeitig verwenden zu k¨ onnen, um den unterschiedlichen Begriffswelten von unterschiedlichen Bereichen einer Organisation (etwa eines Konzerns gerecht zu werden. Semantic Web stellt kurz gesagt den Versuch dar, die Inhalte eines erneuerten“ WWW f¨ ur Software verst¨ andlich“ zu machen. Anders gesagt ” ”

62


zus¨ atzliche Informationen zu pflegen, mit deren Hilfe Software die Informationen sinnvoll erschließen oder gar intelligente“ Aktionen durchf¨ uhren kann ” (zum Beispiel ein Agent sucht den billigsten Preis und bestellt auch gleich). Im Hintergrund dieser Technologie steht dabei eine Ontologie (womit auch der Zusammenhang zum letzten Absatz offensichtlich wird). K¨ unstliche Intelligenz (KI) ist prim¨ ar eine Technologie, die hinter den Kulissen werkt. Eine im Zusammenhang mit KM besonders wichtige Anwendung ist das Berechnen der inhaltlichen N¨ ahe von Dokumenten (oder auch das Generieren und Aktualisieren von Taxonomien). An dem Beispiel wird schon ersichtlich, dass es f¨ ur eine große“ KM Lösung sehr wichtig ist, KI zu ” verwenden. Hier kann es ¨ ofter sogar Sinn machen, KI selbst als Funktionalität anzubieten (zum Beispiel um Verhaltensmuster der Benutzer zu untersuchen, . . . ). In eingeschränktem Umfang ist KI auch Teil des einen oder anderen vorgestellten Produkts und es gibt auch entsprechende Implementierungen, die man einer L¨ osung hinzuf¨ ugen kann. Nach diesen teilweise schon theoretischen Ausf¨ uhrungen zur¨ uck zu praktisch verf¨ ugbaren Open Source Systemen, die in dem einen oder anderen Kontext ein Zusatz oder eventuell sogar die eigentliche Basis sein können. Im Bereich des Customer Relationship Managements (CRM) gibt es drei sehr interessante Produkte (Compiere, openCRX, SugarCRM), die in einem eigenen Abschnitt n¨ aher vorgestellt werden. Zum Teil gehen die Produkte in Richtung Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Sales Force Automation (SFM) und Business Intelligence (BI). Dabei sind die genannten Begriffe nicht so wichtig (vor allem erfunden in Marketing Abteilungen f¨ ur kommerzielle Software), die entsprechenden Funktionen haben aber eine Menge anzubieten. Eine Einbettung von solchen Funktionalitäten in eine KM L¨ osung macht sehr viel Sinn (vor allem wenn man eine große L¨ osung anstrebt). Dar¨ uber hinaus gibt es eine Reihe von Systemen f¨ ur Spezialgebiete oder als potenzielle Erweiterungen von anderen Produkten. Das geht von einer Digital Library (Greenstone) u ¨ ber Visualisierungstools bis zu Workflow Engines. Funktionale Erweiterungen kann man durch Bulletin Board Software, mächtige PHP Kalender beziehungsweise Wikimodule oder ein Ticket Request System erreichen. Weiters gibt es auch einen Klassifizierer von E-Mails (primär f¨ ur Spam verwendet). Diese Tools, Erweiterungen oder Systeme machen sicher nur in bestimmten Kontexten Sinn, k¨ onnen aber helfen Einzellösungen osung zu erreichen. zu erweitern oder eine integrative Gesamtl¨ Wichtig ist der Hinweis, dass es insbesondere bei potenziellen Erweiterungen oder Systemen, die integriert werden können, unmöglich ist, einen ¨ halbwegs kompletten Uberblick zu geben. Die Anzahl der in Frage kommenden Systeme ist einfach viel zu groß. Daher werden nur besonders geeignete beziehungsweise dem Autor aufgefallene Produkte näher beschrieben.


63

3.5.1 Portale Leider gibt es keine genaue Definition, was ein Portal ist. Generell geht es darum, Informationen und Funktionen in einer Oberfläche zu integrieren. Damit könnte man eigentlich auch alle Communityportale“ dazurechnen. Es ist im ” Kontext dieses Buches zum Gl¨ uck nicht notwendig, eine Unterscheidung zu treffen. Wichtig ist vor allem, ob sich ein System besonders gut zur Integration eignet. Schließlich ist das die Hauptaufgabe von Portalen. Eine Kernfunktionalit¨ at von Portalen ist auch noch Personalisierung und damit einhergehend eine fein steuerbare Zugriffsbeschr¨ ankung auf Inhalte. Auf PHP basierend kommt das schon vorgestellte XOOPS einem Portal am N¨ achsten. Im Weiteren werden noch zwei Java basierte Portalsysteme vorgestellt (es gibt nat¨ urlich noch viel mehr Vertreter und die eXo Platform: http://www.exoplatform.com/ ist auch relativ beliebt). Dabei handelt es sich um das Apache Projekt Jetspeed und um Liferay. Beide implementieren schon den Java Portlet Standard JSR 168 (wie auch das JBOSS Portal). Jetspeed (http://portals.apache.org/jetspeed-2/index.html) hat sich auf die Fahnen geheftet, ein Enterprise Information Portal (EIP) zu sein. Dabei wird auf Java und XML (eXtensible Markup Language) vertraut. F¨ ur die Datenbankabstraktion und als Komponentenmodell wird seit Version 2.0 Spring verwendet (ein J2EE Framework Business Layer; siehe http://www. springframework.org/). F¨ ur Inhalte und die Integration von Funktionen gibt es HTML, JSPs, Java Applets und insbesondere Portlets des JSR 168 Standards. Dar¨ uber hinaus existiert eine Integration der Frameworks Cocoon, WebMacro und Velocity (andere Apache Projekte). Zu Struts, Java Server Faces (JSF), PHP und Perl gibt es sogenannte Brigdes. Weitere Anbindungen erm¨ oglichen die Unterst¨ utzung von RSS, WAP und PDAs mittels Avantgo. Zus¨ atzlich zu den vorhandenen Integrationsmöglichkeiten gibt es auch einige vorhandene Portlets. Aktuell etwa einen Kalender oder einen Datenbank Browser neben Portlets, die das direkte Einbinden von anderen Webinhalten erm¨ oglichen. Wie praktisch alle Apache Projekte verwendet es die APL Lizenz und ist außerdem recht flexibel, was die Datenbank angeht (Derby, HyperSonic, IBM DB2, MySQL, Oracle, PostgreSQL, . . . ). Dar¨ uber hinaus wird eigentlich nur noch ein Servlet Container (zum Beispiel Tomcat) benötigt aber kein Application Server (wobei insbesondere IBM WebSphere und JBOSS unterst¨ utzt werden). Die Authentifizierung kann dabei gegen ein LDAP Verzeichnis erfolgen und beruht auf einem Konzept mit Rollen und Gruppen. Weiters stellt Jetspeed den eingebundenen Komponenten einen Single Sign-On Mechanismus zur Verf¨ ugung. Auch das JAAS API wird unterst¨ utzt. Dar¨ uber hinaus ist der Betrieb als Cluster m¨ oglich (auf Java JMS basierend), um höchsten Anforderungen an die Verf¨ ugbarkeit gen¨ ugen zu können. ur Bei Liferay (http://www.liferay.com/) handelt es sich um ein Portal, f¨ das es schon eine Reihe von Modulen gibt. Im Gegensatz zu Jetspeed basiert es auf dem kompletten J2EE Standard inklusive EJBs und benötigt daher in der Standardversion einen Application Server (wobei die Open Source Pro-

64


dukte JBOSS und JOnAS unterst¨ utzt werden). Eine abgespeckte“ Version ” läuft auch mit einem Servlet Container (Jetty oder Tomcat). Einerseits gibt es die M¨ oglichkeit der Integration von Funktionalitäten durch das Portlet API JSR 168 und andererseits gibt es prim¨ ar drei Möglichkeiten der Anbindung, n¨ amlich SOAP, RMI (siehe Abschnitt 4.3.4 f¨ ur mehr Informationen zu diesem Begriff) und ein propriet¨ ares Tunneling“ Protokoll. F¨ ur die Generierung ” von HTML wird Struts verwendet, f¨ ur WML Axis (beides von Apache) und f¨ ur den Rest das sogenannten Tunnel Servlet“. Daneben gibt es noch Un” terst¨ utzung f¨ ur die Verwendung von Java Server Faces (JSF) und dem Spring Framework f¨ ur die Entwicklung eigener Komponenten. Unmittelbar verf¨ ugbar sind Portlets f¨ ur Mail, eine Dokumentensammlung (⇒ DMS), Bildergalerien, ein Kalender, Foren, ein Wiki sowie ein Online Shop Modul. Neben den schon angesprochenen Zugriffsm¨ oglichkeiten (HTML, WML, J2ME/SE/EE) gibt es auch noch eine Liferay Toolbar, die es erlaubt, die Portalfunktionen direkt vom Desktop aus zu nutzen. Bei den Datenbanken werden eigentlich alle wichtigen unterst¨ utzt (zum Beispiel MySQL, PostgreSQL, MaxDB [fr¨ uher SAP DB], IBM DB2, Oracle, MS SQL Server). Als Lizenz kommt die MIT License zu Einsatz. Man sieht, dass beide Produkte konzeptionell gut durchdacht sind und eine fundierte Basis f¨ ur eine Integration auf Java Basis bieten können. Bei Liferay bekommt man mehr Funktionen direkt geliefert und kann auch die Dienste der Liferay LLC. in Anspruch nehmen. Bei Jetspeed sieht man die Verwendung beziehungsweise Integration von vielen beliebten Apache Systemen. Damit wird man eine ganze Reihe von Funktionalitäten finden können, die man unmittelbar im Portal ausf¨ uhren kann. Besonders wichtig ist nat¨ urlich, dass beide schon das Portlet API (JSR 168) unterst¨ utzen. Neue Entwicklungen sollte man m¨ oglichst unabh¨ angig machen, damit auch ein späterer Wechsel der Ausf¨ uhrungsplattform noch m¨ oglich ist. Insbesondere wenn man ein relativ großes“ KM System plant, sollte man ” sich n¨ aher mit Portalen besch¨ aftigen und ihren Einsatz u ¨ berlegen. Je klei” ner“ die unmittelbar oder mittelfristig angestrebte Lösung ist desto eher wird man sich die zum Teil unvermeidbare Komplexität eines Portal Servers nicht antun“ wollen. ” 3.5.2 Topic Maps & Ontologien Bei Topic Maps, Taxonomien und Ontologien geht es weniger darum, einzelne Systeme oder Technologien zu verwenden. Gleichzeitig gibt es selbstverständlich auch daf¨ ur Open Source Software. Ein Beispiel daf¨ ur ist Nexist, eine Referenzimplementierung f¨ ur Topic Maps in Java (auf dem ISO Standard basierend) oder TM4J. Bei Ontologien und Taxonomien gibt es zum Beispiel Ergebnisse von EU-Projekten als Open Source. Insgesamt betrachtet gibt es in diesem Bereich aber weniger direkt einsetzbare Open Source Software. Auch bei kommerziellen Systemen arbeiten diese Technologien eher im Hintergrund, soweit sie u ¨ berhaupt zum Einsatz


65

kommen. Es handelt sich n¨ amlich insbesondere bei Ontologien um ein relativ junges Thema f¨ ur die IT und dementsprechend wenig Standardsoftware“ gibt ” es. Gleichzeitig ist es auch ein sehr schwieriges Thema und eine hochqualitative Ontologie zu erstellen ist ein zeitaufwendiges und kostspieliges Unterfangen (ein weiterer Grund f¨ ur die langsame Verbreitung entsprechender Technologien). Es zeigen sich auch bei schon bestehenden Implementierungen Probleme etwa durch die fehlende Unterst¨ utzung von mehr als einer Sprache in einer Topic Map. An diesem einfachen Beispiel sieht man schon, dass hier noch einiges an Arbeit ansteht. Daher handelt es sich bei diesen Technologien um sehr interessante Entwicklungen. Man sollte auf jeden Fall einen näheren Blick darauf werfen. Gleichzeitig gibt es aktuell nur wenige unmittelbar einsetzbare Systeme und auch daf¨ ur fehlt h¨ aufig die hochqualitative Basis (etwa eine Ontologie). Daher werden entsprechende Open Source Tools nur im dazugehörigen Abschnitt 8.1 kurz vorgestellt. 3.5.3 Semantic Web Der Erfinder des WWW, Sir Tim Berners-Lee, hat 2001 (in [4]) seine Vision eines weltweiten Netzes vorgestellt, in dem Software intelligent“ agieren ” kann. Dabei geht es darum, interoperable Standards zu verwenden und die Bedeutung einer Webseite zu beschreiben (mit Ontologien). Konkret bedeutet das die Verwendung von XML basierten Standards wie RDF (Resource Description Framework) f¨ ur die Eigenschaften oder der Web Ontology Language (OWL) f¨ ur Ontologien. Dabei stellt OWL bis zu einem gewissen Grad eine Erweiterung“ von RDF dar und basiert selbst wiederum auf der DAML+OIL ” Web Ontology Language. Damit gibt einem das Semantic Web unmittelbar die notwendigen Standards an die Hand. Allerdings gibt es weiterhin das Problem mit passenden Ontologien und vor allem ist es extrem schwierig und problematisch, mit verschiedenen Ontologien zu arbeiten. Es gibt dabei vor allem das Problem, zu erkennen welche Begriffe von unterschiedlichen Ontologien wie miteinander in Beziehung stehen. Dieses Problem ist nat¨ urlich bekannt und es wird daran gearbeitet sowohl theoretische als auch praktische Lösungen zu finden (dazu in Abschnitt 8.1.1 mehr). Insgesamt betrachtet stellt das Semantic Web eine der spannendsten und wichtigsten Entwicklungen im Moment dar. Innerhalb einer Organisation ist die Notwendigkeit aber meist nicht besonders hoch. Gleichzeitig sollte man eigene ¨ offentliche Angebote entsprechend des Semantic Web anbieten. Weiters sollte man die Entwicklung beobachten, da vor allem in der Zusammenarbeit zwischen Organisationen ein großes Potenzial f¨ ur Vereinfachung besteht. Auch beim Semantic Web gibt es noch relativ wenig wirklich empfehlenswerte Open Source Software. Daher wird darauf in Abschnitt 8.2 und nicht hier eingegangen.

66


3.5.4 K¨ unstliche Intelligenz Wie schon kurz andiskutiert, ist KI meist eine Technologie hinter den Fassaden. Es geht prinzipiell darum, Dinge herauszufinden, die vorher nicht bekannt waren beziehungsweise alternativ um eine Automatisierung. Ein aktuell besonders wichtiges Thema ist etwa die Bek¨ ampfung von Spam E-Mails, die zum Teil auf entsprechenden Techniken basiert. Beispiele sind dabei die Open Source Websuite Mozilla, der E-Mail Client Thunderbird oder das Tool POPFile, die unter anderem sogenannte Bayes Klassifizierer benutzen, um Spam als solchen zu erkennen. Andere Beispiele sind die Generierung von Taxonomien, die Erkennung von inhaltlich ¨ ahnlichen Dokumenten oder auch das Analysieren des Kundenverhaltens. Als Beispiel werden sicher viele Leser den Online Shop von Amazon kennen, der an vielen Stellen Artikel zeigt, die andere Kunden gekauft oder angesehen haben, nachdem sie auf der aktuell angezeigten Seite waren. Man erkennt also schnell die Wichtigkeit von den entsprechenden Algorithmen (bei denen gleichzeitig der Begriff Intelligenz eigentlich nicht angebracht erscheint). Eine Einf¨ uhrung in das generelle Thema bietet die Unterlage von Petrak [46] oder das sehr gute Buch von Mitchell [40]. An den kurz angerissenen Beispielen sieht man auch was einem prinzipiell f¨ ur Möglichkeiten offen stehen. Man kann vorhandene Inhalte einordnen beziehungsweise in Zusammenhang setzen. Einerseits um die vorhandenen Informationen besser nutzen zu k¨ onnen und andererseits um den Kunden zielgerichteter bedienen zu k¨ onnen. Mit beiden Aktivit¨ aten kann man bei erfolgreicher Umsetzung die Kundenzufriedenheit und den Umsatz erh¨ ohen. Weiters sollte es auch möglich sein, intern die Kosten zu senken, da die Mitarbeiter produktiver arbeiten können. Wenn man in Richtung Open Source blickt, dann gibt es ein sehr umfangreiches Paket namens WEKA (http://www.cs.waikato.ac.nz/ml/), dass prim¨ ar von einer neuseel¨ andischen Universität (Waikato) entwickelt wird (nähere Informationen findet man im Buch von Witten und Frank [63]). Es bietet alle wichtigen Algorithmen und geht noch dar¨ uber hinaus. Die Implementierung in Java erm¨ oglicht gleichzeitig eine relativ einfache Einbindung in viele Systeme. Vor allem nat¨ urlich in eine Java Architektur aber auch zum Beispiel f¨ ur ein PHP System ist es besser, als wenn man erst eine Portierung auf das Zielsystem machen m¨ usste. Insbesondere bei größeren Projekten sollte man unbedingt die vorhandene Datenbasis entsprechend bearbeiten. Je nach vorhandener Information und Know-how kann man den Code hinter den Kulissen“ einsetzen oder direkt auf die Suche nach (zum Beispiel) neuen ” Zusammenh¨ angen gehen. Zusammengefasst stellt KI prim¨ ar eine Technik hinter den Kulissen dar. Sie wird in vielen Systemen schon unmittelbar eingesetzt und bei größeren KM Systemen sollte man die Technik auf jeden Fall nutzen. Daf¨ ur steht mit dem ugung, die alle wichtigen WEKA Toolkit eine ausgezeichnete Basis zur Verf¨ alt. Algorithmen in guter Qualität enth¨


67

3.5.5 Weitere verf¨ ugbare Open Source Software Wie schon am Beginn dieses Abschnitts erw¨ ahnt, gibt es eine Reihe von Open Source Systemen, die je nach unmittelbarer Stoßrichtung einer KM Initiative n¨ aher beleuchtet werden sollten. Besonders relevant sind dabei CRM Systeme. Es handelt sich zwar um drei relativ unterschiedliche Systeme, die aber doch Einiges gemeinsam haben. (Eine weitere PHP Lösung namens XRMS ist aktuell gerade in Entwicklung und kann in weiterer Folge ebenfalls in Betracht kommen. Gleichzeitig gibt es schon einige Anwender und bei weniger umfassenden Anforderungen sollte man einen Blick darauf werden. Nähere Dateils findet man unter: http://xrms.sourceforge.net/.) Dar¨ uber hinaus wird in diesem Abschnitt noch auf eine Reihe von Einzelsystemen oder Modulen und zwei Workflow Engines, die insbesonders f¨ ur sehr strukturierte Aufgaben helfen k¨ onnen, eingegangen. Compiere Bei Compiere handelt es sich nach eigener Aussage um ein ERP und SCM System, das auch f¨ ur CRM Unterst¨ utzung bietet (siehe http://www.compiere. org/). Entsprechend seinem Anspruch handelt es sich also um eine Art MiniSAP, das den klassischen Kern eines Unternehmens elektronisch abbildet. Der Fokus der L¨ osung liegt dabei auf kleinen bis mittleren Unternehmen, wie man auch in der Referenzliste sehen kann. Konsequenterweise bietet es daher Kontakte, Produktverwaltung, Buchhaltung, Inventarisierung, Bestellungen, Anschaffungen, Projekte und einen Webshop mit den wichtigsten Funktionen. Nat¨ urlich bietet es die Möglichkeit, mehrere Organisationen in mehreren Sprachen, Buchhaltungsregeln (zum Beispiel GAAP) und mit unterschiedlichen Steuersätzen und Währungen zu verwalten. Weiters existiert eine Menge an vordefinierten Berichten und man hat die M¨ oglichkeit, selbst welche zu erstellen (zum Beispiel mit OLAP Analysen). Compiere unterst¨ utzt diverse Import und Export Funktionen und dabei etwa die Formate OAGIS und OFX (EDI ist geplant genauso wie die J2EE Connector Architecture). Eine weitere Funktion ist die Unterst¨ utzung f¨ ur Marketingkampagnen, bei denen man die Kunden auswählen und das Ergebnis verfolgen kann. Technisch betrachtet ben¨ otigt das System einen J2EE Application Server (zum Beispiel JBOSS) und ben¨ otigt aktuell eine Oracle 10g oder Sybase ASE 12.5 Datenbank. Es wird auch daran gearbeitet, zusätzlich eine Open Source Datenbank (Derby) zu unterst¨ utzen (beziehungsweise gibt es unabh¨ angige Projekte, die bestimmte Compiere Versionen auf einer Open Source Datenbank zum Laufen gebracht haben). Gleichzeitig muss man im Moment entweder mit der kostenlosen Sybase Version f¨ ur Linux das Auslangen finden oder eine potenziell recht teure Lizenz von Oracle oder Sybase kaufen und damit ist das Ergebnis kein reines Open Source System (wobei aktuell eine Version mit Support und Lizenz f¨ ur 10 interne Benutzer schon

68


ab $1500 zu haben ist). F¨ ur den PDF-Druck wird ebenfalls eine kommerzielle Lizenz ben¨ otigt, die separat zu kaufen ist, wenn man keinen entsprechenden Supportvertrag mit Compiere Inc. abschließt. Ein Java Client stellt das Benutzerinterface zur Verf¨ ugung. Diesen kann man entweder direkt ausf¨ uhren oder mit Java Web Start u ¨ber einen Browser laden und starten. Alternativ gibt es noch einen reinen HTML Client. Die geltende Lizenz ist dabei die MPL (Mozilla Public License). Insgesamt bietet Compiere eine ganze F¨ ulle von Funktionen. Damit stellt es eine fast komplette Infrastruktur f¨ ur eine Firma dar. Vieles davon ist nicht relevant f¨ ur KM. Gleichzeitig ist der K¨ onigsweg aber ein komplett integriertes System, damit KM Funktionen die gesamte Datenbasis einer Organisation ber¨ ucksichtigen können. Daher w¨ urde eine große Lösung die Funktionen eines Compiere mit einer Groupware und einem CMS integrieren. Wenn so eine Kombination auf KM ausgerichtet wird, ist das alleine schon eine große Leistung. Aufbauend darauf ist dann noch viel mehr möglich. Bei Compiere und auch den folgenden zwei Systemen stellt sich also vor allem die Frage, ob es m¨ oglich und sinnvoll ist, sie miteinzuf¨ uhren. Wenn ja, dann sollte man sich entsprechend Zeit nehmen und kann mit einer integrierten L¨ osung sicher dramatisch an Kosten einsparen und gleichzeitig den Mitarbeitern eine weit u ugung ¨ berdurchschnittliche IT Infrastruktur zur Verf¨ stellen. openCRX Ein j¨ ungeres Produkt mit einem teilweise anderen Ansatz ist openCRX (siehe http://www.opencrx.org/). Technisch betrachtet basiert es auf einer MDA (Model Driven Architecture) und benutzt damit einen State-of-the-Art“ Ent” wicklungsprozess. Aus einer funktionalen Sicht bietet es schwerpunktmäßig CRM Funktionen. Gleichzeitig werden aber auch noch eine Menge von weiteren Aspekten abgedeckt. Es bietet eine Kontakt- beziehungsweise Produktverwaltung (inklusive Produktb¨ undeln) und Unterst¨ utzung f¨ ur den Vertriebsprozess beginnend bei den so genannten Leads bis hin zu der Rechnungsausstellung. Weiters werden alle m¨ oglichen Aktivit¨ aten wie die Benutzerbetreuung (Support) oder eine Vielzahl an Berichten (Reports) unterst¨ utzt. Hervorzuheben sind auch noch die M¨ oglichkeiten f¨ ur alternative Darstellungen der vorhandenen Daten beziehungsweise Auswertungen. Damit kann man eine Art integrierte Sicht bekommen, die als Ergebnis ein Kontaktmanagement mit einer Sales Force Automation, einem Kampagnenmanagement (Marketing, etc.) und einem Servicemanagement bietet. Kurz gesagt also eine komplette Sicht u ¨ ber die vertriebsrelevanten Aspekte mit Hinblick auf die Sales Force Automation. Dar¨ uber hinaus bietet openCRX auch diverse Möglichkeiten f¨ ur Import und Export (etwa vCard und XML) oder Workflowunterst¨ utzung (inklusive des automatischen Versendens von E-Mails) an. In diesem Zusammenhang gibt es etwa die Funktion eine Word Vorlage mit Daten aus openCRX zu


69

bef¨ ullen (etwa Kontaktdaten f¨ ur einen Brief). Weiters kann man auch Aufgaben, Dokumente und Probleme (Bugs/Incidents) im System verwalten. F¨ ur IT Firmen k¨ onnte auch die Unterst¨ utzung der OMG (Object Management Group) Reusable Asset Specification“ zur Verwaltung von Softwarekompo” nenten interessant sein. Nat¨ urlich gibt es ein ausgefeiltes Berechtigungssystem mit einem Single Sign-On Mechanismus zum Wechsel zwischen Organisatio¨ nen und eine Anderungshistorie ( Audit Trail“). ” Neben den schon vorhandenen Funktionen wird das System auch sehr schnell weiterentwickelt. Aktuell ist etwa eine Offline Unterst¨ utzung, ein Kalender, Unterst¨ utzung f¨ ur Projekte (von der Planung bis zur Rechnung) oder die Integration mit Outlook, Exchange, Lotus Notes, SAP (R/3), Peoplesoft und Siebel geplant. F¨ ur die Benutzung gibt es einerseits eine web-basierte Möglichkeit und andererseits einen .NET Client. Mit Letzterem kann man die Funktionen in die ja sehr h¨ aufig verwendeten Microsoft Produkte Office und/oder Outlook einbinden. Als Alternativen kann man auch Lotus Notes oder einen Java Client verwenden. Dar¨ uber hinaus gibt es auch noch einen Offline Client, was insbesondere f¨ ur Vertriebsmitarbeiter unterwegs eine sehr wichtige Sache ist. Aus einer mehr technischen Sicht heraus betrachtet, ist noch die flexible Unterst¨ utzung von Plug-ins interessant. Unmittelbar verf¨ ugbar sind hier Module f¨ ur Sicherheits- und Nachvollziehbarkeitsaspekte (wichtig etwa f¨ ur eine Revisionssicherheit). Dieser Aspekt ist auch f¨ ur eine potenzielle Integration in ein KM System von großer Relevanz. Zus¨ atzlich wichtig sind auch noch die vorhandenen Schnittstellen und Adapter. Einerseits ben¨ otigt ein CRM System selbst die Daten von einer Reihe von anderen Systemen. Andererseits muss es auch entsprechende Informationen zur Verf¨ ugung stellen. Hier bietet openCRX relativ umfassende Möglichkeiten. Zum Einen werden aktuelle Standards wie J2EE/EJB, CORBA (siehe Abschnitt 4.3.4 f¨ ur mehr Informationen zu CORBA), Web Services (siehe Abschnitt 4.3.4 f¨ ur mehr Informationen zu diesem Begriff) beziehungsweise HTTP direkt unterst¨ utzt. Zum Anderen gibt es auch noch Adapter zu solch wichtigen Programmiersprachen beziehungsweise Technologien wie SAP BAPI, CORBA, IBM WebSphere MQSeries und WebSphere selbst, BEA Tuxedo oder der J2EE Connector Architecture (JCA). agungen. Die ältere Das openCRX System gibt es dabei in zwei Auspr¨ und f¨ ur dieses Buch interessantere ist eine Java basierte, die einen J2EE Application Server ben¨ otigt (zum Beispiel JBOSS, BEA WebLogic oder IBMs WebSphere). Als Datenbank kommt f¨ ur diese Variante etwa eine MySQL, PostgreSQL, Firebird (Open Source Variante von InterBase), die MaxDB (Open Source Version der SAP Datenbank), eine Oracle oder IBMs DB2 in Frage. Die neuere Variante basiert auf .NET und benötigt (nicht weiter u ¨ berraschend) den Microsoft IIS Web Server, den SQL Server als Datenbank und das .NET Framework als Basis. Die anzuwendende Open Source Lizenz ist BSD basiert.

70


Wenn man versucht einen groben Vergleich mit Compiere zu ziehen, dann ¨ werden zum Teil andere Funktionen angeboten zum Teil gibt es Uberschneidungen. Damit wird eine Entscheidung typischerweise eher aufgrund der wichtigen Funktionen als aufgrund von technischen Fragen zu treffen sein. Insgesamt betrachtet handelt es sich bei openCRX um einen integrierten Ansatz mit einer sehr offenen Architektur. Gleichzeitig ist es noch ein relativ junges System, wo einem da und dort Flexibilität abgeht (wenn etwa gewisse Dinge nur in einer Konfigurationsdatei ge¨ andert werden können). Funktional stehen eindeutig CRM Aspekte im Vordergrund. SugarCRM SugarCRM (beziehungsweise Sugar.Sales) ist der Versuch ein komplettes CRM System auf PHP Basis zu entwickeln (siehe http://www.sugarcrm. com/). Dahinter steht eine neue Firma in den USA, die Venture Capital f¨ ur die Entwicklung nutzt. Damit befindet sich das System in starker Weiterentwicklung und der dargestellte Stand sollte damit unbedingt auf Aktualität u uft werden, wenn es ein m¨ oglicher Kandidat ist. ¨ berpr¨ Was sind jetzt die Funktionen von SugarCRM? Nat¨ urlich die Kontaktverwaltung. Weiters die Unterst¨ utzung des Vertriebsprozesses durch eine Kontakt-, Aktivit¨ aten- und Aufgabenveraltung, die es ermöglicht alle Informationen (Telefonanrufe, E-Mails, Besprechungen, etc.) zum Kunden abzulegen. Zus¨ atzlich kann man noch Notizen und Dateien anhängen. Zur besseren ¨ Ubersicht werden ein sogenanntes Dashboard mit einer grafischen Darstellung von Vertriebschancen im Hinblick auf den Vertriebsprozess oder eine Branche angeboten. Dar¨ uber hinaus gibt es Workflows und ein Projekt- und Dokumentenmanagement, um die Verkaufsprozesse sowohl organisatorisch als auch mit den richtigen Unterlagen zu unterst¨ utzen. Auch ein Gruppenkalender mit Synchronisationsm¨ oglichkeit etwa zu Microsoft Outlook und dem Apple iCal Programm ist vorhanden. Verkaufskampagnen werden einerseits administrativ sowie organisatorisch und andererseits auch u utzt. Nicht nur aber ¨ ber E-Mail Aussendungen unterst¨ auch in diesem Zusammenhang sind automatische Nachrichten (Reminder) interessant. Weiters gibt es eine Reihe von m¨ oglichen Listen und Reports und ein rollenbasiertes Berechtigungssystem. Wichtig ist auch noch der Import von Daten anderer CRM System (wie etwa Salesforce.com, ACT, Microsoft CRM) sowie eine generelle M¨ oglichkeit f¨ ur den Import und Export von Kontaktdaten. Es gibt auch eine Integration eines Mambo Portals“, das etwa als Online Shop ” oder als Frontend f¨ ur die Kunden (unter anderem f¨ ur die offenen Probleme) eingesetzt werden kann. F¨ ur den Benutzer gibt es einen sogenannten Home Screen mit den wichtigsten Vertriebschancen (Opportunities), der Pipeline, Besprechungen und Aufgaben. Informationen k¨ onnen u ¨ber Themen und eine u ¨ bergreifende Suche gefunden werden. Dabei werden HTML und eine Reihe von Dateiformaten einbezogen. Technisch beruht das System wie schon gesagt auf PHP und benötigt


71

eine MySQL Datenbank (>= 4.0). Als Lizenz wird eine MPL basierende verwendet. Erweitern kann man das System mit einem kommerzielles Plug-in f¨ ur Microsoft Word beziehungsweise Outlook, das es ermöglicht E-Mails zwischen den beiden Systemen zu synchronisieren. Kurz gesagt stellt SugarCRM eine relativ interessante Entwicklung auf PHP Basis dar. Schon jetzt bietet das System eine ganze Reihe von interessanten Funktionen und die Weiterentwicklung geschieht aktuell sehr schnell. Verglichen mit den anderen beiden Systemen gibt es sicher noch einen gewissen Aufholbedarf (zumindest bei Details). Gleichzeitig ist es das einzige PHP basierte System und damit besonders interessant, wenn ein komplett auf PHP aufbauendes System angedacht oder geplant ist (was auch die vorhandene Mambo- Integration“ unterstreicht). ” Digital Library Auf ein relativ beliebtes und verbreitetes Digital Library System soll ebenfalls eingegangen werden. Es handelt sich dabei um das Produkt Greenstone (siehe http://www.greenstone.org/). Generell bietet es die Möglichkeit, verschiedene Sammlungen elektronisch zu erfassen und vor allem interessante Eintr¨ age zu finden. Eine unmittelbare Anwendung findet man in B¨ uchereien, die zu allen angebotenen Medien entsprechende Daten erfassen. Die Digital Library erm¨ oglicht dann den Benutzern, alle relevanten Einträge zu finden. Schon diese Anwendung kann durchaus Sinn machen, wenn entsprechende Medien zu verwalten sind (selbst wenn es nur um die Erfassung der vorhandenen Fachb¨ ucher und Anleitungen geht). Noch deutlich spannender“ wird es, wenn es sich um elektronische Do” kumente handelt. Greenstone ist dabei in der Lage, unterschiedliche Formate (PDF, Microsoft Office, HTML, Tex, PostScript, E-Mail, Bilder, Bibliographien, etc.) direkt zu verarbeiten und alle Inhalte zur Verf¨ ugung zu stellen. Insbesondere kann dies die effizienteste M¨ oglichkeit sein, eine größere externe Dokumentensammlung zur Verf¨ ugung zu stellen. Wichtig dabei ist, mächtige Suchfunktionen zur Verf¨ ugung zu haben. Dar¨ uber hinaus gibt es auch noch eine thematische Zuordnung u ¨ ber eine Begriffshierarchie (im Prinzip also zumindest einer Taxonomie). Das Beispiel Greenstone ist dabei in den Programmiersprachen Perl, C++ und Java realisiert (wobei gerade die Version 3.0 in Java und unter Verwendung von XML neu geschrieben wird). Als Lizenz kommt die GPL zum Einsatz. Damit kann man es problemlos zum Einsatz bringen und bei entsprechendem Bedarf in dieser Richtung sicher in eine größere Lösung integrieren. Visualiseriungstool Ein wichtiger Punkt k¨ onnen auch spezielle Visualierungstools sein. Nat¨ urlich bringen alle beschriebenen Systeme mit einer Benutzerschnittstelle schon Funktionen zur Visualisierung mit. Gleichzeitig gibt es f¨ ur viele Gebiete keine

72


optimale Darstellungsart. Ein Beispiel f¨ ur eine entsprechende Software stellt der am Frauenhofer IAO Institut in Deutschland entwickelte Matrixbrowser dar (siehe auch http://matrixbrowser.hci.iao.fraunhofer.de/). Dieser spezielle Browser erlaubt es, verschiedene Beziehungen zwischen unterschiedlichen Knoten zu erforschen. Einerseits gibt es eine sternartige Darstellung und andererseits eine Art 2D Darstellung in der Art einer Tabelle. Die Begriffe sind die Spalten- beziehungsweise Zeilen¨ uberschriften und dazwischen gibt es verschiedene Verbindungen (oder eben auch nicht). Gleichzeitig sind die Begriffe Teile von Begriffshierarchien, die man sozusagen hierarchisch ein- und ausblenden kann. Dadurch kann man sich genau auf die interessanten Bereiche konzentrieren und dort in die Tiefe gehen. Ein wichtiger Aspekt dabei ist die andere Sichtweise verglichen mit 08/15 Darstellungen in anderen Systemen. Die Programmiersprache des Systems ist Java und die Lizenz ist die IAO License. Diese stellt keine echte Open Source Lizenz dar, erlaubt aber zum Beispiel die Verwendung in internen Projekten. Insgesamt zeigt einem der Matrixbrowser eine alternative Darstellung und kann potenziell auch in Java Projekten integriert werden. Gleichzeitig sind solche erweiterten Visualiserungsm¨ oglichkeiten eher in späteren Phasen sinnvoll und k¨ onnen meist bei den ersten Versionen weggelassen werden. Trotzdem sollte man bei jedem System zuerst eine entsprechende Analyse durchf¨ uhren und nach Einf¨ uhrung u ufen, ob weitere Darstellungsvarian¨berpr¨ ten hohen Nutzen bringen. Workflow Engines Workflowunterst¨ utzung bieten einige der schon beschriebenen Produkte. Entsprechende relativ standardisierte Arbeitsabl¨ aufe findet man in fast allen Organisationen. Gleichzeitig gibt es einerseits eine Reihe von Systemen ganz ohne Unterst¨ utzung beziehungsweise sind vorhandene Funktionen meist f¨ ur einfachere Abl¨ aufe gedacht. F¨ ur dar¨ uber hinausgehende Anforderungen ist es daher oft notwendig, eine m¨ achtigere“ Workflow Engine einzubinden. Zwei ” Beispiele daf¨ ur sind OpenWFE und OSWorkflow. OpenWFE ist eine Engine, die auch einen simplen Webclient umfasst. Definitionen k¨ onnen mittels einer in Entwicklung befindlichen Weboberfläche eingepflegt werden. Benutzer werden in einer Datei oder einer SQL Datenbank verwaltet. Da OpenWFE f¨ ur die Integration in andere Systeme gedacht ist, bietet es selbstverst¨ andlich entsprechende APIs und Schnittstellen. Einerseits kann man in Java, Jython oder Python sogenannte Reactors entwickeln (also Aktionen innerhalb des Workflows setzen). Andererseits gibt es eine REST Schnittstelle (eine einfache Web Service Schnittstelle) sowie Python, Ruby und C# Zugriffsbibliotheken (letztere damit .NET Applikationen ebenfalls eingebunden werden k¨ onnen). Auch eine Perl Anbindung ist geplant. Es wird die BSD Lizenz verwendet, sodass man fast beliebig mit dem System arbeiten kann. Mit OpenWFE kann man komplizierte Workflows abdecken (zum Beispiel alle auf www.workflowpatterns.com dargestellten). Auch ein


73

Scheduler ist vorhanden. Als Datenbank sind MySQL und PostgreSQL getestet, wobei eine Bibliothek die Zugriffe kapselt. Insgesamt eine interessante Workflow Engine mit vielleicht etwas zu viel Fokus darauf auch alleine einsetzbar zu sein (siehe Webclient). Weitere Informationen findet man unter http://web.openwfe.org/display/openwfe/Home. Das zweite angesprochene System ist OSWorkflow (siehe auch http: //www.opensymphony.com/), basiert auf Java und unterliegt der APL Lizenz (Apache Foundation). Es basiert auf dem ebenfalls frei verf¨ ugbaren OSCore. Dieses Modul kann unter anderem die Benutzerverwaltung u ¨bernehmen (ist aber kein muss). Vom Prinzip her arbeitet die Workflow Engine rein mit XML Dateien. Als wichtiges Werkzeug gibt es einen GUI Designer, der beim Erstellen dieser Dateien hilft (eine Java Swing Applikation). Soweit sinnvoll verwendet OSWorkflow weitere Komponenten. So wird GLUE von WebMethods f¨ ur das SOAP Interface eingesetzt. Hierbei handelt es sich um eine nur beschr¨ ankt frei einsetzbare Komponente. Wenn dies ein Problem ist, kann man sie weglassen oder durch Apache Axis beziehungsweise eine andere freie Komponente ersetzen (mit entsprechendem Aufwand). Weiters wird Quartz als Scheduler verwendet und unterschiedliche Persistenzschichten unterst¨ utzt (Memory, Serializable [Java Standard], JDBC, OFBiz [primär eigentlich selbst eine Workflow Engine; siehe http://www.ofbiz.org/], EJB). Wie in OpenWFE kann man Workflows durch Zusatzfunktionen erweitern. Diese können in Java (zum Beispiel EJBs), BSF Perlscript/VBScript/Javascript (alle drei von IBM AlphaWorks) geschrieben sein oder als sogenannte Bean Shell Functions (siehe http://www.beanshell.org) beziehungsweise OSWorkflow Utility Functions umgesetzt sein. Weiters sind Trigger, Bedingungen, Berechtigungen, Validatoren und Auto Funktionen m¨ oglich. Die Mechanismen können dabei mit der Generierung von E-Mails erweitert werden. F¨ ur eigenen Java Code kann man auf eine vorhandene Einbindung der Spring und Hibernate Frameworks zur¨ uckgreifen. Als m¨ ogliche Datenbanken wurden Oracle und PostgreSQL getestet. Insgesamt sind beide Workflow Engines mächtig und sicherlich geeignet, Workflow Funktionen nachzur¨ usten oder zu erweitern. OSWorkflow ist noch st¨ arker daran orientiert in ein gr¨ oßeres System eingebaut zu werden als OpenWFE. Gleichzeitig d¨ urfte OpenWFE in nicht Java Systemen schneller zu integrieren sein, da mehr Open Source Schnittstellen und APIs abseits Java zur Verf¨ ugung stehen. Eine konkrete Entscheidung kann man nat¨ urlich nur treffen, wenn der sinnvolle Umfang von Workflow Unterst¨ utzung und die vorhandene Funktionalit¨ at im System ohne extra Engine bekannt sind. Falls eine besonders umfassende Workflow Unterst¨ utzung notwendig ist, sollte man eine Recherche nach weiteren Kandidaten starten, da dieser Abschnitt nur zwei relativ m¨ achtige“ und geeignete Engines untersucht und ¨ ” keinen umfassenden Uberblick darstellt. Hintergrund ist, dass standardisierte Abl¨ aufe, die sich durch Workflows automatisieren lassen, bestenfalls ein Randthema von KM sind. Im Kern stehen ja wissensintensive Prozesse und nicht starre Abl¨ aufe.

74


Erweiterungen (durch Systeme bzw. Module) Abschließend soll noch eine relativ bunt zusammengew¨ urfelte Menge von Systemen beziehungsweise Modulen vorgestellt werden, die KM Systeme bereichern k¨ onnen beziehungsweise (auch) als KM Tool verwendbar sind. Dabei handelt es sich um das schon kurz erw¨ ahnte POPFile zur Klassifizierung von E-Mail, das Perl basierte Open Ticket Request System (OTRS) und drei PHP basierte Systeme. Einerseits phpBB als m¨ achtiges Bulletin Board System, weiters WebCalender (der Name sagt alles) und phpWiki als ein Beispiel eines separaten Wikis. POPFile ist eine Art Zwischenst¨ uck zwischen dem Mailserver und dem Mailprogramm des Endbenutzers (siehe auch http://popfile.sourceforge.net/). Kurz gesagt also ein POP3 Proxy, der u ¨ blicherweise zur Klassifizierung von Spam verwendet wird. Als solches ist er ein potenziell wichtiger Teil eines Groupware Systems aber kaum KM relevant. Gleichzeitig kann POPFile aber auch f¨ ur eine allgemeine Klassifizierung von E-Mails verwendet werden und damit KM Aspekte unterst¨ utzen. Ein einfaches Beispiel ist die Klassifikation von eigehenden E-Mails als Supportanfrage, Preisanfrage, etc. Neben der Funktion als POP3 Proxy gibt es auch noch ein Webinterface, womit es besser als Tool genutzt werden kann. Die Entwicklung von POPFile ist aktiv und unterliegt der GPL Lizenz. Bei OTRS (siehe auch http://otrs.org/) handelt es sich um ein in Perl geschriebenes Ticketing (oder Trouble-Ticket) System. Es bietet alle wichtigen Funktionen wie verschiedene Warteschlangen und Agenten, die sich um die einzelnen Tickets k¨ ummern (inklusive von Berechtigungen auf Tickets). Es ist dabei durchaus m¨ oglich, Tickets nachtr¨ aglich einem anderen Agenten zuzuweisen. Je nach Prozess in einer Organisation kann man problemlos E-Mails generieren lassen und auch welche entgegennehmen. Diese E-Mails d¨ urfen/können dabei mit PGP oder S/MIME verschl¨ usselt sein. Erweitern lässt sich das System einfach mittels Perl-Modulen beziehungsweise kann auch die vorhandene Workflowfunktionalit¨ at verwendet werden. Je nach Komplexität wird man hier entsprechende Aufw¨ ande ber¨ ucksichtigen m¨ ussen. Wichtig f¨ ur den lau¨ fenden Betrieb ist auch die Protokollierung aller Aktionen und Anderungen. Technisch betrachtet ist das Produkt mit MySQL, Oracle und PostgreSQL getestet und unterliegt der GPL Lizenz. Insgesamt eine potenziell wichtige Erweiterung auch f¨ ur ein KM System. Einerseits haben viele Organisationen entsprechende Anforderungen und andererseits stellt die Datenbasis eine wertvolle Quelle f¨ ur ein KM System dar (und selbstverständlich auch umgekehrt). Je nach Bedarf und den potenziell vorhandenen Funktionen (teilweise ja in diesem Kapitel kurz beschrieben) ist es eine wichtige Erweiterung. Nähere Informationen findet man zum Beispiel in der Zeitschrift iX 10/2004 S.66 (Artikel von Lukas Grunwald). achtiges Bulletin Board System vor sich (sieMit phpBB hat man ein m¨ he auch http://www.phpbb.com/). Wichtig vor allem, wenn man im System ur sonst keine oder unterdurchschnittliche Forumfunktionalität hat (primär f¨


75

eine PHP L¨ osung). Da es neben den vielen und ausgereiften Funktionen auch eine aktive Entwicklergemeinde hat, stellt es eine der besten und flexibelsten L¨ osungen dar, die man sinnvollerweise in einem KM System integrieren kann. Technisch betrachtet ist es zusammen mit den Datenbanken MySQL, PostgreSQL, MS SQL Server und Access/ODBC getestet. Als Lizenz kommt die GPL zum Einsatz. WebCalender (http://www.k5n.us/webcalendar.php) stellt ein weiteres PHP basiertes Tool dar. Es bietet einzelnen Benutzern und Gruppen einen web-basierten Kalender f¨ ur Termine wie auch f¨ ur Events. Weiters gibt es auch die M¨ oglichkeit eines iCalendar, vCalendar oder Palm (PDA) Imports und Exports. Zum Zeitpunkt der Recherche befand sich eine Synchronisation mit den Programmen Apple iCal und Mozilla Sunbird, Unterst¨ utzung f¨ ur Dateianh¨ ange sowie Kommentare bei Events oder etwa auch die Bereitstellung des Kalenders im RSS Format in Entwicklung. Angedacht waren unter anderem ein JSR 168 kompatibles Portlet, ein Java Servlet, ein Java Client und wesentliche Verbesserungen der Synchronisationsmöglichkeiten. Alleine deckt es damit einen Teilaspekt von Groupware Systemen ab. Wichtig ist so ein Modul eigentlich nur f¨ ur KM Systeme, denen ein gemeinsamer Terminkalender abgeht. Gleichzeitig ist eine Integration vor allem f¨ ur PHP Lösungen sinnvoll, wo ein solcher Kalender selten fehlt. F¨ ur die Speicherung kann MySQL, PostgreSQL, Oracle, IBM DB2, InterBase oder eine ODBC Schnittstelle verwendet werden. F¨ ur die Benutzerauthentifizierung kann HTTP, LDAP oder NIS zum Einsatz kommen. Damit ist es interessant, WebCalender zu integrieren, wenn man bei einer PHP L¨ osung keinen (brauchbaren) Kalender dabei hat. Punkto Lizenz wird ebenfalls die GPL verwendet. phpWiki (siehe auch http://phpwiki.sourceforge.net/) ist ein Klon des urspr¨ unglichen WikiWikiWeb (siehe http://c2.com/cgi-bin/wiki?WikiWikiWeb daf¨ ur). Nat¨ urlich wird die urspr¨ ungliche Idee der von jedem zu editierenden HTML Seite unterst¨ utzt. Weiters erm¨ oglicht es verschiedene Speicherungsorte, Themen, Plug-ins und ein Berechtigungssystem bis hin zu ACLs. Spannend ist das Wiki vor allem f¨ ur PHP Systeme, die keine entsprechende Funktionalit¨ at anbieten. Gerade in Richtung Zusammenarbeit stellen Wikis einen besonders interessanten Ansatz dar und sollten daher möglichst von einem KM System unterst¨ utzt werden. Technisch betrachtet verwendet phpWiki eine MySQL Datenbank und hat die GPL als Lizenz. Generell sind die in diesem Abschnitt vorgestellten Systeme als Erweiterung eines gr¨ oßeren Systems gedacht (vielleicht mit der Ausnahme des OTRS). Das zeigt schon, dass es hier um die Bereicherung eines Systems geht, das einzelne wichtige Funktionen nicht anbietet. Wie dieser Abschnitt zeigt, gibt es f¨ ur PHP am meisten solcher Systeme. In den nächsten Kapiteln wird fallweiuckgegriffen“ werden, um darzustellen, wie man ein se auf diese Systeme zur¨ ” oglichst vielen vorhandenen Teilen formen“ kann. größeres KM System aus m¨ ”

4 Technische Basis

Im letzten Kapitel wurden schon eine Reihe von Fragen zur technischen Basis angesprochen. Zum Teil wurde auch schon eine kurze Diskussion gef¨ uhrt, wann welche Technologie Sinn macht. In diesem Kapitel geht es nun darum, einerseits auf die vorhandenen Systeme und Datenbestände und andererseits auf technische Entscheidungen f¨ ur ein KM System einzugehen. Besonders wichtig bei einer Entscheidung f¨ ur eine zuk¨ unftige Technologie ist dabei die generelle Frage der Datenspeicherung. In diesem Zusammenhang gibt es leider keine eindeutige Entscheidung oder auch nur Empfehlung. Im Prinzip muss man zuerst das Zielsystem definieren. Danach die vorhandenen Systeme analysieren und identifizieren, was davon abgel¨ ost werden soll. Aus diesen beiden Punkten ergibt sich f¨ ur jede Organisation ein eigenes Ziel und ein entsprechendes KM System, das am meisten Sinn ergibt. Neben den schon genannten f¨ ur ein zuk¨ unftiges System wichtigen Punkten gilt es auch noch die Frage zu beantworten, ob ein Portal die beste, eine sinnvolle oder nur eine optionale Basis f¨ ur das KM System ist. Dabei geht es nicht nur darum, ob es unmittelbar notwendig ist, sondern auch um Zukunftssicherheit und eine m¨ ogliche Ebene der Integration von Informationen und Funktionalit¨ aten. Anhand dieser kurzen Beschreibung sieht man schon, dass dieser Entscheidung eine enorme Bedeutung zukommen kann. Folglich sollte man bei dieser Analyse mindestens soviel Sorgfalt wie zum Beispiel bei der Entscheidung u ¨ ber die Programmiersprache walten lassen.

4.1 Einbeziehung vorhandener Datenbest¨ ande/Systeme Hier geht es um die Frage, was man am besten mit bestehenden Datenbest¨ anden und Systemen tun sollte. Da verschiedene Organisationen historisch gewachsene und h¨ aufig sehr unterschiedliche Systeme im Einsatz haben, kann man nur schwer generelle Aussagen machen. Gleichzeitig gibt es aber

78

4 Technische Basis

durchaus eine Reihe von Systemkategorien, bei denen man wichtige Hinweise und Entscheidungshilfen geben kann. Die aus Sicht eines KM Systems wichtigste Gruppe ist die der Groupware Systeme. Hier geht es n¨ amlich besonders stark um die Frage, ob man sie abl¨ osen soll oder nicht (auch wenn diesem Aspekt häufig wenig Bedeutung beigemessen wird). Besonders wichtig ist auch die Frage von vorhandenen Datenbanken beziehungsweise Datenbest¨ anden. Hier geht es meist um die Integration und nicht unbedingt um eine Abl¨ ose. Wenn man weiters an Business Software (wie ERP oder CRM) denkt, ist eine vorhandene Software ein enorm wichtiger Punkt. Gleichzeitig geht es auch hier meist um Integration und nicht um eine Abl¨ ose. Außerhalb der schon genannten Kategorien gibt es noch eine F¨ ulle weiterer wichtiger Gruppen, bei denen kurz die wichtigsten beleuchtet werden. Nicht vergessen sollte man auch Individualsoftware, bei der gleichzeitig am ehesten Schwierigkeiten zu erwarten sind und je nach Ausgangslage sogar eine Abl¨ ose die billigste Option sein kann. Insgesamt sollte man sich die F¨ ulle an möglichen Systemen vor Augen halten, die heutzutage die unterschiedlichsten Prozesse von ganz verschiedenen Organisationen unterst¨ utzen. Daran erkennt man, dass es praktisch ausgeschlossen ist, eine auch nur ann¨ ahernd komplette Darstellung zu geben. Daher beschr¨ ankt sich dieser Abschnitt auf die wichtigsten Kategorien und Punkte, die man bedenken sollte. Da es von vornherein ausgeschlossen ist den Weg“ ” zu pr¨ asentieren, geht es prim¨ ar darum eine fundierte Entscheidung treffen zu können. 4.1.1 Groupware Systeme Groupware Systeme wurden schon in Abschnitt 3.2 diskutiert. Dabei kann man feststellen, dass prim¨ ar zwei Produkte den Markt f¨ ur kommerzielle Groupware L¨ osungen beherrschen. Einerseits ist dies Microsoft mit der Kombination Exchange und Outlook und andererseits IBM/Lotus mit Domino und Notes. Daneben gibt es noch eine Reihe kleinerer Systeme, insbesondere die Novell Groupware Groupwise hat noch einen nennenswerten Marktanteil. Weiters gibt es auch eine Reihe von kostenlosen Lösungen, von denen die aus KM Sicht passendsten in Abschnitt 3.2 vorgestellt wurden. Bei den großen kommerziellen Systemen geht es um mehrere Fragen. Einerseits, wie intensiv und breit gef¨ achert man sie u ¨ berhaupt nutzt. Insbesondere, ob man sie u ¨ ber die reine Mailing und Kalenderfunktionalität hinaus verwendet (zum Beispiel in Form von Lotus Notes Datenbanken und Add-on L¨ osungen). Je st¨ arker man eine solche Groupware schon nutzt desto unattraktiver ist es sie abzul¨ osen. Gleichzeitig ist es f¨ ur eine große KM Lösung unumg¨ anglich mit einer Groupware zu interagieren, wenn die entsprechenden Funktionen nicht integriert werden k¨ onnen. Im Prinzip bleiben einem drei M¨ oglichkeiten: 1. Man kann die vorhandene L¨ osung wie sie ist beibehalten und möglichst viele Daten f¨ ur das KM System zug¨ anglich machen.

4.1 Einbeziehung vorhandener Datenbest¨ ande/Systeme

79

2. Weiters kann man sich auf die Grundfunktionen Mailing und Kalender zur¨ uckziehen und den Rest (soweit vorhanden) migrieren. 3. Die dritte Alternative ist eine Vollmigration inklusive Mailing und Kalenderfunktionen. Jeder dieser besprochenen M¨ oglichkeiten hat ihre Vor- und Nachteile. Verst¨ andlicherweise ist die erste Variante am billigsten zu implementieren und wenn es nicht zu viele Erweiterungen innerhalb der Groupware gibt, ist diese L¨ osung auch halbwegs leicht zu warten. Bei der zweiten Variante hat man die einfachste Aufteilung und potenziell niedrigere Implementierungskosten. Insbesondere kommt hier noch dazu, dass es keinen Lernaufwand der Nutzer f¨ ur die Groupware Seite gibt. Bei der dritten Lösung schließlich hat man die h¨ ochsten Implementierungs- und Schulungsaufwände. Gleichzeitig sind sicherlich auch Widerst¨ ande zu u uhrtes System ¨ berwinden, wenn man ein eingef¨ ersetzt. Positiv schlagen dagegen prim¨ ar zwei Aspekte zu Buche. Man benötigt keine kommerziellen Lizenzen mit eventuellem Support mehr (man kann die vorhandenen Lizenzen auch verkaufen) und die KM Lösung ist frei von altem Ballast. Vor allem kann sie ein m¨ oglichst einheitliches Benutzerinterface bieten und hat die sehr wichtigen Daten, die u ¨ber eine Groupware erstellt, ausgetauscht, etc. werden, direkt im Zugriff. Die letzte Lösung macht auch dann Sinn, wenn bei der Groupware sowieso ein Upgrade ansteht und man die entsprechenden Kosten gleich in das KM Projekt umleiten kann. Insbesondere sind manche dieser Umstellungen relativ kostspielig und es kann fast gleich teuer sein, auf eine Open Source L¨ osung umzusteigen (unter Ber¨ ucksichtigung, dass ein generelles KM System eingef¨ uhrt wird). Bei vorhandenen Open Source oder kostenlosen Groupware Systemen ist die Diskussion schwieriger. Hier sind keine Einsparungen durch einen Umstieg zu erwarten und das Problem mit der Eingewöhnung beziehungsweise Umschulung der Nutzer f¨ allt dadurch noch schwerer ins Gewicht. Allgemeine Aussagen in diesem Umfeld sind leider auch sehr schwierig, da sich die vorhandenen L¨ osungen stark unterscheiden. Generell ist die Empfehlung sehr wohl an eine Abl¨ ose zu denken. Diese ist meist deutlich leichter als bei einer kommerziellen Lösung, da man etwa alle notwendigen Informationen u ¨ ber die Datenbank hat. Potenziell kann man die Groupware auch direkt in das KM System integrieren oder zumindest Codeteile u ur ¨bernehmen (zum Beispiel f¨ den Zugriff auf alte Daten). Durch die Diversit¨ at ist es also deutlich schwieriger, eine genaue Beschreiur eine urden f¨ bung zu machen. Gleichzeitig sind die zu u ¨ berwindenden H¨ Abl¨ ose geringer und es besteht die Chance, die Groupware u ¨berhaupt beizubehalten. Nicht außer Acht lassen sollte man noch den insbesondere in kleineren und weniger IT lastigen Organisationen anzutreffenden Zustand, dass keine Groupware vorhanden ist. Aus Sicht eines großen KM Systems ist das der Idealzustand, da man hier auf keine gewachsenen IT Systeme R¨ ucksicht nehmen muss. (Gleichzeitig k¨ onnte es hier den heftigsten Widerstand durch die

80

4 Technische Basis

Mitarbeiter geben, die ihre gewohnte Arbeitsweise drastisch anpassen m¨ ussen, damit die vielen Vorteile auch zum Tragen kommen können.) F¨ ur diesen Fall sollte man am besten nach einer eingehenden Analyse des gew¨ unschten KM Systems die am leichtesten zu integrierenden Groupware Funktionen hinzuf¨ ugen. Nat¨ urlich ist auch in diesem Fall wichtig, das komplette Spektrum abzudecken. Weiters sollte man sich besonders um die Unterst¨ utzung der Nutzer k¨ ummern, damit diese lernen alle Funktionen sinnvoll zu nutzen (beziehungsweise selbst neue Verwendungsm¨ oglichkeiten zu finden). Man sieht also, dass es bei der Groupware relativ schwierig ist, eine eindeutige Empfehlung zu geben. Insgesamt sollte man versuchen, eine möglichst enge Integration mit der KM L¨ osung herzustellen. Das muss nicht immer auf die Abl¨ ose eines eventuell vorhandenen Systems hinauslaufen. Gleichzeitig sollte man sich das offen anschauen und bedenken, dass eine Ablöse eine Reihe von Vorteilen hat, wenn es sich bei der Groupware nicht um ein relativ aktuelles und mächtiges“ System handelt. Es kann aber durchaus mehr Sinn ” machen, eine vorhandene Groupware soweit wie möglich einzubeziehen, insbesondere wenn der Fokus der KM Initiative nur relativ schwach mit Groupware Funktionen adressiert werden kann. Dann sollte man seine Kräfte zielgerichteter einsetzen und das System in Hinsicht auf die Groupware möglichst offen gestalten. Dadurch ist es in weiterer Folge relativ leicht, eine Integration doch noch durchzuf¨ uhren. 4.1.2 CMS/DMS Bei CMS und DMS Systemen gibt es f¨ ur beide Kategorien extrem mächtige bis hin zu relativ minimalen L¨ osungen. F¨ ur minimale Lösungen ist selbstverst¨ andlich eine Abl¨ ose das einfachste und beste Szenario. Schwieriger wird es bei den m¨ achtigeren Vertretern. Bei CMS Systemen gibt es eine Reihe sehr guter Systeme am Markt. Obwohl bei verschiedenen kommerziellen Systemen im Vergleich zu Open Source Vertretern noch mehr Funktionen zu finden sind, werden diese häufig gar nicht ben¨ otigt. Weiters macht es sehr viel Sinn, eine enge Integration mit der KM L¨ osung anzustreben. Wenn sich das mit der vorhandenen Software gut unde (wie Wartungskosten) dagegen machen l¨ asst und keine finanziellen Gr¨ sprechen, sollte man diese Option durchaus n¨ aher betrachten. Generell ist es aber anzuraten, in Richtung einer der passenden Open Source CMS Lösungen zu gehen. Einerseits kann man diese meist leicht integrieren und hat keine weiteren Lizenz- und Wartungskosten. Andererseits gibt es eine Reihe guter L¨ osungen, die alle typischen Funktionen und meist sogar noch mehr anbieten k¨ onnen. Bei DMS Systemen muss man sich genau ansehen, wie mächtig eine vorhandene kommerzielle L¨ osung ist. F¨ ur einige dieser Produkte wird es kaum einen vollwertigen Ersatz im Open Source Umfeld geben. Gleichzeitig findet man eine Reihe von Systemen, die alle wichtigen Funktionen anbieten, und


81

damit f¨ ur die meisten Organisationen ausreichend sein sollten. Falls man allerdings auf Zusatzfunktionen einer kommerziellen Lösung angewiesen ist, muss man auf jeden Fall ein bidirektionales Interface zwischen der KM Lösung und dem DMS aufbauen. Die im DMS enthaltenen Informationen sind von essenzieller Bedeutung f¨ ur ein KM System und m¨ ussen dar¨ uber zugreifbar und benutzbar sein. Sowohl bei CMS als auch bei DMS Systemen ist die Empfehlung an eine Migration zu denken, soweit solche Systeme schon im Einsatz sind. Zusammen mit den Groupware Funktionalit¨ aten geht es hier um die Kernfunktionen eines KM Systems und daher m¨ ussen diese unmittelbar gut funktionieren. Weiters kann man andere Systeme nach und nach anbinden oder integrieren, bei den Kernfunktionen sollte man das auf keinen Fall tun. Sonst fehlen einerseits wichtige Daten und andererseits hat man ein hohes Risiko, dass die Nutzer das System nicht annehmen. 4.1.3 Datenbanken/best¨ ande Mit Datenbanken und Datenbest¨ anden sind einerseits wirkliche Datenbanken gemeint. Das sind prim¨ ar Datensammlungen mit relativ wenig System“ ” drumherum. Andererseits geht es um (h¨ aufig kleine) Applikationen, die sich um die Darstellung und Pflege von strukturierten Daten k¨ ummern. Das kann von einer Absenzendatenbank u ¨ ber eine Produktdatenbank bis zu einer Planungsdatenbank reichen. Die dazu verwendeten Technologien können schon innerhalb einer Organisation stark unterschiedlich sein. Zwischen verschiedenen Organisationen gibt es nur selten Gemeinsamkeiten. Man sieht also, dass es hier nicht m¨ oglich ist, generelle Aussagen zu machen. Wichtig sind dabei folgende Punkte: Einerseits sollte eine Organisation genau feststellen, welche Applikationen mit welchen Funktionen verwendet werden. Andererseits geht es um die Bewertung der Daten beziehungsweise Funktionen und ihrer Wichtigkeit f¨ ur die angestrebte KM Lösung. Anders gesagt muss man je nach Umfang der KM L¨ osung und Wichtigkeit der Daten und Funktionen extra entscheiden. Zus¨ atzlich kann auch noch die Anzahl der betroffenen Mitarbeiter ein wichtiges Kriterium sein. Kurz gesagt gibt es drei Kriterien, die f¨ ur eine Einbeziehung sprechen k¨ onnen: 1. Erstens die Wichtigkeit der Daten und/oder Funktionen. 2. Zweitens wenn ein gr¨ oßerer Anteil der Nutzer betroffen ist. 3. Drittens wenn eine Integration relativ leicht ist. Dabei sind die ersten beiden Kriterien ¨ außerst wichtig. Gleichzeitig sollte man sich aber auch nicht die Chance entgehen lassen, leicht zu integrierende Datenbest¨ ande und/oder Funktionen mitzunehmen“. Wenn man sich an ” diese drei Kriterien h¨ alt, sollte man eigentlich alles Wichtige ber¨ ucksichtigen.

82

4 Technische Basis

Ein weiterer wichtiger Punkt ist, dass neue Datenbanken beziehungsweise Datenbest¨ ande nat¨ urlich von vornherein innerhalb der KM Lösung oder kompatibel gestaltet werden. Je umfassender der Ansatz der KM Lösung (zum Beispiel ein Portal, dass fr¨ uher oder sp¨ ater alles“ integrieren soll) desto eher ” ist eine Umsetzung innerhalb der vorhandenen Lösung gefordert. 4.1.4 Business Software (ERP, CRM, etc.) Unter dem Begriff Business Software findet man eine ganze Reihe von Produktkategorien. Besonders wichtige Vertreter sind die schon in Kapitel 3 kurz angesprochenen ERP und CRM Systeme. Weitere Beispiele sind Business Intelligence Tools/Systeme oder auch SCM. In diesen Kategorien findet man meist sehr große und m¨ achtige“ Produkte. In kleineren Organisationen sind ” sie eher selten anzutreffen beziehungsweise findet man dort eher kleinere Systeme im Einsatz. Generell ist es wichtig sich vor Augen zu halten, dass man so ein System nicht einfach abl¨ osen kann. Gleichzeitig sind die enthaltenen Daten von größter Wichtigkeit f¨ ur jedes KM System. Die Folgerung ist simpel. Sollte schon eine relative m¨ achtige“ Business Software im Einsatz sein, wird man diese meist ” integrieren m¨ ussen. Insbesondere bei kommerziellen Systemen sollte man aber auf jeden Fall auch kurz u ¨ berlegen, ob man nicht eine Open Source Software nehmen k¨ onnte und durch die Einsparungen die initialen Kosten rechtfertigen kann. Sollte noch kein entsprechendes System im Einsatz sein (oder eventuell nur wenig genutzt werden), dann hat man zwei Optionen. Einerseits kann man sich auf die anderen Aspekte einer KM L¨ osung konzentrieren – also primär Groupware, DMS und CMS Funktionen. Andererseits kann man die Gelegen” heit“ nutzen und gleich eine entsprechende Business Software einf¨ uhren. Hier sollte man aber die Komplexit¨ at nicht unterschätzen. Nicht nur technisch gibt es dann n¨ amlich deutlich mehr zu tun auch organisatorisch ist die Einf¨ uhrung einer Business Software (wie auch einer KM Lösung) eine große Herausforderung. Eine Kombination beider Aspekte kann Organisationen jeder Größe leicht u ¨berfordern. Damit ist klar, dass man zuerst einmal die vorhandenen Systeme analysieren muss. Typischerweise haben solche Systeme auch APIs, die es ermöglichen sollten, die wichtigsten Daten und Funktionen zu integrieren. Wenn das nicht m¨ oglich ist, muss man zumindest die wichtigsten Daten in eine KM Lösung einbinden und sich u unftig die Mischung der beiden Systeme ¨ berlegen, wie zuk¨ sinnvoll verwendet werden kann. Dabei ist es wichtig zu bedenken, dass das f¨ uhrende System in diesem Bereich SAP ist. Damit sollte schon die mögliche Komplexit¨ at klar sein. Ein generell wichtiger Aspekt, der bei den beschriebenen Systemen besondere Bedeutung hat, ist die Vermeidung von Redundanzen. Kurz gesagt muss man sicherstellen, dass Daten wie etwa ein Lieferant oder ein Auftraggeber sich nicht mehrfach in den Systemen wiederfinden. Sollte man dies tech-


83

nisch nicht vermeiden k¨ onnen, sind unbedingt entsprechende organisatorische Maßnahmen zu treffen. Zusammengefasst ist es unbedingt notwendig, entsprechende Systeme und ihre Daten einzubeziehen. Entweder durch eine Ablöse oder eine möglichst weitgehende Integration. Sollte ein entsprechendes System noch nicht vorhanden sein, macht es Sinn eine entsprechend offene KM Lösung zu wählen. Eine gleichzeitige Einf¨ uhrung ist aber aufgrund der technischen und organisatorischen Komplexit¨ at nur in Ausnahmef¨ allen zu empfehlen. 4.1.5 Portale Der Begriff Portal wird leider inflation¨ ar verwendet. Daher ist es entsprechend schwierig darzustellen, was man mit Portalen tun sollte. Das Wichtigste ist einmal zu erheben, was technologisch wirklich vorhanden ist und welche Funktionen angeboten werden. Teilweise wird man dabei feststellen, dass es sich eher um eine Art Homepage oder Intranet System handelt. Teilweise wird man m¨ achtige Frameworks und Portalserver antreffen. Der erste Fall ist dabei leicht zu behandeln. Hier wird man entweder das vorhandene System ablösen oder parallel weiterbestehen lassen (je nach Wichtigkeit der Daten und Funktionen f¨ ur eine KM L¨ osung und einen effizienten Arbeitsablauf). Ist ein m¨ achtiges Framework beziehungsweise Portalserver im Einsatz, sollte man eine detaillierte Analyse u ¨ ber die gebotenen technischen Möglichkeiten und Funktionen machen. Insbesondere wenn wichtige Funktionen schon realisiert wurden und eine solide Basis zur Verf¨ ugung steht, empfiehlt es sich darauf aufzubauen. Das bedeutet gleichzeitig, dass man die anderen Hinweise in Richtung empfohlener Systeme, einer Systembasis und einer Programmiersprache gr¨ oßtenteils ignorieren sollte. Wichtig ist dann vor allem, welche Funktionen und Systeme man leicht andocken und integrieren kann, um die Ziele der KM Initiative bestm¨ oglich zu unterst¨ utzen. Trotz der Wichtigkeit dieser Ausnahme sollte man zumindest aktuell davon ausgehen, dass vorhandene Portale“ eher in die erste Kategorie fallen ” werden. Eine erweiterbare Portall¨ osung, die sich f¨ ur ein KM System eignet, wird man in wenigen Organisation antreffen. Daher wird im Folgenden auch nur ausnahmsweise auf diesen Sonderfall eingegangen werden. 4.1.6

Diverses“ ”

Neben den bisher besprochenen Kategorien von Software gibt es noch eine Reihe von anderen Systemen. Das kann von einer Zeitaufzeichnung u ¨ ber ein Intranet bis zu einer Buchhaltung reichen. (Es geht hier jetzt nicht primär um die Frage, ob man nicht auch diese Systeme in Richtung der Datenbanken und Datenbest¨ ande einordnen k¨ onnte.) oglichen Systemen einfach zu groß ist, kann man keiDa die Vielfalt an m¨ ne allgemeine Empfehlung geben. Generell muss man hier eine Erfassung der vorhandenen Systeme vornehmen. Je nach Wichtigkeit der Daten wird man

84

4 Technische Basis

die Systeme oder zumindest die enthaltenen Informationen integrieren. Eventuell kann man auch einzelne Systeme durch ein KM System ablösen. Ein Intranet ist etwa typischerweise ein Kandidat f¨ ur eine Ablöse. Eine Zeitaufzeichnung dagegen k¨ onnte weiterhin wie vorher arbeiten und bietet nur bei entsprechend detaillierter Erfassung u ur ¨berhaupt relevante Informationen f¨ ein KM System (die dann nat¨ urlich unbedingt eingebunden werden sollten, damit keine Mehrfacherfassung notwendig ist). 4.1.7 Individualsoftware Bei Individualsoftware hat man es mit einer Kategorie zu tun, die prinzipiell Diverses“ ¨ ahnelt. Von den Aufgabenstellungen an die Software gibt es dabei ” aber keine Einschr¨ ankungen. Daf¨ ur sind diese Systeme Einzelentwicklungen und damit meist schwer bis gar nicht integrierbar. Typischerweise liegt kein Source Code vor, oft nicht einmal eine technische Dokumentation. Grunds¨ atzlich gilt auch hier, dass eine Erfassung der vorhandenen Software mit folgender Begutachtung notwendig ist. Generell sollte man – wenn u oglichst offene Individualsoftware einsetzen. Im Einzelfall kann ¨ berhaupt – m¨ es dabei durchaus Sinn machen, eine solche Software in eine KM Lösung zu integrieren oder zumindest vom Hersteller eine Verbindung schaffen zu lassen. In vielen anderen F¨ allen wird man die Software nach der Analyse einfach unver¨ andert weiternutzen. Soweit es sich um Spezialsoftware handelt, besteht meist keine Notwendigkeit f¨ ur eine Integration. Sollte die Individualsoftware aber prim¨ ar Funktionen anbieten, wo im Kapitel 3 entsprechende Alternativen genannt wurden, sollte man eine Ablöse u ¨ berlegen. Insbesondere bei den Aspekten Groupware, DMS oder CMS macht eine Individualsoftware kaum mehr Sinn, da die Extrakosten f¨ ur eine Weiterentwicklung oder Integration meist hoch und kaum zu rechtfertigen sind. 4.1.8 Zusammenfassung Insgesamt wird in den vorangegangenen Abschnitten klar aufgezeigt, dass vorhandene Systeme einzeln betrachtet und analysiert werden m¨ ussen. Durch die Vielzahl an unterschiedlichen Systemen ist es dabei unmöglich generelle Aussagen zu treffen. Trotzdem kann man wichtige Hinweise geben und bei manchen Kategorien auch konkreter werden. Ganz klare Voraussetzung ist, zuerst die Ziele einer KM Initiative definiert zu haben. Weiters braucht man eine Zielvorstellung der notwendigen Unterst¨ utzung durch ein IT System. Auf dieser Basis kann man eine sinnvolle Analyse der bestehenden Systeme machen. Die einzige Tätigkeit, die man vorher oder parallel durchf¨ uhren kann, ist das Feststellen der vorhandenen Systeme, ihrer Funktionalit¨ aten und wof¨ ur sie von wem verwendet werden. Schon beim ersten Punkt (Groupware) sieht man auch, wie schwierig eine eindeutige Aussage ist. Klar ist jedenfalls, dass man die Daten in eine


85

KM L¨ osung einbeziehen muss und die L¨ osung selbst zumindest teilweise entsprechende Funktionen anzubieten hat. Aus KM Sicht ist dabei sicherlich eine Integration oder Abl¨ ose bestehender Systeme vorzuziehen (was bei kommerziellen Systemen in weiterer Folge auch Einsparungen ergibt). Bei CMS und DMS Systemen ist die klare Empfehlung entweder zu migrieren oder eine enge Integration zu implementieren. Hintergrund ist die Wichtigkeit dieser Daten und Funktionen f¨ ur typische KM Initiativen. Da es insbesondere bei DMS Systemen sehr umfassende kommerzielle Pakete gibt, sollte man bei existierenden Systemen die M¨ oglichkeit einer engen Integration besonders intensiv untersuchen. Wenn es um Datenbanken und Datenbest¨ ande geht, gibt es keine eindeutige Empfehlung. Hier geht es vor allem um die Frage der Wichtigkeit der Daten und Funktionen f¨ ur ein KM System beziehungsweise wie viele Mitglieder einer Organisation diese Systeme nutzen. Kurz gesagt sollte man eine Integration oder Abl¨ ose anstreben, wenn einer oder mehrerer von drei Gr¨ unden gegeben ist: 1. Es handelt sich um entsprechend wichtige Daten und/oder Funktionen. 2. Es ist ein großer Benutzerkreis betroffen. 3. Wenn eine Integration relativ leicht m¨ oglich ist und es Zeit und Budget erlauben. Außerdem sollten neue Entwicklungen nur noch kompatibel mit dem KM System erfolgen. Ein ganz wichtiges Thema ist sogenannte Business Software. Dabei handelt es sich um ein relativ weites Feld. Gleichzeitig zählen hier auch große Softwarepakete dazu, die zum Teil gar nicht adäquat ersetzt werden können (zum Beispiel ein ausgereiztes SAP System). Gleichzeitig sind die Daten und Funktionen solcher Systeme enorm wichtig f¨ ur eine typische KM Initiative. Daher muss man m¨ oglichst viele Daten und Funktionen u ¨ ber die vorhandenen Schnittstellen einbinden. Zus¨ atzlich sollte man ernsthaft analysieren, ob nicht eine Abl¨ ose durch ein Open Source System möglich ist (insbesondere bei kleineren Organisationen durchaus realistisch und mit einem großen Einsparungspotenzial verbunden). Dabei sollte man so eine Ablöse (oder gar eine Einf¨ uhrung eines solchen Systems) von der Einf¨ uhrung eines KM Systems zeitlich trennen, um beide Vorhaben durch die sich ergebende Komplexität nicht unn¨ otig zu gef¨ ahrden. Auf Portaltechnologie im Speziellen wird noch näher eingegangen. Was existierende Portale angeht, ist einmal eine Bestandsaufnahme das Wichtigste. Viele der Systeme wird man dann eher als Homepages oder Intranetsysteme klassifizieren können. Solche Systeme kann man typischerweise relativ leicht abl¨ osen, wenn es sich um entsprechend wichtige Daten und Funktionen handelt. Sollte es sich aber andererseits um ein m¨ achtiges“ Portal handeln, muss ” man sehr genau schauen, ob es als Basis f¨ ur das KM System geeignet ist. Wenn ja, dann ist es immer noch empfehlenswert auch eine Alternative zu analysieren. Gleichzeitig ist dann eine Art Vorentscheidung gefallen.

86

4 Technische Basis

Neben den verschiedenen Kategorien von Softwaresystemen gibt es noch eine Unzahl weiterer Systeme wie etwa Individualsoftware im Einsatz. Hier muss man eine m¨ oglichst gr¨ undliche Analyse u ¨ ber die vorhandenen Daten, Funktionen und deren Benutzung machen. Je nach dem Ergebnis und dem Zusammenhang mit dem geplanten KM System und der KM Initiative muss man entsprechend agieren. Die M¨ oglichkeiten sind selbstverständlich dieselben wie bei den anderen Systemen. Man kann also eine Ablöse oder eine Integration durchf¨ uhren beziehungsweise alternativ das System parallel weiterbestehen lassen. Insgesamt sieht man, dass es deutliche Unterschiede bei den verschiedenen Kategorien von Softwaresystemen gibt. Gleichzeitig gibt es aber nur drei prinzipielle M¨ oglichkeiten. Die Entscheidung kann nur aufgrund einer Analyse der vorhandenen Software und innerhalb des Kontexts einer konkreten KM Initiative getroffen werden.

4.2 Datenspeicherung Datenspeicherung ist einer der wichtigsten Aspekte f¨ ur ein größer angelegtes KM System. F¨ ur den Fall einer eher kleiner angelegten Initiative sollte man die folgende Diskussion als Anregung verstehen. Unmittelbar kann man in so einem Fall sicher mit einer weniger umfangreichen und einfacheren Lösung auskommen. Gleichzeitig ist es wichtig, das System möglichst offen zu gestalten. Kurz gesagt sollte man eine m¨ oglichst flexible Basis schaffen (und zwar prim¨ ar konzeptionell und nicht durch eine teure Realisierung). Im weiteren geht es jetzt aber um KM Systeme bei denen von vornherein komplexere Anforderungen zu erf¨ ullen sind. Bei einem KM System ab mittlerer Gr¨ oße sind eine Reihe von wichtigen Anforderungen zu erf¨ ullen. Neben dem Betrieb und den verschiedenen Technologien und Architekturen ist die Datenspeicherung besonders wichtig (die nat¨ urlich zu allen drei genannten Aspekten dazugehört). Der besondere Fokus ist wichtig, da ein KM System zum Teil die Arbeitsweise einer Organisation bestimmt. Ohne die enthaltenen Daten und Funktionen ist eine normale Arbeit in weiterer Folge nicht mehr m¨ oglich. Dementsprechende Sorgfalt muss man walten lassen. 4.2.1 Offenheit Was die Datenspeicherung und den Zugriff angeht, sollte man auf größtmögliche Offenheit Wert legen. Das bedeutet, dass die Datenstrukturen klar definiert sein m¨ ussen und man m¨ oglichst auch in der zugreifenden Software Schnittstellen zur Verf¨ ugung hat. Weiters sollte man sich die verwendeten Datenstrukturen aller zusammengef¨ uhrten Systeme im Detail anschauen und gut u ¨ berlegen, wie man notwendige Erweiterungen beziehungsweise die Integration am nachhaltigsten erzielen kann. Bei Open Source Produkten ist es

4.2 Datenspeicherung

87

ganz besonders wichtig, am aktuellen Stand bleiben zu können, um wirkliche Unterst¨ utzung der entsprechenden Community zu bekommen. Daher m¨ ussen Integrationen und Erweiterungen darauf R¨ ucksicht nehmen und auch entsprechend dokumentiert werden. Zus¨ atzlich ist es auf jeden Fall empfehlenswert, eine unabhängige Zugriffsschicht auf alle integrierten Datenbest¨ ande zu etablieren. Diese muss dabei soweit m¨ oglich und vorhanden auf die Schnittstellen der integrierten Systeme aufsetzen (um m¨ oglichst versionsunabh¨ angig zu sein). Gleichzeitig stellt diese Schicht das einzige Interface f¨ ur neue Funktionen dar. An dieser Stelle ist auch ein geeigneter Punkt, um die Ausfallssicherheit einer Lösung zu erhöhen, indem den Zugriff auf mehrfach ausgelegte Systeme kapselt. Weiters kann man hier auch externe Systeme ankoppeln. Vom Prinzip her handelt es sich dabei um die beste M¨ oglichkeit einer Einbindung von Daten. Es m¨ ussen dabei aber auch funktionale und die Performance betreffende Fragen ber¨ ucksichtigt werden. 4.2.2 Verf¨ ugbarkeit/Zuverl¨ assigkeit Je gr¨ oßer und wichtiger ein KM System desto wichtiger ist die Verf¨ ugbarkeit und Zuverl¨ assigkeit. Diese muss bis zu einem gewissen Grad applikatorisch gegeben sein. Basis und wichtigste Grundlage f¨ ur ein entsprechendes System ist dabei ein hochverf¨ ugbarer Datenspeicher. Das Mindeste ist dabei ein regelm¨ aßiges Backup (zumindest t¨ aglich), das auch regelmäßig auf Verwendbarkeit u uft wird. Je gr¨ oßer die Organisation und je teurer ein potenzieller ¨berpr¨ Ausfall ist desto mehr wird man dar¨ uber hinausgehen m¨ ussen. Dabei geht es um klassische Themen, auf die hier nicht im Einzelnen eingegangen wird. Trotzdem kurz angef¨ uhrt die wichtigsten Punkte: Ausfallssichere Dateisysteme (von RAID 1-6 bis hin zu teuren Storage Lösungen), Cold Standby Server, Hot Standby Server und nat¨ urlich ein doppelt ausgelegtes System (potenziell als Cluster). Sozusagen der Maximalfall ist K-Fall Fähigkeit, also das komplette Vorhalten eines zweiten, physisch separierten Rechenzentrum. In kleineren Organisationen wird man kaum u ¨ber ein Cold Standby hinausgehen wollen oder m¨ ussen und kann entsprechend deutlich billiger arbeiten. Insgesamt sieht man schnell, dass zwei Punkte auch f¨ ur kleinere Organisationen unabdingbar sind. Einerseits eine funktionierende und getestete Backupl¨ osung (mit Medien an einem physisch anderen Ort) und eine Möglichkeit nach einem Problem schnell weiterarbeiten zu können (am einfachsten mit einer Cold Standby L¨ osung). Je nach verwendeter Technologie kann es dabei sogar relativ simpel sein, einen Cluster aufzubauen, und ist dann wesentlich besser als mit einem reinen Cold Standby ger¨ ustet. Auch bei so einem System darf aber auf keinen Fall auf eine funktionieren Backuplösung verzichtet werden (gerade bei einem Cluster wird das gerne vergessen und der Aufwand“ ” eingespart).

88

4 Technische Basis

4.2.3 Zusammenfassung Dieser Abschnitt geht kurz auf die Wichtigkeit der Datenspeicherung ein. Mit einer KM L¨ osung macht sich eine Firma stark von einem System abhängig. Dementsprechend wichtig ist ein m¨ oglichst durchgängiger und ausfallssicherer Betrieb. Hier darf man von den Minimalanforderungen auf gar keinen Fall Abstriche machen (oder wird mit den Konsequenzen leben m¨ ussen). Gleichzeitig ist diese Schicht auch die erste und wichtigste Integrationsschicht. Zusätzlich kommen auch Eigenentwicklungen und Anforderungen f¨ ur die Integration dazu.

4.3 Entscheidung u ¨ ber Basistechnologien ¨ Nach den Uberlegungen zu vorhandenen Systemen/Datenbeständen und dem extra diskutierten Punkt der Datenspeicherung ist die Frage nach den sinnvollen Basistechnologien zu stellen. Wie man schon im Kapitel 3 und in den vorangegangenen Abschnitten lesen konnte, gibt es keine eindeutige Entscheidung. Vielmehr kommt es auf eine Reihe von Randbedingungen an, welche L¨ osung am geschicktesten ist. Wie schon mehrfach betont, ist der unmittelbare Rahmen die Frage: wie umfassend eine KM Initiative sein soll, welches KM System sinnvoll ist und welche Vorbedingungen schon herrschen. Dazu geh¨ oren einerseits die schon besprochenen vorhandenen Systeme und Datenbest¨ ande. Andererseits geht es aber auch um die Frage von notwendigem und vorhandenem Know-how. 4.3.1 Know-how & Grundlagen einer Evaluierung Bei der Frage nach dem vorhandenen Know-how gibt es vor allem zwei Aspekte. Einerseits das innerhalb einer Organisation vorhandene Know-how. Andererseits das Know-how von Partnern bei der Umsetzung und/oder Wartung der geplanten Systeme. Beides ist nat¨ urlich beeinflussbar, stellt aber gleichzeitig einmal die Ausgangsbasis dar. Wichtig f¨ ur das interne Know-how ist neben der Feststellung der unmittelbar vorhandenen F¨ ahigkeiten auch eine grobe Potenzialanalyse. Dabei geht es darum festzustellen, wie man zum Beispiel mit Schulungsmaßnahmen bestimmte Fertigkeiten ausbilden kann. Weiters sollte man auch die Interessen der Mitarbeiter ber¨ ucksichtigen (und hier könnten vor allem Microsoft” J¨ unger“ ein Problem“ f¨ ur eine Open Source Strategie darstellen). Zusätzlich ” gilt es hier auch zu u ¨ berlegen, ob Neuaufnahmen ein Thema sind. Mit neuen Mitarbeitern kann man gezielt die notwendigen Fertigkeiten in das Unternehmen holen. In weiterer Folge k¨ onnen dann andere Mitarbeiter neue Fertigkeiten direkt bei der Arbeit erlernen. Je kleiner eine Organisation ist, desto wichtiger ist die Auseinandersetzung mit dem vorhandenen Personal, da man hier bestenfalls u ¨ber Einzelpersonen sprechen kann. Ein weiterer wichtiger

4.3 Entscheidung u ¨ ber Basistechnologien

89

Punkt ist auch, sich Gedanken u ogliche Widerstände gegen neue Sys¨ ber m¨ teme zu machen. Der einfachste Weg ist dabei, die vorhandenen Mitarbeiter ¨ in die Systemauswahl und die ganzen Uberlegungen einzubeziehen. Wenn das gelingt, bringen Sie einerseits ihr Wissen und ihre Erfahrung ein und man kann sich Ihrer Unterst¨ utzung in weiterer Folge fast sicher sein. Bei Partnern geht es zuerst um bestehende Partnerschaften. Es gibt ja eine Reihe von Organisationen, die nur eine minimale oder gar keine interne EDV- Truppe“ haben. In solchen F¨ allen ist die Frage der vorhandenen Fähig” keiten und des Vertrauens besonders wichtig. Hintegrund ist die einerseits wichtige Mitarbeit (das Einbringen des vorhandenen Wissens beziehungsweise Erfahrung) und andererseits das Sicherstellen der notwendigen Expertise. Diese Punkte sind insbesondere f¨ ur die Evaluierung beziehungsweise Auswahl eines zuk¨ unftigen KM Systems entscheidend. Ein genereller Vorteil von Open Source Software ist dabei das Fehlen eines Herstellers, der mit allen Mitteln versucht sein Produkt unterzubringen. Nat¨ urlich probieren das auch viele Firmen im Umfeld von Open Source. Die meisten davon haben aber nicht die notwendigen Mittel, um sich mit reinem Marketing beziehungsweise halbwahren Aussagen einen Auftrag zu sichern. ¨ Uberhaupt sollte man hier ganz besonders Acht geben. Einen langjährigen Partner, dem man vertraut, beziehungsweise gute interne Techniker sollte man auf jeden Fall einbeziehen. Gleichzeitig muss man sich u ¨ber die jeweilige Interessenslage im Klaren sein. Besonders wichtig ist die Frage nach den Interessen nat¨ urlich bei einem Partner, der von einer bestimmten Entscheidung in Form eines Auftrags profitieren w¨ urde. Hier sollte man auf jeden Fall darauf achten, eine Firma mit einer alternativen L¨ osung einzubinden und eine möglichst objektive Beurteilung durchf¨ uhren zu lassen. Eine simple Strategie daf¨ ur könnte sein, die Kontrahenten“ die oder das Konzept(e) der anderen Anbieter un” tersuchen und bewerten zu lassen. Danach sollte man mit einem möglichst unbeteiligten Dritten dar¨ uber urteilen. Es ist dabei gar nicht von entscheidender Bedeutung, das objektiv beste System auszuwählen. Es ist vielmehr wichtig ein gutes System auszuw¨ ahlen, das einem relativ einfach und billig die Anforderungen erf¨ ullt. Vielen Leuten m¨ ogen die bis jetzt beschriebenen Punkte als weit u ¨ berzogen vorkommen. So eine Kritik kann unter mehreren Umständen berechtigt sein. Einerseits wenn eine interne EDV mit gen¨ ugendem Know-how vorhanden ist. Dann liegt auf der Hand, dass die entsprechenden Leute eine Auswahl treffen sollten und m¨ oglichst weitgehend alles intern machen. Damit hat man die unmittelbar effizienteste L¨ osung gew¨ ahlt und die zuk¨ unftige Unterst¨ utzung der L¨ osung ist auch kein Problem. Andererseits kann man einen vertrauten und erfahrenen Partner haben, der einem eine L¨ osung anbieten kann. Insbesondere bei relativ geringen Investitionen (eines der wichtigen Ziele bei Verwendung von Open Source) kann man hier in vielen Fällen sicherlich auf eine teure Evaluierung verzichten. Insgesamt sollte man aber auf jeden Fall feststellen, welches Know-how vorhanden ist und m¨ oglichst viel fehlendes Know-how hinzuziehen. Auch

90

4 Technische Basis

bei einer L¨ osung, die anscheinend wenig bis gar nichts kostet, können die Einf¨ uhrungs- und Folgekoten enorm sein. Wie schon mehrfach betont, ändert ein KM System die Art und Weise, wie eine Firma arbeitet. Hier sollte man mit der gebotenen Vorsicht zu Werke gehen und sich genau u ¨ berlegen, wie man zu einem angestrebten Ziel kommt. Gleichzeitig liegt ja auch das Versprechen von KM darin, die vorhandene Arbeitsweise wesentlich effizienter zu machen. Daher sollte man sich auf keinen Fall davon abschrecken lassen. 4.3.2 Know-how Felder Worum geht es bei dem angesprochenen Know-how? Der einfachste Fall sind nat¨ urlich die vorhandenen Systeme. Bei diesen sollten sich die grundlegenden Parameter relativ einfach feststellen lassen. (Wobei auch diese Annahme öfters nicht zutrifft. F¨ ur diesen Fall sollte man eine Ablöse der betroffenen Systeme vorrangig in Erw¨ agung ziehen.) Was m¨ ogliche zuk¨ unftige Lösungen angeht, hat Kapitel 3 viele der denkbaren Systeme vorgestellt. Soweit Informationen fehlen, sind diese f¨ ur gute Techniker im Source Code oder der Konfiguration ersichtlich. Insbesondere u ¨ ber vorhandene Systeme sollte eine Organisation an sich alles an notwendigem fachlichen Wissen haben. F¨ ur die zuk¨ unftige KM Lösung ¨ m¨ ussen entsprechende Uberlegungen im Vorfeld durchgef¨ uhrt werden. Damit soll hier auch nicht intensiver darauf eingegangen werden. (Auch wenn dieses Thema ¨ außerst wichtig ist und auf gar keinen Fall ignoriert werden darf.) Wenn man an die Einf¨ uhrung eines KM Systems denkt, wird man auf jeden Fall das Wissen und die F¨ ahigkeiten zur Bewertung einer geplanten Softwarearchitektur ben¨ otigen. F¨ ur entsprechend erfahrene Leute bietet das vorliegende Buch eine gute Grundlage, um zu einer guten Entscheidung zu kommen. Selbst f¨ ur kleine KM Systeme sollte man diesen Schritt auf keinen Fall u uhrung von KM ¨ bergehen. Im einfachsten Fall sollte man eine in der Einf¨ und entsprechender Systeme erfahrene Beratungsfirma beauftragen (möglichst rein f¨ ur die Beurteilung). Abh¨ angig vom geplanten Umfang des KM Systems ist die Frage der notwendigen F¨ ahigkeiten der Softwareentwicklung mehr oder weniger wichtig. ur eine kleinere L¨ osung entscheidet, die kaum IntegrationsWenn man sich f¨ aufwand bedeutet, wird man sich nicht besonders intensiv um dieses Thema k¨ ummern m¨ ussen. Wenn man eine gr¨ oßere L¨ osung anvisiert, wird man nicht darum herumkommen. Dann wird vor allem die schon beschriebene Frage nach den vorhandenen F¨ ahigkeiten in der eigenen Organisation und eventuell mitarbeitenden externen Firmen wichtig. Insbesondere zu dieser Thematik gibt es noch einen eigenen Abschnitt in diesem Kapitel. Fragen und Wissen u ¨ber den aktuellen und geplanten Betrieb werden h¨ aufig vernachl¨ assigt. Dabei k¨ onnen sich hier große Probleme auftun und enorme Folgekosten entstehen. Einerseits gilt es, die Nutzer der zuk¨ unftigen L¨ osung m¨ oglichst optimal zu unterst¨ utzen. Andererseits muss man dieses Ziel mit minimalen Kosten erreichen. Gerade bei diesem Punkt ist es besonders


91

wichtig, auf vorhandene Erfahrung zu setzen (einerseits f¨ ur vorhandene Applikationen und soweit wie m¨ oglich auch f¨ ur angedachte Systeme). Hintergrund ist das sehr unterschiedliche Verhalten von verschiedenen Systemen in Hinblick auf notwendigen Betreuungsaufwand. Damit lässt sich dieser Aspekt mit genereller Erfahrung in einem Gebiet wesentlich schlechter schätzen als zum Beispiel eine Softwareentwicklung. Um die vier Themenbereiche noch einmal klar herauszustreichen, werden sie in folgender Aufz¨ ahlung kurz zusammengefasst: • • • •

Fachliches Wissen Wissen u ahigkeit der Bewertung von Softwarearchitekturen ¨ ber und F¨ Notwendige F¨ ahigkeiten in der Softwareentwicklung (Programmiersprachen, Datenbanken, Middleware Technologien, etc.) Wissen u ¨ ber den Betrieb

4.3.3 Programmiersprachen Bei Programmiersprachen handelt es sich um einen entscheidenden Punkt f¨ ur die Einf¨ uhrung eines gr¨ oßeren KM Systems. Bei kleineren KM Initiativen wird man sich dieser Frage vor allem in Hinblick auf zuk¨ unftige Erweiterungen widmen m¨ ussen. Das heißt in diesem Kontext geht es vor allem um die Frage, ob ein Ausbau zu einer gr¨ oßeren L¨ osung absehbar ist oder nicht. Man sieht also, dass dieser Aspekt in jedem Fall von großer Bedeutung ist. Je gr¨ oßer dabei die unmittelbar zu erwartenden Aufwände einer Erstellung eines gr¨ oßeren KM Systems auf der Basis von vorhandenen Open Source Systemen sind, desto eher wird es zu einer entscheidenden Frage f¨ ur die zu erwartenden Kosten. Das h¨ angt sehr stark mit der auch separat wichtigen Frage des vorhandenen Know-hows innerhalb einer Organisation und bei potenziellen Partnern zusammen. Im Folgenden werden zuerst die drei wichtigsten Beispiele ganz kurz charakterisiert und in einer weiteren Auflistung noch weitere drei Vertreter kurz beschrieben. Damit soll keineswegs eine generelle Aussage u ¨ ber Tauglichkeit oder Untauglichkeit getroffen werden. Es geht einerseits um die Frage der Praktikabilit¨ at im Kontext von KM und angesichts vorhandener Open Source Software. Andererseits geht es auch um banale Fragen wie der Verf¨ ugbarkeit von Entwicklern (neben anderen Faktoren; etwa Kosten und Abhängigkeit von Personen). Kurz gesagt ist eine Entscheidung f¨ ur oder gegen eine Programmiersprache immer auch eine Frage der Umstände und einer sauberen und guten Begr¨ undung. Die drei wichtigsten Sprachen, mit denen auch die meisten der beschriebenen Systeme aus Kapitel 3 arbeiten, sind: Java Die vermutlich im Moment am h¨ aufigsten eingesetzte Sprache f¨ ur Softwareentwicklung (mit Cobol als wahrscheinlicher Nummer 2). Damit ist

92

4 Technische Basis

einer der Hauptvorteile die breite Verf¨ ugbarkeit von erfahrenen Entwicklern. Java hat auch eine Reihe von Vorteilen als relativ junge Sprache (also wenig Altlasten). Weiters gibt es effiziente Entwicklungsumgebungen. Besonders hervorzuheben ist auch noch die zwischenzeitlich gute Skalierbarkeit und Tauglichkeit f¨ ur große Systeme. Zusammengenommen also die sichere“ Entscheidung. Gleichzeitig kann diese Sicherheit auch kos” ten (etwa weil extrem gute Leute eher selten in Java arbeiten). Inzwischen ist die Weiterentwicklung auch deutlich langsamer als noch gegen Ende der 1990er Jahre. PHP Die vermutlich f¨ ur kleinere bis mittlere Webanwendungen am meisten verbreitete Sprache. Ist als prinzipiell interpretierte Sprache potenziell langsamer in der Ausf¨ uhrung. (Wie aber Beispiele im Internet zeigen, kann man damit trotzdem auch große Portale performant betreiben.) Erm¨ oglicht extrem schnelles Entwickeln von Webfunktionen und hat als Ergebnis einen breiten Fundus, der meist als Open Source im Internet zu finden ist. Wenn man in Richtung einer Intranet- oder Internet-Lösung tendiert, ist PHP eine interessante und gute Wahl. Die Verf¨ ugbarkeit von Entwicklern ist auf absehbare Zeit sicher kein Problem. Durch den Hauptfokus auf unmittelbar nutzbare kleinere Systeme mit viel Benutzerschnittstelle ist aber gleichzeitig eine gr¨ oßere Integration mit PHP schwieriger. Dabei geht es nicht um M¨ angel der Sprache sondern fehlende Erfahrung, Methoden und Tools in Richtung Integration. Daher bei größeren Projekten und/oder Integrationen mit Vorsicht zu betrachten. Python Python hat eine deutlich kleinere Gemeinde als etwa Java oder PHP. Gleichzeitig hat Python einige sehr interessante Lösungen hervorgebracht und eine Reihe von ¨ außerst guten Leuten arbeitet damit. Das bedeutet, dass man generell mehr Schwierigkeiten hat, Leute zu bekommen (beziehungsweise diese teurer sind). Man hat aber auch eine größere Chance, einen oder mehrere sehr gute Leute zu bekommen, und damit im Endeffekt relativ billig zu einer u ¨ berlegenen Lösung zu kommen. Man kann sogar sagen, dass Python im Prinzip (nicht im Detail oder gar vom Aus” sehen“ her) PHP ¨ ahnelt (insbesondere da auch PHP inzwischen ein relativ brauchbares Objektmodell hat). Hier sollte man also vor allem die folgenden Fragen beantworten: • • •

Haben die vorhandenen Python L¨ osungen alles, was gebraucht wird? Ist eine Minderheitenl¨ osung“ auf lange Sicht akzeptabel? ” Hat man erfahrene Leute oder Partner oder will man entsprechende Erfahrungen aufbauen und pflegen?

Daneben gibt es vor allem noch (grob) drei weitere Vertreter, die auch teilweise bei den beschriebenen Systemen im Einsatz sind: Perl Perl ist eine f¨ ur kleinere Aufgaben sehr gerne verwendete Skriptsprache. Als Folge gibt es damit eine ganze Reihe von Systemen und Tools, die auf einer großen Sammlung von Libraries aufbauen können. Viele der Perl


93

Systeme leiden aber an fehlender Strukturierung und schlechter Wartbeziehungsweise Erweiterbarkeit. F¨ ur kleinere Aufgaben beziehungsweise eine lose Kopplung sollte man es aber durchaus im Auge behalten. Gleichzeitig ist fraglich, ob Perl als Basis f¨ ur ein potenziell größeres System geeignet ist. Technisch ist es sicherlich machbar und man kann auf eine ganze Menge an Libraries und (meist kleinere) Systeme zur¨ uckgreifen. IT Leute mit entsprechender Erfahrung sind ausreichend vorhanden. Kurz gesagt scheint es eher f¨ ur kleinere Systeme oder als Ergänzung (zum Beispiel Scripting innerhalb einer gr¨ oßeren Applikation etwa innerhalb eines Workflows) eines gr¨ oßeren Systems geeignet. C/C++/Objectiv-C C und die beiden wichtigsten objektorientierten Erwei” terungen“ C++ und Objective-C (kurz Obj-C) stellen f¨ ur ein aktuelles KM System eine zwiesp¨ altige Sache dar. Erfahrene Entwickler gibt es durchaus in großer Zahl. Die Sprachen eignen sich f¨ ur große und insbesondere performancekritische Anwendungen. Gleichzeitig sind sie etwas aus dem Fokus geraten (prim¨ ar zugunsten von Java beziehungsweise C#). Wie man gesehen hat, gibt es entsprechende Open Source Systeme, mehr Auswahl hat man aber bei Java und PHP. Ein Problem ist die generell niedrigere Programmierereffektivit¨ at in den C-ähnlichen Sprachen verglichen mit praktisch allen anderen erw¨ ahnten Beispielen. Man sollte diesen Effekt aber auch nicht dramatisieren. Wichtig ist auch die Tatsache, dass zumindest C-Code in fast allen anderen Sprachen leicht integrierbar ist. Damit ist es m¨ oglich, performancekritische Bereiche in C/C++ umzusetzen und den Hauptteil der Anwendung in einer anderen Sprache zu entwickeln. Objective-C stellt bis auf das Apple-Umfeld eher eine Minderheitenl¨ osung“ dar. Dagegen k¨ onnen die Rahmenbedingungen (wie ” andere Systeme, Schnittstellen und vorhandene Erfahrung) durchaus f¨ ur eine C/C++ L¨ osung sprechen. Angesichts der Dominanz von Java, PHP, Perl und Python im KM relevanten Open Source Umfeld (in einigen Nischen ist auch C beliebt) sollte man sich so eine Entscheidung aber gut u ¨ berlegen. .NET (C#, VB.NET, ASP.NET, etc.) Bei der .NET Plattform von Microsoft kann man feststellen, dass es eine umfassende und sehr aktuelle Umgebung darstellt. (Noch ist nicht alles in der Microsoft Welt komplett auf .NET umgestellt aber das ist nur eine Frage der Zeit.) Generell ist die .NET Plattform jedoch schlecht f¨ ur eine Open Source Lösung geeignet. Es gibt zwar offene Implementierungen, die kein Microsoft Betriebssystem erfordern (vor allem das Mono Projekt), aber die Zukunft solcher Lösungen ist potenziell problematisch (man denke nur an Patente, die Microsoft an der .NET Technologie h¨ alt). Damit soll nicht gesagt werden, dass man keine guten und billigen KM L¨ osungen mit .NET machen könnte. Es sind aber typischerweise keine reinen Open Source Lösungen und werden daher nicht n¨ aher betrachtet. Es gibt dabei aber einen Einsatzzweck, der auch in einer u ¨ berwiegenden Open Source Lösung Sinn macht. Wenn man mit Microsoft Client Produkten arbeitet und gleichzeitig ein Open Sour-

94

4 Technische Basis

ce KM System anstrebt, ist es potenziell wichtig, ein .NET Interface zu haben und in .NET entwickeln zu k¨ onnen. Aufgrund der Popularität der Plattform sollte man dabei keine großen Probleme haben, entsprechende Partner beziehungsweise Entwickler zu finden. Ein wichtiges Beispiel ist das Verwenden von Microsoft Outlook als Client f¨ ur ein KM System. Da bietet sich .NET als Integrationsplattform auf der Microsoft Seite an. Auf der anderen Seite k¨ onnte man einen Web Service oder auch ein eigenes .NET Service haben. Auf die Frage, wie man Open Source Entwicklungen auf Basis .NET durchf¨ uhren kann, wird etwa auch im k¨ urzlich erschienen Buch Open Source .NET Development“ von Brian Nantz eingegangen. ” Damit enth¨ alt schon die Darstellung der relevantesten Programmiersprachen eine Reihe von Empfehlungen. Gleichzeitig kann eine Entscheidung nur in einer konkreten Situation erfolgen. Insbesondere bei Programmiersprachen sollte man bedenken, dass man jede Entwicklung auch warten muss, und darauf achten, nicht zu viele unterschiedlichen Techniken und Sprachen im Einsatz zu haben. Allerdings muss man bei einer möglichst intensiven Verwendung von bestehenden Open Source Systemen eine gewisse Diversität in Kauf nehmen. Einen Ausweg k¨ onnen hier vor allem kompetente externe Integrationspartner bieten, die fallweise eingreifen k¨ onnen und gleichzeitig eine Reihe an Technologien beherrschen sollten. In der aktuellen Situation im Bereich Programmiersprachen und in Hinblick auf KM relevante Open Source Systeme gibt es zumindest eine Reihe an Empfehlungen. F¨ ur gr¨ oßere Systeme und auch generell ist Java sicher keine schlechte Wahl. Bei PHP sollte man vor der Implementierung eines größeren Systems genau analysieren, wie man mit Integrations- und Skalierungsthemen umgeht. Bei Python muss man sich fragen, ob man es sich leisten kann, ein Minderheitensystem“ zu verwenden. Bei den anderen beschriebenen Pro” grammiersprachen gilt es genau zu u ¨ berlegen, ob sie die richtige Wahl sind. Ziel ist es dabei, m¨ oglichst viel in einer definierten Sprache zu machen. Die sollte nat¨ urlich auch von den zu integrierenden Systemen verwendet werden. Andere Sprachen kann man bei Spezialaufgaben beziehungsweise zur Integration verwenden. Dar¨ uber hinaus sollte man auch die kurzen Hinweise in Kapitel 3 beachten. 4.3.4 Connectivity – Middleware Wenn man mehrere Systeme verbinden will, benötigt man unbedingt eine möglichst flexible Kopplung. Dabei gilt es, eine Reihe von Fragen zu beantworten. Die beiden potenziell Wichtigsten sind die Anbindung an die Datenbank und die Verbindung von verschiedenen Systemen beziehungsweise Systemteilen u ¨ ber diverse Grenzen hinweg (Rechner, Programmiersprache, etc.). Daneben gibt es auch die Anbindung von verschiedenen Geräten beziehungsweise Benutzerschnittstellen. Dabei kann es sich um ein Handy, einen PDA, einen Browser oder auch einen klassischen Client handeln. In all diesen Fällen kann man Middleware einsetzen.


95

Ein wenig anders liegt die Sache, wenn man sich innerhalb eines Application Servers oder einer ¨ ahnlichen Sache (etwa eines Portals) befindet. Hier gibt es eine Infrastruktur, die man am besten verwendet. Es gibt dann Schnittstellen zur Datenbank, zu anderen Systemteilen und eine gemeinsame Infrastruktur. Ein wichtiger Grund davon abzuweichen kann dabei die Notwendigkeit der Integration mit anderen Systemen sein. Auch in diesem Fall sollte man versuchen, m¨ oglichst nahe an den zur Verf¨ ugung gestellten Schnittstellen zu bleiben. Im Idealfall ersetzt man zum Beispiel die Datenbankschnittstelle durch eine eigene Version, die auch weitere Daten anbindet (als klassisches Beispiel, warum das u ¨ berhaupt eine Frage sein könnte). Neben Technologien, die eine relativ hohe Abstraktionsebene bieten, stehen auch noch andere Tools f¨ ur ¨ ahnliche Zwecke zur Verf¨ ugung. Es gibt etwa Wrappergeneratoren, die Services“, die etwa in C++ geschrieben sind, f¨ ur ” Anwender in Python, Java, etc. bereithalten (wobei es in Java auch direkt eine Möglichkeit gibt). Ein gutes Beispiel ist hier das Tool SWIG (www.swig.org), das etwa von Google intern eingesetzt wird und primär C/C++ Funktionen in Python, PHP, Java und noch vielen weiteren Programmiersprachen ¨ zur Verf¨ ugung stellt. Ahnliche Ans¨ atze (prim¨ ar f¨ ur C++) bieten auch Generatoren wie Boost (eine Python Library), ctypes (etwa zum dynamischen Laden von C Libraries und Aufrufen der enthaltenen Funktionen geeignet), calldll (unter Windows) oder cxx. Dabei handelt es sich um eine Technologie, die das Mischen von Programmiersprachen erleichtert. Gleichzeitig muss man sich immer noch u ¨berlegen, ob man sich das leisten kann und will (etwa vom notwendigen Know-how und der Anzahl der Entwickler her). Insbesondere f¨ ur Randgebiete eines KM Systems spricht aber viel f¨ ur solche Generatoren, wenn damit wichtige Funktionen erg¨ anzt werden können. Daher sollte man diese M¨ oglichkeit im Fall des Falles entsprechend mitbetrachten und analysieren. Eigene Middleware Systeme sind insbesondere dann wichtig und sinnvoll, wenn es um eine Verbindung u ¨ ber Rechnergrenzen hinweg geht beziehungsweise eine andere Architektur (Programmiersprache, etc.) anzubinden ist. Hier gibt es eine Reihe von sehr guten Tools, die je nach verwendeter Basis zum Einsatz kommen sollten. Web Services Die sicherlich neueste und universalste Technologie in diesem Zusammenhang sind dabei Web Services, insbesondere wenn sie dem SOAP Standard entsprechend. Damit kann man die meisten besprochenen Systeme relativ problemlos untereinander verbinden (mit XML Nachrichten u ¨ber HTTP transportiert). Vor allem wird sich in n¨ achster Zeit alles in diese Richtung entwickeln und die Unterst¨ utzung immer besser und ausgereifter werden. (Aktuell gibt es ja noch einige Defizite gegen¨ uber schon länger am Markt befindlichen Techno¨ logien wie etwa CORBA). Man hat als Folge der XML Ubertragung zwar einen hohen Overhead aber im Weiteren eine gut verstandene Schnittstelle.

96

4 Technische Basis

Durch die Art der Anbindung sind sie eher f¨ ur eine grobkörnige Kopplung von Systemen gedacht (sprich: kleine Menge an gebotenen Aufrufen, bei denen jeder einzelne relativ viel Funktionsumfang hat). Problematisch könnte vor allem die Anbindung von Altsystemen werden, die zum Teil nicht einmal XML beherrschen. CORBA CORBA (Common Object Request Broker Architecture) ist eine inzwischen relativ ausgereifte und performante Middleware mit dem Ziel, möglichst unabh¨ angig von der Programmiersprache zu sein. Nach dem großen Erfolg von Java (RMI und Application Server), Web Services und auch .NET gerät es in letzter Zeit eher in den Hintergrund (wobei es eine Basis von J2EE ist). Gleichzeitig bietet es die M¨ oglichkeit, auch mit kleineren Funktionsblöcken gut zu arbeiten und ist f¨ ur fast alle relevanten Programmiersprachen und Technologien verf¨ ugbar. Daher bietet es sich insbesondere f¨ ur die Integration von relativ heterogenen Systemen an, die einen guten ORB (eine Implementierung von CORBA) haben. Auch wenn Performance und Bandbreite ein Thema sind, ist CORBA sicher die beste Middleware mit einem gleichzeitig allgemeinen Einsatzspektrum. Auch die Komplexit¨ at von CORBA im Vergleich zu anderen Technologien wird meistens u atzt. Die grundsätzlichen Problematiken ¨ bersch¨ von verteilten Systemen bleiben einem aber auch mit CORBA nicht erspart. RMI Mit RMI (Remote Method Invocation) kann man Java Programme einfacher als mit CORBA (im Prinzip aber recht ¨ ahnlich) verbinden. Vor allem skaliert diese L¨ osung nicht so gut. Gleichzeitig d¨ urfte das in kleineren bis mittleren Systemen keine Rolle spielen. Damit bleibt das Hauptproblem, dass RMI nur zwischen Java Applikationen funktioniert und damit ein eingeschränktes Einsatzgebiet hat. Weitere Middlewaretechnologien Nat¨ urlich gibt es noch eine Reihe weiterer wichtiger Technologien, die ein ähnliches Ziel verfolgen (zum Beispiel Portlets zu denen im Abschnitt u ¨ ber Portale mehr zu lesen ist). Weiters gibt es auch simple proprietäre Protokolle u ¨ ber HTTP oder Alternativen zu Web Services. Im Einzelfall können auch primär vor CORBA wichtige Technologien von Relevanz sein. Wichtige Beispiele sind: Sun RPC (Remote Procedure Call), Microsoft DCOM (Distributed Component Object Model), Tibco Rendezvous, IBM WebSphere MQSeries und BEA Tuxedo. Wie man schon an den Firmennamen erkennt, handelt es sich um kommerzielle Systeme und eine reine Open Source Lösung muss ohne sie auskommen. Bis auf die ersten beiden Beispiele benötigt man außerdem relativ


97

teure Lizenzen. Wichtig sind diese Technologien hauptsächlich zur Anbindung von Systemen, die so eine Schnittstelle haben. Am besten ist dabei eine Kapselung der Funktionen mittels einer Open Source Middleware (beziehungsweise von der Schnittstelle in Richtung etwas Neutralerem wie zum Beispiel dem Java JMS zu abstrahieren). Datenbankanbindung Teilweise wird auch eine Datenbankanbindung unter dem Begriff Middleware subsumiert. Von den bisher unter diesem Begriff vorgestellten Technologien unterscheidet sich das Anbinden einer Datenbank aber deutlich. Generell ist der wichtigste Punkt, eine von der Datenbank unabhängige Schnittstelle zu haben. Diese Forderung erf¨ ullen eine ganze Reihe von Technologien. Im Java Umfeld ist dabei sicher JDBC der wichtigste Standard wobei EJBs hier erg¨ anzend oder aus Sicht des Programmierers ersetzend hinzukommen k¨ onnen. Aber auch bei PHP gibt es gute Datenbankabstraktionen (etwa ADOdb oder PHP PEAR) und bei Python wurden ja primär Zope und darauf aufbauende Produkte vorgestellt. Damit ist die Datenbankanbindung soweit nötig durch Zope gegeben. Zus¨ atzlich kommt noch die Anforderung, weitere Datenquellen transparent einbinden zu k¨ onnen. Damit wird man entweder eine vorhandene Schnittstelle erweitern, ersetzen oder darauf aufbauend eine Neue schaffen m¨ ussen. Die Wichtigkeit gerade dieses Aspekts sollte man auf keinen Fall untersch¨ atzen. Hier wird eine Basis f¨ ur spätere Erweiterungen und Ausbauten geschaffen. Deshalb sollte man hier auch f¨ ur kleinere Systeme entsprechend viel Zeit und Aufwand investieren (und wenn es nur f¨ ur ein solides und durchdachtes Konzept ist). Zusammenfassung Insgesamt geht es bei Connectivity prim¨ ar um Technologien f¨ ur verteilte Applikationen etwa zur Kopplung mehrerer Systeme. Daran erkennt man die unmittelbare Relevanz. Kurz gesagt muss man bei der Zusammenstellung eines KM Systems aus mehr oder wenigen vielen Open Source Produkten darauf achten, wie man die einzelnen Bestandteile m¨ oglichst effizient und einfach miteinander koppeln kann. Gleichzeitig sollte man sich an den schon vorhandenen Technologien orientieren. Dar¨ uber hinausgehend sind vor allem Web Services und auch noch CORBA interessante Ans¨ atze durch ihre fast generelle Einsetzbarkeit. Wenn es um das Einbinden von Code einer Programmiersprache in ein System auf Basis einer anderen Programmiersprache geht, gibt es weiters eine Reihe von Technologien wie etwa Wrappergeneratoren. In bestimmten F¨ allen kann das eine ideale L¨ osung sein, bei der man aber die Folgekosten und Komplexit¨ at nicht untersch¨ atzen sollte. Daneben gibt es vor allem noch die Frage der Datenbankanbindung. Diese wurde ja im Abschnitt u ¨ ber Datenspeicherung schon zum Teil diskutiert.

98

4 Technische Basis

Kurz gesagt geht es hier vor allem darum, eine Abstraktionsebene zu schaffen. Einerseits in Richtung Datenbank, um von bestimmten Datenbanken unabh¨ angig zu sein. Andererseits auch in Richtung der Applikation, damit man diese Schicht f¨ ur eine m¨ oglichst nahe der Persistenzschicht liegenden Integration nutzen kann. 4.3.5 Application Server Der Begriff Application Server ist wie viele andere in der IT Branche nicht eindeutig definiert. (Einerseits wegen Meinungsverschiedenheiten von Technikern und andererseits wegen den Marketingabteilungen der kommerziellen Softwarehersteller.) Kurz gesagt geht es um den Ausf¨ uhrungsort“ der ” Gesch¨ aftslogik. Die beiden wichtigsten anderen Bereiche einer Applikation sind die Benutzerschnittstelle und die Datenhaltung (Persistenzschicht). Mit dieser Definition ist zumindest eine ganz grobe Abgrenzung gegeben. Im Java Umfeld ist der Begriff im Großen und Ganzen von den J2EE Application Servern belegt (mit den Marktf¨ uhrern BEA WebLogic und IBM WebSphere; bei den Open Source Vertretern sind vor allem JBOSS und JOnAS zu nennen). Im Bereich Python nimmt Zope als wichtigstes Produkt den Titel f¨ ur sich in Anspruch. Bei PHP kann man insbesondere XOOPS als eine Art Application Server sehen (beziehungsweise auch als Portal). Aktuell ist die Karawane“ des Marketing gerade in Richtung Portal unter” wegs. Daher wird der Begriff Application Server zugunsten des Portal Server in den Hintergrund gedr¨ angt. Zumindest im Java Umfeld kann man dabei sagen, dass Portal Server auf einem Application Server aufbauen und eher eine Art Erweiterung darstellen. Abseits von Java wird die Sache sowieso noch schwieriger, da J2EE eigentlich der einzige wichtige Standard f¨ ur solche Produkte ist. Damit wird die Unterscheidung noch schwieriger beziehungsweise kann nur noch willk¨ urlich getroffen werden. F¨ ur ein KM System ist es dabei unerheblich, ob man einen Application Server einsetzt oder nicht. Wenn zumindest eines der angedachten Open Source Systeme einen entsprechenden Server benötigt, sollte man versuchen m¨ oglichst viel in diesem zur Ausf¨ uhrung zu bringen und eine möglichst enge Integration zu erreichen. Aufgrund der Komplexität der meisten Application Server sollte man es vermeiden mehr als eine Instanz zu verwenden. Generell betrachtet ist die eben angesprochene Komplexität der negati” ve“ Punkt von Application Servern. Damit soll aber nicht gesagt werden, dass ein Einsatz nicht h¨ aufig Sinn macht. Insbesondere wenn man damit mehrere zu integrierende Systeme zusammen ausf¨ uhren und die Infrastruktur entsprechend sinnvoll einsetzen kann, sollte man auf jeden Fall einen Application Server verwenden. Es ist nicht Sinn und Zweck dieses Buches näher auf Application Server einzugehen (jeder einzelne w¨ urde sicher mehrere B¨ ucher f¨ ullen). Die f¨ ur KM Relevantesten findet man im Kapitel 3 bei den Kandidaten, die einen benötigen. Dabei gibt es auch jeweils Hinweise auf Open Source Vertreter (bei kom-

4.4 Basis Portal?

99

merziellen Systemen werden teilweise enorme Summen pro verwendeter CPU fällig).

4.4 Basis Portal? Auch beim Begriff Portal fehlt eine klare Definition. Dazu kommt noch, dass es sich um ein generelles englisches Wort handelt. Im Prinzip geht es um die Zusammenfassung unterschiedlichster Aspekte zu einer Sicht. Im Internet wurde der Begriff urspr¨ unglich f¨ ur eine Art Zugänglichmachen der Inhalte (durch eine Suche und entsprechende Nachrichten, Kataloge und Verlinkungen) verwendet. Bei einem Portal Server geht es eher um Infrastrukturaspekte. Das Portal k¨ ummert sich um u ¨ bergreifende Aspekte wie eine Authentifizierung und in weiterer Folge Personalisierung beziehungsweise stellt den meist Portlets genannten Bereichen des Bildschirms“ alles Notwendige zur Verf¨ ugung. Da” mit wird auch klar, warum sich Portale als eine Integrationsschicht anbieten. Insbesondere ist damit eine extrem lose Kopplung möglich. Dabei kann das Ergebnis Benutzer des Systems durchaus u ¨ berraschen, da im Extremfall eine gar nicht existierende Verbindung der Systeme vorgetäuscht“ wird. ” 4.4.1 Portal Server Aktuell befinden sich Portal Server eher am Anfang ihrer Entwicklung. Standards sind noch nicht gesetzt. Im Hinblick auf Java existieren inzwischen der Java Portlet (JSR 168) sowie der WSRP Standard, die aber noch L¨ ucken aufweisen. F¨ ur andere Bereiche (zum Beispiel PHP/.NET) findet man primär Produkte mit jeweils propriet¨ aren Standards. Daraus ergibt sich die Forderung, Entwicklungen und Module m¨ oglichst unabhängig von der konkreten Laufzeitumgebung zu gestalten. Im Hinblick auf kleinere Organisationen bleibt auch noch anzumerken, dass die prinzipiellen Vorteile eines Portal Servers mit der Größe der Organisation zunehmen. F¨ ur eine Hand voll Benutzer ist es nicht besonders wichtig, Funktionalit¨ aten leicht zu Benutzern oder Benutzergruppen dazu- oder weggeben zu k¨ onnen. Es kann sogar der notwendige Aufwand f¨ ur eine generelle Lösung deutlich h¨ oher werden, als eine kleine L¨ osung auf einer weniger ausgefeilten Basis (selbst mit einer Berechtigungssteuerung f¨ ur Teile der Funktionen). Auch Personalisierung wird generell weniger genutzt als angenommen. Daf¨ ur gibt es insbesondere zwei Hintergr¨ unde: •

Erstens d¨ urfen Benutzer h¨ aufig nur eine geringe oder gar keine Individualisierung eines Systems durchf¨ uhren (sprich vorhandene Möglichkeiten werden abgeschaltet).

100

•

4 Technische Basis

Zweitens sind erfahrene Benutzer auch bei längeren Navigationswegen in der Lage diese effizient zu bedienen (bei einem entsprechend reaktionsfreudigen System) und empfinden lange Wege meist nicht als nennenswertes Problem.

In der beschriebenen Situation muss man also entscheiden, inwieweit einem eine vorhandene Portalinfrastruktur tatsächlich helfen kann. Dabei ist klar, dass es insbesondere im Java Umfeld in diese Richtung gehen wird. Bei PHP fehlen u uhungen er¨bergreifende Standards, es sind aber durchaus Bem¨ kennbar, dass das Austauschen von Modulen einfacher wird. Bei .NET ist ebenfalls zu erwarten, dass es in Richtung möglichst leicht austauschbarer Module gehen wird. Hierbei handelt es sich aber nur um ein Randthema f¨ ur das vorliegende Buch. 4.4.2 Portal Generell gehen die meisten der vorgestellten größeren Frameworks in Richtung einer Modularisierung der Funktionen. Damit stellt sich nicht nur die Frage nach einem Portal Server sondern auch nach der Tauglichkeit der vorhandenen Ans¨ atze. Die entsprechenden Produkte nennen sich meist Portal und halten eine m¨ oglichst standardisierte Umgebung f¨ ur einzelne Module bereit. Insbesondere sind einige der vorgestellten Systeme direkt ein Portal oder stellen vieles, was eine entsprechende Infrastruktur anbieten sollte, zur Verf¨ ugung. Typischerweise ist das eine HTML L¨ osung mit allen damit verbundenen Vor- und Nachteilen. Mit entsprechendem Aufwand kann man eine Intranet Lösung schon fast identisch zu klassischen Applikationen machen. Ein gewisser Unterschied wird aber noch f¨ ur l¨ angere Zeit vorhanden sein (und wenn man nicht bestimmte Browser und Browserfunktionen voraussetzen kann, ist ein deutlicher Unterschied da). Pro Portal F¨ ur ein Portal spricht, dass der Trend eindeutig in diese Richtung geht. Damit kann man mit einem Portal eher an neuen Entwicklungen teilhaben. Auch d¨ urfte es in Zukunft leichter sein, Fremdmodule in ein Portal als in eine andere L¨ osung zu integrieren. F¨ ur Eigenentwicklungen beziehungsweise Anpassungen hat man ebenfalls eine ideale“ Umgebung (das heißt mit einer starken Beto” nung der Verwendung von Infrastruktur) zur Verf¨ ugung. Trotz der zum Teil fehlenden Standards gibt es schon recht brauchbare Portal Server beziehungsweise Systeme. Darauf aufbauend kann man relativ zukunftssicher weitere Funktionen integrieren beziehungsweise entwickeln. Contra Portal Gegen ein Portal spricht die aktuell kaum vorhandene Standardisierung. Damit ist abzusehen, dass aktuelle Systeme und insbesondere Eigenentwicklun-

4.5 Bild eines umfassenden KM Systems

101

gen an zuk¨ unftige Entwicklungen anzupassen sein werden. Weiters sind aktuelle Portalsysteme noch in einem starken Umbruch begriffen und weisen in einigen Bereichen zum Teil deutliche Defizite auf. Stabile und erprobte Systeme und Frameworks stehen auf der anderen Seite bereit, um auf Ihnen aufbauend neue Funktionen zu entwickeln. Gerade bei diesen Systemen muss man dabei kritisch analysieren, ob eine Weiterentwicklung stattfinden wird oder schon eine gewisse Stagnation beziehungsweise Abwendung“ von Entwicklern zu ” sehen ist. 4.4.3 Zusammenfassung Insgesamt sieht man, dass das Thema Portal aktuell schwierig ist. Einerseits werden zuk¨ unftige Systeme ganz klar in diese Richtung gehen. Andererseits sind im Moment wenige Standards verf¨ ugbar und eine komplette Lösung ist darauf angewiesen, die L¨ ucken“ selbst auszuf¨ ullen. Kurz gesagt sollte man ” sich von dem Hype“ um Portale auf gar keinen Fall anstecken lassen. Da aber ” der Zug“ in Richtung Portale unmittelbar einmal abgefahren“ ist, sollte ” ” man gleichzeitig schauen, ob man die entsprechenden Systeme und Initiativen sinnvoll nutzen beziehungsweise einbinden kann. Damit ist die beste Strategie unabh¨ angig von der Frage Portal oder nicht das gew¨ unschte Zielsystem zu definieren. Wenn es in Richtung eines Portals geht, dann sollte man diese Entscheidung auch wegen der Zukunftssicherheit weiterverfolgen. Wenn die Evaluierung eher gegen ein Portal spricht, sollte man die Frage wie es in Zukunft mit den gew¨ ahlten Systemen und Produkten weitergeht besonders kritisch durchleuchten. Wenn dabei ein positives Ergebnis herauskommt, ist eine Entscheidung gegen ein Portal sicher zu rechtfertigen.

4.5 Bild eines umfassenden KM Systems Basierend auf der Vision aus Kapitel 2 und möglicher technischer Grundlagen aus diesem Kapitel kann man eine grobe Grafik eines umfassenden KM ¨ Systems machen. Damit wird ein Uberblick u ¨ ber die Zusammenhänge so eines Systems geboten. Wichtig dabei ist, dass alle funktionalen Anforderungen an ein KM System unmittelbar adressiert sind. Bis zu einem gewissen Grad handelt es sich auch nicht um ein konkretes Ziel sondern um eine komplette Darstellung, in welche Richtung man gehen sollte. Die Diskussionen und Analysen der folgenden Kapitel werden auch genau auf dieser Basis aufgebaut sein. ¨ Abbildung 4.1 zeigt genau diesen Uberblick. Man sieht sehr schön den zentralen Aspekt einer einheitlichen Benutzeroberfläche und darunter“ die auf ” der einheitlichen Datenbasis aufbauenden Aspekte wie etwa KI Technologien. Ganz besonders wichtig ist auch noch der Berechtigungsfilter, der jeden Zugriff

102

4 Technische Basis

Struktur Struktur & & Hierarchie Hierarchie

Suchen & Finden

Erfassen

Groupware (Leute verbinden)

Einheitliches und konsistentes Benutzerinterface (etwa mittels eines Portals)

Workflow Unterstützung

Kontext/Links/ Historie (Automation)

KI/DM/KDD/ML (Transformation)

Einheitliche Zugriffsschicht

Speicherung (DMS/DBMS)

Integrieren/ Einbinden

Abb. 4.1. Darstellung eines umfassenden KM Systems

Insbesondere Business SW wie ERP, CRM, SCM, ... aber auch etwa ein Ticket Request System oder eine Digital Library, ...

Berechtigungssystem

4.5 Bild eines umfassenden KM Systems

103

auf die Daten u ¨ berwacht. Auch die Integration oder Einbindung von weiteren Systemen insbesondere Business Software ist von enormer Bedeutung. ¨ Insgesamt zeigt dieser Uberblick eine Vision“ eines umfassenden KM Sys” ¨ tems. Man sollte sich bei jeder u f¨ ur ein KM System fra¨berlegten Anderung gen, ob man damit in Richtung dieses Bildes oder dagegen arbeitet. Nur selten wird es gerechtfertigt sein, gegen“ diese Vision zu entscheiden. ”

5 Start mit einem Groupware System

Die bisherigen Kapitel haben u ¨ berwiegend grundsätzliche Punkte diskutiert. In den folgenden Kapiteln wird versucht, eine möglichst konkrete Anleitung f¨ ur die Einf¨ uhrung und den Aufbau eines KM Systems zu geben. An dieser Stelle soll auch noch einmal auf die Wichtigkeit einer komplett durchdachten KM Initiative hingewiesen werden. Es macht keinen ( KM-“)Sinn eine IT L¨ osung einzuf¨ uhren, wenn die Ziele und organisato” rischen Bedingungen beziehungsweise Auswirkungen ganz oder in größeren Teilen unklar sind. Ein wenig einschr¨ anken muss man diese Aussage noch f¨ ur den Fall, dass ein IT System mehreren Zwecken dienen soll. Insbesondere ein Groupware System kann f¨ ur sehr viele Zwecke eingesetzt werden (zum Beispiel Unterst¨ utzen der Teamarbeit innerhalb einer Hierarchie und/oder eines Projektes). Unter solchen Vorzeichen“ kann es Sinn machen, einen Teil der ” IT Infrastruktur auch in Richtung KM vorwegzunehmen“. Um die detaillier” te und komplette Analyse der KM Anforderungen kommt man aber auch so nicht herum (beziehungsweise sollte man sich u ¨ber ein Scheitern einer schlecht durchdachten Initiative nicht wundern). Wie der letzte Absatz noch einmal zeigt und auch schon fr¨ uher klar beschrieben wurde, sind Groupware Systeme f¨ ur eine Vielzahl von Aufgaben gut geeignet. Daraus ergeben sich unmittelbar zwei wichtige Punkte. Einerseits haben viele Firmen schon ein Groupware System (insbesondere größere Organisationen sogar oft mehr als eines). Andererseits muss man die nicht KM-relevanten Einsatzzwecke bei einer Analyse mitber¨ ucksichtigen. Auf den sehr wichtigen ersten Punkt wird im Weiteren noch näher eingegangen werden. F¨ ur den Fall, dass noch kein Groupware System vorhanden ist, besteht neben ¨ den prinzipiellen Uberlegungen von nicht KM-Aspekten auch die Möglichkeit eine andere Basis (beziehungsweise einen anderen Start) f¨ ur das KM System zu w¨ ahlen. Die wichtigste Alternative in Form von CMS Systemen wird in Kapitel 6 untersucht. Dieses Kapitel geht davon aus, dass es eine durchdachte Strategie“ f¨ ur ” ein KM System gibt – basierend auf einer gut u ¨ berlegten KM Initiative. Auf dieser Grundlage werden die relevanten Punkte diskutiert. Insbesondere die

106


Frage, ob man eine vorhandene Groupware weiterverwenden oder eine neue einf¨ uhren soll. Weiters geht es auch darum, welche Punkte f¨ ur den Start eines KM Systems mit einer Groupware sprechen und welche eher dagegen (und u ur ein CMS). F¨ ur diese beiden und alle weiteren relevanten ¨ berwiegend f¨ Fragen werden Entscheidungskriterien analysiert und vorgestellt. Dabei sollte man kein simples Ger¨ ust erwarten sondern eher eine Art Anleitung, wie man selbst in einer konkreten Situation zu einer m¨ oglichst sinnvollen und langfristigen Entscheidung kommen kann.

5.1 Einfu ¨ hren oder Weiterverwenden Je gr¨ oßer eine Organisation desto wahrscheinlicher ist es, dass sie schon ein Groupware System im Einsatz hat (dies gilt neben anderen Faktoren wie Technikaffinit¨ at der Branche beziehungsweise den handelnden Personen). Gleichzeitig gibt es immer noch viele, die kein oder kein adäquates System verwenden. Damit gibt es drei Gruppen, bei denen leider zwei nur schwer unterscheidbar sind. Erstens die simple Kategorie, die kein Groupware System im Einsatz hat. F¨ ur diese Gruppe sind einige der folgenden Diskussionen wie auch der n¨ achste Abschnitt dieses Kapitels u ussig. Die Schwierigkeiten“ ¨ berfl¨ ” ergeben sich n¨ amlich bei der Unterscheidung zwischen Systemen, die sinnvoll in ein KM System integriert oder gar als Basis benutzt werden können, und nicht ad¨ aquaten“ Systemen. Dabei sind prim¨ ar zwei Aspekte zur Beurteilung ” heranzuziehen. Einerseits, ob das System ausreichend und möglichst effizient Groupware Funktionen bereitstellt. Andererseits, ob es sinnvoll in das geplante KM System passt. Kurz zusammengefasst sind die drei Gruppen also: • • •

Organisationen ohne Groupware Organisationen mit Groupware, die sinnvoll integriert werden kann Organisationen mit Groupware, die nicht zum KM System passt

Neben den funktionalen und technischen Aspekten, die f¨ ur oder gegen die Weiterverwendung eines bereits vorhandenen Systems sprechen“ können, ist ” auch die finanzielle Komponente zu ber¨ ucksichtigen. Dabei gibt es eine Reihe von wichtigen Parametern: Wie hoch sind die Kosten des vorhandenen Systems (Abschreibungen, laufende Wartung, Betreuung, notwendige Erweiterungen beziehungsweise Upgrades). Wie hoch sind die Kosten einer Integration des vorhandenen Systems in das geplante KM System (einerseits die initialen Projektkosten, andererseits laufende Wartung, Betreuung und soweit notwendig Lizenz- und Softwarewartungskosten). Und nat¨ urlich wie hoch die Kosten eines Umstiegs auf eine Open Source Lösung im Rahmen des KM Systems sind (zus¨ atzliche Projektkosten sowie zu erwartende laufende Kosten). Ein weiterer Punkt f¨ ur den Vergleich ist auch, inwieweit vorhandene Hardware weitergenutzt werden kann und was an entsprechenden Investitionen bei den unterschiedlichen Varianten notwendig ist.

5.1 Einf¨ uhren oder Weiterverwenden

107

Man sieht also sofort, dass wir hier von einer komplexen Sache sprechen und es durchaus zeitaufwendig (und damit teuer) werden kann, alles Notwendige zu erheben. Bis zu einem gewissen Grad wird man das allerdings nicht verhindern k¨ onnen und wollen (außer man setzt auf das Prinzip Augen zu und ” durch“). Gleichzeitig ist es nicht Sinn der Sache, schon die Analyse prohibitiv teuer zu machen. Um trotzdem ein sinnvolles Ergebnis zu bekommen, muss man sich einerseits auf die potenziell problematischen Punkte konzentrieren und andererseits sollte man versuchen, in diesen Fragestellungen erfahrene Personen einzubinden. Konventionell betrachtet gehören zu letzterem Punkt haupts¨ achlich Consultingfirmen. Es gibt aber auch andere Möglichkeiten, wie den Kontakt zu Organisationen mit ¨ ahnlichen Problemen oder auch Universit¨ aten zu suchen. 5.1.1 Einf¨ uhrung eines Groupware Systems Wenn noch keine Groupware im Einsatz ist, hat man aus einer theoretischen ¨ Sicht ideale Bedingungen. Es gibt keine Probleme mit dem Andern der Arbeitsweise und man kann neue Arbeitsabl¨ aufe optimal an KM Anforderungen ausrichten. Außerdem hat man keine Schwierigkeiten mit dem Migrieren von Daten und kann eine optimal zum KM System passende Groupware Lösung wählen. Es gibt aber auch Nachteile sowohl theoretischer als auch praktischer Natur, wenn noch kein Groupware System im Einsatz ist. Es steht etwa zu bef¨ urchten, dass eine IT Unterst¨ utzung und Neuausrichtung aller Arbeitsabl¨ aufe mit einer Reihe von Anlaufschwierigkeiten zu kämpfen haben wird. Generell muss man sich bei IT L¨ osungen mit harten Grenzen arrangieren, was bei rein von Menschen exekutierten Abl¨ aufen nicht so ist. Auch deutet das Fehlen einer Groupware auf eine eher unterdurchschnittliche Ausstattung mit IT Systemen hin. In so einem Kontext gibt es oft eine Reihe von Mitarbeitern der jeweiligen Organisation, die noch kaum mit einem Computer gearbeitet haben. Man sieht also, dass man gar nicht eindeutig feststellen kann, ob das Fehlen einer Groupware eine besonders gute Voraussetzung f¨ ur die Einf¨ uhrung eines KM Systems mit integrierten Groupware Funktionen ist. Im Rahmen des vorliegenden Buches kann nur zum Teil auf die wichtigen organisatorischen Fragen eingegangen werden. Generell muss man ¨ neben den technischen Uberlegungen auch immer an die zuk¨ unftigen Nutzer des Systems denken. Ein f¨ ur die Technik besonders wichtiger Aspekt ist dabei die generelle Erfahrung mit IT Systemen beziehungsweise Computern. Je weniger diese gegeben ist, desto st¨ arker muss man sich darauf konzentrieren die Hauptfunktionen m¨ oglichst einfach anzubieten. Um eine wirklich einfache Benutzerschnittstelle zu realisieren, wird es sogar notwendig sein, Funkionen vor den Nutzern zu verstecken oder gar auszubauen. Gleichzeitig sollte man m¨ oglichst u ¨ ber eine Personalisierung arbeiten und so erfahreneren Nutzern mehr Funktionalit¨ at bieten. Zus¨ atzlich gibt einem so eine Vorgehensweise auch die Möglichkeit, schrittweise weitere Funktionen zur Verf¨ ugung zu

108


stellen je nach Lernfortschritt der einzelnen Anwender nach der Einf¨ uhrung des Systems. ¨ Uber die Behandlung von wichtigen Vorbedingungen beziehungsweise ¨ Uberlegungen f¨ ur die Einf¨ uhrung einer Groupware und der Zeit danach hinausgehend sollte man nicht die weiteren Vorteile eines solchen Systems vergessen. (Manchem m¨ ogen die letzten Abs¨ atze pessimistisch vorgekommen sein – das ist nicht die Absicht. Es geht nur um eine realistische Betrachtung m¨ oglicher Probleme und wichtiger Aspekte.) Neben der Wichtigkeit f¨ ur ein KM System bieten Groupware Systeme eine Reihe von Möglichkeiten. Besonders relevant ist der schnelle und effiziente Informationsaustausch (entweder als oder ¨ ahnlich zu E-Mails). Insbesondere bei Arbeiten, die die Zusammenarbeit von physisch oder zeitlich (h¨ aufig) getrennten Personen erfordern, ist die asynchrone, fast unmittelbare und praktisch kostenlose Kommunikation von ungeheurem Vorteil. Sozusagen ab einem Stockwerk Ortsunterschied funktioniert die rein informelle und pers¨ onliche Kommunikation nicht mehr in ausreichendem Maße (generell betrachtet; das gilt nicht f¨ ur jeden Menschen gleich). Diese Art der Kommunikation ist dabei so erfolgreich, dass man heutzutage schon eher u ammung nachdenken muss. Insbesondere die ¨ ber eine Eind¨ angeh¨ angten Dokumente sind ein großes Problem, da sie zu einer unglaublichen Anzahl an unterschiedlichen Versionen eines Dokuments f¨ uhren und es in weiterer Folge zu entsprechenden Kommunikationsschwierigkeiten kommen kann. F¨ ur das konkret angesprochene Problem ist im Kontext eines KM Systems selbstverst¨ andlich ein DMS die richtige Lösung. Neben dem Informationsaustausch gibt es noch zwei in praktisch allen Groupware Systemen vorhandene Funktionen: Einerseits einen Gruppenkalender und andererseits ein globales Adressbuch. Ein Gruppenkalender erm¨ oglicht eine Koordination, die sonst nur mit wesentlich höherem Aufwand m¨ oglich wäre (manuelle Abstimmung mit allen Beteiligten potenziell unter Einbindung mehrerer Sekretariate). Außerdem bietet so ein Kalender die M¨ oglichkeit festzustellen, wann gewisse Personen verf¨ ugbar sind (zum Beispiel f¨ ur ein Telefonat). Ein globales Adressbuch erm¨ oglicht einmal unmittelbar die Verwendung von stets aktuellen Kontaktdaten (also eben Adresse, Telefon- und Fax¨ nummern, E-Mail, etc.). Uber die Suche kann man auch mit unvollständigen Namen herausfinden, um wen es sich handelt. Weiters kann man häufig noch eine grobe Einstufung der Position bekommen (also zum Beispiel, ob jemand ein Verkäufer oder Techniker ist). Insbesondere f¨ ur interne Mitarbeiter kann man diese Informationen durchaus noch ausbauen (zum Beispiel mit der hierarchischen Einordnung der Person). H¨ aufig kann man u ¨ber das Adressbuch auch gleich eine Reihe von Aktionen anstoßen. Da geht es um das Versenden einer E-Mail, eines Faxes, das Einladen zu einem Termin, das Anstoßen eines Chats, einer Videokonferenz oder eines Telefonats. Nat¨ urlich hängt es von den eingebundenen Systemen ab, was davon wirklich funktioniert. Insbesondere das direkte Anrufen ist zwar schon lange möglich wird aber erst mit Voice over IP (VoIP) wirklich praktikabel werden (aktuell braucht man eine

5.1 Einf¨ uhren oder Weiterverwenden

109

Integration von Systemen – meist mit dem CTI Interface – die in der Praxis kaum anzutreffen ist). Wie schon beim globalen Adressbuch angedeutet, gibt es neben den drei Hauptfunktionen“ einer Groupware auch eine Reihe weiterer Funktiona” litäten. Bei den meisten geht es um eine Integration aller möglichen Kommunikationsformen, wie etwa Fax, Chat, Telefonie, Videokonferenz. Oft geht es auch um M¨ oglichkeiten zur strukturierten Kommunikation wie zum Beispiel mit einem Forum. Zum Teil auch um ganz andere Dinge wie etwa Lotus Notes Datenbanken zeigen. F¨ ur eine bessere Differenzierung werden solche Funktionen eher als Erweiterungen betrachtet und behandelt (außer eine besprochene Groupware L¨ osung bringt sie schon direkt mit). Insgesamt zeigt dieser Abschnitt die Komplexität der Einf¨ uhrung eines Groupware Systems. Dabei demonstriert schon dieser kurze Text, dass bei einer gut durchdachten und geplanten Einf¨ uhrung eines KM Systems zusammen mit einer Groupware, eine enorme Steigerung der Effizienz und Produktivität m¨ oglich ist. Insbesondere erh¨ oht sich die Reaktionsgeschwindigkeit durch die asynchrone aber fast unmittelbare Kommunikation einer Groupware enorm. 5.1.2 Abl¨ ose eines Groupware Systems Im Prinzip k¨ onnte man sagen, dass die Abl¨ ose eines Groupware Systems einen Spezialfall der Einf¨ uhrung eines solchen Systems darstellt. Obwohl dies eine Vereinfachung ist, gilt auch f¨ ur eine Abl¨ ose eines Groupware Systems vieles aus dem vorherigen Abschnitt u uhrung. Eine Analyse des bestehenden ¨ ber die Einf¨ Systems stellt sowieso die Voraussetzung f¨ ur ein solches Vorhaben dar. Wenn die vorhandene Groupware von vielen Anwendern und in unterschiedlicher Art und Weise eingesetzt wird, sollte man dies auf jeden Fall erheben. Dabei gibt es eine Reihe von wichtigen Aspekten: • • •

Aktuelle Verwendung der Groupware (gesamthaft) Datenmigration: Ja/Nein/Wie? Die konkrete Abl¨ ose mit Schulungen/Beispielen/. . .

Insgesamt muss ganz klar sein, wof¨ ur (organisatorisch und was die Funktionen betrifft) die Groupware aktuell in einer Organisation verwendet wird. Weiters geht es darum, welche Informationen und in welcher Form in der Groupware vorhanden sind (zum Beispiel Dokumente, Protokolle“, etc.). ” Die Wichtigkeit dieser Analyse ergibt sich aus der Notwendigkeit, die vorhandene Groupware komplett zu ersetzen. Nach der Umsetzung sollten die Mitarbeiter m¨ oglichst rasch die Vorteile der neuen Arbeitsweise und des (der) neuen Tool(s) sehen k¨ onnen. Ein weiterer ganz wichtiger Punkt ist eine Datenmigration. Dabei ahlt werden. Einerseits kann man können sehr unterschiedliche Varianten gew¨ großteils auf eine Migration verzichten und es den Nutzern u ¨berlassen, einzelne Inhalte zu u ¨ bernehmen. Andererseits kann man auch die Inhalte soweit

110


wie m¨ oglich und so originalgetreu wie m¨ oglich in die neue Groupware Lösung u uhren. Diese beiden Varianten stellen dabei auch (typischerweise) die ¨ berf¨ Extremvarianten“ hinsichtlich der verursachten Kosten dar. Eine mittlere ” ¨ Variante k¨ onnte die Ubernahme der Altdaten in das neue KM System sein. Abh¨ angig vom Zielsystem kann dabei die neue Groupware (beziehungsweise der entsprechende Teil des KM Systems) oder auch eine simple Datenbank den Zugriff gew¨ ahrleisten. Wichtig ist vor allem, dass jeder Mitarbeiter Zugriff auf seine alten Daten beh¨ alt. Eine Integration der alten Daten in den Groupwareteil der neuen Lösung ist nat¨ urlich zu bevorzugen aber nicht absolut notwendig. Gleichzeitig verursacht ein eventuelles Weiterverwenden der alten Lösung zusätzliche Kosten. Das Minimum sind die notwendigen Betreuungskosten. Je nach Altsystem k¨ onnen auch Softwarewartungskosten dazukommen. Außerdem kann man Lizenzen kommerzieller L¨ osungen nach kompletter Ablöse veräußern und so einen Teil der Kosten des neuen Systems abdecken. Bisher wurden vor allem Aspekte in Zusammenhang mit der alten Lösung diskutiert. Insbesondere im Hinblick auf die im vorigen Abschnitt u ¨ ber die Einf¨ uhrung eines Groupware Systems diskutierten Punkte m¨ ussen noch Unterschiede bei der Einf¨ uhrung des Systems u ¨ berlegt werden. Einerseits kennen die Leute schon die grunds¨ atzlichen Vorteile einer Groupware Lösung und haben praktische Erfahrung im Umgang mit ihr. Andererseits ist es notwendig, den Benutzern eine (mehr oder weniger) andere Bedienung und Funktionsvielfalt nahe zu bringen. Eine Idee in diesem Zusammenhang ist das Darstellen von ein paar wenigen klassischen Aufgaben und der praktischen Umsetzung in dem alten sowie dem neuen System. Zus¨ atzlich sollte man auch ein paar simple und m¨ oglichst praxisnahe Beispiele u ¨ ber neue Möglichkeiten vorbereiten. Gerade bei einer Abl¨ ose sollte man versuchen, wichtige und versierte Benutzer der vorhandenen L¨ osung einzubeziehen. Einerseits um möglichst genau zu sehen, wie das existierende System benutzt wird. Andererseits um zusammen Details und Ausgestaltung der neuen L¨ osung festzulegen. Insbesondere ¨ ist ja bekannt, dass eine Anderung in einem fr¨ uhen Stadium eines Projekts ¨ wesentlich weniger als sp¨ ater kostet. Uberhaupt ist die Möglichkeit, erfahrene Anwender einbeziehen zu k¨ onnen, ein Vorteil, den man praktisch nur dann hat, wenn man ein vorhandenes System abl¨ ost. Insgesamt sieht man, dass die Abl¨ ose einer existierende Groupware Lösung ein relativ kompliziertes Unterfangen ist. Gleichzeitig hat man mit einem relativ eng integrierten KM System, das auch Groupware Funktionen umfasst, eine deutlich bessere Basis f¨ ur weitere Ausbauten und die Benutzung des kompletten vorhandenen Informationspools einer Organisation. Auch eine detaillierte Analyse des Ist-Status ist bei einer Ablöse besonders wichtig, um die notwendigen Funktionen besser erkennen und eine erfolgreiche Umstellung sicherstellen zu k¨ onnen.

5.2 Punkte f¨ ur die Integration eines bestehenden System

111

5.2 Punkte fu ¨ r die Integration eines bestehenden System Einzelne Punkte, die f¨ ur die Integration eines bestehenden Systems sprechen, wurden schon im vorangegangenen Abschnitt dieses Buches behandelt. Gleichzeitig ist diese Frage relativ wichtig. Insbesondere wenn man daran denkt, die Einf¨ uhrung eines KM Systems mit Groupware Funktionen zu beginnen. Was k¨ onnen generell Punkte sein, die daf¨ ur sprechen ein bestehendes System weiterzuverwenden (ohne bestimmte Ordnung)? • • • • • • •

Hohe Zufriedenheit mit der aktuellen L¨ osung Abdeckung aller oder zumindest aller wichtigen Groupware Funktionen Gute Integrationsm¨ oglichkeiten in die angestrebte KM Lösung (Funktionalit¨ at, Daten, Performance, etc.) Zukunftssicherheit der vorhandenen L¨ osung Geringe Erhaltungs-/Wartungskosten (trotz separater Lösung) Hohe Abl¨ osekosten (Projektkosten, verlorene Produktivität, etc.) Wichtige Eigenentwicklungen auf Basis der vorhandenen Groupware (insbesondere bei Lotus Domino/Notes und etwas weniger stark bei Microsoft Exchange verbreitet)

Je nachdem wie viele der Punkte zutreffen, spricht mehr oder weniger viel f¨ ur eine Beibehaltung des bestehenden Systems. Gleichzeitig zeigt die Liste auch Punkte auf, die gegen eine Integration sprechen. Die Frage der Integrierbarkeit ist dabei besonders wichtig (und hat Auswirkungen auf die Erhaltungs-/Wartungskosten beziehungsweise Ablösekosten). Wenn man sich die Punkte kurz n¨ aher ansieht, ist der unterschiedliche Fokus klar ersichtlich. Bei der Zufriedenheit mit der aktuellen Lösung geht es eigentlich um eine subjektive Bewertung der aktuellen Situation. Klarerweise ist es wesentlich schwieriger (und weniger sinnvoll) eine gut eingef¨ uhrte und akzeptierte L¨ osung zu ersetzen, als das bei einem eher hingenommenen“ Sys” tem der Fall ist. Einerseits zeigt eine hohe Zufriedenheit, dass die wichtigsten Funktionen f¨ ur die Nutzer gut abgedeckt sind. Andererseits ist die Ablöse eines stark verankerten Systems nur mit einer großen Kraftanstrengung möglich. Damit ist auch schon zum Teil der zweite Punkt u ¨ ber die Abdeckung der Groupware Funktionen beantwortet. Generell ist es im Sinne einer soliden Basis f¨ ur ein KM System (das mit einer Groupware Lösung beginnt) notwendig, einen relativ umfassenden Funktionsumfang zu haben. Die Beurteilung sollte aufgrund der geplanten Arbeitsabl¨ aufe und der sinnvoll einzusetzenden Funktionen geschehen. Nat¨ urlich kann man sich trotz eines Defizits an Funkur eine vorhandene L¨ osung entscheiden. Es ist aber absolut notwendig, tionen f¨ dar¨ uber genau Bescheid zu wissen. Wie schon erw¨ ahnt sind die vorhandenen Integrationsm¨ oglichkeiten einer der wichtigsten Punkte u ¨berhaupt. Insbesondere da Probleme in diesem Bereich eigentlich das ganze Vorhaben sinnlos machen. Wenn man sich also u aten der L¨ osung nicht sicher ist, sollte man entsprechende ¨ ber die Qualit¨ Tests machen und dabei auch versuchen, die geplanten Datenmengen sowie

112


Abfrageh¨ aufigkeit in Rechnung zu stellen. Je besser die vorhandene Lösung ist, desto eher wird man sogar Teile der Funktionen des geplanten KM Systems auf Basis der Groupware realisieren k¨ onnen. Kurz gesagt ist es f¨ ur ein mittel- bis langfristig angelegtes KM System absolut notwendig, ein gut integrierbares Groupware System zu haben. Wenn das nicht möglich ist, sollte man das vorhandene System abl¨ osen. Kein anderer Vorteil kann eine fehlende Integration aufwiegen. Die Frage der Zukunftssicherheit ist relativ wichtig und gleichzeitig schwierig zu beantworten. Bis zu einem gewissen Grad sind alle häufig eingesetzten Groupware Systeme zukunftssicher (wenn es sich um ein System mit kleinem Marktanteil handelt, sollte man generell von einer geringeren Zukunftssicherheit ausgehen). Allerdings sch¨ utzt einen das nicht vor teuren Umstellungen und gerade eine komplexe und enge Integration kann dabei in große Probleme geraten. Es geht also prim¨ ar darum, ob man die vorhandene L¨ osung als halbwegs zukunftssicher ansehen kann. Wenn nein, sollte man sie auf jeden Fall abl¨ osen. Wenn ja, dann sollte man auch nicht zu sehr darauf vertrauen (kann aber diesen Punkt abhaken). Bei der Kostenthematik geht es bei der Integration einer vorhandenen L¨ osung zuerst einmal um die Kosten des Weiterbetriebs der vorhandenen L¨ osung. Man muss feststellen, was einen der Betrieb zusätzlich zu dem geplanten KM System kostet und sollte dabei neben den Hardware-, Lizenz-, Softwarewartungs- und Personalkosten (direkt und f¨ ur das notwendige Knowhow) auch nicht auf notwendige Upgrades vergessen. Je besser die vorhandene Groupware L¨ osung zum KM System insgesamt passt (beziehungsweise auch umgekehrt!) desto niedriger sollten die Summe ausfallen. Die genannten Kosten kann man dabei unter Hinzuziehung externer Dienstleister zum Teil minimieren (insbesondere f¨ ur das Vorhalten des notwendigen Know-hows). Der zweite wichtige Punkt bei den Kosten betrifft eine potenzielle Abl¨ ose. Damit sind diese Kosten alternativ zu den gerade diskutierten zu sehen. Dabei geht es um eine Reihe von Dingen. Etwa die relativ offensichtlichen Kosten, die das Implementieren einer Groupware L¨ osung mit sich bringt. Weiters zuk¨ unftige Wartungskosten (inklusive Know-how Aufbau und Erhaltung) und nicht zu vergessen die indirekten Kosten durch die nach der Ablöse vor¨ ubergehend niedrigere Produktivit¨ at. Sozusagen abziehen kann man davon die sonst notwendigen Integrationskosten und eventuell zu erwartende Erlöse durch das Aufgeben der aktuellen L¨ osung (prim¨ ar der Verkauf von Lizenzen; eventuell auch von Hardware). Mit dem Ergebnis der beiden Kostendarstellungen ist dann eine grobe Absch¨ atzung der finanziellen Auswirkungen einer Ablöse machbar. Nicht zu vergessen sind auch vorhandene Entwicklungen auf Basis der existierenden Groupware. Diese sind f¨ ur ein KM System zum Teil eine diffizile Angelegenheit. Manche dieser Entwicklungen sind in Software festgeschriebe” ne“ Arbeitsabl¨ aufe. Damit w¨ are ein Ersatz oder zumindest eine Adaptierung des Prozesses (potenziell ein Ergebnis einer Analyse aus KM Sicht) sowieso h¨ aufig notwendig. Gleichzeitig gibt es sicher auch eine Reihe von Beispielen,

5.3 Entscheidungskriterien

113

¨ wo es sich um Randsysteme handelt, bei denen eine Anderung in absehbarer Zeit nicht notwendig ist. Hier muss man also sehen, wie viel man bei einem Wechsel der Groupware L¨ osung neu machen m¨ usste unter Ber¨ ucksichtigung der Tatsache, dass manches sowieso zu erneuern wäre. Insgesamt also ein Punkt, den man genau untersuchen sollte. Gleichzeitig einer der f¨ ur die Integration der vorhandenen L¨ osung spricht, da alternativ gewisse Investitionen unumg¨ anglich sind und selbstverst¨ andlich ber¨ ucksichtigt werden m¨ ussen. Gerade der letzte Punkt u ¨ber die Kosten der Ablöse eines vorhandenen Systems zeigt ein generelles Problem auf. Wenn man auf einer nicht standardisierten Basis aufbaut, ist eine Abl¨ osung nur noch schwer möglich. Auch Open Source ¨ andert prinzipiell nichts an dieser Problemstellung (es ist nat¨ urlich bei vorhandenem Source Code einfacher und billiger zu wechseln; es kann aber immer noch prohibitiv teuer sein). Daher sollte man auch unter strategischen Aspekten u uhrung des vorhandenen Systems im bes¨berlegen, ob eine Weiterf¨ ten Interesse der Organisation ist. Wenn man die meisten Erweiterungen relativ billig durch auf einem Standard aufbauende Entwicklungen ablösen kann, sollte man diese Chance nutzen. Wenn dem nicht so ist, sollte man das als eine Lehre sehen und sich in Zukunft entsprechend verhalten. Man sieht also, dass es eine Reihe von Punkten gibt, die eher f¨ ur die Integration einer vorhandenen Groupware L¨ osung sprechen, während andere Punkte eine Abl¨ ose nahe legen. Man muss daher unbedingt eine Abwägung der fachlichen und auch finanziellen Aspekte durchf¨ uhren, um zu einer sinnvollen Entscheidung zu kommen. Voraussetzung ist dabei, dass die vorhandene Lösung sinnvoll integriert werden kann. Ist das nicht gegeben, er¨ ubrigen sich eigentlich weitere Untersuchungen.

5.3 Entscheidungskriterien In den bisherigen Abschnitten dieses Kapitels wurde untersucht, ob es Sinn macht eine neue Groupware L¨ osung (als Teil eines KM Systems) einzuf¨ uhren oder ein vorhandenes System zu integrieren. Wie man gesehen hat, ist das eine relativ schwierige Frage und eine gute Entscheidung setzt eine durchdachte KM Initiative mit einem durchdefinierten KM System als mittel- oder langfristigem Ziel voraus. Bei der Frage nach Entscheidungskriterien geht es primär um zwei Fragen: Einerseits wie man die Groupware Funktionen umsetzt beziehungsweise einbindet. Andererseits um die bis jetzt kaum behandelte Frage, ob man u ¨ berhaupt mit einem Groupware System (eben als Teil des KM Systems) beginnen soll. 5.3.1 Die Art der Einbindung Nachdem es schon eingehende Diskussionen u ¨ ber die Frage der Einbindung von Groupware Funktionen in ein KM System gegeben hat, ist es wichtig,

114


sich die Problematik noch einmal gesamthaft vor Augen zu f¨ uhren. Dabei gibt es drei grunds¨ atzliche M¨ oglichkeiten: 1. Keine Groupware vorhanden ⇒ Einf¨ uhrung 2. Nicht ad¨ aquate Groupware vorhanden ⇒ Ablöse 3. Ad¨ aquate Groupware vorhanden ⇒ Integration Der einfachste Fall ist dabei das Fehlen eines Groupware Systems. Die weiteren Diskussionen sind dann nur von begrenztem Informationswert (obwohl sie gewisse prinzipielle Problematiken und Vorgangsweisen aufzeigen). Zu den generellen M¨ oglichkeiten der Einbindung von Groupware Funktionen ¨ hat schon Kapitel 3 die Basis aufgezeigt und Kapitel 4 prinzipielle Uberlegungen behandelt. Weitere Punkte werden sp¨ ater in diesem Kapitel behandelt. Bei der Einf¨ uhrung eines Groupware Systems steht nat¨ urlich ganz klar die enge Integration mit dem Rest des KM Systems im Vordergrund. Daneben geht es auch um ein (funktional und technisch) möglichst gutes“ Groupware ” Subsystem“. ” Wie schon ausf¨ uhrlich besprochen wurde, ist der Fall der Abl¨ ose eines vorhandenen Systems eine Art Spezialfall der Einf¨ uhrung mit ein paar sehr wichtigen Besonderheiten. F¨ ur die Einbindung gilt im Prinzip dasselbe wie f¨ ur die Einf¨ uhrung eines neuen Systems, da ja das alte System komplett abgel¨ ost wird. (Der Sonderfall, dass die alte Groupware trotz Einf¨ uhrung eines neuen Subsystems“ ganz oder zum Teil weiterverwendet wird, ist eigentlich ” eine Mischung aus Abl¨ ose und Integration und wird nicht explizit diskutiert.) Damit ist die Frage der Einbindung haupts¨ achlich in Hinblick auf die vorhandenen Daten zu stellen und zu beantworten. Gleichzeitig kann es auf diese Fragestellung keine generelle Antwort geben. Es handelt sich vielmehr um ¨ eine Abw¨ agung von Kosten versus Probleme in der Ubergangszeit (mit entsprechenden direkten und indirekten Kosten). Daher muss man f¨ ur eine indiuckviduelle Situation eine Abw¨ agung durchf¨ uhren und sollte dabei auch ber¨ sichtigen, wie man am einfachsten und mit den geringsten Widerständen das KM System einf¨ uhren kann (eventuell durch Migrieren der alten Daten obwohl es sich nicht direkt rechnet). Nach den beiden leichten“ Varianten gibt es noch die Möglichkeit der ” Integration eines bestehenden Systems. Dieser Fall ist der eigentlich relevante f¨ ur die Frage der Einbindung in das KM System (da bei der Einf¨ uhrung als großer Alternative kein vorhandenes System zu ber¨ ucksichtigen ist und es prim¨ ar um die Frage des gesamten KM Systems geht). Die Analyse welche Punkte in welcher Form f¨ ur die Integration des bestehenden Systems sprechen, bildet dabei die Grundlage einer m¨ oglichst effizienten Einbindung des vorhandenen Systems. Auch in diesem Fall ist es nicht m¨ oglich, eine generelle Aussage zu treffen, da die potenziell zu integrierenden Systeme einfach zu unterschiedlich sind. Trotzdem ist es notwendig, sich die wichtigsten Aspekte zu u ¨ berlegen und auf grunds¨ atzliche Fragen einzugehen. Praktisch alle wichtigen Groupware Systeme sind entweder Client/Server L¨ osungen oder rein serverbasiert.


115

Damit besteht eine prinzipiell gute Voraussetzung f¨ ur eine Integration auf der Serverseite. Die beiden wichtigsten kommerziellen Groupware Produkte sind sicherlich Lotus Domino/Notes und Microsoft Exchange/Outlook (aus rein theoretischer Sicht k¨ onnte man die Einstufung Groupware zwar anzweifeln aus praktischer Sicht macht das aber keinen Sinn). Insbesondere bei älteren Versionen dieser Systeme k¨ onnte es schwierig werden, eine enge Integration zu erreichen. Das liegt an bekannten Limitationen und auch an der nur noch schwachen Unterst¨ utzung f¨ ur ¨ altere Versionen, die nichtsdestotrotz noch weit verbreitet im Einsatz sind. Die gerade angesprochene Thematik ¨ alterer Versionen zeigt damit ein weiteres Problem auf: Selbst wenn es sinnvoll erscheint eine bestimmte Groupware beizubehalten, kann eine Integration auch bei einer prinzipiell geeigneten Lösung praktisch der falsche Weg sein. Gerade wenn man mit alten (oder gar veralteten) Versionen von Groupware Systemen konfrontiert ist, sollte man noch einmal u ¨ berlegen, ob nicht doch eine Ablöse Sinn macht. Weiters bieten alte Versionen auch einen geringeren Funktionsumfang und sind daher typischerweise leichter abl¨ osbar. Insgesamt sollte man die meisten der gerade angesprochenen Punkte schon bei der generellen Beurteilung der Integration eines bestehenden Systems untersucht haben. Weiters kann man sagen, dass bei relativ alten Groupware Versionen eine Integration nur in Ausnahmefällen Sinn macht. Entweder muss man sowieso u ¨ber kurz oder lang auf eine neue Version migrieren oder eine Abl¨ ose ist direkt sinnvoller als eine Integration. Damit ergibt sich vor allem die Thematik der Integration aktueller Versionen. Hier hat man einerseits die Unterst¨ utzung des Herstellers und andererseits sind die Systeme wesentlich offener als das fr¨ uher der Fall war (wo es zum Teil nicht einmal eindeutige Schl¨ ussel f¨ ur Dokumente in der Groupware gegeben hat). Weiters gibt es auch schon entsprechende Anbindungen zum Beispiel in Portalservern (unter anderem in den entsprechenden Oracle und Sun Produkten als Portlets realisiert). Das zeigt, dass eine bidirektionale Anbindung nicht nur prinzipiell m¨ oglich ist sondern zu einer Frage des Preises wird. Wenn man sich entschieden hat, die alte Groupware weiterzuverwenden, wird man voraussichtlich nicht zu viel in eine Duplizierung“ von ” Funktionalit¨ aten investieren wollen oder k¨ onnen. Daher ist die Anbindung vor allem zur Integration der vorhandenen und weiter ausgetauschten Daten und Dokumente wichtig. Hierbei gilt es neben technischen Aspekten auch dem Datenschutz zu seinem Recht zu verhelfen. Im deutschen Sprachraum wird das auf eine Betriebsvereinbarung hinauslaufen, die vor allem die Frage von privaten Dokumenten in Firmensystemen zu regeln hat. Daneben ist noch ein abgestufter Zugriff auf Dokumente eine absolute Notwendigkeit. Je nach zu integrierendem System wird man hier vor allem auch organisatorisch tätig werden m¨ ussen (und das Ergebnis mithilfe der IT Wirklichkeit“ werden ” lassen). Dieselben Themen muss man auch bei der Integration von Altbest¨ anden ber¨ ucksichtigen. Man hat allerdings den großen Vorteil, dass es eine einmalige Aktion sein wird und man sicherlich gewisse Vereinfachungen vor-

116


nehmen kann, die in einem laufenden Betrieb nicht akzeptabel wären. Eine wirkliche Integration der vorhandenen Groupware Lösung f¨ ur den Zugriff auf Altbest¨ ande sollte dabei die letzte Option sein, da jede weitere und nicht notwendige Komplexit¨ at dem gesamten KM System abträglich“ ist. ” Insgesamt sieht man schnell, dass die Art der Einbindung primär f¨ ur ein zu integrierendes Groupware System beziehungsweise vorhandene Datenbest¨ ande zu beantworten ist. Leider kann man aufgrund der Unterschiedlichkeit und Komplexit¨ at der aktuell h¨ aufig eingesetzten Systeme keine einfachen und eindeutigen Antworten geben. Trotzdem ist ganz klar, dass eine bidirektionale Anbindung meistens m¨ oglich und aus Sicht eines KM Systems auch notwendig ist. Gleichzeitig wurde noch einmal ganz klar dargelegt, dass ein Weiterbetrieb eines vorhandenen Systems eher die seltenere und auf jeden Fall gut¨ uberlegte L¨ osung sein sollte. Insbesondere wenn es um die Integration von vorhandenen Datenbest¨ anden geht, sollte primär eine Daten¨ ubernahme in das abl¨ osende System angestrebt werden, um die Komplexität und die Altlasten“ ” zu minimieren. 5.3.2 Argumente f¨ ur den Start mit einem Groupware System Bis jetzt ist es haupts¨ achlich um die Frage gegangen, wie man die Groupware Thematik innerhalb eines KM Systems am geschicktesten und besten angehen kann. Ein Punkt, der eher am Rande gestreift wurde, war die Frage, wie sinnvoll es ist mit einem Groupware Subsystem“ als erstem Teil eines KM ” Systems zu starten“. Es wird den Leser nicht u ¨berraschen, dass es darauf ” weder eine einfache noch eine eindeutige Antwort geben kann. Allerdings gibt es sehr gute Argumente daf¨ ur, genau diesen Weg zu beschreiten, und damit er¨ ubrigen sich potenziell Analysen, bei denen ein eindeutiges Ergebnis nur selten zu erwarten ist. Wie schon in den vorangegangenen Abschnitten ist es auch f¨ ur diese Fragestellung notwendig, die drei Hauptszenarien (Einf¨ uhrung/Ablöse/Integration) zu betrachten. Gleichzeitig gelten viele der Argumente f¨ ur alle drei Szenarien und einige sind schon kurz angerissen worden (zum Beispiel im Abschnitt 5.1 u uhrung oder das Weiterverwenden einer Groupware Lösung). ¨ ber die Einf¨ Prinzipiell hilft einem ein Groupware System einfach dabei, effizienter innerhalb einer Organisation und auch mit anderen Organisationen zu kommunizieren. Je nach konkretem Funktionsumfang einer gewählten oder vorhandenen L¨ osung wird man mit dem geplanten KM System noch Ergänzungen und Erweiterungen vornehmen. Dabei m¨ ussen diese nicht direkt Teil des KM Systems sein, allerdings beides zusammen gut integriert werden. Wenn eine Organisation noch u ¨ berhaupt keine Groupware im Einsatz hat, sind sicherlich die gr¨ oßten positiven Effekte zu erwarten. Gleichzeitig wird man besondere Sorgfalt auf die Schulung und Begleitung der Benutzer legen m¨ ussen, damit das System sinnvoll genutzt wird und die erhofften Effekte Realität werden. Die wichtigsten Aspekte dabei wurden schon beschrieben und drehen sich um den Austausch von Texten und Dokumenten (meist per E-Mail), einen


117

Gruppenkalender und ein globales Adressbuch. Nat¨ urlich brauchen schon diese Funktionen eine Verkn¨ upfung untereinander. Diese Punkte werden von praktisch jeder Groupware erf¨ ullt und stellen damit Kernfunktionen von Produkten dieser Kategorie dar. Im Kontext eines geplanten KM Systems ist es dabei (prinzipiell) gar nicht so wichtig, welche konkreten dar¨ uber hinausgehenden Funktionen vorhanden sind, da man wichtige Punkte relativ leicht erg¨ anzen kann. Dabei geht es einerseits um noch informellere Kommunikation, als es eine E-Mail darstellt, und um strukturiertere Varianten. Bei den informelleren Kommunikationsmethoden geht es in Richtung Telefon- oder Videokonferenz per Computer oder auch Instant Messaging (Chat). Hier ist vor allem wichtig, diese M¨ oglichkeiten anzubieten, soweit das leicht m¨ oglich ist, und das Ergebnis zugreifbar zu machen (¨ uber eine Volltextsuche mit m¨ oglichst vielen Attributen). Diese Informationen werden heutzutage oft nicht entsprechend zug¨ anglich gemacht. Das liegt selbstverständlich zum Teil an ihrer Natur. Zum anderen sind häufig die notwendigen Technologien nicht im Einsatz. Bei den strukturierteren Kommunikationsmethoden geht es meist um andere Kommunikationsmuster: etwa um eine asynchrone Kommunikation innerhalb einer Gruppe und die m¨ oglichst einfache Handhabung derselben. Ein ideales Beispiel sind Foren und ¨ ahnliche Systeme. Hier kann man zu einem gewissen Thema innerhalb eines Forums eine Diskussion mit Antworten auf Antworten usw. f¨ uhren. Durch die formelle Art der Diskussion und relative Klarheit des Themas sind sie leicht zug¨ anglich (und das beste Beispiel ist das Usenet des Internets mit seinen abertausenden Newsgroups). Kurz soll hier auch noch erw¨ ahnt werden, dass dar¨ uber hinausgehende Kommunikationsmethoden sich in letzter Zeit als sehr populär und zum Teil sehr hilfreich erwiesen haben. Ein wichtiges Beispiel sind Blogs. Hier schreiben Leute eine Art Online Tagebuch, das häufig die Möglichkeit zur ¨ direkten oder indirekten Reaktion gibt. Uber diesen Mechanismus“ laufen ” aktuell einige sehr interessante und kontroversielle Diskussionen im Internet ab. Ein zweites spannendes Beispiel sind Wikis (mehr dazu in Abschnitt 8.4.3). Hier geht es vom Prinzip her um das gemeinsame Erstellen eines oder mehrerer Dokumente im Internet (bis zu einem gewissen Grad eine Weiterf¨ uhrung von Spezialsystemen f¨ ur das gemeinsame Bearbeiten von Dokumenten). Beide Beispiele sind eine Art logische Erweiterung des urspr¨ unglichen Groupware Gedanken. All die beschriebenen Kommunikationsmethoden zeigen, was man im erweiterten Sinn unter einer Groupware verstehen kann und was die entsprechenden Systeme leisten k¨ onnen. Insbesondere die später beschriebenen Möglichkeiten eines Blogs oder eines Wikis sind dabei kaum groupwarespezifisch und daher kein Entscheidungskriterium. Gleichzeitig sieht man ganz klar, dass praktisch jede Organisation eine Groupware haben sollte. Daher ist die Empfehlung f¨ ur Organisationen, die so etwas noch nicht haben, ganz klar mit einem Groupware Subsystem“ zu beginnen. Ein weiterer Punkt dabei ist nämlich ” auch, dass die entsprechenden Konzepte relativ leicht verständlich und abge-

118


schlossen sind. Damit ist eine Einf¨ uhrung verhältnismäßig einfach. Dar¨ uber hinaus sehen die Benutzer auch sehr schnell die Vorteile.

5.4 Umsetzungsstrategien Nach einer Entscheidung f¨ ur den Start mit einem Groupware (Sub-)System ist es notwendig, sich mit der notwendigen Umsetzungsstrategie zu beschäftigen. Dazu muss man wieder die Unterscheidung zwischen einer Einf¨ uhrung und einer Integration treffen. Zus¨ atzlich gibt es noch die Ablöse (primär) als Sonderfall der Einf¨ uhrung. Die Einf¨ uhrung eines entsprechenden Systems ist dabei am einfachs” ten“. Aus technischer Sicht sowieso, da man sich nicht mit Altlasten“ her” ¨ umschlagen muss und es keine Ubergangszeit gibt. Aber auch aus organisatorischer Sicht ist es weniger komplex als die anderen beiden Szenarien. Hier sind zwar der Schulungsaufwand und die Umstellung f¨ ur die Mitarbeiter potenziell am gr¨ oßten, man kann sich aber auf die Kernaufgabe konzentrieren. Bei einer Abl¨ ose oder einer Integration ist aus technischer Sicht wesent¨ lich mehr zu tun. Sowohl eine Ubernahme oder Integration von vorhandenen Daten als auch die Einbindung einer Groupware in ein neues System erfordern technische Umstellungen, die auf Anhieb funktionieren m¨ ussen. Je mehr Schwierigkeiten es n¨ amlich bei der Umstellung gibt desto eher wird das neue System nur eingeschr¨ ankt benutzt werden. Auch organisatorisch ist die Ablöse einer Groupware eine delikate“ Angelegenheit. Die Nutzer haben sich an die ” Eigenheiten und Vorteile der vorhandenen L¨ osung gewöhnt und daher sollte man m¨ oglichst konkret die neuen M¨ oglichkeiten präsentieren und darauf eingehen, wie die Alltagsarbeit in Zukunft erledigt werden kann. 5.4.1 Geplanter Umfang des KM Systems Der vielleicht wichtigste Punkt bei der Entscheidung f¨ ur oder gegen eine bestimmte Umsetzungsstrategie oder ein bestimmtes System ist die Frage, wie umfangreich das KM System im Endausbau sein soll. Dabei geht es einerseits um die Vision, die man sich selbst gegeben hat, und andererseits um die geplanten und absehbaren Ausbaustufen. Die notwendige Abwägung dabei ist ganz offensichtlich. Man muss eine denkbare Basis f¨ ur die Vision schaffen (aber nicht jede Einzelheit ber¨ ucksichtigen oder analysiert haben). Vor allem aber muss man eine gute Grundlage f¨ ur die absehbaren Ausbaustufen herstellen. F¨ ur die Ausarbeitung der entsprechenden mittel- bis langfristigen Vision kann einem dabei Kapitel 2 eine Menge an Anhaltspunkten bieten. ur die Beurteilung ist, ob eine bestimmDer wichtigste Unterschied f¨ te Funktionalit¨ at vorhanden ist beziehungsweise prinzipiell realisiert werden kann. Wenn eine entsprechende Notwendigkeit nicht absehbar ist, dann gen¨ ugt die grunds¨ atzliche Machbarkeit. Dabei sollte man durchaus einen Blick“ in ” die Zukunft der betroffenen Organisation geworfen haben und die potenziell

5.4 Umsetzungsstrategien

119

wichtigen Funktionen den eher wahrscheinlichen Zukunftsszenarien der Organisation angemessen sein. Kurz gesagt soll es sich nicht um eine Einbahnstraße handeln, aber man braucht auch nicht auf eine unwahrscheinliche Zukunft vorbereitet sein (um die kann man sich k¨ ummern, wenn sie eintreffen sollte). Ein wichtiger Punkt dabei ist noch – wie schon zum Teil in Kapitel 4 besprochen – die Beurteilung der Popularit¨ at“ einer Technologie, die in Frage ” kommt. Bei den vorgestellten Systemen gibt es mit Objective-C und Python zwei Programmiersprachen die deutlich weniger populär“ als Java und PHP ” sind (teilweise auch als C/C++). Gleichzeitig gibt es entsprechend interessante Systeme in diesen Sprachen. Die Folgerung ist klar: Je wahrscheinlicher es ist, dass man Funktionen ben¨ otigen wird, wo es aktuell keine entsprechende Software (Basis) gibt, desto eher sollte man sich nicht f¨ ur eine weniger oft eingesetzte Sprache entscheiden. Bei den beliebteren Sprachen ist es dagegen eher wahrscheinlich, dass eine aktuell vorhandene L¨ ucke gef¨ ullt ist, bevor man wirklich Bedarf hat. Nat¨ urlich kann man sich auch entscheiden im Fall des Falles, eine entsprechende Entwicklung selbst durchzuf¨ uhren beziehungsweise durchf¨ uhren zu lassen. Die potenzielle Notwendigkeit sollte man aber ¨ von vornherein in die entsprechenden Uberlegungen einbezogen haben. 5.4.2 Externe oder interne Entwicklung und Betrieb Eine weitere Frage der Umsetzungsstrategie ist, ob man notwendige Entwicklungen beziehungsweise auch Consulting und Einf¨ uhrung extern oder intern durchf¨ uhren l¨ asst. Es ist dabei relativ offensichtlich, dass eine entsprechende Entscheidung nur auf Basis der vorhandenen und geplanten Situation getroffen werden kann. Je nach Ausgangsbasis kann sich diese Frage als sehr einfach oder relativ komplex erweisen. Praktisch betrachtet gibt es dabei drei Fälle: • • •

Externer Betrieb und Entwicklung Eine Mischung aus internem und externem Betrieb beziehungsweise Entwicklung Interner Betrieb und Entwicklung

Am einfachsten“ ist es f¨ ur Organisationen, die ihre IT nicht selbst ” betreuen. Hier stellt sich eher die Frage nach der sinnvollen Kombination von externen Partnern (h¨ aufig wird eine auf IT Betrieb und Support ausgelegte Organisation nicht das notwendige Know-how f¨ ur Entwicklungen oder auch in einer der gew¨ unschten Technologien haben). Gleichzeitig sollte die Organisation, die in Zukunft den Betrieb der EDV Landschaft sicherstellen wird, in das Projekt von Anfang an eingebunden sein. Insbesondere wenn man daran denkt, dass die Wartungs- und Betreuungskosten umso stärker dominieren je geringer die Entwicklungsaufw¨ ande sind. Gleichzeitig ist die Grundidee des Einsatzes von Open Source Technologie, minimale (bis gar keine) Entwicklungskosten zu haben. Man sollte aber auch die Einf¨ uhrungskosten nicht untersch¨ atzen und bei einem externen Dienstleister kann man alle anfallenden

120


Kosten unmittelbar sehen (wobei man auf jeden Fall auch mehr oder weniger offensichtliche interne Kosten hat). Wenn man den internen Betrieb selbst handhabt, dann hat dies sowohl Vor- als auch Nachteile. Potenziell negative Punkte sind fehlendes Know¨ how, Uberlastung durch die zus¨ atzlich notwendige Einschulung auf und Unterst¨ utzung f¨ ur das neue System oder auch mögliche Verzögerungen durch ¨ Uberlastung oder unvorgesehene Probleme im Betrieb. Positive Punkte sind niedrigere Kosten (eine Einf¨ uhrung kann zum Teil nebenbei erledigt werden), hohes Know-how u aufe und Notwendigkeiten der Organi¨ ber die Arbeitsabl¨ sation oder auch das problemlose Weiterarbeiten nach der Einf¨ uhrung (ein besonders wichtiger Punkt). Wenn also ausreichendes Know-how intern vorhanden ist, u uhrung wird ¨ berwiegen generell die positiven Punkte. Die Einf¨ billiger und vermutlich besser (aufgrund des vorhandenen Fachwissens und der N¨ ahe zu den eigentlichen Nutzern). Insgesamt ist eine Mischung von interner und externer Dienstleistung sicher ein gutes Szenario, dass sich f¨ ur viele Organisationen eignen wird (unabh¨ angig davon ob man selbst IT Entwicklungen durchf¨ uhren kann oder nicht). Schließlich gibt es noch die M¨ oglichkeit, dass man die Einf¨ uhrung und alle damit zusammenh¨ angenden T¨ atigkeiten komplett intern abwickeln kann. Je kleiner eine Organisation desto unwahrscheinlicher ist das (und auch viele gr¨ oßere Organisationen haben kein entsprechendes Know-how). Im Prinzip gelten dieselben positiven und negativen Punkte wie bei dem Fall des internen Betriebs. Das Risiko, des fehlenden oder falschen Know-hows ist dabei gr¨ oßer. Alternativ k¨ onnte auch das vorhandene Know-how zu einer suboptimalen L¨ osung f¨ uhren. Nat¨ urlich werden n¨ amlich interne Personen eher zu f¨ ur sie pers¨ onlich interessanten oder schon bekannten Technologien drängen. Auf diesen Aspekt sollte man ein Auge haben und zumindest zum Teil eine externe Sicht einbeziehen. Gleichzeitig sollte man sehr wohl auf die internen Stärken setzen, wenn das Ergebnis eine gute Lösung ist. Mit gut ist dabei gemeint, dass es vielleicht eine theoretisch bessere Lösung geben mag, aber die zu erwartenden Unterschiede in der Ergebnisqualität (in Hinsicht auf Funktionalit¨ at, Quality of Service, Kosten, Nutzen f¨ ur die Organisation, etc.) nicht zu groß sind. Ein weiterer nicht zu untersch¨ atzender positiver Aspekt ist der Kostenvorteil, den eine interne Umsetzung bietet (bei entsprechend vorhandenem Know-how). Kurz gesagt hilft internes Know-how die Kosten niedrig zu halten und eine m¨ oglichst problemlose Einf¨ uhrung und einen möglichst einfachen Betrieb zu erreichen. Bei einer komplett externen L¨ osung kann man wahrscheinlich deutlich schneller zum Ziel kommen und eine gute nachfolgende Betreuung bekommen. In jedem Fall sollte man aber eine (oder mehrere) möglichst objektive, externe Sicht(en) einbeziehen. Dabei geht es darum zu wissen wof¨ ur oder wogegen man sich entscheidet unabh¨ angig von der Entscheidung selbst (alleine die Kostengr¨ unde k¨ onnten ausreichen, sich f¨ ur eine langsamere interne Implementierung zu entscheiden).

5.5 Vorhandene Open Source Basis

121

5.4.3 Zusammenfassung Bei der Umsetzungsstrategie kommt es entscheidend auf die Fragen des geplanten Umfangs des KM Systems und wer es wie umsetzen und betreuen wird an. Aus diesen Faktoren ergeben sich die Grundlagen f¨ ur eine Entscheidung sowohl in qualitativer wie auch in finanzieller Hinsicht. Der geplante und f¨ ur potenziell wichtig gehaltene Umfang des Systems gibt die Rahmenbedingung f¨ ur die notwendigen Bestandteile vor. Die Kosten und das vorhandene Know-how f¨ ur eine Einf¨ uhrung und Betreuung erlauben einem danach eine Entscheidung f¨ ur eine bestimmte technische Lösung. Damit kann man dann die Einf¨ uhrung selbst planen und durchf¨ uhren. Um die Beschreibung der Umsetzungsstrategie noch klarer zu machen, findet man in Abbildung 5.1 eine Darstellung der wichtigsten Zusammenh¨ ange und Abläufe.

5.5 Vorhandene Open Source Basis Eine Beschreibung von wichtigen Open Source Groupware Systemen wurde schon in Abschnitt 3.2 gegeben. Dabei wurden sechs verschiedene Systeme vorgestellt, die unmittelbar Groupware Funktionen zur Verf¨ ugung stellen. F¨ ur den Beginn mit einem Groupware System stellen diese Systeme die beste Basis dar (wenn auch nicht die einzig m¨ ogliche). Gleichzeitig ergibt sich durch die unterschiedliche technologische Basis schon von vornherein eine kleinere Auswahl, wenn man nicht v¨ ollig frei in der Wahl ist (zum Beispiel aufgrund von vorhandenem Know-how, anderen Systemen, die integriert werden sollen, ¨ oder grunds¨ atzlichen technologischen Uberlegungen). 5.5.1 Diskussion der Groupware Systeme In Richtung Java gibt es vor allem die L¨ osung Open-Xchange. F¨ ur Java spricht die sehr gute Skalierbarkeit und Performance sowie die Verf¨ ugbarkeit von einer sehr großen Zahl an weiteren Systemen, die integriert werden k¨ onnen. Außerdem ist Java Know-how extrem verbreitet und häufig anzutreffen beziehungsweise zu bekommen“. Weiters steht hinter der Lösung mit ” Novell auch ein finanzkr¨ aftiger Unterst¨ utzer der Open Source Bewegung. Bei PHP bietet sich PHProjekt am ehesten an, da es eine relativ gut integrierte Gesamtl¨ osung darstellt. Bei der Alternative PhpGroupWare muss man vor allem eine schlechtere Integration in Kauf nehmen, hat aber daf¨ ur gleich eine gr¨ oßere Funktionsvielfalt. Tiki – als dritte reine“ PHP-Lösung ” – schneidet rein als Groupware betrachtet schlechter ab. Daher ist es eher geeignet, wenn ein schw¨ acherer Fokus auf dem Groupware Aspekt liegt. Die Bewertung der L¨ osung Kolab/Kroupware ist gemischt. Als Groupware System konzipiert und entwickelt bietet es alle wichtigen Funktionen aufbauend auf verschiedenen anderen Systemen. Dadurch ergeben sich eine

mittelfristige Ziele

langfristige Ziele

unmittelbare Ziele

Entwicklung & Betrieb

mögliche Zukunft der Organisation

1. KM Vision

gemischt

beides extern

beides intern

zukünftig nötige Funktionen

unmittelbar nötige Funktionen

sprachen)

Programmier

(z.B.:

Knowhow

verfügbares

2b.

2a. mögliche Open Source Systeme

Kosten

Abschätzung der Zukunft einzelner Systeme

3. Systemauswahl

122 5 Start mit einem Groupware System

Abb. 5.1. Umsetzungsstrategie f¨ ur eine Groupware Einf¨ uhrung

5.5 Vorhandene Open Source Basis

123

Reihe von Vor- und Nachteilen. F¨ ur ein gr¨ oßeres KM System ist es selbst keine ideale Ausgangsbasis. Wenn aber die Ausbaupläne des Systems beschränkt sind, stellt es eine sehr interessante Alternative dar. Bei OpenGroupware handelt es sich technologisch durch die Verwendung von Objective-C um eine Art Außenseiter. Gleichzeitig stellt es eine gut integrierte Gesamtl¨ osung dar, die durchaus als Basis f¨ ur Erweiterungen oder Integrationen herangezogen werden kann. Wenn das Ziel ein sehr mächtiges und komplexes KM System ist, k¨ onnte sich die verwendete Technologie aber als hinderlich erweisen (das System wurde nie daf¨ ur konzipiert). Kurz gesagt eine auf jeden Fall interessante Alternative, wenn der Schwerpunkt des angedachten KM Systems auf Groupware Aspekten liegt. 5.5.2 Integration einer vorhandenen Groupware Die im vorigen Abschnitt beschriebenen Systeme sind dabei f¨ ur den Fall der Einf¨ uhrung oder der Abl¨ ose eines Groupware Systems relevant. Wenn es um eine Integration geht, helfen einem diese Groupware Produkte wenig bis gar nicht weiter. Was man mit einigen der genannten Systeme machen kann, ist das (E-)Mailing u ¨ ber eine vorhandene Groupware Lösung abzuwickeln und nur f¨ ur den Rest das andere System zu verwenden. Das ist eine Art Kompromiss, der aber nur selten wirklich befriedigend sein d¨ urfte. Schließlich wird man eine Groupware, die rein f¨ ur das Mailing verwendet wird, relativ leicht ablösen k¨ onnen. F¨ ur eine weitreichende Integration bieten sich eher Portale an. Gleichzeitig geht es dabei eher um eine technische Integration, da die Groupware Funktionen ja offensichtlich schon ausreichend abgedeckt sind. Wenn es möglich ist, eine Benutzerschnittstelle direkt zu integrieren, sollte man das tun oder versuchen, zumindest Teile der Funktionalität zur Verf¨ ugung zu stellen. Hier bietet sich zum Beispiel das Mailing System an. Sehr oft kann man diese Funktion u ¨ ber eine Standardschnittstelle (zum Beispiel IMAP oder WebDAV) anbinden und anbieten. Wie schon beschrieben ist dabei XOOPS das PHP Projekt, dass aus der beschriebenen Auswahl am ehesten eine Portallösung darstellt (auch wenn es bei den CMS Systemen eingereiht ist). Im Prinzip bietet sich das vor allem an, wenn PHP eine gute Basis darstellt (entweder wegen des vorhandenen Knowhows in einer Organisation beziehungsweise bei relevanten Partnern oder weil der weitere Ausbau durch leicht integrierbare PHP Module abgedeckt werden kann). Dabei stellt sich vor allem die Frage einer gesamthaften Datenbasis, ucksichtigt werdamit m¨ oglichst viele Informationen von einer KM Lösung ber¨ den k¨ onnen. Alternativ bieten sich vor allem Java basierte Portale an. In Abschnitt 3.5.1 wurden in dieser Kategorie Jetspeed und Liferay vorgestellt. Auch das JBOSS Portal (vorgestellt in Abschnitt 3.3.4) gehört hier dazu. Der einfachere Teil ist dabei die Integration einer Benutzerschnittstelle in das

124


Portal. Wie auch schon bei XOOPS beschrieben, ist die eigentlich schwierige Aufgabe, eine integrierte Datenbasis zur Verf¨ ugung zu stellen. Wichtig ist bei den gerade gemachten Ausf¨ uhrungen, dass die Aufgabe eine integrierte Datenbasis zur Verf¨ ugung zu stellen auch bei den alternativen Vorgangsweisen (Einf¨ uhrung beziehungsweise Ablöse) in weiterer Folge notwendig ist. Bei der Integration einer Groupware Lösung handelt es sich um das wichtigste Problem, bei der Einf¨ uhrung beziehungsweise Ablöse um ein Folgeproblem, dass man nicht unmittelbar lösen muss. Ein prinzipieller Vorteil besteht bei Open Source L¨ osungen darin, dass alle Schnittstellen und Datenstrukturen offen liegen. Dadurch ist eine Integration wesentlich leichter als bei Closed Source Produkten (das betrifft auch Freeware Programme, bei denen zwar keine Kosten anfallen aber die Interna ebenfalls unklar sind). Neben Portalen kann eine Integration nat¨ urlich auch auf Basis eines CMS Systems oder auch vieler anderer Systeme implementiert werden (zum Beispiel auch mit einem ERP oder CRM System). Was CMS Systeme betrifft wird dieser Aspekt in Kapitel 6 behandelt. Insgesamt bietet sich eine ähnliche Vorgehensweise an. Sonst macht es aber wenig Sinn hier in Details gehen zu wollen, da die Unterschiede zwischen verschiedenen Systemkategorien einfach zu groß sind. 5.5.3 Zusammenfassung F¨ ur die Fragestellung der Einf¨ uhrung oder der Ablöse eine Groupware Systems kommen als Open Source Vertreter die L¨ osungen aus Abschnitt 3.2 in Frage. Dabei adressieren die verschiedenen Vertreter unterschiedliche Anforderungen, sodass man das am besten passende System aussuchen kann. Wichtig ist dabei neben den Funktionalit¨ aten auch zuk¨ unftige Anforderungen im Auge zu behalten und bei der Technologie auf weitere Funktionen sowie verf¨ ugbares Know-how zu achten. Bei einer Integration dagegen ist die Verwendung eines Portals die generelle L¨ osung. Alternativ kann man sicher auch ein CMS System verwenden (wobei hier noch keine n¨ ahere Analyse präsentiert wird). Je nach den genauen Anforderungen k¨ onnten auch andere Lösungen als Basis f¨ ur eine Integration herangezogen werden. Generell ist dabei die Herausforderung, eine integrierte Datenbasis f¨ ur weitere KM Funktionen zur Verf¨ ugung zu stellen. Die Bereitstellung von Groupware Funktionen ist dagegen nicht so wichtig (da ja die vorhandenen Tools weiterbenutzt werden). Trotzdem sollte man versuchen m¨ oglichst viel Funktionalität in die KM Lösung selbst zu integrieren.

6 Alternativ Start mit einem Content Management System

Die Diskussionen im letzten Kapitel haben schon aufgezeigt, dass eine Groupware nicht in jedem Fall der ideale Startpunkt f¨ ur ein KM System ist. Das gilt selbstverst¨ andlich f¨ ur Organisationen, die schon eine u ¨berzeugende Lösung im Einsatz haben. Ein anderer Punkt ist der Schwerpunkt der KM Initiative. Sollte dieser weniger auf Zusammenarbeit (Collaboration) ausgerichtet sein, sind andere Ans¨ atze vielleicht effizienter. Schon bei der Untersuchung der vorhanden Open Source Basis wurde neben den Groupware Systemen ein besonderer Schwerpunkt auf Content Management Systeme gelegt. Unmittelbar eignen sie sich f¨ ur die Bereitstellung von allen m¨ oglichen Informationen in verschiedensten Formen und Formaten. Das geschieht innerhalb einer inhaltlichen Struktur aber u ¨berwiegend in unstrukturierter Form. Dar¨ uber hinaus gibt es f¨ ur praktisch alle Systeme eine Reihe von Zusatzmodulen in Richtung Kommunikation. Das kann zum Beispiel in strukturierter Form in einem Forum erfolgen oder die gemeinsame Arbeit an einem von einem Wiki verwalteten Dokument sein. Schon an diesen Beispielen sieht man, dass es um CMS Systeme mit sinnvollen Erweiterungen geht. Damit k¨ onnen zum Teil andere Anforderungen als mit Groupware Systemen abgedeckt werden. Nat¨ urlich gibt es noch andere M¨ oglichkeiten f¨ ur den Start eines KM Systems. Keine davon bietet sich aber aus genereller Sicht so an, wie mit einer Groupware L¨ osung beziehungsweise einem Content Management System. Eine M¨ oglichkeit w¨ are zum Beispiel der Start mit einem Portal. Hier m¨ usste man sich aber erst wieder um die Frage der Anwendungen k¨ ummern und hätte unmittelbar nur eine Technologie. Eine andere Variante wäre der Start mit einem der Open Source ERP und/oder CRM Systeme. Während es sich dabei in mehrerer Hinsicht um eine sehr interessante Möglichkeit handelt, stellt diese Variante aber nur einen Ausnahmefall dar. Bei größeren Organisationen sind entsprechende Systeme schon vorhanden oder nur sehr schwer einzuf¨ uhren. Bei kleineren Organisationen stellen die damit verbundene Komplexität und Umstellungen eine große H¨ urde dar. Gleichzeitig kann diese klassische“ Form der ” Business Software meistens nur einen kleineren Teil der Anforderungen einer

126


KM Initiative abdecken. Man sieht also schnell, dass es durchaus Alternativen gibt. Diese sind aber nicht so allgemein, wie die im letzten und diesem Kapitel beschriebenen Systemkategorien.

6.1 Potenzielle Anwendungsgebiete Es wurde schon kurz darauf hingewiesen, dass es bei CMS Systemen auch um die vielf¨ altigen Erweiterungsmodule geht. Damit kommt man zu der Fragestellung, f¨ ur welches Anwendungsgebiete man eine Lösung benötigt. Dazu jetzt eine grobe Einteilung in unterschiedliche Gebiete: Core CMS Funktionen Editieren von Seiten mit einem WYSIWYG Editor; Dabei Unterst¨ utzung durch Workflows und ein Versionssystem; Meist auch Metadaten, G¨ ultigkeitszeitr¨ aume, Templates“ ” Erweiterte CMS Funktionen Artikelsystem (Unterst¨ utzung f¨ ur das Schal” ten“ von Nachrichten); Anbieten und Verwalten von Dateien (bis hin zum kleinen“ DMS); H¨ aufig Unterst¨ utzung von Events (zum Beispiel Eventka” lender); Zum Teil Links (als separates Angebot), Kommentare (eventuell mit Moderation), Formulargeneratoren, etc. Personalisierung Im Sinne von passenden Angeboten; Durch die Möglichkeit einer individuellen Anpassung (meist des Look & Feel); Durch Zugriffskontrollen (meist als ACLs) Weitere zur Verf¨ ugung gestellte Informationen FAQs, HOWTOs, Fotogalerien, Adressbuch, Blogs Strukturierte Kommunikation Forumsfunktionalität, Issue Tracker, Umfragen, Newsletter (zum Teil) Unstrukturierte Kommunikation Chat, Instant Messaging, Webmail beziehungsweise Zugriff auf E-Mail-Infrastruktur, Mailinglisten (zum Teil) Zusammenarbeit (Collaboration) Bug Tracking, Wikis, Kalenderfunktionalit¨ at Projektunterst¨ utzung Projektverwaltung eventuell plus Aufgaben, Benachrichtigungen, etc. Man sieht, dass es im Kern um das Zurverf¨ ugungstellen von Informationen geht. Dazu kommt das Erm¨ oglichen und Unterst¨ utzen einer Zusammenarbeit mittels fachlicher Module sowie verschiedene Formen der Kommunikation und Kollaboration. Dadurch ergibt sich eine prinzipielle Unterscheidung zu Groupware Systemen und gleichzeitig kann man eine Reihe von Gemeinsamkeiten erkennen. 6.1.1 Ziele der KM Initiative/des KM Systems Die Darstellung der verschiedenen Einsatzgebiete von CMS Systemen inklusive diverser Zusatzmodule illustriert wieder die Notwendigkeit, ein klares Ziel

6.1 Potenzielle Anwendungsgebiete

127

vor Augen zu haben. Bevor ein Eingehen auf einzelne Funktionsblöcke oder individuelle Systeme Sinn macht, muss man sich die unmittelbaren und mittelfristigen Ziele des KM Systems u ¨ berlegt haben. Die Voraussetzung das tun zu k¨ onnen ist eine klar umrissene KM Initiative. Dabei geht es einerseits um die Vision aber auch gleichzeitig um konkrete Ziele, die Zug um Zug erreicht werden sollen. Wichtig ist auch noch zu u ¨ berlegen, was mittelfristig in einem konkreten Fall bedeutet. Dieses Buch m¨ ochte das nicht exakt festlegen, gleichzeitig wird an den Bereich von zwei bis maximal f¨ unf Jahre gedacht. Damit ist auch eine Abgrenzung f¨ ur die beiden anderen Bereiche (also unmittelbar und langfristig) gegeben. In einer konkreten Situation können selbstverständlich auch andere Definitionen Sinn machen. Zu dem generellen Thema KM gibt es dabei ja eine Unmenge an Literatur mit einer Reihe von m¨ oglichen Ans¨ atzen dazu. Dabei sollte man unbedingt auf ganzheitliche Ans¨ atze abzielen und nicht bei einer rein wirtschaftlichen oder technischen Betrachtung stehen bleiben. Zusätzlich gibt es eine Reihe von Beratungsfirmen, die entsprechende Erfahrungen sammeln konnten. Hier sollte man sich an erfolgreichen Projekten orientieren und Erfahrungsberichte von anderen Organisationen (¨ uber KM Projekte und die Berater) einbeziehen. Die Notwendigkeit einer mittelfristigen Strategie f¨ ur ein KM System ist ebenfalls schon diskutiert worden. Auch bei einem Start mit einem CMS System handelt es sich dabei um eine notwendige Voraussetzung. Man sollte hier auch insbesondere an die in den 1990er Jahren oft eingef¨ uhrten IntranetSysteme denken, die h¨ aufig nur einen minimalen Effekt auf die jeweilige Organisation hatten. Bei einem Open Source CMS System geht es dabei um geringere Kosten aber um die gleiche Problematik. Es zeigt sich ganz deutlich, dass auch bei einem Start mit einem CMS System eine fachliche und technische Strategie“ absolut notwendig ist. Zu” erst muss bekannt sein, welche KM Ziele eine Organisation erreichen will. Als Zweites muss daraus das mittelfristig angestrebte KM System definiert werden. Zus¨ atzlich gilt es nat¨ urlich noch, generell wichtige Rahmenbedingungen wie die Zukunftssicherheit einer Plattform zu ber¨ ucksichtigen. Schnell ein” mal“ ein CMS System einzuf¨ uhren ist f¨ ur eine größer angelegte KM Initiative auf jeden Fall ein Fehler, den man vermeiden sollte. 6.1.2 Vorhandene Systeme Wie bei Groupware Systemen muss man damit rechnen, dass viele Organisationen schon einen Internetauftritt beziehungsweise ein Intranet und oft dahinter ein CMS System haben. Allerdings werden diese CMS Systeme meist von wesentlich weniger Leuten f¨ ur weniger KM-sensitive“ Aufgaben verwendet. ” Dazu kommt noch die Tatsache, dass es wesentlich einfacher ist, Webinhalte in eine neue L¨ osung zu integrieren (mittels einer Ablöse oder zum Beispiel unger und durch Verlinkungen). Weiters sind CMS L¨ osungen noch wesentlich j¨ nur wenige Organisationen werden ein wirklich mächtiges“ CMS System im ” Einsatz haben, das eventuell als Basis oder Teil eines KM Systems in Frage

128


kommt. Damit kann man feststellen, dass eine Integration eines vorhandenen CMS Systems eher eine Ausnahme sein wird und nicht im Detail beleuchtet werden muss. Schwieriger wird es bei in ein Intranet eingebundenen Zusatzsystemen. Dabei handelt es sich typischerweise um fachliche Applikationen mit einem Web-Interface. Unmittelbar geht es wieder um die Wichtigkeit f¨ ur das KM System. Daneben um die Frage, ob die Funktionalität leicht durch ein neues Modul abgel¨ ost werden kann. Abh¨ angig von den Antworten wird man das System abl¨ osen, inklusive der Daten und Funktionen oder nur als Benutzerschnittstelle integrieren. Leider kann man wegen der Vielfalt der vorhandenen Lösungen hier nicht in die Tiefe gehen. Ein wichtiger Punkt ist aber, dass zumindest die oberfl¨ achliche Integration m¨ oglich sein m¨ usste. Ein anderer Aspekt sind nat¨ urlich die vorhandenen Inhalte in Intranet-, Internet- beziehungsweise generell CMS Systemen. Insbesondere IntranetSysteme sollten mit Einf¨ uhrung eines CMS System als Teil eines KM Systems abgel¨ ost werden. Der Internetauftritt einer Organisation wird dagegen eher ein Randthema sein. Es wird sicher auch an dieser Stelle wichtige Informationen geben und man sollte sich u ¨berlegen alles mit einem System abzudecken. Es handelt sich im Normalfall aber um keine Kernaufgabe eines KM Systems. Insgesamt betrachtet geht es prim¨ ar um vorhandene Intranet-Inhalte (ob mit oder ohne dazugeh¨ origem CMS). Diese sollten möglichst in die neue Lösung migriert und das alte Intranet vollst¨ andig abgelöst werden. Je strukturierter vorhandene Inhalte u ¨bernommen werden können desto besser. Diese Frage stellt sich insbesondere auch bei Zusatzfunktionen, die u ¨ ber ein reines Intranet hinausgehen. Hier m¨ ussen wieder die vorhandenen Möglichkeiten analysiert werden und soweit machbar, eine Ablöse oder eine möglichst weitgehende Integration durchgef¨ uhrt werden. Auf keinen Fall sollte man einfach ein CMS System einf¨ uhren und auf positive KM Effekte hoffen. Der wahrscheinlichste Effekt ist verlorene Produktivit¨ at durch die Beschäftigung mit einem System, das den Leuten nicht wirklich bei der Arbeit helfen kann. 6.1.3 Argumente f¨ ur den Start mit einem CMS System Insgesamt stellt sich die Frage, welche Aspekte f¨ ur den Start mit einem CMS System sprechen und was Argumente dagegen sind. Wie schon erwähnt, gibt es aus Sicht des Autors prim¨ ar drei M¨ oglichkeiten: 1. Start mit einem Groupware System 2. Start mit einem CMS System 3. Start auf Basis eines anderen Systems. Die dritte M¨ oglichkeit wird dabei nicht näher beleuchtet, da sie eher in Ausnahmef¨ allen sinnvoll ist (aber einen potenziell wichtigen Punkt f¨ ur eine Analyse darstellt). Im Kapitel 5 wurde schon auf die Wichtigkeit von Kommunikation und Zusammenarbeit hingewiesen. Je mehr Verbesserung bei diesen Themen durch

6.2 Entscheidung f¨ ur ein Gebiet

129

ein geplantes System m¨ oglich ist und je st¨ arker eine KM Initiative diesen Bereich adressieren will, desto eher wird ein Start mit einer Groupware Sinn machen. Diese Argumentation zeigt umgekehrt, wann mehr f¨ ur einen Start mit einem CMS System spricht. Nat¨ urlich ist eine rein negative“ Argumentation ” nicht ausreichend. Die eindeutigste Argumentation f¨ ur einen Start mit einem CMS System ist das Ziel, Informationen intern und eventuell auch extern in einem Intranet beziehungsweise Extranet oder einer Homepage (einem Portal) zur Verf¨ ugung stellen zu k¨ onnen. Dazu z¨ ahlen bei weitem nicht nur HTML Doku¨ mente sondern auch HOWTOs, FAQs, Dateien, etc. Ahnliches gilt f¨ ur die Konzentration auf (heutzutage meist) web“-basierte Funktionen. Hierbei geht es ” etwa um Foren, Blogs, Wikis, Umfragen, etc. Weniger eindeutig ist die Argumentation bei unstrukturierter Kommunikation wie E-Mail, vielen Formen der Zusammenarbeit (Collaboration) oder auch der Projektunterst¨ utzung. Diese Bereiche werden u ¨ berwiegend (auch) durch Groupware Systeme abgedeckt und nicht jede auf einem CMS System basierende Funktionalit¨ at kann (zumindest aktuell) ein vollwertiger Ersatz sein. Eine weitere sehr wichtige Argumentation f¨ ur einen Start“ mit einem ” CMS System kann das Vorhandensein einer guten Groupware L¨ osung darstellen. Wie schon in Kapitel 5 diskutiert, macht es häufig Sinn eine vorhandene Groupware zu behalten und sie in ein KM System zu integrieren. Praktisch kann das heißen, mit einem CMS System zu beginnen und danach die Groupware zu integrieren. Je umfassender eine KM Initiative ist, desto eher wird man sowieso ein CMS System beziehungsweise entsprechende Funktionalit¨ aten integrieren wollen. Zusammengefasst gibt es prim¨ ar zwei Gr¨ unde f¨ ur den Start mit einem CMS System. Einerseits der (zumindest unmittelbare) Fokus auf Informationsdarstellung und Weitergabe mittels eines Intranets beziehungsweise auch Extranets, etc. Andererseits den Aufbau eines kompletten KM Systems wobei das CMS System unmittelbar oder in weiterer Folge ein Groupware System erg¨ anzt und erweitert. Beim zweiten Ansatz stehen die Zusammenarbeitsaspekte eher im Vordergrund als beim ersten. Nicht vergessen sollte man aber festzustellen, ob nicht ein Start mit einem anderen Subsystem mehr Sinn macht. Das k¨ onnte zum Beispiel ein CRM System f¨ ur eine sehr kundenorientierte Organisation sein, die die Zusammenarbeit beziehungsweise Informationsweitergabe gut im Griff hat.

6.2 Entscheidung fu ¨ r ein Gebiet Wie der vorherige Abschnitt gezeigt hat, gibt es eine Reihe von Gebieten, die ein CMS System abdecken kann. Weiters stellt sich die Frage, ob und wenn ja welche vorhandenen Funktionalit¨ aten abgel¨ ost werden sollen. Wenn man noch

130


die kurz- und mittelfristigen Ziele des geplanten KM Systems einbezieht, sollte eine Entscheidung f¨ ur oder gegen gewisse Anwendungsgebiete leicht fallen. Eine umfassende KM Initiative wird nat¨ urlich kaum auf eines der aufgezeigten Gebiete verzichten k¨ onnen. Hierf¨ ur wird man ganz im Gegenteil noch weiter gehen m¨ ussen. Eine entsprechende Diskussion kann man in den folgenden Kapiteln finden. Auf die Aspekte der Zusammenarbeit wird man bei einer KM Initiative am wenigsten verzichten können. Daher w¨ urden am ehesten die Kernfunktionen eines CMS Systems in manchen Fällen verzichtbar erscheinen. Entsprechende Diskussionen finden sich in Kapitel 5. Wenn man zumindest mittelfristig große“ Pläne hat, wird man sich auf ” jeden Fall ein relativ komplettes KM System u ussen. Dabei geht es ¨berlegen m¨ einerseits um eine solide technische Basis f¨ ur ein komplexes System, das aus mehreren verschiedenen Modulen und Systemen besteht. Andererseits geht es darum, m¨ oglichst umfassende Module f¨ ur die gew¨ unschten fachlichen Funktionen anbieten zu k¨ onnen. Diese beiden Fragen sollte man bis zu einem gewissen Grad separat betrachten und dann in weiterer Folge eine Synthese“ ” bilden. Hintergrund ist, dass man funktionale Aspekte ohne Ber¨ ucksichti” gung“ der technischen Machbarkeit untersuchen sollte. Eine rein technische Analyse muss dagegen u ¨ berlegen, wie eine Integration umgesetzt werden kann oder auch ein wartbares Gesamtsystem entsteht. Ein dritter Aspekt besteht dann noch in den initialen und laufenden Kosten. Eine Gesamtentscheidung kann erst nach gr¨ undlicher Aufarbeitung von allen drei Fragestellungen stattfinden. Einfacher“ ist es, wenn mittelfristig keine umfassende KM Initiative ” angestrebt wird. Gerade f¨ ur kleinere Organisationen, die aktuell wenig bis gar keine IT Unterst¨ utzung nutzen, ist das sicher eine empfehlenswerte Strategie. Je weniger entsprechende Erfahrung und Nutzung vorliegen desto wichtiger ist die gut u uhrung und das Vertrautmachen mit IT Systemen. ¨berlegte Einf¨ Trotzdem sollte man dabei weiterf¨ uhrende Aspekte grob im Hinterkopf haben. (Insbesondere etwa darauf achten, dass die Daten relativ einfach migrierbar sind; also zum Beispiel ein dokumentiertes Datenbankschema vorhanden ist.) Organisationen die prinzipiell einmal nicht in Richtung einer umfassenden KM Initiative gehen wollen, sollten sich ganz besonders intensiv mit den potenziellen M¨ oglichkeiten auseinander setzen. Man sollte eine Entscheidung dann vor allem von organisatorischen Fragen abhängig machen: • •

Was sind die Kernprozesse der Organisation? ur eine verbesserte IT Unterst¨ utzung? Wo besteht der größte Bedarf f¨

6.2.1 Entscheidungsgrundlagen In den folgenden Abschnitten werden wichtige Punkte zu den einzelnen Funktionsgebieten erl¨ autert. Dabei gibt es eine kurze Beschreibung der Funktion(en), eine kurze Diskussion, wof¨ ur so etwas hilfreich ist, und wie man eine Entscheidung herbeif¨ uhren kann.


131

Core CMS Funktionen Core CMS Funktionalit¨ at ist bei einem Start mit einem CMS System ein Teil der Systembasis. Damit kann man relativ einfach Inhalte pflegen und zur Verf¨ ugung stellen. Dieser Teil eignet sich damit f¨ ur allgemeine und selten zu ¨ andernde Inhalte. F¨ ur sich alleine genommen ist diese Funktionalität aber relativ eingeschränkt und bietet nur sehr eingeschränkte KM Unterst¨ utzung. Erweiterte CMS Funktionen Wenn man zus¨ atzlich eine Art Redaktion einrichten kann, bieten erweiterte CMS Funktionen M¨ oglichkeiten mehr Inhalte und diese strukturierter anzubieten. Die konkreten Funktionen der Systeme sind relativ uneinheitlich. Generell geht es aber in Richtung von strukturierten Informationen wie Artikel oder Events beziehungsweise auch um Dateien. Eine gewisse Interaktivit¨ at ist durch Kommentare oder Formulare möglich. Es geht aber nicht um das Zusammenarbeiten. Wenn also genug an entsprechend strukturierten Informationen zusammenkommen, sollte man diese Funktionen anstreben und ausnutzen. Insbesondere da die besseren CMS Systeme sie sowieso mitbringen. Wie der Begriff Redaktion andeutet, helfen diese erweiterten Möglichkeiten auch bei der Zusammenarbeit von mehreren Bearbeitern (zum Beispiel braucht man fast keine Abstimmung, wenn mehrere Redakteure Artikel erfassen; das ist wesentlich schwieriger, wenn man eine reine Sammlung“ von ” HTML-Seiten hat). Personalisierung Der n¨ achste Punkt ist die Personalisierung. Insbesondere eine Zugriffskontrolle ist absolut notwendig, wenn man sensitive oder vertrauliche Informationen im System verwalten will. Weiters kann man Partnern in Form eines Extranets auch Teile des eigenen Systems zug¨ anglich machen, wenn ein entsprechend flexibles Berechtigungssystem vorhanden ist. Eine Individualisierung der Oberfl¨ ache ist umso wichtiger je unterschiedlicher die Aufgaben der verschiedenen Mitarbeiter sind und je mehr Funktionen das KM System anbietet. Der Umkehrschluss gilt nat¨ urlich ebenfalls. Weiters sollte man bedenken, dass die M¨ oglichkeit einer Individualisierung der Oberfläche durch jeden Mitarbeiter die Wartungskosten leicht in die H¨ ohe treiben kann. In dieser Frage muss man daher versuchen, einen sinnvollen Weg zu finden diese Funktion nicht zu verbieten. (Eine Idee w¨ are es generell zu erlauben und bei größeren Problemen eines Benutzers seine Oberfl¨ ache mit einer Standardvariante zu u ¨ berschreiben.) Schließlich k¨ onnen auch manche Systeme aufgrund von bekannten Interessen beziehungsweise Informationen u ¨ber die Systemnutzung mögliche passende Inhalte anbieten. Das kann in Form von zusätzlichen Ansichten oder

132


¨ als entsprechende Angebote in den verschiedenen Modulen geschehen. Uberwiegend werden solche Funktionen dabei aber nur nach einer eingehenden Analyse und entsprechender Konfiguration (sinnvoll) funktionieren. Als Standarerweiterungen von CMS Systemen sollte man sie also nicht sehen (und auch nicht auf Datenschutz¨ uberlegungen vergessen). Weitere zur Verf¨ ugung gestellte Informationen Bei dem Punkt weitere zur Verf¨ ugung gestellte Informationen“ gilt einiges ” was schon zu den erweiterten CMS Funktionen gesagt wurde. Es handelt sich bei dieser Gruppe prim¨ ar um spezialisierte und meist strukturierte Zusatzangebote. Bei FAQs und HOWTOs geht es darum, Handlungsanleitungen zur Verf¨ ugung zu stellen. Bei einem Adressbuch einfach darum, eine einheitliche und gemeinsam gepflegte Liste von Adressen zu haben. In größeren Initiativen ist das ein wichtiger Aspekt einer Groupware und man sollte darauf achten, immer nur ein globales Adressbuch in einer Organisation zu haben (beziehungsweise zwischen mehreren vorhandenen Systemen ständige Abgleiche zu fahren). Fotogalerien sind ebenfalls ein Beispiel f¨ ur weitere zur Verf¨ ugung gestellte Informationen. Blogs (Web-Logs) stellen dagegen eine relative junge Möglichkeit f¨ ur Mitteilungen dar. Am einfachsten k¨ onnte man sie mit einem öffentlichen Online Tagebuch vergleichen. Einerseits kann man damit relativ effektiv unwichtige“ ” Informationen transportieren (die nur von Interessierten gelesen werden) und andererseits auch durchaus kontroversielle Diskussionen anfachen. Je größer die Gemeinde ist, die so etwas liest, desto effektiver ist es. Dieser Mechanismus w¨ urde sich f¨ ur die Schl¨ usselpersonen einer Organisation anbieten, die so ihre Gedanken zu verschiedenen Themen zur Verf¨ ugung“ stellen können. ” Insgesamt sollte ein mittleres CMS System eine Reihe dieser Funktionen anbieten und man muss sich haupts¨ achlich u ¨ berlegen, wie man sie in die Arbeitsabl¨ aufe einbindet. Je weniger direkten Kontakt die Schl¨ usselpersonen einer Organisation mit den anderen Mitarbeitern haben, desto eher sollte man auch Blogs einbinden und darum bitten, sie entsprechend zu benutzen (anordnen kann man so etwas sicher nicht). Strukturierte Kommunikation Mit strukturierter Kommunikation n¨ ahert man sich schon einer Groupware (beziehungsweise kann man es auch umgekehrt sehen). Am wichtigsten sind dabei sicher Foren. Sie bieten die M¨ oglichkeit einer strukturierten Kommunikation und k¨ onnen helfen, Informationsfl¨ usse zu kanalisieren. Man hat auch offentliche“ Dokumentation und kann damit Doppelgleisiggleichzeitig eine ¨ ” keiten oder gar unterschiedliche Entscheidungen von verschiedenen Leuten vermeiden oder zumindest reduzieren. Issue Tracker und Umfragen sind schon spezialisiertere Formen, die je nach vorhandenen Aufgaben einer Organisation


133

mehr oder weniger sinnvoll sein k¨ onnen. Newsletter als letztes Beispiel helfen, zu einem Themenbereich geh¨ orige Informationen an alle Interessierten zu verteilen. Das kann sozusagen die elektronische Form einer Mitarbeiterzeitung sein oder auch einfach interessante Informationen zu einem bestimmten Thema (zum Beispiel Security) beinhalten. Je eher eine Organisation in irgendeiner Form getrennt arbeiten muss, desto eher wird strukturierte Kommunikation ein wichtiger Faktor zur Unterst¨ utzung von Gruppenarbeit sein. Insbesondere wenn es um nicht zeitkritische Punkte geht (bei denen das potenziell fehlende rasche Feedback kein Problem ist). Wenn es sich dagegen um eine kleine Firma handelt in der praktisch alle Mitarbeiter in einem Stockwerk sind und u uro ¨ berwiegend im B¨ arbeiten, werden entsprechende Kommunikationsformen weniger Verbesserungen bringen. Auch in solchen Umgebungen gibt es Vorteile aber der erhöhte Aufwand der Kommunikation wird oft nicht zu rechtfertigen sein. Unstrukturierte Kommunikation Unstrukturierte Kommunikation entspricht eigentlich Groupware Funktionen als Teil oder Modul eines CMS Systems. Es geht dabei um das Anbieten von vorhandenen E-Mails und Mailfunktionalit¨ aten inklusive Mailinglisten. Dabei kann es sich um das prim¨ are Medium oder eine Ergänzung handeln. Bei letzterer Verwendung muss aber unbedingt sichergestellt werden, dass immer die prim¨ aren E-Mail-Daten zur Verwendung kommen und es keine (sichtbaren) Redundanzen gibt. Bei Chat und Instant Messaging geht es um synchrone Kommunikation zwischen beliebig vielen Teilnehmern. Dies ist vor allem vorteilhaft, um r¨ aumlich getrennte Personen m¨ oglichst einfach und ungezwungen miteinander kommunizieren zu lassen. Ein wichtiger Punkt dabei ist, dass elektronisch gef¨ uhrte Kommunikationen f¨ ur eine spätere Suche zur Verf¨ ugung stehen und so den Pool an vorhandenen Informationen bereichern können (etwas was bei pers¨ onlichen oder per Telefon gef¨ uhrten Besprechungen noch kaum m¨ oglich ist). Kurz gesagt geht es einerseits darum Groupware Funktionen anzubinden oder abzurunden. Zu dieser Thematik liefert Kapitel 5 eine detaillierte Diskussion u ur und Wieder. Andererseits geht es um die Unterst¨ utzung ¨ber das F¨ von erweiterten Kommunikationsmethoden, die vor allem f¨ ur räumlich verteilt (beziehungsweise u ¨ berhaupt mobil) arbeitende Mitarbeiter wichtig sind. Dabei geht es zum Teil ebenfalls um Groupware Aspekte aber in einer anderen Form. In beiden F¨ allen sollte einem eine Analyse der vorhandenen Situation und des angestrebten KM Systems helfen, eine Entscheidung u ¨ ber die Notwendigkeit dieser Funktionen treffen zu k¨ onnen. Zusammenarbeit (Collaboration) Das n¨ achste Gebiet umfasst verschiedene Aspekte der Zusammenarbeit (Collaboration). Zum Teil geht es wieder in Richtung Groupware. Hierzu gehört

134


etwa ein Gruppenkalender, der alle Termine umfassen sollte (entweder direkt oder mittels eines Abgleichs). Eine andere Sache ist ein Bug Tracker (prinzipiell einem Issue Tracker ¨ ahnlich; je nach Verwendung eher f¨ ur strukturierte Kommunikation oder mit st¨ arkerem Fokus auf Zusammenarbeit). Hier geht es darum, die Zusammenarbeit zum Beheben eines Problems zu unterst¨ utzen und auch eine entsprechende Dokumentation zu haben. Eine besonders interessante Form der Zusammenarbeit stellen die seit einiger Zeit sehr beliebten Wikis dar. Sie erm¨ oglichen in Intranets (oder auch dem Internet) gemeinsam an einem Text zu arbeiten. Dieser Text kann dabei eine technische Beschreibung, eine Bedienungsanleitung, etc. sein. Wichtig ist, dass mehrere Personen daran zusammenarbeiten können. Dadurch werden einerseits m¨ oglichst viele Leute einbezogen und andererseits eine höhere Qualität und Aktualit¨ at erreicht. Diese Effekte bed¨ urfen nat¨ urlich einer entsprechenden organisatorischen Verankerung (in den Arbeitsabläufen und generell in der Art, wie manche Sachen gehandhabt werden). Wenn eine Organisation entweder von Zusammenarbeit profitieren kann oder sie sogar Voraussetzung f¨ ur ein Erreichen ihrer Ziele ist (heutzutage d¨ urfte das schon die Mehrheit sein), k¨ onnen Wikis eine wichtige Hilfe sein. Da es relativ einfach sein sollte entsprechende Funktionen zus¨ atzlich anzubieten, spricht aus technischer Sicht kaum etwas gegen eine Einbindung. Projektunterst¨ utzung Bei der Projektunterst¨ utzung geht es um das Verwalten von Projekten und dazugeh¨ origen Informationen. Dabei handelt es sich bis zu einem gewissen Grad um spezialisierte Funktionen, die bei wenigen CMS Systemen direkt oder als Modul vorhanden sind. Je nach den Aufgaben einer Organisation wird man entweder schon ein Projektsystem haben oder eventuell keines benötigen (Support oder Beratung werden zum Beispiel meist nicht projekthaft abgewickelt). Wichtig sind dabei folgende Fragen: Ben¨ otigt man eine entsprechende Unterst¨ utzung? Wenn ja, dann muss man entweder ein CMS System mit solchen Funktionen auswählen oder ein anderes System integrieren. Könnte einem ein entsprechendes System helfen? Wenn ja, dann sollte man schauen, ob man ein CMS System mit den anderen notwendigen Funktionen und einer Unterst¨ utzung von Projekten findet. Insgesamt ist die gebotene Funktionalit¨ at zur Projektunterst¨ utzung meist mittelm¨ aßig“. Von daher sollte man gut u ¨berlegen, ob einem das ausreicht. ” Andererseits kann es helfen, eine gewisse Uniformität herzustellen und einen ¨ Uberblick zu ermöglichen. Wichtig ist vor allem festzustellen, wie eine solche Lösung in einen zuk¨ unftigen Arbeitsablauf passen kann.

6.3 Entscheidung f¨ ur ein System

135

6.2.2 Zusammenfassung Man sieht, dass es bis auf die Core CMS Funktionen auf die jeweilige Situation und die unmittelbaren Ziele des KM Systems ankommt. Nur unter Ber¨ ucksichtigung dieser Rahmenbedingungen“ kann eine Entscheidung u ¨ber die Not” wendigkeit oder Wichtigkeit einzelner Gebiete getroffen werden. Gleichzeitig sind diese Entscheidungen aber die Voraussetzung f¨ ur eine Systemauswahl. Besonders wichtig ist die Fragestellung, ob man Core“ und Erweiterte“ ” ” CMS Funktionen u otigt. Sollte der Bedarf nicht relativ groß sein, ¨ berhaupt ben¨ ist eventuell ein Start mit einer Groupware Lösung sinnvoller. Gleichzeitig kann sich die Anforderung auch aus der geplanten zuk¨ unftigen Arbeitsweise ¨ ergeben. Wichtig ist weiters die Uberlegung einer Einbeziehung von Partnern in die eigenen Systeme. Das ist mit web-basierten Systemen am leichtesten. Entsprechende Extranets“ lassen sich meist relativ einfach mit besseren CMS ” Systemen einrichten.

6.3 Entscheidung fu ¨ r ein System Abschnitt 3.3 hat schon wichtige Open Source CMS Systeme vorgestellt und einander gegen¨ ubergestellt. Man kann dabei vier Kategorien unterscheiden. Einerseits gibt es drei verschiedene Programmiersprachen (Python, Java und PHP). Andererseits kann man die PHP Vertreter noch in einfachere und komplexere CMS Systeme unterteilen (wobei man die Unterscheidung auch eher in Hinblick auf Portal“-Eignung sehen kann). ” Insgesamt gibt es zwei besonders wichtige Fragen in diesem Zusammenhang. Erstens, welches System ist f¨ ur welchen Zweck am besten geeignet. Zweitens, welche sonstigen Kriterien sollte man f¨ ur eine Systemauswahl ber¨ ucksichtigen. Diese Aspekte werden in den folgenden Abschnitten näher beleuchtet. 6.3.1 Diskussion der CMS Systeme Eine Diskussion der vorgestellten CMS Systeme muss vor allem auf die Eignung f¨ ur die vorgestellten Einsatzzwecke eingehen. Neben den in Abschnitt 3.3 beschriebenen Produkten werden auch noch zwei weitere PHP basierte Systeme betrachtet. Dabei handelt es sich um eher als Groupware eingestufte Produkte, die sich daher in Abschnitt 3.2 finden. Sie passen relativ gut zur Kategorie der komplexeren PHP basierten CMS System dazu (auch wenn sich das komplex eher auf das ganze Produkt und nicht auf den CMS Aspekt bezieht). Zus¨ atzlich werden noch besonders wichtige nicht funktionale Aspekte dargestellt. Eine generelle Diskussion dieser Fragestellungen gibt es aber erst im folgenden Abschnitt.

136


Plone Plone basiert auf dem Python Application Server Zope und bietet eine ganze Reihe von Funktionen. Damit werden die drei Kerngebiete von CMS Systemen (also Core sowie erweiterte CMS Funktionen und Personalisierung) musterg¨ ultig“ unterst¨ utzt. Auch bei der Kategorie Weitere zur Verf¨ ugung ” ” gestellte Informationen“ bietet Plone eine Reihe von Funktionen. F¨ ur Struk” turierte Kommunikation“ werden unter anderem Foren, ein Issue Tracker und Umfragen unterst¨ utzt. Genauso gibt es entsprechende Möglichkeiten der un” strukturierten Kommunikation“ in der Form von Chat, Instant Messaging oder auch Webmail. Die letzten beiden Gebiete (Zusammenarbeit beziehungsweise Projektunterst¨ utzung) werden allerdings nicht direkt adressiert. Insgesamt bietet Plone eine reichhaltige Unterst¨ utzung von fast allen f¨ ur CMS Systeme relevanten Gebieten. Es fehlen eigentlich nur die von einem reinen“ CMS System schon entfernteren“ Gebiete Zusammenarbeit und ” ” Projektunterst¨ utzung (zumindest was den unmittelbaren Funktionsumfang angeht). Damit bietet es sich als eines der besten CMS Systeme an. Gleichzeitig gehen Zope und Plone bis zu einem gewissen Grad eigene Wege (schon beginnend mit der Programmiersprache Python). Diesen Aspekt darf man bei einer Entscheidung nicht u ¨ bersehen. Gerade an solchen Fragestellungen erkennt man auch wieder die Wichtigkeit einer mittelfristigen Planung eines KM Systems die Voraussetzung ist, um solche Punkte sinnvoll diskutieren zu k¨ onnen. Diese Fragestellung kann entscheidend werden, wenn es um die Integration von vielen weiteren Systemen (etwa einer Groupware) geht. elevateIT elevateIT stellt bis zu einem gewissen Grad einen Sonderfall dar, weil es versucht ein besseres“ Plone zu sein. Damit ergibt sich im Großen und Ganzen ” eine ¨ ahnliche funktionale Beurteilung. Die primären Unterschiede (zum Beispiel Metadaten zu jedem Element und ein verbesserter Workflow) muss man prim¨ ar gegen das Risiko des j¨ ungeren Systems mit kleinerem Nutzer- und Entwicklerkreis abw¨ agen. OpenCMS OpenCMS ist das ¨ altere von den zwei Java basierten CMS Systemen. Es unterst¨ utzt die beiden Gebiete von CMS Funktionen. Ebenso bietet es weitere M¨ oglichkeiten der Zurverf¨ ugungstellung von Informationen. Personalisierungsaspekte sind vorhanden aber eher schw¨ acher ausgeprägt. Generell sind Kommunikationsaspekte durch OpenCMS selbst kaum adressiert. Daf¨ ur gibt utzung f¨ ur Zues ein Projektsystem und etwa durch einen Kalender Unterst¨ sammenarbeit (Collaboration).


137

Insgesamt also ein relativ komplettes CMS System. Kommunikationsmodule werden aber nicht direkt zur Verf¨ ugung gestellt. Daf¨ ur gibt es Unterst¨ utzung f¨ ur Projekte und generell Zusammenarbeit. Durch Java als Programmiersprache ist eine enge Integration mit anderer Java Software relativ einfach m¨ oglich (etwa auch in Form von JSPs). Daher insbesondere empfehlenswert, wenn eine Java L¨ osung gesucht ist, die sich nicht direkt um Kommunikationsaspekte k¨ ummern muss. Zum Beispiel, weil es zusätzlich zu einer web-f¨ ahigen Groupware eingesetzt oder beides in ein Portal integriert wird. JBOSS Portal Ein weiteres Java basiertes CMS System ist JBOSS Portal. Wie auch XOOPS hat es keinen expliziten CMS Fokus sondern stellt ein Portal mit CMS Funktionalit¨ aten dar. Es bietet die grunds¨ atzlichen CMS Funktionen, wobei hier noch mehr m¨ oglich w¨ are. Personalisierung ist zum Teil vorhanden. Zusätzlich gibt es die M¨ oglichkeit von FAQs, um Informationen zur Verf¨ ugung zu stellen, sowie auch Foren und Umfragen zur Unterst¨ utzung von strukturierter Kommunikation. In Richtung Zusammenarbeit oder Projektunterst¨ utzung gibt es zumindest ein Wiki aber keine anderen wichtigen Hilfestellungen. Unstrukturierter Kommunikation wird nicht direkt angeboten. Gleichzeitig war dieses System zum Zeitpunkt der Analyse in aktiver Entwicklung. Daher sollte man bei prinzipiellem Interesse einen Blick auf den aktuellen Status werfen. Gesamthaft betrachtet bietet es die wichtigsten CMS Funktionen im Kontext eines Portals, das auf einem Application Server basiert. Diese Eigenschaft empfiehlt es f¨ ur Integrationsprojekte auf Java Basis. Gleichzeitig werden mehrere der identifizierten Gebiete gar nicht oder nur zum Teil (direkt) unterst¨ utzt. Daher ist es weniger geeignet, wenn man ein möglichst umfangreiches CMS System sucht. Contenido Mit Contenido kommen wir zum ersten PHP basierten CMS System. In dieser Skriptsprache gibt es eine unglaubliche Vielzahl an web-basierten Entwicklungen und als Ergebnis ist das Feld kaum mehr u ¨ berschaubar. Contenido selbst ist ein relativ beliebtes CMS System, das die beiden grundlegenden Funktionsbl¨ ocke gut unterst¨ utzt. Zus¨ atzlich gibt es etwa noch Umfragen, Statistiken und Todos f¨ ur Redakteure, also gewisse M¨ oglichkeiten f¨ ur Zusammenarbeit und Kommunikation. Vor allem das Fehlen von ACLs zeigt aber schon, dass es sich hier prim¨ ar um ein klassisches“ CMS System handelt, das weniger f¨ ur ” andere Einsatzgebiete gedacht ist. Kurz gesagt ist Contenido vor allem ein reines“ CMS System. Daher bie” tet es sich vor allem f¨ ur KM Initiativen und Systeme mit relativ eng umrissenen Bedarf auf diesem Gebiet an. Gerade deshalb ist es auch noch wichtiger als sonst, zu u ¨berlegen ob ein PHP basiertes CMS gut in das Gesamtsystem integrierbar ist. Bei potenziell mehr Bedarf an Funktionalität gibt es sowohl auf Basis PHP als auch ohne eine Reihe von besser geeigneten Systemen.

138


Mambo/Joomla Ein weiteres beliebtes PHP basiertes CMS System ist Mambo. Es deckt die beiden Kerngebiete von CMS Systemen gut ab. Dar¨ uber hinaus bietet es Unterst¨ utzung f¨ ur das Anbieten von weiteren Informationen und zur strukturierten Kommunikation. Zus¨ atzlich werden mit einem Kalender und einem Help Desk System auch Zusammenarbeitsaspekte adressiert. Kaum bis gar nicht unterst¨ utzt werden dagegen Personalisierung, unstrukturierte Kommunikation und Projekte. Kurz gesagt also ein CMS System mit einer gewissen Reihe an Zusatzmodulen. Wie bei Contenido fehlt aber ein ACL System was ein wichtiges Problem im Kontext eines KM Systems sein kann. Daher muss man relativ genau die Notwendigkeit solch einer Unterst¨ utzung analysiert haben. Insgesamt stellt Mambo ein interessantes CMS System mit einer Reihe von Zusatzmodulen wie etwa f¨ ur strukturierte Kommunikation dar. Durch das Fehlen von ACLs und der Unterst¨ utzung von Projekten beziehungsweise unstrukturierter Kommunikation ist es aber nur f¨ ur bestimmte Verwendungszwecke gut geeignet. Wie bei Contenido muss man sehr genau u ¨ berlegen, ob so ein System wirklich in das Gesamtkonzept passt. Das gesagte gilt nat¨ urlich genauso f¨ ur Joomla, das ja eine Abspaltung“ ” von Mambo darstellt. Zum Zeitpunkt der Analyse waren die Systeme noch gr¨ oßtenteils identisch. N¨ ahere Hinweise findet man in Abschnitt 3.3.6. PHP-Nuke PHP-Nuke ist eines der beliebtesten Open Source CMS Systeme. Es ist vor allem durch die unglaubliche Menge an verf¨ ugbaren Modulen interessant. Dabei muss einschr¨ ankend angemerkt werden, dass eher eine selektive Auswahl zur Beurteilung herangezogen wurde. Die St¨ arken liegen auf den Gebieten der CMS Funktionalit¨ at beziehungsweise dem zur Verf¨ ugung stellen von Informa¨ tionen. Uber Zusatzmodule gibt es unter anderem Möglichkeiten zur struk¨ turierten Kommunikation. Uberhaupt kann man f¨ ur eine ganze Reihe von Einsatzgebieten passende Module finden. Gleichzeitig hat es aber Schwachpunkte im Design (was man dem System aufgrund der Geschichte eigentlich kaum vorwerfen will), die es f¨ ur den Einsatz in einem größeren KM System als ungeeignet erscheinen lassen. Kurz gesagt ist PHP-Nuke vor allem f¨ ur kleinere KM Initiativen interessant, die mit einem (in gewisser Hinsicht) schlecht erweiterbaren und skalierbaren System leben k¨ onnen. Daf¨ ur bietet es eine unglaubliche F¨ ulle an Zusatzmodulen, die unmittelbar sehr viel Funktionalität anbieten können. Wenn PHP-Nuke eine interessante Alternative f¨ ur eine KM Initiative darstellt, sollte man sehr genau abw¨ agen, ob die unmittelbaren Vorteile die potenziellen mittelfristigen Probleme aufwiegen.


139

Typo3 Ein weiteres beliebtes PHP basiertes CMS System ist Typo3. Es bietet gute Funktionalit¨ at betreffend den beiden CMS Gebieten. Weiters gibt es noch direkt Unterst¨ utzung f¨ ur Kommunikation mit einem Mail und einem Newsletter Modul. Dar¨ uber hinaus wird nur wenig Unterst¨ utzung im Basissystem angeboten. Damit hat man ein reines“ CMS System vor sich. ” Generell ist Typo3 ein auf die prim¨ aren CMS Funktionen fokussiertes Produkt. Als solches ist es durchaus erfolgreich und auch entsprechend beliebt. Damit empfiehlt es sich entweder f¨ ur sehr eingeschränkte KM Initiativen oder parallel zum eigentlichen KM System. Gerade der letztere Einsatzzweck ist aber nicht der Fokus dieses Kapitels und stellt insgesamt eher ein Randthema dar. F¨ ur zumindest mittelfristig umfassendere Initiativen ist Typo3 daher eher schlecht geeignet. Xaraya Xaraya ist ein noch relativ junges PHP basiertes CMS System. Unmittelbar unterst¨ utzt es die wichtigsten CMS Funktionen und hat zusätzlich noch ein gutes Berechtigungssystem (und damit eine gewisse Personalisierung). Aktuell gibt es auch noch Unterst¨ utzung f¨ ur weitere Formen der zur Verf¨ ugung Stellung von Informationen wie FAQs oder Bilder. Damit k¨ ummert es sich um einige wichtige Gebiete. Nicht adressiert werden Aspekte der Kommunikation oder Zusammenarbeit (auch nicht in Form von Projekten). Alles in allem ist Xaraya ein prinzipiell interessantes System. Da es sich aber noch stark in Entwicklung befindet und nur einen Teil der potenziell relevanten Gebiete adressiert, empfiehlt es sich aktuell nicht f¨ ur einen Einsatz. F¨ ur reine CMS Funktionen gibt es ausgereiftere Systeme und wesentlich mehr bietet Xaraya im Moment nicht an. XOOPS Mit XOOPS kommen wir zu einem auf PHP basierenden CMS System, das man eventuell auch als Portal einstufen k¨ onnte. Trotzdem bietet es die wichtigsten CMS Funktionen (wenn auch etwas eingeschränkter als andere Systeme). Zus¨ atzlich hat es aber einen starken Fokus auf Personalisierung und bietet mit einer Reihe von Zusatzmodulen Unterst¨ utzung f¨ ur verschiedene Formen der Kommunikation, Zusammenarbeit oder dem zur Verf¨ ugung stellen von Informationen. Nur die Projektunterst¨ utzung ist nicht (direkt) gegeben. Insgesamt deckt XOOPS fast alle angef¨ uhrten Gebiete gut ab. Es fehlt eigentlich nur die Projektunterst¨ utzung. Sonst ist der CMS Kern leicht unterdurchschnittlich. Als Ausgleich wird aber eine F¨ ulle von Zusatzfunktionen zur Kommunikation und Zusammenarbeit geboten. Außerdem stellt XOOPS eine relativ gute Integrationsplattform auf PHP Basis dar. Kurz gesagt bietet es

140


sich an, wenn man nicht zu umfangreiche CMS Anforderungen hat. Insbesondere ist es das (von den dargestellten) PHP Produkten am besten geeignete System, um darauf ein gr¨ oßeres System aufzubauen. Daher sollte man bei einer gewissen Tendenz in Richtung PHP einen besonders intensiven Blick auf XOOPS werfen. phpWebSite phpWebSite ist ein weiteres PHP basiertes CMS System. Es bietet eine gute Unterst¨ utzung der direkten CMS Funktionen. Weiters hilft es bei der zur Verf¨ ugung Stellung von Informationen und unterst¨ utzt strukturierte Kommunikation mit Foren oder auch Umfragen. Zusätzlich gibt es auch noch Mailinglisten. F¨ ur ein KM System problematisch ist das Fehlen von ACLs. Daher eignet es sich nur schlecht f¨ ur verschiedene Formen der Zusammenarbeit. Damit gilt f¨ ur phpWebSite, was schon f¨ ur a¨hnliche Vertreter von CMS Systemen gesagt worden ist. Sie eignen sich nur, wenn der Fokus des CMS Systems eng umrissen ist und alles Angedachte abgedeckt werden kann. Alternativ ist noch ein Betrieb parallel zur eigentlichen“ KM Lösung möglich. ” Diese Variante ist aber nur in Ausnahmef¨ allen zu empfehlen (etwa aufgrund besonders wichtiger Anforderungen, die nur so abdeckbar sind). Sollte keiner der beschriebenen F¨ alle zutreffen, ist eher ein anderes CMS System anzuraten.

Tiki Bei Tiki handelt es sich um eine PHP basierte Mischung aus Groupware und CMS System. Daher ist es in Kapitel 3 bei den Groupware Systemen eingeordnet. Es bietet eine brauchbare Unterst¨ utzung der direkten CMS Funktionen und erm¨ oglicht auch verschiedene Formen der zur Verf¨ ugung Stellung von weiteren Informationen. F¨ ur ein Groupware System nicht weiter u ¨ berraschend unterst¨ utzt es auch Personalisierung (mit ACLs), diverse Formen der Kommunikation (von Webmail bis zu Foren) und Funktionen f¨ ur Zusammenarbeit (etwa einen Kalender und Wikis). Damit fehlt nur die direkte Unterst¨ utzung f¨ ur Projekte von den angef¨ uhrten Gebieten. Kurz gesagt deckt Tiki wie etwa auch XOOPS alle funktionalen Bereiche bis auf Projekte ab. W¨ ahrend XOOPS schon in Richtung Portal tendiert, ist Tiki eher gleichzeitig als web-basierte Groupware ausgelegt. Damit eignet sich Tiki relativ gut als kleineres bis mittleres System zur Unterst¨ utzung einer technisch auf Groupware und CMS ausgerichteten KM Initiative. Gleichzeitig ist von der Idee her XOOPS eher als Integrationsplattform gestaltet. So wie bei XOOPS sollte man daher einen intensiven Blick auf Tiki werfen, wenn eine PHP L¨ osung in Frage kommt und das funktionale Angebot relativ gut zu dem angestrebten System passt. Bis zu einem gewissen Grad ist dieses System auch schon ein Vorgriff auf Kapitel 7 in dem Zwittersysteme wie Tiki extra beleuchtet werden.


141

PhpGroupWare PhpGroupWare ist ¨ ahnlich wie Tiki ein PHP basiertes System, das sowohl Groupware als auch CMS Aspekte abdecken kann und in Kapitel 3 primär als Groupware System eingeordnet wurde. Es bietet ein relativ brauchbares CMS Modul, das die Grundfunktionen abdeckt. Weiters gibt es noch dar¨ uber hinausgehende M¨ oglichkeiten, Informationen zur Verf¨ ugung zu stellen. Auf der Seite der eher Groupware orientierten Funktionen werden diverse Möglichkeiten der strukturierten und unstrukturierten Kommunikation sowie auch Unterst¨ utzung f¨ ur Zusammenarbeitsaspekte und Projekte angeboten. Damit fehlt bei den Funktionsbl¨ ocken nur noch die Personalisierung. Teilweise ist auch diese gegeben. Da PhpGroupWare zum Teil aus fast selbstständigen Modulen besteht, ist dieser Aspekt uneinheitlich gelöst. Aus einer gesamthaften Perspektive heraus kann man die Unterst¨ utzung daher nur als sehr eingeschr¨ ankt bezeichnen. Insgesamt deckt PhpGroupWare damit alle der identifizierten Funktionsblöcke in der einen oder anderen Form ab. Bis auf die Projektunterst¨ utzung ist es damit ¨ ahnlich wie XOOPS oder Tiki zu beurteilen. Gleichzeitig gibt es eine wichtige Schw¨ ache in der Personalisierung. Obwohl das System auf einem extra Framework basiert, kann es sich in dieser Hinsicht nicht wesentlich von Tiki absetzen. Damit ergibt sich auch eine ¨ ahnliche Schlussfolgerung. Wenn der vorhandene Funktionsumfang gut zu den mittelfristig geplanten Zielen der KM Initiative passt, sollte man auf jeden Fall eine genaue Analyse im Kontext der entsprechenden Organisation durchf¨ uhren. Zusammenfassung Die Beschreibungen der einzelnen Systeme haben sehr gut die grob vier Kategorien aufgezeigt. Es gibt die beiden auf Python/Zope basierenden Systeme. Weiters wurden zwei wichtige Java basierte Systeme beschrieben. Schließlich gibt es noch die Vielzahl an PHP Systemen. Sowohl die Anzahl als auch die unterschiedliche Funktionalit¨ at rechtfertigen hier eine weitere Aufteilung. Einerseits gibt es die u ¨ berwiegend als CMS gedachten Systeme, die aus Sicht KM nicht einmal“ ACLs zur Verf¨ ugung stellen. Dadurch sind sie f¨ ur mitt” lere bis gr¨ oßere KM Systeme schlecht geeignet und können eher schwerer als andere Vertreter eng integriert werden. Andererseits gibt es die aus KM Sicht besseren“ PHP basierten CMS Systeme. Die folgende Auflistung zeigt diese ” grobe Einstufung: Python/Zope Systeme: Plone, elevateIT Java Systeme: OpenCMS, JBOSS Portal simple“/ reine“ PHP CMS Systeme tw. ohne ACLs: Mambo/Joomla, Con” ” tenido, Typo3, phpWebSite achtigere“ PHP CMS Systeme mit ACLs: PHP-Nuke, Xaraya, XOOPS, Tim¨ ” ki, PhpGroupWare

142


Wichtig ist vor allem f¨ ur die letzte Kategorie, noch vorhandene Bedenken zu ber¨ ucksichtigen: PHP-Nuke und Xaraya finden sich zwar in der Kategorie der m¨ achtigeren“ Systeme, sind aber nicht 100%ig mit den anderen 3 Vertre” tern zu vergleichen, da es bei ihnen prinzipielle Bedenken hinsichtlich Design beziehungsweise Ausgereiftheit gibt. 6.3.2 Hilfestellung f¨ ur die Systemauswahl Nachdem die funktionalen Aspekte ausf¨ uhrlich diskutiert worden sind, ist der nächste Schritt zu u ¨berlegen welche anderen wichtigen Aspekte bei einer Systemauswahl zu ber¨ ucksichtigen sind. Aus einer generellen Sicht wurden entscheidende Punkte schon in Kapitel 4 analysiert. Im Kontext dieses Kapitels geht es jetzt darum darzustellen, was im Kontext der diskutierten CMS Sys¨ teme beachtet werden sollte. Damit lassen sich gewissen Uberschneidungen nicht verhindern, die aber minimal gehalten wurden. Was sind also im Hinblick auf die beschriebenen CMS Systeme wichtige Punkte? Wie schon ausf¨ uhrlich dargelegt wurde, ist es der vielleicht wichtigste Aspekt u ¨berhaupt, eine mittelfristige Perspektive ausgearbeitet zu haben. Als Ergebnis kann man ein CMS System sowohl anhand der unmittelbaren als auch der mittelfristigen Ziele bewerten. Dabei geht es nicht um Details, sondern etwa um die Frage der Zukunftssicherheit einer Lösung oder wie man weitere Module oder Systeme integrieren kann. Weiters ist wie auch schon generell oder bei den Groupware Systemen die Frage der am besten geeigneten Programmiersprache zu klären. Die Vorgehensweise dabei h¨ angt bis zu einem gewissen Grad von der geplanten Umsetzung ab. Wenn m¨ oglichst ein definierter Partner oder Organisationsteil daf¨ ur verantwortlich sein soll, stellt das entsprechend vorhandene Know-how schon eine Vorauswahl dar. Mittelfristige Ziele F¨ ur das kurzfristige Ziel eines guten CMS Systems sind eine ganze Reihe der vorgestellten Systeme gut geeignet. Je nach unmittelbar geplantem Einsatz der einzelnen Funktionen sollte sich relativ leicht feststellen lassen, welches der vorgestellten Systeme in Frage kommt. Wenn man versucht die mittelfristigen Ziele und Entwicklungen zu ber¨ ucksichtigen, gibt es leider keine solch einfachen Antworten. Einerseits weiß man nicht wirklich, was man in weiterer Folge an Funktionen ben¨ otigen wird. Wichtig ist etwa eine Betrachtung der evolutionären ¨ Weiterentwicklung der Organisation. Es k¨ onnte aber auch eine Ubernahme oder eine Neuorientierung des Gesch¨ aftsfeldes stattfinden. F¨ ur solche dras¨ tischen Anderungen wird man aber typischerweise nicht planen wollen (und auch gar nicht k¨ onnen). Andererseits kann man die weitere Entwicklung der einzelnen Systeme nur relativ ungenau vorhersagen. Zusammengefasst geht es


143

um eine Absch¨ atzung von zwei sich st¨ andig verändernden und voneinander unabh¨ angigen Entwicklungen. Woran kann man sich dann aber orientieren? Ein Fixpunkt“ (ver” glichen mit den anderen Variablen) ist der Umfang eines kompletten“ KM ” Systems. Kapitel 2 stellt eine m¨ ogliche und relativ umfassende Variante dar und kann daher als Richtschnur dienen. Je weniger man selbst f¨ ur seine Organisation als mittelfristig wichtig ansieht, desto weniger kann einem allerdings diese Vision helfen. Gleichzeitig zeigt sie zumindest, welche Möglichkeiten man u ¨ berdacht haben sollte. Je unklarer die eigene Stoßrichtung ist, desto eher sollte man auf m¨ oglichst breit eingesetzte Systeme setzen und desto geringer sollten die unmittelbaren Investitionen sein. Dabei darf man aber nicht u urlich auch der sich ergebende Nutzen entsprechend gerin¨ bersehen, dass nat¨ ger ausfallen wird. Man sieht also noch einmal, dass f¨ ur eine möglichst gute Entscheidung kein Weg an einer m¨ oglichst konkreten Definition eines Ziels vorbeif¨ uhrt. Was die Open Source CMS Systeme angeht ist es kaum möglich, eine l¨ angerfristige Prognose abzugeben. Ein Faktum ist aber sehr wichtig: Je mehr Anwender und Entwickler ein System hat, desto größer sind die Chancen auf eine entsprechende Weiterentwicklung. Die Entwickler und Anwender haben selbstverst¨ andlich entsprechendes Kapital“ (bei Open Source häufig ” nicht monet¨ arer Art) investiert und werden in Folge f¨ ur eine Weiterentwicklung sorgen. Die Entwickler- und Anwenderzahl abzuschätzen sollte anhand verschiedener Indizien zumindest grob gelingen. Auf Sourceforge kann man die Anzahl der registrierten Entwickler und Downloads beobachten. Weiters sollte man unbedingt die Mailinglisten und die stattfindende Aktivität ansehen. Wichtig ist auch, einen Eindruck der Anwenderzahl zu bekommen (zum Beispiel u ¨ ber Referenzinstallationen) und eventuell den einen oder anderen zu kontaktieren. Zus¨ atzlich sollte man sicherstellen, dass man nicht eine zu ausgefallene Form der Verwendung des n¨ amlichen Systems plant. So etwas k¨ onnte in weiterer Folge zu Schwierigkeiten f¨ uhren. Nat¨ urlich k¨ onnen einen diese Maßnahmen nicht definitiv absichern. Sie helfen aber einen guten Eindruck u ¨ ber die generelle Zukunft des Systems zu bekommen. Vor allem garantiert“ eine entsprechend große Anwenderschar, ” dass es ausreichend Unterst¨ utzung beziehungsweise potenzielle Kooperationspartner gibt. Weiters stehen die Chancen gut, dass selbst bei einer Einstellung eines Systems einfache M¨ oglichkeiten der Abl¨ ose zur Verf¨ ugung stehen werden (durch Open Source ist das auch ganz ohne Unterst¨ utzung des Herstellers“ ” wesentlich leichter). Programmiersprache Generell wurde der Aspekt der Programmiersprachen schon in Abschnitt 4.3.3 analysiert und diskutiert. Diese Fragestellung ist selbstverständlich auch bei einem Start mit einem CMS System zu beantworten. Hier wiegt sie bis zu

144


einem gewissen Grad besonders schwer, da es u ¨berwiegend PHP Systeme zur Auswahl gibt. Eine der wichtigen Fragestellungen in diesem Zusammenhang ist, wie geplante Entwicklungen und der Betrieb funktionieren können und sollen. Diese Fragestellung wurde dabei in Abschnitt 5.4.2 f¨ ur Groupware Systeme schon diskutiert. Aus Sicht des KM Systems ist es am besten, wenn es keine Einschr¨ ankungen durch diese Aspekte gibt. Gleichzeitig könnten so die Kosten ausufern und den gegebenen Nutzen weit u ¨ bersteigen. Wichtig ist auch, so weit wie m¨ oglich die mittelfristig angedachten Erweiterungen zu ber¨ ucksichtigen. Wenn man alles zusammen hat, sollte man aufgrund einer wahrscheinlichen Entwicklung der Anforderungen und der in Frage kommenden Systeme sowie von notwendigen eigenen Entwicklungen eine gute Entscheidung treffen k¨ onnen. Technische Basis/Integrationsaspekte Je eher man zumindest mittelfristig ein gr¨ oßeres KM System anstrebt, desto wichtiger ist die Frage, wie einfach oder schwierig es ist, eine Kopplung mit anderen Systemen zu erzielen oder neue Funktionen einzubauen. Ein Aspekt, der eher in Kapitel 5 diskutiert wurde, ist dabei, welche weitere Software integriert werden muss oder eingebunden sein sollte. Einerseits muss das schon bei der Frage der Programmiersprache u ¨ berlegt worden sein. Andererseits geht es um die St¨ arken und Schw¨ achen der einzelnen Lösungen in Hinblick auf Integrationsaspekte. Generell sind diese Punkte schon in Kapitel 4 diskutiert worden. Wenn man auf die analysierten CMS Systeme n¨ aher eingeht, dann wird schnell klar, dass solche Aspekte nur teilweise adressiert werden. Die beiden Python/Zope System sind sowieso etwas außen vor. Gleichzeitig kann man hier aber auch auf eine Reihe von M¨ oglichkeiten zu einer Integration verweisen (wie etwa in Abschnitt 4.3.4 beschrieben). Prinzipiell sind die beiden Java Systeme am besten f¨ ur eine Integration ger¨ ustet. Dabei handelt es sich nicht um Pro” dukteigenschaften“ sondern um das Ergebnis der Entwicklungen von Java und verf¨ ugbaren Integrationstechnologien. Bei PHP gibt es wie bei Python nat¨ urlich eine Reihe von M¨ oglichkeiten f¨ ur Schnittstellen. Diese sind dabei weniger zahlreich und zum Teil eingeschr¨ ankter als mit Java. Allerdings gibt es gerade im PHP Umfeld eine unglaubliche Vielzahl an vorhandenen Modulen und Systemen f¨ ur fast alle denkbaren Einsatzgebiete. Typischerweise sind diese eher f¨ ur kleinere Installationen geeignet und das sollte man im Hinterkopf behalten. Insgesamt sind also die generellen Fragen der Offenheit der Systeme und m¨ oglicher Schnittstellen besonders wichtig. Zusätzlich hat die Wahl der Programmiersprache(n) Konsequenzen im Hinblick auf mögliche Integrationen und/oder Erweiterungen. Daher sollte man diesen Aspekt entsprechend uhrlich analysieren und bewerten. ausf¨

6.4 Umsetzung

145

Zusammenfassung Aufgrund der enormen Unterschiede von Organisationen, die eine Wahl hinsichtlich eines CMS Systems im Kontext einer KM Initiative zu treffen haben, kann man leider nur relativ allgemeine Hinweise geben. Wichtig ist vor allem, sich u ¨ ber die mittelfristige Zukunft Gedanken zu machen. Einerseits u ¨ ber die der eigenen Organisation und andererseits die der potenziell in Frage kommenden Systeme. Mit dem Ergebnis kann man dann die Fragen der am besten geeigneten Programmiersprache und der Möglichkeiten, (Sub-)Systeme ¨ oder Module zu integrieren, behandeln. Alle Uberlegungen zusammengenommen sollten es einem erm¨ oglichen, zu einer guten und vor allem mittelfristig haltbaren Entscheidung zu gelangen. Um die beschriebenen komplizierten Zusammenh¨ ange noch klarer zu machen, bietet Abbildung 6.1 eine entsprechende Illustration.

6.4 Umsetzung Nachdem man sich f¨ ur eines der analysierten CMS Systeme entschieden hat, stellt sich die Frage der Umsetzung. W¨ ahrend bei den Groupware Systemen mehrere Varianten des Einsatzes als wahrscheinlich diskutiert wurden, konzentriert sich dieses Kapitel auf die Frage der Einf¨ uhrung eines KM Systems. Dieser Unterschied ist vor allem aus einer pragmatischen Sichtweise heraus gerechtfertigt. Es gibt viele Organisationen, die schon eine Groupware im Einsatz haben, die von praktisch allen Mitgliedern genutzt wird. CMS Systeme werden dagegen insgesamt seltener beziehungsweise nur von einer kleinen Anzahl von Personen genutzt. Daher ist die Einf¨ uhrung oder Ablöse eines CMS Systems beziehungsweise eventuell der Parallelbetrieb wesentlich wahrscheinlicher als die Notwendigkeit einer Integration. 6.4.1 Organisatorische Punkte Eine wichtige Voraussetzung f¨ ur die sinnvolle Verwendung eines CMS Systems ist nat¨ urlich eine entsprechende Vertrautheit der Mitglieder einer Organisation mit dem Arbeiten am Computer. Sollte dies nicht gegeben sein, so kann nur empfohlen werden, parallel zu den Analysen und Arbeiten an der Einf¨ uhrung entsprechende Schulungen durchzuf¨ uhren. Man sollte bei einer fachlichen Erhebung m¨ oglichst auch die Vertrautheit mit Computern ber¨ ucksichtigen. Damit ist nicht gemeint, Personen ohne diese Vertrautheit nicht einzubinden. Allerdings wird man hier besonders sorgfältig beim Einarbeiten von Informationen sein m¨ ussen. Damit ist einer der wichtigsten Aspekte auch schon kurz angerissen: Die Einbindung von Schl¨ usselpersonen in die Analyse, Evaluierung und Gestaltung eines zuk¨ unftigen Systems. Dabei geht es primär um zwei Punkte. Einerseits um ein Nutzbarmachen und Einbinden des vorhandenen Wissens

1. Start

mögliche Zukunft der Organisation


unmittelbare Ziele

2. mögliche Open Source Systeme

Abb. 6.1. Entscheidungsbaum“ f¨ ur ein CMS System ”

Programmiersprachen

vorhandenes Knowhow

Entwicklung & Betrieb

zukünftig nötige Funktionen

unmittelbar nötige Funktionen

Integrationsfähigkeit

Kosten

Zukunft der Systeme

3. Systemauswahl

146 6 Alternativ Start mit einem Content Management System

6.4 Umsetzung

147

u aufe und der damit verbundenen Notwendigkeiten. An¨ ber die Arbeitsabl¨ dererseits den Umstieg und die Akzeptanz des neuen Systems zu steigern, indem es von Start weg eine Reihe von Anwendern gibt, die wichtige Hintergr¨ unde und das neue System selbst kennen. Dabei sollte man die mit so einem Vorgehen verbundenen Schwierigkeiten nicht unterschätzen. Aus einer simplifizierten Sicht heraus ist das Ganze unn¨ otig und nur ein Kostenfaktor. Auch die ausgew¨ ahlten Personen selbst sehen vielleicht den Sinn des Ganzen nicht ein und k¨ onnten die Aktivit¨ aten als reine Zusatzbelastung wahrnehmen. Daher ist es unbedingt notwendig, die Wichtigkeit und den Sinn dieses Vorgehens zu kommunizieren und von der Spitze der Organisation auch entsprechende Unterst¨ utzung zu bekommen. Kurz gesagt gibt es aus organisatorischer Sicht drei extrem wichtige Punkte, die man ber¨ ucksichtigen sollte: 1. Das Sicherstellen einer ausreichenden Vertrautheit mit Computern als unverzichtbare Basis f¨ ur die Einf¨ uhrung eines CMS Systems. 2. Die Einbeziehung von Personen, die mit den aktuellen Arbeitsabläufen gut vertraut sind. 3. Die durchgehende Einbindung von zuk¨ unftigen Anwendern in die Ausgestaltung des Systems und der zuk¨ unftigen Arbeitsabläufe. Diese Aspekte ben¨ otigen dabei eine entsprechende Unterst¨ utzung durch die Spitze der Organisation. 6.4.2 Technische Punkte Die Einf¨ uhrung eines CMS Systems ist aus einer technischen Perspektive kein besonderes Problem. Es gibt selbstverst¨ andlich sensitive und problematische Themen wie das Berechtigungssystem oder ein Zugriff von außerhalb des physischen Netzwerkes der Organisation. Diese sind aber kein spezifisches Problem eines KM Systems und außerdem gibt es mehr oder weniger ausgefeilte Lösungen daf¨ ur. Die wichtigste Herausforderung ist eigentlich die Zusammenarbeit mit den fachlich kompetenten Personen und das Implementieren einer möglichst einfachen aber gleichzeitig m¨ achtigen KM L¨ osung f¨ ur die Organisation. Ein wichtiger Aspekt ist dabei das m¨ oglichst schnelle Kennenlernen der ausgewählten L¨ osung, um entsprechend flexibel und kompetent das neue System erstellen zu k¨ onnen. Generell wichtige Punkte zur Datenspeicherung oder Verf¨ ugbarkeit sind dabei schon in Kapitel 4 diskutiert worden. Dabei sollte man unbedingt den notwendigen Grad an Service festlegen und ein entsprechendes Ergebnis reaßig testen. Dieser Aspekt ist zwar in keinster Weise spezifisch f¨ ur ein gelm¨ KM System aber einer der am ehesten vernachlässigten. Daher auch hier der Hinweis, dass ein Backup unbedingt regelm¨ aßig getestet und verifiziert werden

148


muss. Dasselbe gilt f¨ ur alle anderen Komponenten und etwa auch ein potenziell ausfallssicheres System. Zum Teil sind das schon Fragen des Betriebs, der aber auf jeden Fall in seiner Gesamtheit ber¨ ucksichtigt werden muss! 6.4.3 Zusammenfassung Nach der Entscheidung f¨ ur ein CMS System ist es von entscheidender Wichtigkeit, auch die Umsetzung entsprechend professionell und gut durchzuf¨ uhren. Die reine Einf¨ uhrung eines neuen Systems bringt nur Kosten und keinen Nutzen. Dieses Faktum sollte man sich immer vor Augen halten. Daher auch die enorme Wichtigkeit der organisatorischen Aspekte. Vor allem m¨ ussen alle zuk¨ unftigen Anwender ausreichend mit einem Computer vertraut sein. Weiters geh¨ oren fachlich versierte Personen in den gesamten Einf¨ uhrungsprozess beginnend mit der Analyse einbezogen. Einerseits kann man nur so optimale L¨ osungen schaffen und andererseits ist dies der beste Weg die Einf¨ uhrung m¨ oglichst effizient zu gestalten (da Erfahrungen und Hintegrundwissen zum Teil bei den Anwendern vorhanden sind). Dar¨ uber hinaus m¨ ussen die Unterst¨ utzung und eine entsprechende Mitarbeit des gesamten Managements gegeben sein. Die technischen Aspekte sind dagegen eher genereller Natur. Deshalb ist es nicht notwendig, zu sehr in Details wie das Garantieren eines gewissen Quality of Service“ zu gehen. Wichtig ist vor allem, dass die Technik bei dem ” Design und der Implementierung der L¨ osung mit den fachlich kompetenten Personen zusammenarbeiten kann (und das auch tut).

7 Einbinden Groupware oder CMS bzw. Erweitern um DMS

Abgesehen von eher klein angelegten KM Initiativen stellt sich nach dem unmittelbaren Start mit einem KM System die Frage nach dem weiteren Ausbau. Dabei hat man als Basis entweder ein Groupware oder ein CMS System. Wichtig ist es, an die Vision eines KM Systems im Generellen (beschrieben in Kapitel 2) zu denken. Noch wichtiger ist dann nat¨ urlich, die mittel- bis langfristigen Ziele der eigenen KM Initiative analysiert und festgelegt zu haben. Auf der sich ergebenden Strategie sollte man als Fundament aufbauen können. Unmittelbar stellt sich nat¨ urlich die Frage einer Erweiterung einer Groupware um eine CMS L¨ osung beziehungsweise eines CMS Systems um Groupware Aspekte. Dar¨ uber hinaus besch¨ aftigt sich dieses Kapitel mit der Frage der Erweiterung um ein Document Management System (DMS). Es wird dabei auch untersucht, warum sich gerade DMS Funktionen besonders gut f¨ ur einen weiteren Ausbau eignen. In diesem Zusammenhang ist eines der wichtigsten Argumente, dass entsprechende Funktionen oft besonders abgehen und einen strukturierten Umgang mit Informationen unterst¨ utzen. Praktisch betrachtet ist es dabei nicht so einfach, eine klare Unterscheidung zu treffen. Wie man schon mehrfach gesehen hat, sind Systeme die ausschließlich Aspekte einer Kategorie adressieren eher die Ausnahme. Zusätzlich gibt es noch Produkte, die kaum einordenbar sind. Die verschiedenen Systeme sind auch bis jetzt schon unter diesem Aspekt diskutiert worden. Gerade in diesem Kapitel wird noch entsprechend darauf eingegangen werden, da solche Systeme nat¨ urlich eine Erweiterung beziehungsweise Integration unnötig machen.

7.1 Erweitern um ein Content Management System Sofern man mit einem Groupware System begonnen hat, ist die am ehesten sinnvolle Erweiterung ein CMS System (nat¨ urlich mit entsprechend kompletter Ausstattung/Zusatzfunktionen). Mit dieser Aussage ist gemeint, dass es

150


f¨ ur eine Mehrheit an Organisationen Sinn machen wird. F¨ ur eine individuelle Firma kann das ganz anders aussehen. In Abschnitt 6.1.3 wurde diskutiert, warum man mit einem CMS System beginnen sollte. Leicht angepasst sind das auch genau die Argumente f¨ ur eine Erweiterung des KM Systems um ein CMS System. Die nächste Aufgabe ist festzulegen, welche Anwendungsgebiete das eigene KM System unmittelbar und mittelfristig abdecken soll. Hilfreich ist hier die grobe Unterteilung in Abschnitt 6.1 sowie die detaillierte Diskussion in Abschnitt 6.2. Auf diesen Informationen aufbauend sollte es relativ“ einfach sein, die eigenen Bed¨ urf” nisse zu identifizieren. Der Schl¨ ussel f¨ ur eine gute Entscheidung ist hier, die Einbeziehung von Personen mit Know-how in solchen Punkten. Damit kann man Erfahrungen von anderen KM Systemen einbeziehen und so auch nicht offensichtliche Nutzungsm¨ oglichkeiten von Funktionen erkunden. Dazu muss aber immer auch klar sein, dass so eine Funktionalität sinnvoll und wichtig f¨ ur die einzelne Organisation sein sollte. Eine Entscheidung f¨ ur ein konkretes System kann man nat¨ urlich nicht so wie in Kapitel 6 treffen. Schließlich muss man das vorhandene Groupware System ber¨ ucksichtigen und die Frage Integration oder Nebeneinander“ beant” worten. Diese Fragestellung illustriert auch die Wichtigkeit der prinzipiellen ¨ Uberlegungen in Kapitel 4. 7.1.1 Integration oder Nebeneinander Generell ist ein ideales KM System ein Teil eines integrierten Systems, das alle IT Aspekte einer Organisation abdeckt. Zumindest aber sollte es selbst ein integriertes System sein. Die entsprechende Argumentation in Kapitel 2 zeigt wichtige Gr¨ unde daf¨ ur auf. Gleichzeitig ist es oft sehr schwierig, so eine enge Integration zu erreichen. Selbst wenn man an sehr teure kommerzielle L¨ osungen denkt, muss man sich um eine Integration von Individualsoftware selbst k¨ ummern. Weiters werden auch nur ausgew¨ ahlte Systeme mit einer vorhandenen Einbindung unterst¨ utzt. Kurz gesagt stellt eine integrierte Gesamtlösung einen unwahrscheinlichen Gl¨ ucksfall dar, wenn man nicht bereit ist, sehr große Summen f¨ ur ein Integrationsprojekt in die Hand zu nehmen. Im Bereich Open Source ist die Situation ein wenig anders aber prinzipiell durchaus ¨ ahnlich. Einerseits f¨ allt zumindest die häufig sehr teure kommerzielle L¨ osung weg. Andererseits bleibt der meist sehr hohe Aufwand f¨ ur eine enge Integration verschiedenster Systeme bestehen. Damit stellt sich die Frage, wie man am besten mit diesem Problem umgeht. ur eine KM Initiative alleine“ wird man kaum seine gesamte EDV InfraF¨ ” struktur umkrempeln k¨ onnen und wollen. Das wäre vor allem denkbar, wenn noch andere Aspekte dazukommen. Sehr interessant könnte ein komplettes Umstellungsprojekt f¨ ur eine ganze Organisation sein, um mit modernen und integrierten Systemen m¨ oglichst effizient und wissensintensiv“ arbeiten zu ”

7.1 Erweitern um ein Content Management System

151

können. Gleichzeitig sollte man die Risiken so eines Unterfangens nicht untersch¨ atzen. Insgesamt ist so eine Umstellung also weder realistisch noch zu empfehlen. Der einzige Sonderfall ist eine Organisation, die noch relativ wenige IT Systeme im Einsatz hat. Hier kann man von Beginn weg auf eine integrierte Gesamtl¨ osung setzen. Das sollte man auch tun, um die g¨ unstige (und seltene) Gelegenheit zu n¨ utzen. Gut geplant und durchgef¨ uhrt ist hier eine deutliche und nachhaltige Steigerung der Produktivität zu erwarten. Wei¨ ters braucht man die restlichen Uberlegungen zu diesem Thema nicht weiter beachten und sollte sich auf eine m¨ oglichst fundierte und gute Entscheidung f¨ ur das Basissystem konzentrieren. Die prinzipielle Ausgangsbasis f¨ ur die Frage Integration oder Nebenein” ander“ ist ein existierendes Groupwaresystem. Der Sonderfall eines vorhandenen Groupware Systems und der alternative Start mit einem CMS System wurde schon kurz in Abschnitt 6.1.3 angesprochen. Praktisch ergeben sich zwei grunds¨ atzliche Möglichkeiten: Das vorhandene Groupware System eignet sich als Integrationsplattform beziehungsweise l¨ asst sich leicht integrieren oder eine Integration ist nur schwer m¨ oglich. Entsprechend den Diskussionen und Argumentationen in Kapitel 5 sollte eine neu eingef¨ uhrte Groupware Möglichkeiten f¨ ur eine Integration bieten. Bei einer vorhandenen Lösung kann es da schon eher Schwierigkeiten geben (muss aber keineswegs so sein). Aber auch im Fall einer neuen Groupware ist eine Integration nur dann gewährleistet“, wenn ” man die Analyse im Hinblick auf ein potenzielles CMS System gemacht hat. Kurz gesagt stellt sich die Frage, ob man ein bestimmtes Groupware System mit einem bestimmten CMS System sinnvoll und leicht integrieren kann. Insgesamt stellt sich damit die Frage nach der Kosten-/Nutzenrechnung einer Integration. Aus einer theoretischen“ Perspektive heraus ist es einfach ” eine Notwendigkeit, ohne großen Aufwand wichtige Informationen zu finden und in einem gesamthaften System damit arbeiten zu können. Sollte dies technisch nicht m¨ oglich oder zu teuer sein, kann man u ¨ ber organisatorische Maßnahmen nachdenken. Damit ist gemeint, dass bei einer klaren Definition wo was zu tun ist, ein Wiederfinden von Informationen relativ einfach sein m¨ usste. Nat¨ urlich steigen aber der Aufwand und das Risiko, vorhandene Informationen nicht zu finden. Wichtig ist dabei vor allem, die aktuellen und geplanten Arbeitsabl¨ aufe zu kennen. Mit diesem Wissen kann man beurteilen, ob ein Nebeneinander von CMS und Groupware System mehr oder weniger Probleme bringen sollte. Außerdem erm¨ oglicht dieser Ansatz eine Entscheidung, welche Zwischenvarianten angemessen sind. Dabei geht es um eine partielle Integration von ¨ wichtigen Daten und Funktionen. Hinter dieser Uberlegung steht auch die Tatsache, dass es fast immer M¨ oglichkeiten gibt, zumindest manche Daten und Funktionen einzubinden. Beispielsweise d¨ urfte es fast immer möglich sein E-Mail Daten und Funktionalit¨ at eines Groupware Systems in ein CMS System zu integrieren. Dabei kann man im Extremfall einen Proxy-Server f¨ ur die E-Mail Protokolle installieren u ¨ber den die Groupware Clients oder der E-Mail Server der Groupware L¨ osung kommunizieren.

152


Es zeigt sich damit, dass es neben der Variante eines reinen Nebeneinander und einer Vollintegration noch eine Reihe von Abstufungen gibt. Typischerweise wird man auch kaum eine 100%-ige Integration erreichen können, wenn es sich um verschiedene Systeme handelt. Gleichzeitig bleibt die Frage, ob ein reines Nebeneinander eine sinnvolle Option ist. Dazu kann man eigentlich nur Nein sagen. Es wird nat¨ urlich immer Sonderf¨ alle und Ausnahmen geben, aber generell macht ein Nebeneinander eines Groupware und eines CMS Systems keinen Sinn. Im Kontext dieses Buches steht eine breite Nutzung beider Systeme im Vordergrund. Hierbei ist eine minimale Integration einfach wichtig. Auch wenn es nur eine gemeinsame Suchmaske ist, die Ergebnisse aus beiden Systemen liefert, so geht es darum, eine gemeinsame Sicht auf die vorhandenen Informationen sicherzustellen und eine einfache Verwendung zu ermöglichen. An der Bedeutung einer u ¨bergreifenden Suche kann man auch schon einen weiteren wichtigen Punkt ablesen. Es geht darum, eine möglichst umfassende Suchfunktion zu haben. Diese sollte alle potenziell relevanten Informationen finden und zur Verf¨ ugung stellen k¨ onnen. Wenn man diesen Gedanken weiterspinnt, dann gibt es folgende sinnvollen Möglichkeiten einer Integration: • • •

¨ Ubergreifende Suche Unterst¨ utzen aller wichtigen Arbeitsabl¨ aufe ohne ersichtlichen Systemwechsel Volle Integration

Besser“ als die u urlich die Unterst¨ utzung al¨bergreifende Suche ist nat¨ ” ler wichtigen Arbeitsabl¨ aufe in einer einheitlichen Oberfl¨ ache. Die Art der Integration ist hierbei offen gelassen und kann recht unterschiedlich sein. Gleichzeitig sind bei dieser Variante wichtige Funktionen noch separat zu erreichen. Um zu veranschaulichen, wie man sich diese Idee konkret vorstellen kann, werden wieder einmal E-Mails als Beispiel genommen. Ein Arbeitsablauf k¨ onnte es erfordern, E-Mails zu senden und/oder zu empfangen, sich aber sonst prim¨ ar in einem CMS basierten“ (sprich: ein Modul des CMS Systems) ” Wiki abspielen. Hier ist mit der Integration eines web-basierten Zugriffs zum Mailingsystem der Organisation eine komplette Abbildung dieses Arbeitsablaufs in einem System m¨ oglich. Gleichzeitig wird der echte“ E-Mail Client ” (der Groupware) eine wesentlich gr¨ oßere Funktionsvielfalt aufweisen. Wenn man sich eine volle Integration u ¨ berlegt, dann lässt sich das ebenfalls leicht anhand des schon beschriebenen Beispiels illustrieren. Bei einer vollen Integration muss die komplette Funktionalität des Groupware Clients und des CMS Systems gemeinsam zur Verf¨ ugung stehen. Dabei ist es unerheblich, wie die Oberfl¨ ache dann aussieht (sprich welches System die Basis ache ist). Aus rein funktionaler Sicht hat auch die f¨ ur die gemeinsame Oberfl¨ Frage, wie sich der Server dieses Systems darstellt, keine Relevanz. Aus einer technischen Perspektive sind diese Fragen nat¨ urlich von enormer Bedeutung und m¨ ussen m¨ oglichst umfassend analysiert werden. Bei der Frage wie weit eine individuelle KM Initiative gehen sollte, kann man nat¨ urlich nur Anhaltspunkte geben. Klar ist, dass eine volle Inte-


153

gration von zwei unterschiedlichen Systemen die höchsten Kosten verursacht. Gleichzeitig wird man den gr¨ oßten Nutzen haben. Die Zwischenvariante“ ei” ner Unterst¨ utzung der wichtigsten Arbeitsabl¨ aufe kann wesentlich billiger sein und genau dann ist sie auch empfehlenswert. Weiters sollte man diesen Weg auch beschreiten, wenn die KM Initiative eher kleiner angelegt ist. In beiden Fällen ist nat¨ urlich das entscheidende Kriterium, dass sich die Kosten voraussichtlich nicht rechtfertigen lassen. Es handelt sich dabei um eine pragmatische L¨ osung und der Nutzen ist sicher geringer als mit der vollen Integration. Wie die Diskussion zeigt, hat man mit unterschiedlichen Systemen typischerweise ein Kostenproblem. Eine volle Integration ist wichtig und hilfreich aber vielleicht zu teuer. Damit ergibt sich an dieser Stelle auch noch einmal die Frage, ob nicht eine integrierte Gesamtlösung besser ist. Dabei sollten ¨ die Uberlegungen ganz pragmatisch sein. Die eine Seite ist, wie viel mehr Nutzen man durch die volle Integration hat und wie ein weiterer Ausbau erfolgen kann. Die andere Seite sind m¨ ogliche Zusatzfunktionen der einzelnen idea” len“ Systeme, die aber nur mit Zusatzaufwand integriert werden können. Bei dieser Frage sollte man unmittelbare und zuk¨ unftige Aspekte in etwa gleich gewichten. Wobei f¨ ur zu erwartende Anforderungen auch die Wahrscheinlichkeit des Eintreffens ber¨ ucksichtigt werden muss. Je klarer und wichtiger eine Anforderung ist (unabh¨ angig davon wann das der Fall ist beziehungsweise sein wird), desto eher muss sie unmittelbar ber¨ ucksichtigt werden. Zusammenfassung Die Diskussion der Frage, wie man ein vorhandenes Groupware System am besten um ein CMS System erweitert, zeigt grob drei Varianten auf. Das Einfachste ist nat¨ urlich ein Nebeneinander der Systeme. Gleichzeitig ist diese Lösung aus KM Sicht abzulehnen. Der wichtigste Hintergrund sind dabei Arbeitsabl¨ aufe, die die Verwendung beider Systeme betreffen. Bei einer relativ umfassenden Nutzung der Systeme ist dann so etwas kaum mehr zu verhindern. Bei nur minimaler Nutzung eines der beiden Systeme sollte man eher die Frage stellen, ob es wirklich Teil des KM Systems sein muss. Damit bleibt die Frage der unterschiedlichen Abstufungen einer Integration. In diesem Zusammenhang ist eine u ¨ bergreifende Suche der einfachste Fall (auch wenn technisch vielleicht etwas anderes einfacher sein mag). Dabei geht es sozusagen um die Mindestanforderung und die Möglichkeit, von einer gemeinsamen Oberfl¨ ache aus alle Bereiche des KM Systems im Zugriff zu haben. Die n¨ achste Stufe ist die Integration f¨ ur alle wichtigen Arbeitsur speabl¨ aufe (entweder wegen vieler Nutzer oder wegen der Notwendigkeit f¨ zielle Prozesse). Hier gibt es unterschiedliche Möglichkeiten und verschiedene urlich die volle Integration Kompromisse sind vorstellbar. Anzustreben ist nat¨ beider Systeme. Der Nutzen wird dabei sicherlich am größten sein. Gleichzeitig kann nur eine Abw¨ agung der Kosten versus dem Nutzen eine Antwort f¨ ur eine konkrete Situation liefern.

154


Schlussendlich muss man auch noch an die vorhandenen integrierten Module denken. Man sollte also noch eine Abw¨ agung machen, ob die möglicherweise vorhandenen Zusatzfunktionen von Einzellösungen die Kosten (insbesondere einer vollen) und die Probleme einer teilweisen Integration aufwiegen. Bei dieser Abw¨ agung muss man nat¨ urlich u ¨ berlegen, wie wichtig und wie wahrscheinlich“ (f¨ ur die Zukunft) eine Anforderung ist. F¨ ur einen besseren ”¨ Uberblick werden diese Zusammenh¨ ange in Abbildung 7.1 dargestellt. 7.1.2 Entscheidung(skriterien) F¨ ur die Frage welches CMS System am besten zum geplanten KM System passt, geht es zuerst um die Art der Integration. F¨ ur den Fall eines Nebeneinander braucht man sich hier weiter keine Gedanken zu machen. Daher kann man sich im Großen und Ganzen an Abschnitt 6.3 halten. Der primäre ¨ Unterschied in der Uberlegung ist die Ber¨ ucksichtigung der Funktionalitäten des Groupware Systems. Man wird gewissen Anforderungen mit der Groupware und andere mit dem CMS System abdecken wollen. Nachdem man diese ¨ Uberlegungen angestellt hat, ist der Rest der Fragen wie f¨ ur ein einzelnes CMS System zu kl¨ aren. Schwieriger wird es bei einer Integration. Ganz wichtig ist dabei eine m¨ oglichst komplette Vorstellung von den vorhandenen Schnittstellen und Integrationsm¨ oglichkeiten der vorhandenen Groupware zu haben beziehungsweise zu schaffen. Darauf aufbauend kann man die vorgestellten CMS Systeme durchgehen. Ziel der Analyse sollte eine grobe Vorstellung davon sein, welche Systeme man wieweit integrieren kann. Weiters sollte auch klar sein, welche Zwischenschritte machbar sind. F¨ ur alle diese Varianten braucht man noch eine grobe Kostensch¨ atzung. Man sollte nach der Analyse f¨ ur jedes CMS System wissen, mit welchen Kosten welche Integrationstiefe erreicht werden kann. Weiters benötigt man noch eine Einsch¨ atzung, wie gut die geforderten Funktionen durch ein CMS System zur Verf¨ ugung gestellt werden. Diese Fakten zusammengenommen sollten meistens schon eine Entscheidung ergeben oder zumindest das Feld an potenziellen Systemen stark schrumpfen lassen. In diesem Zusammenhang muss noch kurz auf die Forderung nach Kostensch¨ atzungen eingegangen werden. So etwas kann f¨ ur sich schon relativ teuer werden und daher sollte man sich an eine einfache und effiziente Vorgehensweise halten: Technisch versierte Personen beurteilen zuerst grob die Machbarkeit einer gewissen Integrationsstufe f¨ ur ein gewisses System. Soweit es nur mit hoher Komplexit¨ at machbar ist, scheidet diese Möglichkeit aus. F¨ ur die weitere Analyse versucht man grobe Annahmen zu treffen (in der Form: ist billig, ist mittel-teuer, ist teuer). Damit kann man sicher weitere Systeme ausscheiden. Dar¨ uber hinaus sollte man auch noch die anderen schon diskutierten Punkte wie vorhandenes Know-how von Mitgliedern der Organisation und wichtigen Partnern ber¨ ucksichtigen. Kurz gesagt wird man eine detaillierte Kostensch¨ atzung wenn u ur sehr wenige Kombinationen ¨berhaupt dann nur f¨

moderate Kosten

keine Schulungen / etc. nötig

weiterhin „Brüche“ vorhanden nennenswerte Kosten mögliche Verwirrung der Nutzer

„Brüche“ bei „Systemwechseln“

aus KM Sicht abzulehnen

weniger nachhaltige Verbesserung

Nachteile:

gemeinsame Sicht vorhanden

schnelle Implementierung

Nachteile:

wichtige Abläufe integriert

Vorteile:

Teilweise Integration

geringe Kosten

Vorteile:

Nebeneinander der Systeme

Mög lich keiten der Einbindung

nötig

Schulungen für alle Funktionen

hohe Kosten

Nachteile:

Alle Funktionen verknüpft

Basis für umfassendes System

keine „Brüche“ zw. Systemen

Vorteile:

Volle Integration

7.1 Erweitern um ein Content Management System 155

Abb. 7.1. Erweiterung um ein CMS System: Nebeneinander oder integrieren?

156


durchf¨ uhren. Schließlich ist eines der Ziele, die der Einsatz von Open Source erreichen soll, eine Kostenersparnis. Damit stellt sich die Frage nach den Bewertungskriterien. Ganz wichtig sind einmal die unmittelbaren Vorteile durch die Einbindung des CMS Systems. Fast gleichwertig ist der Aspekt, eine möglichst umfangreiche Integration zu erreichen. Weiters sollte man großen Wert auf Offenheit und Erweiterbarkeit legen. Der letzte Punkt bezieht sich dabei einerseits auf andere Module der Open Source Community und andererseits auf die Möglichkeit von individuellen Entwicklungen. Das zuletzt noch fehlende Element ist nat¨ urlich der Preis. Wie viel kostet die Einf¨ uhrung und die Integration des CMS Systems und wie schnell ist sie machbar. Die Abwägung dieser zuletzt genannten Aspekte sollte unter Ber¨ ucksichtigung der mittelfristigen Ziele der KM Initiative geschehen. Diese Zusammenh¨ ange veranschaulicht Grafik 7.2. Eine auf die potenziellen Anwendungsfelder abgestimmte Diskussion der in Kapitel 3 pr¨ asentierten Systeme leistet schon Abschnitt 6.3. Wichtig ist dabei, dass f¨ ur eine Integration von den vier Gruppen von Systemen alle bis auf die simpleren“ CMS Systeme in Frage kommen. Wie u ¨blich ist diese ” Aussage nicht als Gesetz“ zu werten sondern als eine Richtschnur und ein ” Hinweis wie man die Analyse beschleunigen kann. Damit hat man die Python/Zope basierten Systeme, die Java basierten Vertreter und m¨ achtigere“ PHP basierte Produkte. Wie schon mehrfach dis” kutiert ist eine m¨ oglichst einheitliche KM L¨ osung zu bevorzugen. Daher sollte man insbesondere die CMS Systeme n¨ aher betrachten, die in derselben Programmiersprache und mit derselben Technologie umgesetzt sind wie die Groupware (soweit es so etwas gibt). Vor allem f¨ ur eine volle Integration macht eine m¨ oglichst ¨ ahnliche Technologiebasis vieles einfacher. Gleichzeitig sollte man aber auch nicht vergessen, eine Art Portal (oder auch ein richtiges“) als ” Integrationsergebnis zu betrachten. Wenn man diese Variante anpeilt, kann ein Groupware System mit sehr guten Schnittstellen möglicherweise relativ billig und einfach integriert werden, auch wenn eine andere Technologie verwendet wird. Zusammengenommen sollten die diskutierten Aspekte eine fundierte Entscheidung erm¨ oglichen. Einerseits werden aktuelle und zuk¨ unftige Anforderungen ber¨ ucksichtigt. Andererseits wird das Ziel einer möglichst engen Integration verfolgt. Dabei werden technologische und kostenrelevante Aspekte ¨ ucksichtigt. Soweit man diese Uberlegungen fundiert gemacht hat, steht ber¨ einer erfolgreichen Erweiterung des KM Systems nichts mehr im Weg. 7.1.3 Umsetzung Die bisherigen Abschnitte haben sich mit der Frage beschäftigt, wie man eine Groupware als Kern eines KM Systems um ein CMS System erweitern kann. Dabei wurde zuerst generell diskutiert, wie man dabei vorgehen sollte. Danach ging es um die Frage, wie man sich f¨ ur ein bestimmtes System und eine be-


157


unmittelbare Vorteile durch CMS Integration?

Bewertungskriterien

möglichst möglichst umfangreiche umfangreiche Integration? Integration?

Ze it

individuelle individuelle Entwicklung Entwicklung

Kosten

Offenheit & Erweiterbarkeit? Open Open Source Source Module Module

Ergebnis

Abb. 7.2. Darstellung der Bewertungskriterien bei Erweiterung um ein CMS System

stimmte Integrationstiefe“ entscheidet. Damit stellt sich hauptsächlich noch ” die Frage, wie man die getroffene Entscheidung umsetzen kann. Was das CMS System an sich betrifft, werden diese Fragen in Abschnitt 6.4 ausf¨ uhrlich behandelt. Damit ist vor allem der Aspekt der Integration und der Ver¨ anderung“ des Groupware Systems beziehungsweise der Anpassung von ” Arbeitsprozessen extra zu diskutieren. Hier gibt es wieder vor allem organisatorische und technische Aspekte. Die technischen Punkte sind dabei sicherlich

158


von enormer Wichtigkeit. Aus Sicht KM sollte man aber noch mehr Gewicht auf die organisatorischen Aspekte legen. Was die reine“ Technik betrifft, ist die Integration eines CMS mit einem ” Groupware System keine theoretische Angelegenheit sondern schon praktisch erprobt. Daher steht die prinzipielle Machbarkeit außer Frage und es gibt eine Reihe von M¨ oglichkeiten sie durchzuf¨ uhren. Gleichzeitig wird ein neues Sys¨ tem eingef¨ uhrt und damit ist der Ubergang weniger problematisch, als er es bei einer Abl¨ ose w¨ are. Als Ziel sollte man aber trotzdem eine einfache und stabile Architektur anpeilen. Je mehr Systeme zusammenwirken desto schwieriger wird die Fehlersuche und desto wahrscheinlicher ist ein (Teil-)Ausfall. Klarerweise sinkt durch eine potenziell geringere Verf¨ ugbarkeit des Systems der Nutzen. Auch hier sieht man wieder, dass es nicht nur um die Einf¨ uhrung eines Systems, sondern sehr stark auch um den Betrieb danach geht. Organisatorisch sieht die Sache wesentlich dramatischer aus. Eine ganz konkrete Anleitung kann und will dieses Buch zwar nicht leisten, Anhaltspunkte und Anregungen werden aber sehr wohl geboten. Wichtig ist sich vor Augen zu halten, dass die aktuellen Arbeitsabläufe durch die Einf¨ uhrung eines CMS Systems in zweierlei Hinsicht ver¨ andert werden. Einerseits durch die neuen Funktionen und andererseits durch das Ergebnis der Integration. Man muss sich daher neue Prozesse u ucksichtigen. ¨ berlegen, die beide Faktoren ber¨ Wie schon fr¨ uher vorgeschlagen sollte man dabei unbedingt einen oder mehrere unmittelbar Betroffene pro Prozess einbeziehen. Weiters muss man auch unbedingt nach Einf¨ uhrung noch einmal zusammen mit den Betroffenen an der Optimierung des Systems und der Prozesse arbeiten. Auf keinen Fall darf man die neuen Abl¨ aufe von oben oder gar von extern (zum Beispiel durch einen Berater) vorgeben oder vorgeben lassen.

7.2 Erweitern um ein Groupware System Nach der Diskussion u ¨ ber die Erweiterung eines Groupware um ein CMS System fehlt jetzt noch die Analyse der umgekehrten Reihenfolge. Diese Fragestellung ist nat¨ urlich sehr a ¨hnlich. Gleichzeitig gibt es aber auch wichtige Unterschiede. Auf diesen liegt auch der Fokus des Textes. Wie schon mehrfach betont ist der erste Schritt festzustellen, ob und wie eine Groupware der KM Initiative helfen kann. Ohne einer entsprechenden Analyse vorgreifen zu wollen, kann man typischerweise davon ausgehen (und sollte ein gegenteiliges Ergebnis gut durch¨ uberlegt haben), dass es eine ganze Reihe von Punkten gibt. Damit ist die Frage der wichtigen Funktionalitäten und der Integrationsm¨ oglichkeiten entscheidend f¨ ur die Auswahl eines Systems. Wenn man an Kapitel 6 zur¨ uckdenkt, dann kann es verschiedene Ausgangslagen f¨ ur die Erweiterung um ein Groupware System geben. In Abschnitt 6.1.3 wird n¨ aher darauf eingegangen. Der einfachste Fall ist das Fehlen einer Groupware. Hier gibt es ganz klar die Empfehlung, eine Group-

7.2 Erweitern um ein Groupware System

159

ware als integrierten Bestandteil des KM Systems einzuf¨ uhren. Schwieriger wird es, wenn schon ein Groupware System vorhanden ist. Primär auf die¨ sen Fall bezieht sich auch die Fragestellung in der Uberschrift des nächsten Abschnitts ( Integration oder Nebeneinander“). Zusätzlich gibt es nat¨ urlich ” noch die Variante, dass ein vorhandenes System durch ein neues abgelöst werden soll. Hierbei handelt es sich um einen Spezialfall, der ähnlich schon in Abschnitt 5.1.2 diskutiert wurde. 7.2.1 Integration oder Nebeneinander Als Basis f¨ ur diesen Abschnitt sollte man sich an Abschnitt 7.1.1 erinnern, da einige der relevanten Argumente dort schon diskutiert wurden. Wie bei dieser Variante muss man einmal feststellen, ob eine der vorhandenen Plattformen eine geeignete Integrationsbasis darstellt. Weiters sind die Abstufungen einer Integration und die Kosten-/Nutzendiskussion von besonderer Wichtigkeit. Kurz gesagt gibt es eine Reihe von Eckpunkten zu ber¨ ucksichtigen: • • • • •

Das Ziel der KM Initiative Die aktuellen und angestrebten Arbeitsabläufe Die vorhandene Infrastruktur Die Kosten f¨ ur verschiedene Auspr¨ agungen einer Integration (inklusive notwendiger Abl¨ osen von alten Systemen) Die Kosten f¨ ur den Betrieb der so geschaffenen Lösung

Auf dieser Basis l¨ asst sich relativ leicht“ eine Entscheidung f¨ ur eine Inte” gration oder ein Nebeneinander treffen. Eine Argumentation f¨ ur ein Nebeneinander k¨ onnte auf folgenden Eckpunkten basieren: • • •

Die Anforderungen an eine Groupware werden durch das bestehende System ausreichend abgedeckt. Die Kosten f¨ ur eine auch nur oberfl¨ achliche Integration können nicht gerechtfertigt werden. Die geplanten Arbeitsabl¨ aufe lassen sich mit den verschiedenen daf¨ ur notwendigen Systemen effizient und einfach abbilden.

Kann man diese drei Fragen nicht mit Ja“ beantworten, ist eine Inte” gration die logische Schlussfolgerung. Damit muss man feststellen, welches ur agung einer Integration am besten f¨ Groupware System mit welcher Auspr¨ die Organisation geeignet ist. Nachdem schon bei der Entscheidung f¨ ur ein CMS mit¨ uberlegt wurde, wie es um die Integrationsmöglichkeiten steht, hat man hier schon eine Reihe von Vorgaben“. Zusammen mit den funktionalen ” Anforderungen sollte sich damit das Feld der Groupware Systeme gut einengen lassen. Gegen¨ uber der Variante eines Groupware Systems, dass um CMS Funktionen erweitert wird, gibt es also prim¨ ar zwei tendenzielle Unterschiede. Einerseits die (begr¨ undete) Annahme, dass bei einem CMS System fast nie eine

160


problematische Abl¨ ose vorkommt, w¨ ahrend das bei Groupware Systemen nicht unwahrscheinlich ist. Andererseits und eigentlich als verwandtes Thema die größere Wahrscheinlichkeit, dass ein Nebeneinander die unmittelbar effizienteste L¨ osung ist. Davon abgesehen ist diese Analyse eine Weiterf¨ uhrung des schon Besprochenen und kann in Ausnahmef¨ allen durchaus auch f¨ ur den Fall einer Erweiterung um ein CMS System Sinn machen. 7.2.2 Umsetzungsstrategien Zu Beginn dieses Abschnitts u ogliche Umsetzung sollte man an Ab¨ber die m¨ schnitt 5.4, der die entsprechenden Punkt f¨ ur die Einf¨ uhrung einer Groupware behandelt, zur¨ uckdenken. Kurz gesagt geht es darum, eine Entscheidung u ¨ ber den Umfang des einzuf¨ uhrenden Systems zu treffen. Weiters stellt sich die Frage wie die Entwicklung und der Betrieb aussehen sollten. Diese Punkte sind bei einer Erweiterung eines vorhandenen Systems weniger wichtig, da es schon eine entsprechende Infrastruktur gibt, die man möglichst nutzen sollte (auch mit dem Ziel m¨ oglichst wenige Partner f¨ ur das KM-System zu benötigen). Weiters sollte man sich auch an Abschnitt 7.1.3 erinnern. Wie dort dargelegt wird, sind technisch keine un¨ uberwindbaren Probleme zu erwarten. Gleichzeitig gilt der Hinweis auf die zuk¨ unftigen Prozesse und die Einbindung der Betroffenen nat¨ urlich f¨ ur eine Groupware genauso wie f¨ ur ein CMS System. Praktisch betrachtet kann man damit vier Fälle unterscheiden: • • • •

Weiterverwenden einer vorhandenen Groupware ohne Integration Integration einer vorhandenen Groupware Abl¨ ose einer vorhandenen Groupware Einf¨ uhrung eines Groupwaresystems

Weiterverwendung einer vorhandenen Groupware ohne Integration Diese Variante ist vor allem f¨ ur weniger ambitionierte KM Initiativen realistisch, die außerdem noch eine relativ brauchbare Groupware vorgefunden haben. Technisch betrachtet gibt es hier nichts zu tun. Die organisatorischen Punkte m¨ ussen dagegen besonders sorgf¨ altig durchgedacht werden. Im Prinzip hat man es in Folge mit zumindest zwei unabhängigen Systemen zu tun. Die Arbeitsabl¨ aufe der Organisation m¨ ussen daher sicherstellen, dass die Aruhrt werden kann. Als beit effizient und ohne doppelte Datenhaltung durchgef¨ Vorteil hat man minimale Einmalkosten und zwar auch, was den Schulungsaufwand und verlorene Produktivit¨ at betrifft. Als Minus könnten zum Beispiel erh¨ ohte Wartungs- und Betriebskosten anfallen. Integration einer vorhandenen Groupware Zusammen mit der Abl¨ ose ist die Integration einer vorhandenen Groupware die potenziell schwierigste Variante. Wenn man schon bei der Auswahl des

7.2 Erweitern um ein Groupware System

161

CMS Systems auf diese Fragestellung R¨ ucksicht genommen hat, sollte es aber ¨ im Großen und Ganzen keine b¨ osen Uberraschungen gegeben. F¨ ur die Umsetzung ist es besonders wichtig, ein klares Bild der zuk¨ unftigen Prozesse und ihrer Unterst¨ utzung durch die IT vor Augen zu haben. Vor diesem Hintergrund sollte es relativ einfach sein, die notwendigen Schnittstellen und Umbauten zu identifizieren und in weiterer Folge umzusetzen. Besonderes Augenmerk muss man auch darauf haben, dass die Vorteile einer veränderten Arbeitsweise klar kommuniziert werden. Weiters ist darauf zu achten, dass es nicht zu Problemen durch ein Weiterleben der alten Verwendung der Groupware kommt (und damit eventuell Daten und Informationen schwer auffindbar werden). Abl¨ ose einer vorhandenen Groupware Entscheidet man sich f¨ ur die Abl¨ ose eines existierenden Systems, sollte man einer Reihe von Punkten besonderes Augenmerk schenken. Der Nutzen der Organisation und in weiterer Folge jedes Einzelnen muss klar kommuniziert werden (und nat¨ urlich bis auf Ausnahmen vorhanden sein). Man sollte möglichst in Zusammenarbeit mit den aktuellen Anwendern feststellen, wie bestimmte Funktionalit¨ aten im neuen System abgebildet werden, und die in Hinblick auf die angestrebten Ziele der KM Initiative geplanten Arbeitsabläufe ber¨ ucksich¨ tigen. Besonders wichtig sind Schulungen und die Ubergangszeit. Hier muss man sich auf jeden Fall die notwendige Zeit nehmen, um einen möglichst ein¨ fachen und gleichzeitig schnellen Ubergang zu schaffen. Hierzu gehört auch die Frage der vorhandenen Datenbest¨ ande. Je nach Zugriffshäufigkeit und Anzahl der betroffenen Nutzer wird man nach Abw¨ agung der Kosten eine angemessene und f¨ ur die Nutzer brauchbare L¨ osung finden m¨ ussen. Einf¨ uhrung eines Groupwaresystems Der einfachste Fall ist nat¨ urlich die Einf¨ uhrung eines Groupware Systems. Hier hat man weder mit alten Best¨ anden noch mit einer möglicherweise falschen Verwendung nach einer Integration zu kämpfen. Gleichzeitig gewinnt der Aspekt der Benutzerschulung besondere Wichtigkeit. Einen gewissen Umgang mit IT kann man gl¨ ucklicherweise schon voraussetzen (zumindest mit dem CMS System). Allerdings wird den meisten Nutzern eine konkrete Vorstellung einer Groupware fehlen und damit ist hier besonderes Augenmerk unftigen Prozesse geboten. Man sollte auf jeden Fall bei der Definition der zuk¨ wieder zuk¨ unftige Nutzer einbinden. Allerdings m¨ ussen diese Personen besonders auf die generell andere Arbeitsweise hingewiesen werden. Nat¨ urlich ist die Einf¨ uhrung des Systems dann auch entsprechend zu begleiten. Im Gegensatz zu den anderen Szenarien ist der zeitliche Aspekt nicht ganz so wichtig, aber man muss besonders auf eine erfolgreiche Schulung der Mitarbeiter in einer f¨ ur sie neuen Art von System achten.

162


Zusammenfassung Die wichtigsten Aspekte einer Erweiterung eines CMS um ein Groupware System wurden einerseits bei der generellen Einf¨ uhrung eines Groupware Systems und andererseits bei der umgekehrten Erweiterung besprochen. Gleichzeitig ist es bei dem angesprochenen Szenario besonders wichtig unterschiedliche Schwerpunkte, die der entsprechenden Umsetzungsvariante entsprechen, zu setzen. Daher muss man zuerst entscheiden, welche Variante f¨ ur die KM Initiative am besten ist, und dann situationsgemäß vorgehen.

7.3 Wichtigkeit und Anwendungsgebiete DMS Nach der intensiven Besch¨ aftigung mit CMS und Groupware Systemen ist es jetzt an der Zeit die dritte prominente Kategorie aus Kapitel 3, die Document Management Systeme, anzusprechen. Wie auch schon bei der Frage ob man mit einem CMS oder einem Groupware System beginnen soll oder auch wie eine Erweiterung aussehen kann, gibt es hier eine ganze Reihe von Fragen zu analysieren. Prinzipiell betrachtet ist eine Groupware eher ein Mittel zur unstrukturierten Zusammenarbeit w¨ ahrend CMS Systeme eine klare Struktur haben. DMS Systeme sind ebenfalls eher strukturiert und stellen im Minimalfall eine Dokumentenablage mit Berechtigungs- und Versionierungssystem dar. Insbesondere kommerzielle Systeme gehen deutlich dar¨ uber hinaus und bilden ganze Arbeitsabl¨ aufe mit Workflows, etc. ab. 7.3.1 Wichtigkeit von DMS Funktionen Die interessanteste Frage im Hinblick auf ein KM System und die dahinterliegende KM Initiative ist nat¨ urlich, warum DMS Funktionen besonders wichtig sind. Kurz gesagt geht es um das Ablegen und Wiederfinden von allen möglichen Dokumenten. Dieser Aspekt kann nat¨ urlich auf unterschiedlichste Arten und Weisen abgedeckt werden. Gleichzeitig ist ein DMS System einer der effektivsten M¨ oglichkeiten das zu tun. Dabei sollte man nicht nur an die unmittelbare Verwendung der Dateien denken sondern auch, was in weiterer Folge damit geschieht. Hier sind etwa Fragen der Nachvollziehbarkeit bis hin zu einer Revision zu ber¨ ucksichtigen. Gewisse Dokumente m¨ ussen aufgrund gesetzlicher Vorschriften in gewisser Art und Weise aufbewahrt werden. Andere wiederum stellen einen Wert“ an ” sich dar und sollten ebenfalls speziell behandelt werden. Ein simples Beispiel sind alle Arten von Vertr¨ agen, die eine Organisation abschließt. Man k¨ onnte nat¨ urlich einwenden, dass solche Anforderungen auch ohne DMS System abgedeckt werden k¨ onnen. Das ist grundsätzlich auch richtig. Gleichzeitig sind die meisten gebr¨ auchlichen Alternativen“ mit verschie” denen Problemen verbunden. Die Einfachste (und potenziell am häufigsten

7.3 Wichtigkeit und Anwendungsgebiete DMS

163

benutzte) ist dabei ein Netzlaufwerk. Zusammen mit einem funktionierenden Backup hat man hier schon einmal Minimalanforderungen abgedeckt. Vieles muss man allerdings organisatorisch und/oder manuell lösen. Eine revisionssichere Ablage zum Beispiel bedeutet das regelmäßige Sichern von den betroffenen Dateien auf Read-only Medien. Eine Versionierung erfolgt potenziell u ¨ ber eine Vielzahl von Dokumentversionen“ als Dateien mit unter” schiedlichem Namen. Ein Archiv k¨ onnte eine Art Schattenlaufwerk sein und es gibt jemanden der die Dokumente entsprechend verschiebt. Insgesamt eine mögliche aber auch problematische Herangehensweise an ein potenziell sehr sensibles Thema (ein nicht auffindbarer Vertrag kann etwa kleinere Organisationen in ihrer Existenz bedrohen). Nat¨ urlich gibt es auch bessere Varianten und gerade ein mächtigeres“ ” CMS System bietet schon von Haus gewisse Funktionen. Häufig handelt man sich aber mit so einer missbr¨ auchlichen“ Verwendung ebenfalls wieder Pro” bleme ein. Daher wird diese Variante nur in Ausnahmefällen einen sinnvollen Ersatz f¨ ur ein DMS System darstellen. – Eine komplett andere Situation ergibt sich wiederum, wenn entweder das verwendete Groupware oder CMS System mehr oder weniger ausgefeilte DMS Funktionen haben. Auf diesen Sonderfall wird sp¨ ater noch eingegangen. Man sieht also schon an dieser groben Aufzählung wie wichtig DMS Funktionen im Generellen sind. Inwieweit man von KM sprechen kann, lässt sich dabei in vielen F¨ allen (berechtigt) bezweifeln. Gleichzeitig sind die Dokumente eines DMS (Teil-)Systems Informationen von unschätzbarem Wert f¨ ur ein KM System. Dar¨ uber hinaus helfen DMS Funktionen, wissensintensive Abläufe zu unterst¨ utzen. Das beginnt bei der Recherche von vorhandenem Material geht weiter u ¨ber die Speicherung aller Ergebnisse und stellt auch eine unverzichtbare Quelle von Informationen f¨ ur weiterf¨ uhrende Systeme dar (etwa eine Experten- oder F¨ ahigkeitenidentifikation). 7.3.2 Anwendungsgebiete von DMS Funktionen F¨ ur eine konkretere Analyse ist es notwendig, näher auf wichtige Anwendungsgebiete von DMS Funktionen einzugehen. Dabei ist das Ziel nicht eine vollst¨ andige Liste, sondern eine u ¨berblickshafte Darstellung. Zuerst sollte man sich dabei die typischen Funktionen vor Augen f¨ uhren: 1. 2. 3. 4.

Hierarchische Struktur ( Ordner“ oder ¨ ahnliches) ” Versionsverwaltung mit Check-in/out ACL Zugriffsschutz (mit entsprechender Benutzerverwaltung) Suche u ¨ ber Ordner und Daten zum Teil auch in bekannten Formaten (z.B. Word) 5. G¨ ultigkeitszeitr¨ aume und/oder ein Archiv 6. Fallweise mit Workflowunterst¨ utzung 7. Fallweise virtuelle Ordner (¨ uber Suchkriterien) und/oder Links

164


Dazu kann man sagen, dass die ersten vier bis f¨ unf Punkte eine Art Minimalanforderung an ein gutes DMS System sind. Insbesondere bei der Suche oder den G¨ ultigkeitszeitr¨ aumen/Archivfunktionen gibt es dabei zum Teil erhebliche Unterschiede. Je nach konkreten Anforderungen kann man hier Systeme recht gut unterscheiden. Zus¨ atzlich haben die verf¨ ugbaren Produkte typischerweise auch noch weitere hilfreiche Funktionen wie etwa Kommentare zu Dokumenten, die zus¨ atzliche Verwaltung von anderen Informationen wie ¨ Weblinks oder Benachrichtigungen bei Anderungen im DMS System. Aufbauend auf dieser Unterscheidung geht es darum, möglichst umfassend Anwendungsgebiete und Anforderungen eines KM Systems abzudecken. Wenn man in diesem Zusammenhang an Kapitel 2 zur¨ uckdenkt, dann helfen DMS Funktionen (vor allem) bei den folgenden Aspekten: Speicherung: Ein DMS System ist ein zentrales beziehungsweise verbindendes Element einer Speicherl¨ osung f¨ ur ein KM System. Selbst bei einer losen Kopplung muss es u ¨bergreifende Zugriffsfunktionen geben. Flexibles & adaptierbares Berechtigungssystem: Ist f¨ ur ein DMS System eine besonders wichtige Sache und sollte auf jeden Fall integriert beziehungsweise abgeglichen sein. KI/DM/KDD/ML: F¨ ur die verschiedenen Möglichkeiten Informationen aus vorhandenen Daten zu generieren ist der Informationspool eines DMS Systems ideal geeignet (insbesondere auch durch die zusätzlichen Strukturund Metadaten). Kontext, Links, Historie: Solche (Meta-)Daten kann man typischerweise in einem DMS System verwalten. Insbesondere die Versionsverwaltung ist dabei ein Plus, dass man anders nicht wirklich adäquat abbilden kann. Transparenz und Nachvollziehbarkeit: Durch die l¨ uckenlose“ Historie und ” soweit vorhanden Kontext und Links werden wichtige Aspekte von Transparenz und Nachvollziehbarkeit automatisch abgedeckt. Insgesamt geht es also um die strukturierte Speicherung von Dokumenten mit einer Versionsverwaltung. Dazu gehören unbedingt ein Berechtigungssystem und eine m¨ oglichst umfassende Suche. Weiters sind G¨ ultigkeitszeitr¨ aume/Archivfunktionen, Workflowunterst¨ utzung oder erweiterte Strukturierungsm¨ oglichkeiten von großer Bedeutung. Mit diesen Punkten kann man eine ganze Reihe von Anforderungen an ein KM System abdecken. Dar¨ uber hinaus wurde auch schon diskutiert, dass Nachvollziehbarkeit zum Teil gesetzlich beziehungsweise auch von Revisionen gefordert ist. Aus all diesen Punkten heraus ist die Wichtigkeit einer DMS L¨ osung f¨ ur ein umfassendes KM System offensichtlich. Inwieweit das auch f¨ ur kleinere Initiativen zutrifft und wie eine Integration aussehen kann, wird im Anschluss untersucht. 7.3.3 Volltextsuche ur DMS sowie KM Systeme im AllgeWegen der besonderen Wichtigkeit f¨ meinen gibt es jetzt noch einen extra Abschnitt zum Thema Volltextsuche.


165

Eigentlich geht es dabei um eine generelle Funktionalität. Gleichzeitig besteht ein besonderer Zusammenhang mit DMS Systemen und daher wird eine Analyse an dieser Stelle vorgenommen. Der grundsätzliche Vorteil einer Volltextsuche kann mit dem Hinweis auf die Internetsuchmaschine Google einfach illustriert werden. Prinzipiell haben fast alle der vorgestellten Systeme und Teilsysteme eine Volltextsuche. Leider heißt das keineswegs, dass man von einer schnellen Suche, die alle relevanten Informationen findet, ausgehen könnte. Das ist ganz im Gegenteil eher die Ausnahme. Daher sollte man bei einer Auswahl eines Systems hier ganz besonders auf die wirklich vorhandene Funktionalität achten. Wichtigkeit einer Volltextsuche Viele Leser werden sich vielleicht kaum vorstellen können, ohne eine Volltextsuche zu arbeiten. Andere werden sie eventuell f¨ ur verzichtbar halten, weil sie bis jetzt gut ohne ausgekommen sind. Dabei gibt es verschiedene Antworten auf die Frage der Wichtigkeit einer Volltextsuche. Einerseits wird so etwas durch die st¨ andig wachsende Flut an Dateien und Dokumenten immer wichtiger. Andererseits ist ein schneller Zugriff zum Teil nur u ¨ ber eine Volltextsuche realisierbar (gerade wenn das Arbeitsumfeld umfassender ist und man in einer Reihe von Strukturen aktiv sein muss). Auch die noch näher analysierte Einbeziehung von Dokumentinhalten unterstreicht die N¨ utzlichkeit einer Volltextsuche. Kurz gesagt geht es bei einer Volltextsuche um das schnelle Finden von Informationen. Einerseits um das Wiederfinden und damit um eine Entlastung des Ged¨ achtnisses. Andererseits um das Finden von Dokumenten anderer Mitarbeiter. Dar¨ uber hinaus hilft eine Volltextsuche durch eine Einbeziehung von weiteren Informationsquellen u ¨ ber verschiedene Informationssysteme hinweg zu suchen. Anders gesagt wird die Arbeit mit großen Dateibeständen erleichtert. Ab einem gewissen Umfang wird man ohne eine Volltextsuche große Schwierigkeiten bekommen. Aber auch mit ihr wird man ab einer noch einmal gr¨ oßeren Menge an Dateien zu weiteren Hilfsmitteln greifen m¨ ussen (hierauf wird zum Teil in Kapitel 8 eingegangen). Dokumentformate Hintergrund der teilweise wenig befriedigenden Suchfunktionen ist dabei einerseits die notwendige Indexierung mit technologischen und speicherrelevanten Fragen (sprich Kosten). Andererseits geht es auch um die F¨ ulle der vorhandenen Dateiformate und der Zug¨ anglichkeit des Inhalts. Das Vorhandensein einer Volltextsuche bedeutet also keineswegs, dass es eine Indexierung (f¨ ur den schnellen Zugriff) gibt oder dass mehr als die vom Programm selbst unterst¨ utzten Dateiformate erkannt und verarbeitet werden. Bei kommerziellen Systemen wird daher meist eine Suchmaschine mit einer Menge an Filtern

166


zum Verarbeiten von unterschiedlichsten Formaten verwendet. Leider sind diese Systeme relativ teuer und nat¨ urlich f¨ ur eine Open Source Lösung nicht verwendbar. Nach der Erl¨ auterung dieses Hintergrunds wird man auch das Eingehen auf die unterst¨ utzten Formate im Kapitel 3 noch besser verstehen. Gleichzeitig muss man feststellen, dass man keine umfassende Unterst¨ utzung von Formaten findet. Typischerweise gibt es integrierte (könnte etwa ein Lucene f¨ ur Java sein) oder eingebaute Funktionen, die man mehr oder weniger leicht um weitere Filter erweitern kann. Direkt unterst¨ utzt werden nur relativ simple und verbreitete Formate wie HTML oder etwa CSV. Meist findet man auch noch PDF sowie die wichtigsten Formate des Microsoft Office und ofter die von OpenOffice/StarOffice. Dar¨ uber hinaus ist es relativ schwierig ¨ vorgefertigte Filter zu finden. Gl¨ ucklicherweise decken schon die beschriebenen Formate eine ganze Menge an Dokumenten ab und werden im Einzelfall unmittelbar ausreichend sein. Wenn nur wenige Formate fehlen, f¨ ur die es ausreichend Dokumentation gibt, wird sich ein fehlender Filter auch relativ billig erstellen lassen. Dar¨ uber hinaus wird die Sache aber schwierig. Wer also entweder extrem viele Formate verwendet oder relativ ausgefallene und komplizierte Vertreter“ verwalten muss, wird mit einer Volltextsuche u ¨ ber diese ” Inhalte Schwierigkeiten haben. Indexierung Kurz ein paar Worte zur Indexierung. F¨ ur eine schnelle Suche ist ein Index einfach eine Voraussetzung. Dabei sind ein paar Punkte zu beachten. Alle zu indexierenden Daten m¨ ussen schnell zugreifbar sein (potenziell aber nur f¨ ur eine einmalige Indexierung; etwa bei Archivdaten). Alle mit Inhalt zu indexierenden Dateien m¨ ussen u ¨ ber entsprechende Filter zugänglich gemacht werden (oder genauer: ihr Inhalt). Dabei muss man sich u ur die Erstel¨ ber die Kosten f¨ lung, Aktualisierung und Speicherung der Indexe im Klaren sein. Eigentlich sollten sich diese Fragen relativ leicht beantworten lassen. Gleichzeitig sollte man sich mit ihnen relativ fr¨ uh auseinander setzen (potenziell ohne Detaildiskussion), um nicht in Schwierigkeiten zu geraten. Ein wichtiger Punkt ist bei Offlinefunktionalit¨ at zu beachten: Indexe k¨ onnen hier relativ problematisch werden. Am besten funktioniert eine Indexierung aller lokalen Ressourcen, die ein Benutzer mitnehmen“ kann. Diesem Aspekt sollte man bei der gene” rell schwierigen Frage von Offlinefunktionen besonderes Augenmerk schenken (insbesondere auch was Zugriffsrechte angeht). Dateiformate Ein weiterer wichtiger Aspekt ist die Unterscheidung zwischen Datei- und Dokumentformaten. Nicht jede Information findet sich in einem Dokument wieder. Je nach Dateiinhalt stellen sich hier noch wesentlich größere Probleme als bei Dokumenten. Relativ“ simpel sind noch Verbundformate wie eine ”


167

Outlook Maildatei. Hier handelt es sich im Prinzip um eine Sammlung von EMails und allen Anh¨ angen. Bei den Anh¨ angen hat man aber wieder dasselbe Problem. Grunds¨ atzlich kann es sich bei Dateien die keine Dokumente sind, um so ziemlich alles handeln. Daher ist es notwendig sich auf wichtige Typen einzuschr¨ anken (f¨ ur Sonderf¨ alle muss man die Analyse nat¨ urlich entsprechend erweitern). Zu Dokumenten am ¨ ahnlichsten“ sind Bilder“ von Dokumen” ” ten. Dabei kann es sich um gescannten, gefaxten oder auch fotografierten Text handeln. Je nach Wichtigkeit und Qualit¨ at der vorhandenen Daten kann man hier eine Texterkennung verwenden, um die Inhalte zugänglich zu machen. Hierbei handelt es sich um eine sehr h¨ aufig anzutreffende Variante. Nat¨ urlich kann man auch echte Bilder, Abbildungen, Skizzen, etc. haben. Hier gibt es durchaus eine Reihe von vielversprechenden Ansätzen (siehe auch die Bildersuche von Google). Gleichzeitig handelt es sich hier um Funktionen und Systeme, die noch nicht leicht anzuwenden sind. F¨ ur ein Open Source KM System sollte man nur in Ausnahmef¨ allen eine Einbindung versuchen. Von der Zug¨ anglichkeit her zwischen Bildern und Dokumenten sind Tonaufnahmen angesiedelt. Je nach Organisation gibt es mehr oder weniger viele Dateien mit Aufnahmen von Gespr¨ achen, etc. Auch hier gibt es noch kaum einfache Systeme und man sollte sich eine Einbindung gut u ¨ berlegen. Gleichzeitig handelt es sich um ein Zukunftsthema und es ist noch einiges zu erwarten. Wenn man allerdings den Fokus auf eine stabile und kosteng¨ unstige L¨ osung legt, sollte man noch abwarten. Daneben gibt es nat¨ urlich noch eine Unzahl von Inhalten von Dateiformaten. Es k¨ onnte zum Beispiel Musik sein, wo man von einer Anwendersicht her mit ¨ ahnlichen Problemen wie bei Bildern k¨ ampft. Es könnten aber auch Konstruktionszeichnungen (zum Beispiel das Format eines CAD-Programmes) sein. Je nach der Branche, in der eine Organisation tätig ist, wird man hier sicher noch viele weitere Formate oder Typen finden. Grundsätzlich muss man sich u ¨berlegen, wie viel davon als Text zugänglich gemacht werden kann und wie die Volltextsuche damit umgehen kann. Je ausgefallener ein Format ist, desto eher sollte man u ¨ berlegen, ob ein Verzicht darauf wesentliche Einschränkungen mit sich bringt oder vertretbar ist. Berechtigungssystem Die Frage der Berechtigungen ist bei einer Volltextsuche aüßerst wichtig. Insbesondere da schon das Wissen u ¨ ber das Vorhandensein einer gewissen Information ein Problem sein kann. Man stelle sich nur vor ein Mitarbeiter könnte feststellen, ob es Dokumente mit dem Begriff K¨ undigung“ mit aktuellem ” ¨ Anderungsdatum gibt. Auch ohne die M¨ oglichkeit auf das Dokument selbst zugreifen zu k¨ onnen, muss man so etwas verhindern. Leider gestaltet sich das in einem heterogenen Umfeld recht schwierig. Eine simple Variante, alle Anforderungen zu erf¨ ullen, setzt einen performanten und direkt zugreifbaren Speicher aller Dokumente voraus. Auf dieser

168


Basis kann f¨ ur das Ergebnis einer Suche noch mit den vorhandenen Berechtigungen gefiltert werden. Wenn einer der beiden Punkte nicht erf¨ ullt ist, wird die Sache problematisch. Man muss n¨ amlich einen performanten Zugriff auf alle Berechtigungen schaffen und in weiterer Folge einen Abgleich machen. Technisch betrachtet kein Problem, allerdings erhöhen sich die Kosten und die Komplexit¨ at der beschriebenen L¨ osung. F¨ ur Offlinenutzung ist eine simple Variante gleich nur die Dokumente mit Rechten f¨ ur einen Benutzer zu indexieren. Offensichtlich gibt es damit eine Einschränkung auf einzelne Benutzer und wieder die Notwendigkeit des Abgleichs. Zusammengenommen geht es prim¨ ar um die Frage des performanten und direkten Zugriffs auf die Berechtigungsinformationen. Hierzu muss man sich je nach angestrebtem KM System eine mehr oder weniger komplizierte Lösung einfallen lassen, die allen geschilderten Anforderungen gerecht wird. Insbesondere muss man auch noch auf Offlinefunktionalität achten. Zusammenfassung ¨ Wenn man jetzt versucht sich einen Uberblick u ¨ber das Themengebiet Volltextsuche zu verschaffen, hat man es mit einer ganzen Reihe von Fragen zu ¨ tun. F¨ ur eine bessere Ubersichtlichkeit bieten sich hier Beschreibungen der Einzelpunkte an: Wichtigkeit einer Volltextsuche Ergibt sich hauptsächlich aus der Notwendigkeit, die immer st¨ arker wachsende Dokumentflut sinnvoll nutzen zu k¨ onnen. Ist nat¨ urlich f¨ ur jede Organisation individuell zu bewerten. Formate Einerseits bei Dokumentformaten andererseits bei Dateiformaten muss man feststellen, welche besonders wichtig sind. Leider gibt es keine umfassende Filtersammlung in der Open Source Gemeinde. Daher sollten man hier eine m¨ oglichst umfassende Unterst¨ utzung f¨ ur alle wichtigen Typen anstreben und f¨ ur besonders wichtige fehlende Formate selbst Filter entwickeln (lassen) und nat¨ urlich der Open Source Gemeinde zur Verf¨ ugung stellen. Indexierung Ist eine Notwendigkeit f¨ ur schnellen Zugriff auf alle Dokumente im DMS beziehungsweise einem Pool von Informationen. Hierf¨ ur ist ein performanter Zugriff notwendig. Weiters muss man die Indexierung selbst sowie die Speicherung u ¨ berlegen. Berechtigungssystem Eine Volltextsuche muss so entwickelt werden, dass vertrauliche Informationen vertraulich bleiben. Daf¨ ur gibt es unterschiedlich osungen, die man den Anforderungen entsprechend umsetzen komplexe L¨ muss. at Ist generell eine problematische Sache. Hier muss man Offlinefunktionalit¨ sich genau u ¨ berlegen, was Sinn macht und was keine vertretbare Kosten/Nutzenrechnung hat.


169

7.3.4 Entscheidungskriterien Nach diesem Ausflug“ zum Thema Volltextsuche geht es jetzt um die Frage, ” wie man sich f¨ ur ein DMS System entscheidet (oder auch dagegen). Eine ganz grunds¨ atzliche Frage dabei ist wie schon bei CMS und Groupware Systemen beziehungsweise der wechselseitigen Erweiterung der geplante Umfang der KM Initiative. Zus¨ atzlich nat¨ urlich auch wieder die Frage der schon vorhandenen Systeme, die man nat¨ urlich mitbetrachten muss. Die Organisation dieses Buches zeigt eine generell mögliche Vorgehensweise auf. Dabei sind CMS und Groupware Systeme vorgezogen, weil sie breitere und aus Sicht KM wichtigere Anwendungen haben. Wenn nicht nur KM Aspekte im Vordergrund stehen oder Sonderfaktoren dominieren, kann nat¨ urlich ein Start mit einem DMS System genauso Sinn machen. Der weitere Text wird dabei gr¨ oßtenteils von den gerade beschriebenen Annahmen ausgehen. Die prinzipiellen Funktionalit¨ aten eines DMS Systems wurden ja schon in Abschnitt 7.3.2 dargestellt. Damit stellt sich die Frage, auf welchen Eckpunkten eine Bewertung der Wichtigkeit eines DMS Systems beruhen sollte. Die folgende Aufz¨ ahlung gibt dazu eine Reihe von Anhaltspunkten: • • • • • •

Umfang, Ziel und Fokus der KM Initiative Vorhandene Funktionen in den ausgew¨ ahlten CMS und/oder Groupware Systemen Wichtigkeit der DMS Funktionen f¨ ur die geplanten/gew¨ unschten Arbeitsabl¨ aufe Als Ergebnis einer System- und Anforderungsanalyse die Wichtigkeit einer engen Integration Ganz oder teilweise außerhalb des Fokus von KM liegende Aspekte (wie rechtliche Erfordernisse) Eine (eventuell grobe) Kosten-/Nutzenrechnung f¨ ur das angedachte System oder auch mehrerer Varianten; Hierbei gilt es neben Projektkosten auch Wartungs-/Betriebskosten und andere technische Punkte (wie die resultierende Komplexit¨ at oder Heterogenität) zu ber¨ ucksichtigen

Wenn man sich mit den genannten Punkten intensiv beschäftigt, sollte es relativ“ leicht fallen, f¨ ur eine konkrete Situation konkrete Entscheidungs” kriterien zu finden. Im Normalfall sollte man sogar eine Vorentscheidung ¨ haben, die einem alle weiteren Uberlegungen wesentlich erleichtert. Jedenfalls hat man die n¨ otige Basis, um mit einer konkreten Analyse der Anforderungen und m¨ oglichen Systeme eine Entscheidung zu treffen. 7.3.5 Vorhandenes bzw. Integration urlich ist es auch bei der Einf¨ uhrung von DMS Funktionalitäten unbedingt Nat¨ notwendig zu analysieren, was schon vorhanden ist. Die beiden Extremfälle“ ” sind nat¨ urlich das Vorhandensein beziehungsweise das völlige Fehlen eines

170


DMS Systems. Das v¨ ollige Fehlen solcher Funktionen wird relativ selten anzutreffen sein. Gleichzeitig stellt dieser Fall aus technischer Sicht den einfachsten dar. Aus einer KM Sicht kann man das nicht sagen. Hier ist ein existierendes DMS System von Vorteil, da man eine bessere Ausgangsbasis f¨ ur praktische Ergebnisse der KM Initiative hat. In der Praxis muss man daher zuerst folgende Punkte analysieren: •

Vorhandene DMS Systeme (h¨ aufig kommerziell aber auch Open Source Systeme) • Vorhandene DMS Funktionen in vorhandenen Systemen (zum Beispiel CMS Systeme) • DMS ¨ ahnliche Systeme“ (am h¨ aufigsten ein Dateisystem eines Servers) ” Bei den genannten Punkten muss man zusätzlich noch auf alle möglichen Kombinationen gefasst sein. Insbesondere eine Art strukturierte Dateiablage auf einem Dateisystem wird praktisch immer eingesetzt unabhängig von der Existenz eines DMS Systems. Wichtig ist dabei vor allem, ein möglichst vollst¨ andiges Bild der Dokumentenlandschaft“ einer Organisation zu bekom” men. Weiters wurde schon mehrfach darauf hingewiesen, dass man unbedingt die zuk¨ unftigen Arbeitsabl¨ aufe u usste klar werden, ¨berlegen sollte. Damit m¨ wie man DMS Funktionen am einfachsten einbetten kann (und auch welche Variante technisch mehr Sinn macht). Generell ist es notwendig bei vorhandenen DMS Systemen beziehungsweise Funktionen festzustellen, ob sie alle wichtigen Anwendungsgebiete abdecken. Weiters muss man sich eine m¨ ogliche Form der Integration u ¨ berlegen. Das sollte bei DMS Funktionen von Systemen, die schon Teil des KM Systems sind, keine gr¨ oßeren Schwierigkeiten machen (muss aber auf jeden Fall analysiert werden). Schwieriger wird es bei kommerziellen Systemen. Hier stellt sich wieder einmal die Frage nach Schnittstellen und einer Reihe von technischen, organisatorischen und finanziellen Aspekten. Noch einmal kurz zusammengefasst muss sich ein DMS System in ein KM System relativ eng integrieren lassen. Das umfasst sowohl die Benutzerverwaltung als auch den gegenseitigen Zugriff auf Dokumente und Funktionen. Weiters ist eine einheitliche Sicht der Benutzer zu gewährleisten. Zusätzlich stellt sich die Frage der technischen Betreuung. Je inhomogener die verwendeten Technologien sind, desto eher sollte man hier mit anhaltenden Schwierigkeiten rechnen. Aus organisatorischer Sicht könnte die Unterst¨ utzung und der Betrieb einer schlecht integrierten oder uneinheitlichen Lösung Probleme aufwerfen. Aus finanzieller Sicht wird man f¨ ur eine komplexe Lösung und insbesondere ein kommerzielles System mit erh¨ ohten Wartungskosten kalkulieren ussen (kann nat¨ urlich trotzdem g¨ unstiger als eine Ablöse sein). Da sich entm¨ sprechende Hinweise in Kapitel 5 oder Kapitel 6 finden, wird hier nicht näher darauf eingegangen. Im n¨ achsten Abschnitt werden DMS Systeme beziehungsweise DMS Funktionen von im Kapitel 3 vorgestellten Groupware und CMS Systemen analysiert. Die folgende Analyse kann dabei prim¨ ar drei mögliche Ergebnisse haben:


• • •

171

Eine Entscheidung f¨ ur eines der vorgestellten DMS Systeme und wie man es in das existierende oder geplante KM System integrieren kann Die Nutzung von vorhandenen DMS Funktionen, die durch andere Systeme zur Verf¨ ugung gestellt werden Soweit man noch kein KM System hat, k¨ onnen die Anforderungen hinsichtlich DMS Funktionen eine Entscheidung f¨ ur ein bestimmtes Groupware und/oder CMS System als Teil des KM Systems nahelegen

Je nach kurz- und mittelfristigen Zielen einer KM Initiative ist das schon f¨ ur einen ersten Schritt wichtig oder kann eher am Rande beachtet werden. Jedenfalls sieht man sehr sch¨ on, wie die einzelnen Themengebiete Groupware, CMS und DMS Systeme aufeinander aufbauen und wie ein KM System umfassend zu betrachten ist. Im Hinblick auf die Abl¨ ose eines vorhandenen Systems ist vor allem die Frage wichtig, wie man an alle relevanten Daten kommt. Ein Export des aktuellen Zustands ist dabei meist weniger schwierig als an weitere Daten zu kommen. Dabei geht es um Metainformationen, alte Stände inklusive gelöschter Dateien und alle m¨ oglichen weiteren Informationen (wie Kommentare). Hierbei handelt es sich um sehr interessante Informationen f¨ ur ein größeres KM System. Je kleiner“ die KM Initiative angelegt ist, desto eher wird man hier ” Kosten einsparen k¨ onnen. Sollten solche Daten aber leicht exportierbar sein, muss man auf jeden Fall einen Weg finden, sie im KM System zu importieren. 7.3.6 Diskussion der DMS Systeme In Kapitel 3 wurde eine Reihe von DMS Systemen vorgestellt und bei den CMS sowie Groupware Systemen grob vermerkt, welche DMS Funktionen vorhanden sind. Der n¨ achste logische Schritt ist eine kurze Diskussion der vorgestellten Systeme beziehungsweise ihrer Funktionen in Hinblick auf die identifizierten DMS Funktionsbl¨ ocke (siehe Abschnitt 7.3.2). Dabei wird diskutiert, wie eine Bewertung dieser Systeme aus Sicht eines größeren KM Systems aussehen k¨ onnte. Das inkludiert auch nichtfunktionale Aspekte, soweit diese besonders wichtig sind. docman docman ist eine kleine und relativ einfache PHP Lösung. Es deckt die drei wichtigsten DMS Anwendungsgebiete durchaus ab. Es bietet eine hierarchische Struktur, eine Versionsverwaltung mit Check-in/out und einen Zugriffsschutz mit entsprechender Benutzerverwaltung. Weiters gibt es noch Notizen und Benachrichtigungen f¨ ur Dokumente. Allerdings gibt es eine Reihe von Schwierigkeiten durch fehlende Funktionen und Schnittstellen. Insbesondere fehlt auch Mehrsprachigkeit, was einen Einsatz im deutschen Sprachraum sehr problematisch macht.

172


Insgesamt ist docman ein relativ einfaches und simples DMS System. Es eignet sich aber kaum f¨ ur eine Integration in ein KM System. Daher ist es im Kontext eines solchen Systems nicht empfehlenswert. KnowledgeTree KnowledgeTree ist ein PHP basiertes DMS System mit einem größeren Funktionsumfang. Genauer gesagt adressiert es als eines der wenigen Systeme alle identifizierten Anwendungsgebiete. Zum Zeitpunkt der Analyse war allerdings noch keine komplette Mehrsprachigkeit gegeben. Eigentlich ist das eine Voraussetzung doch wurde schon daran gearbeitet und damit sollte das eigentlich kein nennenswertes Problem darstellen. Bei der Suche werden die Binärformate Excel, PDF und Word unterst¨ utzt (weitere Filter können integriert werden). Dar¨ uber hinaus gibt es auch noch Diskussionsforen und Benachrichtigungen zu Dokumenten sowie Weblinks. Alles in allem ist damit KnowledgeTree eines der besten von den analysierten Open Source DMS Systemen. Es deckt alle Anwendungsgebiete ab und zumindest eine lose Integration sollte m¨ oglich sein. Wie ein Zusammenspiel im Kontext eines KM Systems aussehen k¨ onnte, muss man sich nat¨ urlich anhand von konkreten Beispielen anschauen. Man wird sich nat¨ urlich leichter tun, wenn auch die anderen Bestandteile PHP basiert sind. Allerdings sollte es auch in anderen Konstellationen relativ leicht sein, das Webinterface und die Daten in der Datenbank zu integrieren. NO-SOD: eDMS Ein weiteres PHP basiertes System ist eDMS, das viele der Anwendungsgebiete von DMS Funktionen abdeckt. Es gibt primär zwei Einschränkungen: Einerseits kann nicht in Dokumentinhalten gesucht werden und andererseits gibt es keine virtuellen Ordner oder Links. Die Lösung basiert dabei auf dem NO-SOD Framework (daher auch der Name). Damit ist es besonders interessant, sollte man mit anderen Funktionen auf derselben Basis ein kleines KM System erreichen k¨ onnen. Empfehlenswert ist dies aber nur f¨ ur sehr klein angelegte KM Initiativen (auch mittelfristig). Neben den schon beschriebenen Funktionen bietet eDMS noch ein Aufgabenmanagement sowie Kommentare zu Dokumenten. Insgesamt also ein System, dass man bei einer Analyse nicht u ¨ bergehen sollte. Angesichts der anderen vorhandenen Systeme wird es aber eher in Ausnahmef¨ allen die beste Wahl sein. OpenDocMan OpenDocMan ist ein kleines PHP basiertes DMS System. Es bietet eine hierarchische Struktur, Versionen sowie Check-in/out, ACL Zugriffsschutz, eine


173

Suche u orter, G¨ ultigkeitszeitr¨ aume mit Archiv und Workflowun¨ ber Schlagw¨ terst¨ utzung. Damit fehlen einerseits eine Suche in Dokumentinhalten und andererseits virtuelle Ordner oder Links. Was noch schwerer wiegt, ist das Fehlen einer deutschen Version. Außerdem gibt es keine gr¨ oßeren Weiterentwicklungspläne. Daher kann man im Zusammenhang mit einem integrierten KM System von diesem Produkt nur abraten. Damit soll allerdings keineswegs die Eignung als simples standalone DMS System in Frage gestellt werden. OWL Bei OWL handelt es sich um das letzte der vorgestellten DMS Systeme, das auf PHP basiert. Es bietet die wichtigsten DMS Funktionen, namentlich hierarchische Struktur, Versionsverwaltung mit Check-in/out, einen gruppenbasierten Zugriffsschutz und eine Suche, die PDF und Word Inhalte inkludiert. Verwaltet werden weiters URLs sowie Notizen. Dar¨ uber hinaus werden Quotas und E-Mail-Benachrichtigungen unterst¨ utzt. Gesamthaft betrachtet ist OWL eine relativ komplettes, kleines DMS System. Es eignet sich damit eher als standalone Lösung oder zur losen Ergänzung eines kleinen KM Systems. Im Kontext einer größeren Lösung ist es eher nicht zu empfehlen. Paper Harbour In zweierlei Hinsicht handelt es sich bei Paper Harbour um ein deutlich anderes System als bei den bisher betrachteten Vertretern. Einerseits basiert es auf Java und andererseits ist es ein Client/Server System (die bisher beschriebenen Systeme sind web-basiert). Interessanterweise ist das Wiederfinden von Dokumenten hier u ¨ ber Filter, Links und eine Suchfunktion realisiert. Weiters gibt es Versionen mit Check-in/out, ACL Zugriffsschutz, ein Archiv und einen Workflow. Als Zusatzfunktionen findet man noch Benachrichtigungen und die Verschl¨ usselung von Inhalten. Insgesamt handelt es sich bei Paper Harbour um ein mittleres DMS System, das durchaus als standalone Tool denkbar ist. Da das Geschäftsmodell der Herstellerfirma eher restriktiv mit Informationen umgeht, ist eine exakte Bewertung schwierig. Ganz allgemein ist es aufgrund der vorhandenen Funktionen und der Art der Umsetzung eher schlecht f¨ ur mittlere bis größere KM Systeme geeignet. xinco-DMS xinco-DMS ist das zweite Java basierte CMS und unterst¨ utzt die grundsätzlichen Funktionalit¨ aten. Nicht vorhanden ist etwa eine Workflowunterst¨ utzung oder virtuelle Ordner. Die Weiterentwicklungspläne sind dabei weitreichend

174


und daher empfiehlt es sich vor einer Entscheidung den aktuellen Status zu pr¨ ufen. Neben den beschriebenen Funktionalit¨ aten gibt es Kontakte, den Import von ganzen Ordnerhierarchien und SOAP als Protokoll der Client/Server L¨ osung. Insbesondere der letzte Aspekt erleichtert eine Integration, da praktisch alle Funktionalit¨ aten u ugung ge¨ ber entsprechende Interfaces zur Verf¨ stellt werden (es ist unter anderem ein zweiter Client geplant). Zusammengefasst d¨ urfte sich xinco-DMS mit den geplanten Erweiterungen als standalone Lösung eignen. Durch die Art und Weise der Anbindung des eigenen Clients m¨ usste auch eine relativ enge Integration in ein KM System machbar sein. Je eher man eine Java L¨ osung erweitert oder zu einer tendiert desto attraktiver ist xinco-DMS. jLibrary jLibrary ist ein weiteres Java basierte CMS, das vom Konzept her sehr a¨hnlich zu xinco-DMS ist und ebenfalls die grundsätzlichen Funktionalitäten unterst¨ utzt. Wie bei xinco-DMS fehlen auch hier unter anderem Workflowunterst¨ utzung und virtuelle Ordner. Da es sich um ein sehr junges“ Produkt ” handelt, sollte man auch in diesem Fall vor einer Entscheidung den aktuellen Status des Projekts feststellen. Als zus¨ atzliche Funktionen werden Notizen zu und Beziehungen zwischen Dokumenten angeboten. Als internes Protokoll kommt SOAP zum Einsatz und es werden die Methoden des JSR 170 implementiert. Dadurch kann man auf alternative Benutzerschnittstellen hoffen. Der Import und Export von Ordnerhierarchien und der m¨ ogliche standalone“ Einsatz sind ebenfalls noch ” erw¨ ahnenswert. Insgesamt handelt es sich um eine konzeptionell zu xinco-DMS ähnliche Lösung. Die Verwendung des JSR 170 APIs ist ein wesentliche Unterschied dabei. Auch die Verwendung von Eclipse als Basis des Clients ist sehr interessant. Wenn man eine Java L¨ osung ausbauen will, sollte man auf jeden Fall einen Blick auf dieses Produkt werfen. Auch ein einzelner Einsatz kann Sinn machen. OpenGroupware Wie schon angek¨ undigt gibt es auch Groupware und CMS Systeme mit DMS Funktionen. Der erste Vertreter ist OpenGroupware. Dabei werden die Grundfunktionen – namentlich: hierarchische Struktur, Versionskontrolle mit Checkin/out, Zugriffsschutz und Links – unterst¨ utzt. Damit fehlen hier umfangreichere DMS Funktionalit¨ aten. Gleichzeitig liegt aber schon eine integrierte Lösung vor. Es zeigt sich hier wieder die Wichtigkeit eines mittelfristigen Ziels und einer genauen Analyse der Bed¨ urfnisse und zuk¨ unftigen Arbeitsabläufe. Auf so einer Basis kann man beurteilen, ob man mit den gebotenen Funktionen das


175

Auslangen findet. Das ist umso wichtiger als sowohl die Einf¨ uhrung als auch der Betrieb eines Systems eine Organisation unweigerlich mit Zusatzkosten konfrontiert. Als Ergebnis kann man festhalten, dass OpenGroupware die Grundfunktionen eines DMS Systems anbietet. Wenn man damit das Auslangen findet und auch eine Groupware Perspektive f¨ ur dieses System spricht, hat man eine fast ideale Position und die Entscheidung liegt auf der Hand. XOOPS Das zweite Groupware“ System mit DMS Funktionen ist der Zwitter“ ” ” XOOPS. Beschrieben wurde es in der Gruppe der CMS Systeme aber auch diese Einordnung ist nicht ganz korrekt. Eigentlich ist es eine Art Portal mit einer Reihe von vorhandenen Funktionen wie etwa im DMS Bereich. Diese werden u ugung gestellt. Daher ¨berwiegend durch XOOPS Module zur Verf¨ verwundert es nicht, dass es mehr als ein DMS Modul gibt. Das Geeignetste nennt sich dabei Document Management System“. ” Aus Sicht der wichtigen DMS Anwendungsgebiete unterst¨ utzt es eine hierarchische Struktur, eine Versionsverwaltung mit Check-in/out, einen ACL Zugriffsschutz, eine Suche u orter und auch in den Inhalten einer Rei¨ber Schlagw¨ he von Dokumentformaten. Die Suche verwendet dabei eine relativ mächtige Indexierungsmaschine namens Swish-E (http://swish-e.org), die unter anderem direkt PDF, Word, Excel, PowerPoint und PostScript unterst¨ utzt. Durch so eine allgemeine Engine und die schon vorhandene Unterst¨ utzung hat man hier einen Ansatzpunkt f¨ ur eine generelle Einbindung als Volltextsuche. Dar¨ uber hinaus gibt es noch eine Art Workflow (Lifecycle genannt) und die M¨ oglichkeit, Benachrichtigungen zu bekommen. Eine komplette Unterst¨ utzung f¨ ur alle Anwendungsgebiete ist damit nicht gegeben. Ein relativ großer Bereich wird aber sehr wohl abgedeckt. Insbesondere wenn man sich die Alternativen ansieht, ist die vorgestellte Lösung relativ attraktiv und mit XOOPS in eine denkbare CMS Lösung integriert. Insgesamt kann man sagen, dass XOOPS sich noch einmal als interessante mittlere L¨ osung pr¨ asentiert. Damit ist es bei einem Schwerpunkt auf CMS und DMS mit mittleren Anforderungen ein sehr interessantes System. Zusätzlich ist es auch als Portall¨ osung“ relativ einfach, weitere Funktionen zu in” tegrieren, soweit diese nicht schon vorhanden sind. Eine tiefe Integration ist nat¨ urlich im Einzelfall trotzdem zu analysieren. Dabei sollte man auch nicht vergessen, dass zwei Integrationskonzepte eventuell nicht zusammenpassen. Gleichzeitig k¨ onnte XOOPS insbesondere bei vorhandener Groupware eine relativ billige“ L¨ osung sein, die einen großen Bereich abdecken kann. ” CMS Systeme im Allgemeinen Bis auf XOOPS gibt es keine n¨ ahere Analyse der CMS Systeme. Dahinter steht keine Abwertung der anderen Produkte. Gleichzeitig gibt es aber auch kein

176


zweites System mit einem guten Grundkonzept, wo ein relativ eng integriertes Modul f¨ ur DMS Funktionen existiert. Was man im Prinzip in jedem besseren CMS System machen kann, ist alle Mitarbeiter als Redakteure zu definieren und die Dokumente mit den Mitteln eines CMS zu verwalten. Dazu gibt es eine ganz wichtige Voraussetzung in der Form von ACLs f¨ ur den Zugriffsschutz. Damit scheidet knapp die Hälfte der PHP Systeme als ungeeignet aus. Was die anderen CMS Systeme betrifft, illustriert eine grobe Analyse die wichtigsten Punkte. Bis zu einem gewissen Grad handelt es sich bei der Verwendung von CMS Funktionen f¨ ur DMS Zwecke um einen Missbrauch“. Das braucht einen als ” Anwender nicht weiter zu beunruhigen, hat aber gewissen Konsequenzen: • • • •

Das Benutzerinterface“ ist zum einen die Administrationssicht und zum ” anderen das Intranet (beziehungsweise Extranet oder der Webauftritt der Organisation) Die Strukturierungsm¨ oglichkeiten sind dementsprechend teilweise suboptimal W¨ ahrend Versionierung typischerweise vorhanden ist, fehlt Check-in/out meistens Suchm¨ oglichkeiten sind zum Teil eingeschr¨ ankt (virtuelle Ordner oder ähnliches sind typischerweise nicht vorhanden)

Gleichzeitig ist zum Beispiel ein gut durchdachter Workflow eines CMS Systems durchaus f¨ ur DMS Zwecke benutzbar. Kurz gesagt sollte einem bei Verwendung eines CMS Systems f¨ ur DMS Zwecke bewusst sein, dass man mit gewissen Einschränkungen leben muss. Diese sind nat¨ urlich je nach CMS System unterschiedlich und das muss im Lichte der konkreten Anforderungen einer Organisation betrachtet werden. Die entsprechende Schlussfolgerung kann man aber auch anders formulieren: Je kleiner die Anwendungsgebiete von DMS Funktionen ausfallen und je flexibler und umfassender die Unterst¨ utzung des CMS Systems ist, desto eher macht es Sinn das CMS System zu nutzen. Zusammenfassung Die Analyse der DMS Systeme beziehungsweise von anderen Systemen mit DMS Funktionen zeigt, dass es praktisch kein System gibt, das uneingeschr¨ ankt empfehlenswert ist. Selbst bei den besseren Systemen sollte man immer genau analysieren, ob die L¨ osung auch mittelfristig sinnvoll ist. Zuerst geht es in der Betrachtung um die reinen“ DMS Systeme. Danach um die ” ebenfalls analysierten anderen Vertreter. Bei den PHP Systemen erscheinen vor allem KnowledgeTree und mit Einschr¨ ankungen OWL als geeignet. Beide bieten relativ viele Funktionen und sollten sich zumindest lose an vorhandene Systeme koppeln lassen. Nennenswert sind auch noch die drei Java Systeme, die gleichzeitig die einzigen Client/Server L¨ osungen sind. Bei Paper Harbour sind allerdings Zweifel an den


177

Integrationsm¨ oglichkeiten angebracht. Auf der anderen Seite bieten xincoDMS und jLibrary zwar schon eine Reihe an interessanten Funktionen sind aber noch recht jung“ und die Zukunft scheint jeweils an sehr wenigen Per” sonen zu h¨ angen. Daher gibt es keine wirkliche Empfehlung im Java Bereich sondern die Aufforderung sich bei einer konkreten Analyse insbesondere den aktuellen Stand von xinco-DMS und jLibrary anzuschauen. Man sollte bei Java Systemen auch auf den schon erw¨ ahnten Standard JSR-170 (auch vom JBOSS Portal angeboten) f¨ ur die Ablage versionierter Dokumente in Bibliotheken (Repositories) oder sogar den Nachfolger JSR-283 mit Erweiterungen ¨ etwa in Bezug auf Systemadministration und Uberwachung achten. Je mehr solcher Standards man sinnvoll verwenden kann, desto einfacher sollte die Integration werden und desto problemloser“ sollte sich die Zukunft des KM ” Systems gestalten. N¨ aher betrachtet wurden auch OpenGroupware und XOOPS. Beide bieten neben ihrer jeweiligen prim¨ aren Funktion noch DMS Aspekte an. Bei OpenGroupware ist die Basis abgedeckt, w¨ ahrend XOOPS sogar ein leicht u ¨ berdurchschnittliches DMS System bietet (besonders wichtig ist dabei die Volltextsuche). Je nach der Eignung von OpenGroupware als Groupware System beziehungsweise XOOPS als CMS System könnten die DMS Funktionen hier eventuell den Ausschlag f¨ ur eine Entscheidung geben. Als Letztes wurden noch CMS Systeme im Allgemeinen betrachtet. Soweit sie ACL Zugriffsschutz bieten, sind sie fast zwangsläufig als kleines DMS System geeignet. Ob man sich darauf einlassen will, hängt einerseits von der mittelfristigen Strategie und andererseits auch stark von organisatorischen ¨ Uberlegungen ab. Je eher man großen Wert auf umfassende DMS Funktionen legt, desto eher wird so eine L¨ osung nicht in Frage kommen. Auch organisatorisch kann die Vermischung des Intra-/Internets mit dem DMS System zu Schwierigkeiten f¨ uhren, die man sich vorher u ¨ berlegt haben sollte. Wichtig ist vor allem daran zu denken, wie ein möglichst kohärentes KM System mit m¨ oglichst vielen f¨ ur die Organisation sinnvollen Funktionen entstehen kann. Dazu wird man am besten ein Reihe von Varianten durchrechnen und in Hinblick auf m¨ ogliche Arbeitsabl¨ aufe und Funktionen analysieren. Die Wichtigkeit dieses Aspekts sollte nach der Beschreibung einer Groupware Lösung, die danach um CMS und weiters um DMS Funktionen erweitert wird, offensichtlich sein. 7.3.7 Umsetzung Nach der Diskussion der m¨ oglichen Systeme oder auch Systemkategorien ist vor allem noch eine Diskussion der Umsetzung ausständig. Einiges wurde schon ganz oder teilweise diskutiert (etwa anhand eines speziellen Falles). Eine Reihe von weiteren Punkten muss aber noch zu ihrem Recht kommen.

178


Systemwahl Wie auch schon f¨ ur CMS Systeme beschrieben, sollte man bei einer Entscheidung f¨ ur ein DMS System mitber¨ ucksichtigen, wie beliebt“ es ist und wie lan” ge es schon existiert. Damit bekommt man Anhaltspunkte, ob ein bestimmtes System eine sichere Wahl ist oder an Zweifel an seiner Zukunft angebracht sind. Auch geplante Erweiterungen – am besten mit einem Blick wie lange so etwas in der Vergangenheit gedauert hat – k¨ onnen bei der Einschätzung eines Systems helfen. An sich sind diese Aspekte u ¨berwiegend nichtfunktional. Sie sind leider auch sehr schwer fassbar. Gleichzeitig sollte man sich nicht um eine zumindest grobe Analyse dieser Aspekte dr¨ ucken“. Sonst besteht die große Gefahr, mit ” einer kaum genutzten L¨ osung in eine Sackgasse zu geraten. (Gerade anhand dieser Problematik wird h¨ aufig argumentiert, dass man mit kommerziellen Lösungen besser bedient ist. Wenn man aber zur¨ uckdenkt, treffen eigentlich fast dieselben Kriterien zu. Systeme mit einer kleinen Anwenderschar hatten immer wieder Problem zu u ¨ berleben. Solche mit einer großen Anwenderzahl finden im schlimmsten Fall einen Hersteller, der das Produkt fortf¨ uhrt.) Technische Aspekte Wie schon kurz angedeutet, wird die Komplexität der technischen Aspekte nat¨ urlich gr¨ oßer je mehr Systeme (beziehungsweise Systemteile) im Spiel sind. Insbesondere, wenn man an eine Integration von drei unabhängigen Systemen f¨ ur die Bereiche Groupware, CMS und DMS denkt, muss man besondere Vorsicht walten lassen. Es wurde schon wiederholt auf die zentrale Rolle eines KM Systems hingewiesen. Jede Instabilit¨ at gef¨ ahrdet einerseits den Erfolg der KM Initiative und in weiterer Folge sogar die Existenz der Organisation selbst. Daher muss man versuchen, eine robuste L¨ osung zu schaffen. Das ist bei einer m¨ oglichst homogenen L¨ osung am einfachsten. Aber auch mit vielen Systembestandteilen kann man f¨ ur eine gewisse Redundanz sorgen. Einerseits um einen st¨ orungslosen Betrieb w¨ ahrend eines (Teil-)Ausfalls zu garantieren. Andererseits um einen eingeschr¨ ankten Betrieb bei dem kompletten Ausfall von Systemteilen sicherzustellen. Ganz klar geht es hier um die Frage der Programmiersprache, die Anzahl der beteiligten Systeme und ihrer Kopplung aber auch um Fragen der Systembetreuung, Wartbarkeit und des Betriebs. Auch die Erweiterbarkeit sollte ¨ ber¨ ucksichtigt werden, um bei Anderungern, die sich in der Lösung widerspiegeln sollen, flexibel zu bleiben. Die besprochenen Aspekte sind besonders problematisch, wenn eine Lösung zum Teil aus vorhandenen (eventuell kommerziellen) Systemen besteht. Man kennt dann n¨ amlich die Schw¨ achen dieser Systeme, kann aber in vielen Fällen nur Workarounds“ f¨ ur Probleme finden. Daher ist ein insgesamt stabiles und ” redundantes“ System in so einem Fall (wie auch bei einer besonders inhomo” genen, neuen L¨ osung) besonders schwer zu erreichen.


179

Organisatorische Aspekte Generell kann man bei der Einf¨ uhrung eines DMS Systems mit einer entsprechenden Vertrautheit der Mitarbeiter einer Organisation im Umgang mit EDV-Systemen rechnen. Schließlich sollte ja schon ein Groupware und/oder CMS System im Einsatz sein. Schwierig k¨ onnte es werden, vorhandene Gewohnheiten im Umgang mit Dokumenten zu ¨ andern. In vielen Organisationen findet sich das meiste auf (potenziell lokalen) Festplatten und in E-Mails. Ausgesuchte Dokumente haben vielleicht noch weitere Speicherorte (nat¨ urlich ohne Versionsverwaltung). Diese Art des Umgangs mit Dokumenten ist nat¨ urlich extrem flexibel. Gleichzeitig verhindert sie aber effiziente Abläufe, da immer unklar ist, wer eigentlich womit arbeitet. Der ja schon vorgestellte Weg der Einbindung von betroffenen Mitarbeitern bekommt hier besondere Bedeutung. Einerseits um festzustellen, was es u ¨ berhaupt an relevanten Dokumenten gibt. Andererseits um effiziente und doch noch flexible neue Arbeitsabl¨ aufe zu finden. Im Zusammenhang mit den anderen Teilen des KM Systems m¨ usste es eigentlich relativ einfach sein, prinzipielle Vorteile aufzuzeigen. Man sollte aber auch in der Lage sein, ganz praktische Vorteile zu finden und entsprechend zu kommunizieren. In der Folge muss klar sein, was mit welchen Dokumenten zu geschehen hat. Besonders wichtig ist dabei die Unterscheidung in wichtige und weniger relevante Dokumente, die dann nicht denselben strengen“ Regeln unterliegen m¨ ussen. ” Zusammenfassung Der letzte Abschnitt dieses Kapitels besch¨ aftigt sich mit Umsetzungsfragen. Zuerst geht es um die Frage der Systemwahl. Hierbei sollte man neben den in den vorangegangenen Abschnitten beschriebenen Aspekten auch noch die mittelfristige Tauglichkeit der potenziellen L¨ osungen f¨ ur DMS Funktionen analysieren. Dabei geht es prim¨ ar um die Frage, ob das gewählte System eine sinnvolle Weiterentwicklung und Betreuung haben wird. Weiters gibt es auch eine Reihe von technischen Punkten, die man nicht vernachl¨ assigen sollte. Wichtig ist dabei das Faktum, das es sich inzwischen um potenziell drei unterschiedliche Systeme mit ihren Teilsystemen handelt, ¨ die das KM System ausmachen. Daraus folgt, dass man sich Uberlegungen u allen machen muss. Auch ist es notwendig zu ¨ ber den Betrieb bei Teilausf¨ bedenken, wie man die Systeme einf¨ uhren, betreuen und erweitern kann. Hier geht es zum Beispiel um die Frage der Programmiersprache. Der letzte große Punkt besch¨ aftigt sich mit organisatorischen Aspekten. Ein DMS System hat hier eine potenziell sehr schwierige Ausgangsbasis, da die Handhabung von Dokumenten auf alle m¨ oglichen Arten erfolgen und noch dazu sehr unterschiedlich sein kann. Daher ist die erfolgreiche Einbindung von zuk¨ unftigen Anwendern in die Definition des Systems und den resultierenden Arbeitsabl¨ aufen besonders wichtig.

8 Weiterer Ausbau

Die letzten drei Kapitel haben aufgezeigt, wie man mit Groupware, CMS und DMS Systemen ein mehr oder weniger konsistentes KM System aufbauen kann. Dabei wurde auch immer wieder auf den größeren Rahmen verwiesen. Dieser wurde theoretisch in Kapitel 2 n¨ aher erläutert. Praktisch wurden schon in Kapitel 3 neben den gerade genannten Kategorien weitere wichtige Open Source Produkte beschrieben und zum Teil analysiert. Was die technische Basis und allgemeine Fragen angeht, hat auch schon Kapitel 4 einen breiten Fokus. Im aktuellen Kapitel geht es jetzt um die Frage der Erweiterung eines KM Systems, dass als Annahme aus einer Groupware, einem CMS und einem DMS System beziehungsweise entsprechenden Funktionalitäten besteht. In diesem Zusammenhang ist es wichtig zu verstehen, dass eine solche Erweiterung nicht zwangsl¨ aufig eine gute Idee ist. Gleichzeitig benötigt man f¨ ur eine umfassende KM Initiative und ein m¨ achtiges KM System auch ein wirklich umfassendes IT System. Daraus folgt, dass der Inhalt dieses Kapitels aus mehreren Sichtweisen heraus besonders wichtig ist: • • • •

F¨ ur umfassende KM Initiativen, wo man diese Aspekte auch relativ schnell realisieren will. F¨ ur ambitionierte KM Initiativen, die entsprechende Erweiterungen zumindest schon mitplanen wollen. F¨ ur KM Initiativen mit mittlerem Umfang: Um festzustellen, woran man bei prinzipiellen Entscheidungen denken sollte, damit man sich keine M¨ oglichkeiten verbaut. Aus generellem Interesse und als Hintergrundinformation f¨ ur KM Initiativen und Bestrebungen aller Art und Gr¨ oße.

Kurz gesagt ist der Inhalt dieses Kapitels f¨ ur ambitionierte Leser und/oder KM Initiativen sehr wichtig. Soweit man sich nur um eine kleinere KM Initiative k¨ ummern möchte, sind die Themen relativ weit von der zu erwartenden Praxis entfernt.

182

8 Weiterer Ausbau

Ein wichtiger Aspekt ist noch, dass es f¨ ur einige der untersuchten Kategorien viel weniger und auch viel weniger ausgereifte Unterst¨ utzung als bei den bisher betrachteten Produktkategorien gibt. Das trifft keineswegs nur Open Source Produkte. Allerdings ist eine Weiterentwicklung in den komplexeren Gebieten weniger schnell als bei kommerziellen Anbietern zu erwarten, die zum Teil gr¨ oßere Investitionen in neue M¨ arkte tätigen. Praktisch betrachtet ist das auch der Grund f¨ ur die Zusammenfassung einer Reihe von Themen in diesem Kapitel, die teilweise recht unterschiedliche Zielrichtungen und Anwendungen haben. Manche sind aber auch durchaus verwandt wie insbesondere die Themen Topic Maps, Ontologien und das Semantic Web. Wobei man in die Verwandtschaft auch nicht zu viel hineininterpretieren sollte. Nach diesen drei Themen geht es um weniger junge Technologien, nämlich die Integration von Drittsystemen/Datenquellen und Workflowunterst¨ utzung. Darauf folgt ein kurzer Abschnitt zur Frage von eLearning im Kontext eines KM Systems. Als Abschluss geht es danach um die Nutzbarmachung der gesammelten Datenquellen und Informationen. Es handelt sich dabei um eine m¨ oglichst praxisnahe Behandlung, die aber gleichzeitig aufgrund der Heterogenit¨ at von verschiedenen echten KM Systemen nur eingeschränkt konkrete Antworten liefern kann.

8.1 Einbeziehung von Topic Maps Aktuell werden Topic Maps und noch st¨ arker Ontologien als Lösung von vielen KM Problemen angesehen. Es spricht auch einiges f¨ ur diese Sichtweise. Gleichzeitig gibt es eine ganze Reihe von theoretischen und praktischen Problemen, die einer unmittelbaren Anwendung im Weg stehen. Anders gesagt kann man diese Entwicklungen mitverfolgen und praktische Ergebnisse integrieren. Zu viel sollte man allerdings nicht erwarten und eine gewisse Skepsis bewahren, wenn von einem Durchbruch die Rede ist. Einerseits sind Taxonomien und Ontologien ein eigenes Thema. Andererseits gibt es eine starke Analogie zwischen Ontologien und Topic Maps. Daher wird der n¨ achste Abschnitt sich einmal mit Taxonomien und Ontologien befassen. Darauf aufbauend sollte es leichter sein, die Konzepte und Probleme von Topic Maps zu verstehen. 8.1.1 Taxonomien und Onotologien Beide Begriffe wurden schon kurz in Kapitel 3 vorgestellt. Die folgenden Definitionen sollen das Verst¨ andnis f¨ ur diese beiden Punkte vertiefen: Taxonomie: Im engeren Sinn ist eine Taxonomie eine Einteilung von Tierund Pflanzenarten. Im Kontext von KM und KM Systemen geht es um eine Einteilung von Dingen, ein Klassifikationssystem. Als Ergebnis hat

8.1 Einbeziehung von Topic Maps

183

¨ man eine Hierarchie von Begriffen wie etwa Säugetier als Uberbegriff f¨ ur Katze. Ontologie: Der Begriff Ontologie an sich ist aus dem 19. Jahrhundert (ontos f¨ ur das Sein und logos f¨ ur das Wort) und wurde von den deutschen Philosophen eingef¨ uhrt. Traditionellerweise geht diese Art der Klassifizierung auf die Griechen zur¨ uck; im Speziellen auf die 10 prinzipiellen Kategorien von Aristoteles. Kurz gesagt ist eine Ontologie eine hierarchische Ordnung von Begriffen zusammen mit der jeweiligen semantischen Bedeutung (genau diese fehlt bei der Taxonomie) und oft auch Beziehungen. Damit gibt ¨ es Uberund Unterbegriffe und jeweils eine exakte Bedeutung. Ein ganz einfaches Beispiel ist etwa f¨ ur die Begriffe hat“, Peter als Mensch“ und ” ” Katze“: Peter hat eine Katze“. Damit ergibt sich etwa als Folgerung, ” ” dass Peter ein S¨ augetier hat. Zus¨ atzlich liefert die Ontologie auch zu den Begriffen Mensch“, Katze“ und S¨ augetier“ deren semantische Bedeu” ” ” tung. Linguistische versus formale Ontologie: In manchen Fällen ist es auch noch wichtig zu wissen, welche unterschiedlichen Arten von Ontologien existieren. Dabei gibt es keine allgemein benutzten und anerkannten Begriffe aber doch zwei besonders relevante Ausprägungen. Im Fall von formalen Ontologien ist bekannt, welche Begriffe disjunkt sind und es wird zwischen Typen und Rollen unterschieden. Dies ist bei linguistischen Ontologien nicht der Fall. Man sollte solche Differenzen dabei weder u ¨ berbewerten noch ignorieren sondern je nach Aufgabenstellung und konkreter Anforderung darauf eingehen. F¨ ur den Praktiker stellt sich damit die Frage, was Taxonomien und Ontologien jetzt wirklich und in welcher Weise leisten können. Als Antwort gibt es einerseits schon existierende Anwendungen wie etwa eine Verbesserung von Suchm¨ oglichkeiten durch das Anbieten und/oder die Verwendung einer immer aktuellen Taxonomie. Andererseits kann ein Computer semantische Informationen in Form einer Ontologie benutzen, um den Anschein von Intelligenz zu erwecken. Hier geht es etwa um Schlussfolgerungen aufgrund vorhandener Informationen, die erst durch die semantischen Daten möglich gemacht werden. Wie wir noch sehen werden basiert etwa das Semantic Web auf Ontologien. Bei Ontologien besteht außer in Spezialf¨ allen im Gegensatz zu Taxonomien keine M¨ oglichkeit einer automatischen Generierung. Gleichzeitig gibt es insbesondere drei hochwertige und zum Teil frei verf¨ ugbare allgemeine Ontologien. Der gr¨ oßte Vertreter mit detaillierten Axiomen und Definitionen f¨ ur jedes Konzept ist dabei Cyc (abgeleitet von Ecyclopedia) und Abbildung 8.1 zeigt den obersten Teil dieser Ontologie. Die anderen beiden Ontologien (EDR und WordNet) sind so genannte linguistische Ontologien. Wichtig ist dabei noch der Hinweis, dass die Grafik zwar eine Ontologie zeigt, aber der Ausschnitt auch eine reine Taxonomie illustrieren könnte da keine semantischen oder Beziehungsinformationen dargestellt werden.

184

8 Weiterer Ausbau

Thing

Individual Object

Intangible

Represented Thing

Stuff

Intangible Object

Collection

Event

Intangible Stuff

Relationship

Abb. 8.1. Oberster Teil der Cyc“-Ontologie ”

Die drei genannten Ontologien sind dabei alle in Englisch und nur eine (EDR) ist auch in Japanisch verf¨ ugbar. Daneben gibt es auch Ontologien in anderen Sprachen wie etwa EuroWordNet mit verschiedenen europäischen Sprachen inklusive Deutsch. Gleichzeitig sind diese nicht annähernd so umfas¨ send und damit weniger relevant. Daher konzentriert sich der folgende Uberblick auf die drei großen Vertreter. Cyc: Die mit fast 200.000 Begriffen und vor allem u ¨ ber einer Million von Axiomen umfassendste Ontologie. Frei verf¨ ugbar als OpenCyc (mit aktuell 47.000 Begriffen; siehe http://www.opencyc.org/). EDR: Das Electronic Dictionary Research“- Projekt in Japan hat u ¨ ber ” 400.000 Konzepte und die jeweilige Abbildung in die englische und japanische Sprache allerdings deutlich weniger Details zu den Konzepten als Cyc. Zu finden unter: http://www2.nict.go.jp/kk/e416/EDR/. WordNet: Prim¨ ar von George Miller und seiner Gruppe wurde WordNet als Hierarchie von u ¨ ber 200.000 Wortformen und Bedeutungspaaren definiert.


185

Obwohl Cyc mehr in die Tiefe geht und EDR mehr Begriffe beinhaltet wird WordNet am h¨ aufigsten verwendet, da es schon lange frei verf¨ ugbar ist (unter: http://wordnet.princeton.edu/). Der komplexen und zum Teil sehr theoretischen Natur von Taxonomien und Ontologien kann ein kurzer Abschnitt in einem Buch leider nicht voll gerecht werden. Daher wird noch auf eine Reihe weiterf¨ uhrender Unterlagen verwiesen. Nennenswert sind etwa Gruber [16] (What is an Ontology) oder Beck und Pinto [3]. Weiters gibt es nat¨ urlich auch eine Reihe von Unterlagen zum Zusammenhang von Ontologien mit Informationssystemen im Allgemeinen oder Knowledge Management im Speziellen. Der Text von Smith [55] besch¨ aftigt sich etwa mit allgemeineren Fragen. Dagegen befasst sich das Buch von Studer et al. [58] explizit mit dem Thema Ontologien und Wissensmanagement. Im Text von Fensel [12] geht es ebenfalls um diesen Zusammenhang und darum, wie e-Commerce davon betroffen ist. In letzter Zeit gibt es eine starke Konzentration im KM Umfeld und auch einigen anderen Bereichen auf Ontologien. Dahinter steht zum Teil die Einsicht, dass die fr¨ uher verfolgten Ans¨ atze nicht zum Ziel f¨ uhren werden. Gleichzeitig gibt es im Forschungsfeld Ontologie noch eine ganze Reihe von grundlegenden Fragen, sodass hier bis zu einem gewissen Grad auf Sand“ gebaut ” wird. Gerade weil es schon eine Reihe von technischen Systemen gibt, muss man hier besonders vorsichtig sein und im Einzelfall die Vor- und Nachteile abw¨ agen. Anders gesagt sind Ontologien ganz sicher ein wichtiger Baustein f¨ ur KM und andere Felder. Gleichzeitig gilt es noch eine Reihe von Problemen zu l¨ osen, bevor man die entsprechenden Technologien uneingeschränkt verwenden kann. 8.1.2 Topic Maps Was sind jetzt konkret die Analogien zwischen Topic Maps und Ontologien? Beide bestehen im Kern aus Begriffen oder Topics und Relationen zwischen diesen Begriffen. Typischerweise wird eine Topic Map auch eine Begriffshierarchie haben, was den Zusammenhang noch deutlicher macht. Das geht soweit, dass man Taxonomien und Ontologien als Topic Maps darstellen kann und sie damit in einem standardisierten Format hat. Das f¨ uhrt uns auch schon zu dem Thema, dass Topic Maps durch einen ISO Standard (Details siehe ISO [22]) definiert sind. Der offensichtlichtste Vorteil davon ist, dass man mit weniger Schwierigkeiten in der praktischen Verwendung k¨ ampfen muss. Der gr¨ oßte Nachteil ist, dass es aktuell noch einige Probleme mit der Verwendung gibt und man eventuell die Wege des Standards verlassen muss, um praktisch etwas damit anfangen zu können. Dabei beruhte die erste Definition des Standards noch auf SGML (Standard Generalized Markup Language: der Vorl¨ aufer von HTML und XML) und nannte sich HyTime. Um der steigenden Bedeutung von XML gerecht zu werden, wurde danach noch eine weitere Variante namens XTM (XML Topic Maps)

186

8 Weiterer Ausbau

spezifiziert. Wichtig und interessant ist auch, dass eines der wichtigsten Motive f¨ ur den Standard eine Abbildung von Buchindexes war und in Analogie ist eine Topic Map unter anderem geeignet, ein oder mehrere Dokumente zu erschließen. Damit ist noch nicht beantwortet, was jetzt eine Topic Map genau ist. Es gibt dabei drei große Bereiche mit ihren Unterbegriffen, die die folgende Beschreibung ganz kurz erl¨ autert: Topic: Im Prinzip ist ein Topic ein Begriff u ¨ ber den man etwas aussagen kann unabh¨ angig von seiner konkreten Existenz oder seinen Charakteristiken. ¨ Es kann etwa der Name einer Stadt wie Wien oder eines Landes wie Osterreich sein. Topic Types: Topic types sind Kategorien und Topics können Instanzen von 0 bis mehreren Topic types sein. Damit hätte Wien den Topic type ¨ Stadt und Osterreich den Topic type Land. Aus Sicht des Standards sind Topic types auch wieder Topics und können damit auch selbst wieder Topic types haben. Das ergibt potenziell eine Begriffshierarchie. Die Unterscheidung zwischen Topic type und Topic ist dabei nicht definiert und muss daher in der Applikation getroffen werden. Topic Names: Ein Topic kann 0 bis mehrere Namen haben etwa zur Abbildung verschiedener Kontexte (eines Namens innerhalb eines Sco” pes“ wie im folgenden Beispiel die Sprachen: Deutsch, Französisch und ¨ Englisch). Damit k¨ onnten weitere Namen des Topics Osterreich etwa Autriche und Austria sein. Occurrence: Jede Ressource, die f¨ ur ein Topic relevant ist, wird als Occurrence dieses Topics betrachtet. Das k¨ onnen im Fall Wien etwa ein Stadtplan und ein Eintrag in einer Enzyklop¨ adie sein. Occurrence Roles: Mit Occurrence roles und den dazu möglichen Occurrence role types kann man den Occurrences“ einen Typ zuordnen ” (etwa Landkarte f¨ ur den Stadtplan). In XTM gibt es nur Occurrence types die dieselbe Bedeutung wie Occurrence role types in HyTime haben. Association: Associations modellieren die Beziehungen zwischen Topics etwa ¨ Wien ist in Osterreich“. ” Association Types: So wie Occurrences Typen haben gibt es auch Association types und im Beispiel w¨ are der Type etwa ist in“ (der ” nat¨ urlich selbst wiederum ein Topic ist). Association Roles: Bei einer Association gibt es zumindest zwei Topics die eine Rolle in dieser Beziehung spielen und die Association role genannt wird (und selbst wieder ein Topic ist). F¨ ur das gegebene Beispiel k¨ onnten die Rollen etwa Ort“ und Land“ sein. ” ” Diese Darstellung orientiert sich dabei grob an einer Beschreibung von Pepper [44] und zeigt anhand eines ganz einfachen Beispiels, was eine Topic Map beinhalten kann. Man sieht auch, dass man Taxonomien und Ontolo-


187

gien mit den vorhandenen Mitteln abbilden kann und damit auch eine reine Verwendung als Austauschstandard m¨ oglich ist. Allgemeine Fragen u ¨ ber den Zusammenhang von KM und Topic Maps können und sollen hier aber nicht im Detail analysiert werden. Stattdessen wird eine Einf¨ uhrung mit ein paar Anhaltspunkten geboten. Wichtig in diesem Zusammenhang sind etwa Autoren die argumentieren, dass Topic Map Software KM erm¨ oglicht oder gar KM Software darstellt. Die Frage ob dieser Anspruch gerechtfertigt ist, soll hier nicht weiter diskutiert werden, da man sich f¨ ur eine sinnvolle Analyse eines Einzelfalls näher mit den Konzepten und M¨ oglichkeiten von Topic Maps besch¨ aftigen muss. Darauf aufbauend kann man sich eigene M¨ oglichkeiten einer Verwendung u ¨ berlegen. Bekannte Forscher in diesem Bereich sind dabei Pepper (siehe zum Beispiel [44] oder [45]) und die dahinterstehende Firma Ontopia oder Rath (siehe zum Beispiel [49]) und die dahinterstehende Firma Empolis. Beide genannten Firmen sind auch unter den wichtigsten Herstellern von Topic Map Software. Sehr wohl wird noch darauf eingegangen was (und auch wie) man praktisch mit Topic Map Software als Erweiterung des vorgeschlagenen KM Systems machen kann und welche Schwierigkeiten es dabei gibt. 8.1.3 Generelle Fragen Was sind also die wichtigsten Aspekte, die man im Hinblick auf Topic Maps und ihren Einsatz in einem KM System beachten sollte? Es beginnt mit der Feststellung, dass es nicht einfach ist, mit Topic Maps zu arbeiten. Dabei geht es weniger um technische Fragen (wobei auch hier mit gröberen Schwierigkeiten zu rechnen ist). F¨ ur eine sinnvolle Verwendung einer Topic Map sollte man dabei eine entsprechende Ontologie (oder zumindest Taxonomie) als Basis verwenden. Schon dieser Aspekt kann eine ziemliche Herausforderung werden und je gr¨ oßer eine Organisation ist, desto unm¨ oglicher wird das sogar. Hier wird man eventuell mit mehreren Begriffswelten arbeiten m¨ ussen. Weiters ist das Erstellen einer Ontologie zumindest aktuell mit sehr viel manueller Arbeit verbunden (Toolunterst¨ utzung ist teilweise gar nicht vorhanden). Um mehrere Ontologien in einer Organisation sinnvoll einsetzen zu können, ben¨ otigt man eine Zuordnung von verschiedenen Begriffen. Hier ist einerseits wieder h¨ aufig Handarbeit gefragt und andererseits gibt es öfter Begriffe, die keine eindeutige Entsprechung haben. Dieses Problem kommt dann noch zu der sowieso schon schwierigen Wartung einer Ontologie hinzu. Ohne entsprechende Zuordnung kann man allerdings wiederum keine entsprechend effektiven, bereichs¨ ubergreifenden“ Suchen realisieren. Alle diese Punkte zusam” mengenommen hat man also folgende Aufgaben vor sich, wenn man Topic Maps auf Basis einer Ontologie verwenden will: • • • •

Zumindest teilweise h¨ andische Definition der Ontologie(n) Schwierige und u ¨ berwiegend manuelle Wartung der Ontologie(n) Problematische Zuordnung von Begriffen mehrerer Ontologien ¨ Wahrung der Zuordnung bei Anderungen in einer Ontologie

188

8 Weiterer Ausbau

Insgesamt also ein potenziell recht aufwendiges Unterfangen mit relativ wenig IT-relevanten Fragen (zumindest im Moment). Weitere Schwierigkeiten von zumindest fr¨ uheren Topic Map Implementierungen zeigt auch die Diplomarbeit von Carlstedt and Nordborg [8] auf. Die Wichtigste ist dabei sicherlich die fehlende Unterst¨ utzung von mehrsprachigen Topic Maps. Hier tritt nat¨ urlich auch noch das Problem der unterschiedlichen Bedeutungen von W¨ ortern in unterschiedlichen Sprachen zutage. Leider gibt es ja selbst zwischen relativ ¨ ahnlichen“ Sprachen wie Deutsch und Englisch häufig ” ¨ Schwierigkeiten, eine 1:1 Ubersetzung zu finden. Andererseits existieren auch Ans¨ atze, Topic Maps in Groupware zu integrieren. Ein Beispiel ist in einem Artikel von Smolnik and Nastansky [56] beschrieben. Angesichts der Probleme, die in der Arbeit von Carlstedt and Nordborg beschrieben werden, scheint der Ansatz aber recht optimistisch zu sein.

Know

Do you know him? I don´t know...

Wissen = Savoir

Kennen = Connâitre

Ich weiß es nicht...

Können Sie Eng lis ch?

Abb. 8.2. Unterschiedliche Sprachen, unterschiedliche Begriffe

Abbildung 8.2 demonstriert eines der prinzipiellen Probleme, dass man hat wenn man Topic Maps, Taxonomien oder Ontologien aus verschiedenen Sprachen in Zusammenhang miteinander bringen will. (So wie das Beispiel von Abbildung 8.3 im Internet unter http://www.jfsowa.com/ontology/ontoshar. htm zu finden.) Das Wort Know“ aus dem Englischen findet keine hundert” ¨ prozentige Ubersetzung ins Deutsche oder das Französische. Dort gibt es zwei Begriffe ( Kennen“ und Wissen“), die zusammen die volle Bedeutung dieses ” ” englischen Wortes abdecken. Schon ein Mensch wird manchmal Schwierigkeiten haben, solche subtilen Unterschiede in einer Fremdsprache zu erkennen.


189

Ein Computer hat aktuell keine Chance außer man macht diese Aspekte explizit und als Information verf¨ ugbar. Aber auch dieser Ansatz kann nicht alles abdecken, weil die menschliche Verwendung der Sprache einfach zu vielseitig und bis zu einem gewissen Grad auch unvorhersehbar ist.

Ellipse

Kreis

Kreis

Ellipse

Abb. 8.3. Unterschiedliche Begriffshierarchien

Ein weiteres in Abbildung 8.3 illustriertes prinzipielles Problem von Begriffshierarchien ist, dass selbst in einer Sprache eine umgekehrte Beziehung von zwei Begriffen sinnvoll sein kann. Im allgemeinen Sprachgebrauch wird man davon ausgehen, dass Kreis ein Unterbegriff von Ellipse ist (da ein Kreis als eine Ellipse betrachtet werden kann, bei der beide Achsen zusammenfallen). Wenn es sich dagegen um objekt-orientierte Programmierung handelt, wird meistens Ellipse als Subklasse von Kreis modelliert, da Kreis der grunds¨ atzlichere Datentyp ist. Diesen Widerspruch kann ein Computer nicht aufl¨ osen und das illustriert anhand eines ganz einfachen Beispiels, welche Schwierigkeiten es unweigerlich gibt, wenn man zwei Begriffshierarchien in Beziehung zueinander setzen will. Insgesamt sieht man, dass bei der Verwendung von Topic Maps in größerem Umfang und in gr¨ oßeren Organisationen eine ganze Reihe von Punkten zu beachten ist. Dabei soll mit den aufgezeigten Problemen nicht die prinzipielle Sinnhaftigkeit in Frage gestellt werden, sondern es geht um eine realistische Betrachtungsweise. Wir werden auch noch sehen, dass viele der angesproche-

190

8 Weiterer Ausbau

nen Probleme in ¨ ahnlicher Form bei anderen Technologien eine einfache Verwendung erschweren. Es handelt sich hier um Themengebiete, in denen noch relativ viel Forschung und Bewegung stattfinden. Man kann also durchaus mit deutlichen Verbesserungen der Situation rechnen. Ein wichtiger Punkt ist etwa, dass im Moment viel Arbeit in das Definieren von u ¨ bergreifenden Taxonomien und Ontologien gesteckt wird. Auch die Problematik, möglichst effizient mit unterschiedlichen Ontologien oder Taxonomien umgehen zu können, ist seit einiger Zeit auf der Agenda der Forscher. Unmittelbar muss man allerdings mit relativ hohen initialen und auch laufenden Aufw¨ anden rechnen, wenn man sich daf¨ ur entscheidet Topic Maps (und Ontologien/Taxonomien) einzusetzen. Wenn man also nicht wirklich gute Gr¨ unde hat, auf dieser Technologie aufzusetzen, wird man eine Einf¨ uhrung zum aktuellen Zeitpunkt nur schwer rechtfertigen können. Etwas besser sieht die Situation nur aus, wenn man im Großen und Ganzen mit einer einzelnen Ontologie oder Taxonomie das Auslangen findet (zum Beispiel in kleineren Organisationen). Wenn man dann noch eine extern Definierte u ¨bernehmen kann, wird die Sache f¨ ur eine mittlere bis gr¨ oßere KM-Initiative interessant. Gelingt es n¨ amlich eine entsprechende Ontologie oder Taxonomie f¨ ur ein KM System zu schaffen, k¨ onnen eine Reihe von Funktionen bessere Resultate ¨ liefern. So ist zum Beispiel eine Ahnlichkeit von Dokumenten untereinander oder eine Relevanz f¨ ur eine bestimmte Suche viel leichter auf so einer Basis zu erkennen“. Außerdem bietet eine Topic Map eine weitere Art der Navigation ” durch die vorhandenen Dokumente und Informationen. Eine interessante L¨ osung existiert zum Beispiel von IBM/Lotus. Hier gibt es die M¨ oglichkeit, sich eine Taxonomie automatisch generieren zu lassen. Weiters kann das System diese auch aktuell halten und nutzt sie nat¨ urlich, um entsprechenden Mehrwert anzubieten. Leider kennt der Autor aktuell keine vergleichbare Funktionalit¨ at im Open Source Umfeld. Dar¨ uber hinaus hat man trotzdem einige der weiter oben beschriebenen Probleme. Allerdings zeigt das Beispiel, wie effektiver Mehrwert durch die Verwendung von Topic Maps geboten werden k¨ onnte (der konkrete Fall kommt soweit bekannt ohne Topic Map Standard aus). Damit ist vor allem eines klar: Man sollte sich vor einer Verwendung von Topic Maps (und implizit einer Taxonomie, Ontologie oder etwas ähnlichem) gut u ¨ berlegen, wie das KM System davon profitieren kann. Einerseits kann man damit eine ganze Reihe von KM-relevanten“ Funktionen unterst¨ utzen. ” Andererseits hat man damit sicher sehr viel Arbeit und auch eine technische Umsetzung kostet Einiges. 8.1.4 Vorhandene Open Source Basis Wie schon angedeutet, gibt es f¨ ur Topic Maps wenig Open Source Software. aß, da der Standard Weiters handelt es sich um junge Produkte (naturgem¨ auch noch verh¨ altnism¨ aßig neu ist), bei denen gleichzeitig in letzter Zeit relativ wenig Aktivit¨ at zu beobachten ist. Das ist unter anderem auf die Probleme


191

bei einem praktischen Einsatz und den aktuellen Fokus auf das Semantic Web (siehe Abschnitt 8.2) zur¨ uckzuf¨ uhren. Daher möchte dieser Abschnitt nur ¨ einen groben Uberblick u ¨ber aktuell vorhandene Systeme und eine ungefähre Idee u oglichkeiten und Funktionen geben. ¨ ber die M¨ TM4J Topic Maps 4 Java (TM4J) ist ein Toolkit, mit dem man Topic Maps speichern, laden, verwenden und auch bearbeiten kann. Schwerpunkt dieses Systems ist die TM4J Engine, die den Import von XTM beziehungsweise LTM (Linear Topic Map – eine simple Textnotation f¨ ur eine Topic Map) formatierten Topic Maps erm¨ oglicht. Zum Abrufen“ der Informationen gibt es weiters ” die Tolog (eine Abfragesprache f¨ ur Topic Maps, die von der Firma Ontopia entwickelt wurde) Sprache. Das Abspeichern erfolgt dann in einer Datenbank (viele getestet). Angeboten wird dabei ein Java API. Erg¨ anzt wird die Engine mit einer Library namens Panckoucke“ zum Er” stellen von Graphen aus Topic Maps. Dabei geht es darum, aus einer Topic Map eine f¨ ur andere Applikationen gut verwendbare Struktur zu generieren. Die wichtigsten Vertreter“ sind dabei Java Datenstrukturen und XML Re” präsentationen. Daneben gibt es eine Java Swing Anwendung zum Begutachten einer Topic Map in grafischer (hierarchischer) Form. Weiters ist geplant, auch das Erstellen und Ver¨ andern von Topic Maps zu ermöglichen. In Richtung einer unmittelbaren Anwendung geht TM4Web. Hier ist der Fokus eine Integration der TM4J Engine in Frameworks von Web-Applikationen. Die beiden wichtigsten Beispiele sind dabei Apaches Cocoon sowie Struts. Nat¨ urlich ist das gesamte Toolkit in Java geschrieben. Als Lizenz verwendet es die APL und erf¨ ullt damit alle Anspr¨ uche an Open Source Software. Weitere (und immer aktuelle) Informationen findet man unter der URL http://www.tm4j.org/. Insgesamt das vielleicht am weitesten entwickelte Open Source Produkt zur Unterst¨ utzung von Topic Maps. Allerdings scheint die Weiterentwicklung nur noch z¨ ogerlich zu verlaufen (2005 und Anfang 2006 gab es nur wenig Aktivit¨ at). Trotzdem ist es durch die Verwendung von Java und dem Fokus auf Integrierbarkeit f¨ ur gr¨ oßere Systeme prinzipiell gut geeignet. SemanText Bei SemanText handelt es sich um eine Software, die auf einer Topic Map aufbauend eine Art KM L¨ osung realisiert hat. Die Knoten der Topic Map stellen Themen dar und die Verbindungen dazwischen sind Zusammenhänge. Aufgrund der hierarchischen Beziehungen kann man auch Schlussfolgerungen durch den Computer ziehen lassen. Damit ist es möglich automatisch weitere Informationen zu der Datenbasis hinzuf¨ ugen. Eine wichtige Funktion stellt auch das Extrahieren von Themen und Beziehungen aus strukturiertem Text wie etwa aus XML oder RDF Dateien dar.

192

8 Weiterer Ausbau

Zus¨ atzlich gibt es die M¨ oglichkeit, Fließtext in einer ähnlichen Art und Weise zu importieren“. ” SemanText ist eine Python Anwendung und unterliegt der GPL Lizenz. Es wird u ¨berwiegend durch Eric Freese entwickelt und betreut. Weitere Informationen findet man unter http://www.semantext.com/. Kurz gesagt ist SemanText eine interessante kleine Anwendung. Eventuell kann man das System sogar als standalone“ Erweiterung eines KM Systems ” nutzen, um f¨ ur einzelne Benutzer oder f¨ ur bestimmte Fragestellungen mit einer Art semantischem Netz arbeiten zu k¨ onnen. Zumindest eine oberflächliche Integration in ein Portal w¨ are eine weitere Denkvariante. Bei einer engen Integration muss man aber mit einigem Aufwand rechnen und auch bedenken, dass es seit 2001 kaum Projektaktivit¨ aten gibt (womit vor allem ein Einsatz als standalone“ Erweiterung sinnvoll erscheint). ” tmproc Bei tmproc handelt es sich um eine im Source verf¨ ugbare und teilweise freie Topic Map Implementierung von Ontopia. An Funktionen bietet es primär einmal den Import, Export, die Abfrage und die Manipulation von Topic Maps. F¨ ur diese Funktionen gibt es klare und sauber definierte Schnittstellen. Dar¨ uber hinaus werden noch verschiedene Transformationen sowie Druckm¨ oglichkeiten angeboten. Weiters gibt es auch noch ein Kommandozeilentool f¨ ur die Ansicht einer Topic Map. Im Prinzip also eine Demonstration“ was Ontopia kann und f¨ ur spezielle ” Einsatzzwecke sicher auch eine interessante Software. Es handelt sich um eine freie Software, solange man nicht selbst ein Produkt mit oder auf tmproc aufbauend verkauft. Damit ist es keine Open Source Software, mag aber im Einzelfall eine interessante Erg¨ anzung eines Open Source KM Systems zu sein. Bedenken sollte man auch noch, dass die letzte Version aus dem Jahr 2000 ¨ stammt und man Anderungen vermutlich in Eigenregie“ durchf¨ uhren m¨ usste. ” Als Programmiersprache wird Python verwendet. Nähere Informationen findet man unter http://www.ontopia.net/software/tmproc/. Weitere Systeme/Punkte Eine weitere Java basierte Topic Map Software ist Nexist. Hierbei handelt es sich um ein Open Source Projekt, das eine Referenzimplementierung f¨ ur Topic Maps sein will. Allerdings gibt es seit J¨ anner 2002 keine Entwicklungsaktivit¨ aten mehr. Daher kann man von einer Verwendung dieser Software (f¨ ur eine Integration) nur abraten. Wer trotzdem einen näheren Blick darauf werfen will, findet das Projekt unter: http://nexist.sourceforge.net/. Eine weitere frei verf¨ ugbare Topic Map Software ist TMTab. Allerdings handelt es sich nicht um Open Source, da nur eine Binärversion verf¨ ugbar und freigegeben ist. Prinzipiell ist es ein Plug-in f¨ ur Protégé-2000 (ein Tool zur Erstellung von Ontologien) und erm¨ oglicht einen Export im XTM Format.

8.2 Verwendung von Semantic Web Technologien (OWL, RDF, . . . )

193

Außerdem wurde die aktive Weiterentwicklung Mitte 2004 eingestellt (zumindest f¨ ur den Moment“). Weitere Informationen und das Tool selbst finden ” sich unter: http://www.techquila.com/tmtab.html. Zusammengenommen sieht man, dass relativ wenig Software als Open Source verf¨ ugbar ist. Praktisch betrachtet kommt vor allem TM4J f¨ ur eine enge Integration in ein Java basiertes KM System in Frage. Wobei die geringen Projektativit¨ aten in letzter Zeit ber¨ ucksichtig werden m¨ ussen. Mit SemanText findet man dagegen eine Applikation, die eine Ergänzung eines KM Systems sein beziehungsweise im Einzelfall auch integriert werden könnte. Hier stellt sich vor allem die Frage eines brauchbaren Exports aller Daten des KM Systems, sodass SemanText sie verwerten kann. 8.1.5 Zusammenfassung Die vorangegangenen Diskussionen zeigen, dass das Thema Topic Maps ein relativ komplexes ist und sich auch kaum unabh¨ angig von Taxonomien und/oder Ontologien betrachten l¨ asst. Einerseits versprechen Topic Maps eine Menge von sehr KM-relevanten Funktionen. Andererseits ist es recht schwierig, mit der vorhandenen Basis solche Features umzusetzen. Aktuell kann man auch kaum darauf verzichten, sich mit der dahinterliegenden Theorie näher vertraut zu machen. Dabei stellt man bald fest, dass es eine Reihe von offenen Fragen gibt und sich ein praktischer Einsatz schwie¨ rig gestaltet. Weiters ist sehr viel an Uberlegungsarbeit zu leisten, bevor eine technische Umsetzung Sinn macht. Daher muss man einfach empfehlen, die Technik erst nach einer erfolgreichen Phase an notwendigen Definitionen und ¨ Uberlegungen einzubeziehen. Es macht keinen Sinn u ¨ ber technologische Fragen nachzudenken, solange grunds¨ atzliche Fragen unklar sind. Was die vorhandene Open Source Basis betrifft, gibt es leider nur eine relativ kleine Anzahl an Vertretern. Am interessantesten sind dabei noch TM4J als Java basierte Library und SemanText als Applikation, die vielleicht direkt als Zusatz zu einem KM System Sinn machen könnte. Zusammengefasst kann man sagen, dass es nur ein relativ kleines Angebot gibt und die Aktivitäten eher zur¨ uckgehen. Daher muss ein Einsatz besonders gut u ¨ berlegt werden.

8.2 Verwendung von Semantic Web Technologien (OWL, RDF, . . . ) Eine der aktuell wichtigsten Bestrebungen, die sich mit der Bedeutung von Informationen befasst, ist sicher das Semantic Web. Daraus ergibt sich auch die Bedeutung dieser Initiative f¨ ur KM. Inhaltlich besteht auch eine große Nähe zu Topic Maps, was schon alleine die zentrale Rolle von Ontologien f¨ ur das Semantic Web und die diskutierten Zusammenhänge mit Topic Maps zeigen. Daher stellt die Diskussion von Ontologien im Abschnitt 8.1.1 eine Grundlage f¨ ur den folgenden Text dar.

194

8 Weiterer Ausbau

Eine kurze Darstellung der generellen Idee des Semantic Web hat schon Abschnitt 3.5.3 geliefert (insbesondere auch mit dem Hinweis auf den grundlegenden Artikel von Sir Tim Berners-Lee [4]). Dort wurde auch schon darauf eingegangen, dass die Bedeutung eher in der organisations¨ ubergreifenden Interaktion liegt und ein KM System durchaus andere Möglichkeiten hat. Gleichzeitig wird es sicher Sinn machen, gut funktionierende Semantic Web Technologien innerhalb eines KM Systems einzusetzen, insbesondere bei größeren Organisationen aber auch bei kleineren aus reinen Synergie¨ uberlegungen. Ein besseres Verst¨ andnis der dahinterliegenden Standards, Technologien und der Zusammenh¨ ange mit KM Systemen setzt nat¨ urlich eine entsprechende Analyse und Diskussion voraus, die die n¨ achsten beiden Abschnitte bieten. 8.2.1 Semantic Web Standards Wie alle neueren Standards des W3C (so wie etwa auch die aktuelle Topic Map Syntax XTM) basiert das Semantic Web auf XML zum Transport der Daten. In diesem Zusammenhang gibt es vor allem zwei Standards, die entsprechende XML Dokumente beschreiben. Einerseits handelt es sich dabei um RDF und andererseits um die OWL (die selbst wiederum auf DAML+OIL beruht): RDF: Steht f¨ ur Resource Description Framework und ist im Kern ein flexibler und erweiterbarer Mechanismus zur Repräsentation von Metadaten (etwa von Webseiten die neben der Adresse auch einen Titel und einen Autor extra ausgezeichnet haben). Weiters gibt es im RDF Datenmodell die M¨ oglichkeit Zusammenh¨ ange in Trippeln von jeweils einem Subjekt, Pr¨ adikat und Objekt auszudr¨ ucken etwa kann ein Dorf (Subjekt) als Begriff eine Unterklasse (das Prädikat) von Siedlung sein (das Subjekt). Weitere Informationen findet man zum Beispiel unter: http://www.w3.org/RDF/. Typischerweise wird RDF in XML abgebildet, es gibt aber auch die von Sir Tim Berners-Lee entworfene wesentlich kompaktere Notation 3 (N3). Ein weiterer Standard in diesem Zusammenhang ist RDF-Schema (abgek¨ urzt RDFS), der es wie die OWL ermöglicht Taxonomien und Ontologien in RDF zu repräsentieren. Da er aber wesentlich weniger m¨ achtig als die OWL ist und auch nicht im Zentrum des Interesses steht, wird er nicht weiter betrachtet. OWL: Steht f¨ ur Web Ontology Language und definiert, wie eine Ontologie f¨ ur das Semantic Web aussehen muss, damit sie erstellt, publiziert und verteilt werden kann (wie auch der Topic Map Standard XTM). Technisch basiert die OWL auf der RDF Syntax und historisch ist sie aus dem DAML+OIL Standard abgeleitet. Eine technische Beschreibung findet sich etwa unter: http://www.w3.org/TR/owl-features und eine Einf¨ uhrung in die OWL bietet der Text von Costello und Jacobs [9]. Um die unterschiedlichen Einsatzzwecke der OWL ad¨ aquat abdecken zu können, gibt es drei unterschiedlich m¨ achtige Ausformungen:


195

OWL Lite: Eine vereinfachte Untermenge des kompletten Standards, vor allem f¨ ur die Beschreibung einfacher Taxonomien und Ontologien mit relativ wenigen und einfachen Axiomen gedacht. OWL DL: Die OWL Variante, die noch am meisten der Definition und M¨ achtigkeit von DAML+OIL entspricht. DL steht dabei f¨ ur Description Logic und stellt eine sogenannte entscheidbare Prädikatenlogik erster Stufe dar. Praktisch betrachtet wurden gegen¨ uber DAML+OIL einige Einschr¨ ankungen vorgenommen, um gewisse Algorithmen und Techniken anwenden zu k¨ onnen. OWL Full: Ist fast wie OWL DL nur ohne die dort getroffenen Einschr¨ ankungen. Damit ist es m¨ oglich kompliziertere Sachverhalte abzubilden, kann aber gleichzeitig nicht mehr garantiert werden, dass bestimmte Fragen“ eine Antwort haben. ” Daneben sind auch noch die historischen Vorfahren“ von OWL f¨ ur das ” Verst¨ andnis interessant: OIL: Bei dem Ontology Reference Layer“ oder der Ontology Inter” ” change Language“ handelt es sich um eine Definition von Ontologien auf der Description Logic (DL) basierend. Diese Arbeit floss u ¨ berwiegend in DAML+OIL und zum Teil auch direkt in die OWL ein. Die Webseite http://www.ontoknowledge.org/oil/ bietet weitere Informationen zu diesem Thema. DAML+OIL: DAML steht f¨ ur DARPA Agent Markup Language und f¨ uhrte zur DAML+OIL Auszeichnungssprache. Sie basiert wie die OWL auf dem RDF Standard und ermöglicht die Abbildung einer Ontologie. Bis zu einem gewissen Grad wird die Arbeit an DAML+OIL parallel zu der OWL fortgef¨ uhrt, wobei auf letzterer wesentlich mehr Aufmerksamkeit ruht. Auf http://www.daml.org/ findet man weitere Details zu diesem Standard. Man sieht, dass schon die Beschreibung der wichtigsten Standards des Semantic Web eine große Komplexit¨ at aufzeigt. Ein Hintergrund ist dabei, dass eine Sprache die sehr flexibel und m¨ achtig ist auf der anderen Seite kaum automatische Schl¨ usse zul¨ asst und ein Computer nur wenig tun kann. In Folge muss man sich relativ formalistischer Methoden bedienen, um echte Schlussfolgerungen zuzulassen (etwa mittels der kurz erwähnten Prädikatenlogik). Mit den bis jetzt beschriebenen Standards ist geklärt, wie eine Ontologie beschrieben werden kann (mittels OWL) und wie man sinnvolle Metadaten zu einer Webseite oder auch einem Service hinzuf¨ ugt (mittels RDF unter Verwendung der mit OWL beschriebenen Ontologie). Was noch fehlt uhrt oder auch aus ist, wie man Abfragen u ¨ber ein RDF Dokument durchf¨ der verwendeten Ontologie Regeln und Fakten ableitet. Die zwei wichtigsten vorgeschlagenen Sprachen f¨ ur die Abfrage von RDF Daten sind die RDF Query Language (RDQL) und die zum Teil auf der RDQL basierende SPARQL Protocol And RDF Query Language (SPARQL) (siehe http: //www.w3.org/TR/rdf-sparql-query/ f¨ ur n¨ ahere Information). Beide Vertre-

196

8 Weiterer Ausbau

ter bieten eine grob an SQL erinnernde Abfragesprache, deren Ergebnisse von Einzeldat¨ umern bis hin zu neuen RDF-B¨ aumen reichen können. Weiters stehen auch schon Implementierungen zur Verf¨ ugung. Insgesamt zeigt dieser Abschnitt, welche Standards die aktuelle Basis des Semantic Web bilden. Neben XML handelt es sich dabei primär um RDF zur Auszeichnung von Metadaten und Beziehungen sowie der OWL f¨ ur die Abbildung von Ontologien und damit verbunden das Verf¨ ugbarmachen der Bedeutung der Begriffe. Dabei ist es wichtig, sich die unterschiedlichen Ausformungen der OWL und ihre Einsatzzwecke vor Augen zu halten. Gleichzeitig fehlen auch noch (verabschiedete) Standards etwa zur Abfrage von RDF Daten, sodass konkrete Implementierungen hier zum Teil uneinheitlich sind. ¨ Uberhaupt stellen die enorme Komplexit¨ at der beim Semantic Web angerissenen Fragen und die noch jungen wenn u ¨berhaupt existierenden Standards ein großes Hindernis f¨ ur die technische Umsetzung dar. 8.2.2 Semantic Web & KM Systeme Wie schon kurz angedeutet gibt es eine Reihe von Ankn¨ upfungspunkten des Semantic Web und seiner Technologien zu KM Systemen. Man könnte sogar so weit gehen und das Semantic Web als eine KM Anwendung sehen (oder auch umgekehrt). Aus einer praktischen Perspektive ist diese Frage nicht besonders relevant. Hier geht es vielmehr darum, welche Produkte und Technologien verf¨ ugbar sind, wie sie zusammenspielen k¨ onnen und was man dabei beachten sollte. In diesem Zusammenhang ist es wichtig sich vor Augen zu halten, dass das Semantic Web eine junge Sache darstellt und noch gar nicht alle wichtigen Standards komplett definiert sind. Dazu kommen noch die prinzipiellen Schwierigkeiten, die sich beim Definieren und Verwenden etwa von Ontologien ergeben. Daher ist es nicht weiter verwunderlich, dass es aktuell wenig verf¨ ugbare Open Source Software existiert und viele Vertreter f¨ ur einen generellen Einsatz noch reifen“ m¨ ussen. In diesem Zusammenhang gibt es auch ” das Problem, dass das Semantic Web eigentlich erst dann seinen großen Nutzen zeigt, wenn es jeder verwendet und anbietet. Anders gesagt bestehen wenige Anreize der Erste oder bei den Ersten dabei zu sein und daher wird eine entsprechende Verbreitung sicher noch dauern (hat allerdings auch das Potenzial einer Explosion in dem Moment, wo die kritische Masse erreicht wird, und man einen wirklichen Nutzen ziehen kann). Es gibt nat¨ urlich eine Reihe von Initiativen, dass Semantic Web immer mehr Realit¨ at werden zu lassen. Schwierig ist das einerseits, weil die Wirtschaft und auch die Forschung weltweit unter starkem Kostendruck stehen. Andererseits wurden Investitionen in IT Systeme nach dem Platzen des Internet Hype deutlich reduziert. Ein gutes Beispiel f¨ ur aktuelle Initiativen sind hier etwa die Anstrengungen mithilfe der Service Ontologie OWL-S (siehe http://www.daml.org/services/ owl-s) Web Services Bedeutung zu geben. Praktisch betrachtet werden Web


197

Services mit Metadaten versehen und er¨ offnen damit die Möglichkeit sie automatisch zu benutzen und integrieren. Auch in diesem Fall handelt es sich um eine aktuelle Entwicklung und keine ausgereifte und erprobte Technik. ¨ Eine gute Ubersichtsbeschreibung dieses Aspekts findet sich in einem iX Artikel von Matthias Fl¨ ugge und Kay-Uwe Schmidt [13]. Gleichzeitig gibt es seit kurzem auch Open Source Produkte wie etwa das Jena (siehe Beschreibung weiter unten) basierte OWL-S API f¨ ur Java. Es steht unter der LGPL Lizenz und wird von der Carnegie Mellon University in den USA entwickelt. Nähere Informationen findet man unter http://www.daml.ri.cmu.edu/owlsapi/. Weitere Software ist etwa unter http://www.semwebcentral.org/ oder http: //www.daml.ri.cmu.edu/owlsapi/relatedprojects.htm verf¨ ugbar. Was es im Moment vor allem gibt (im Kontext des Semantic Web als Ganzem), sind einerseits relativ simple Methoden, um etwa RDF Inhalte aus verschiedenen Datenquellen wie einer SQL Datenbank zu extrahieren. Andererseits gibt es trotz all der beschriebenen Probleme nat¨ urlich Open Source Produkte, die gr¨ oßere Aspekte einer Semantic Web Anwendung abdecken und im Folgenden kurz beschrieben werden: Jena: Bei Jena handelt es sich um ein Open Source (BSD Lizenz) Framework f¨ ur das Semantic Web f¨ ur und in Java. Historisch betrachtet basiert Jena auf Semantic Web Anstrengungen von HP (siehe http://www.hpl.hp. com/semweb/). Die grunds¨ atzliche Funktionalität ist dabei ein RDF API, ein RDF Parser (der RDF/XML, N3 und N-Triples versteht), ein OWL API, Unterst¨ utzung f¨ ur die RDQL und die SPARQL Abfragesprache sowie ein Modul f¨ ur regelbasierte Schlussfolgerungen. Mit diesem Framework kann man eine Semantic Web Applikation erstellen beziehungsweise auch Semantic Web Technologien in ein KM System integrieren. Im Moment scheint es eines der interessantesten Semantic Web Open Source Projekte zu sein (auch wegen der konstant hohen Aktivität). OWL API: Eine wesentlich weniger umfangreiche und auch noch nicht f¨ ur den produktiven Einsatz freigegebene Java Library. Geboten wird ein API zum Zugriff auf eine OWL (prim¨ ar f¨ ur OWL Lite und DL) und bietet etwa eine Schnittstelle f¨ ur regelbasiertes Schlussfolgern. Könnte man zum Beispiel verwenden, um eine Ontologie als OWL zu importieren und exportieren. Unter http://owl.man.ac.uk/api.shtml findet man weitere Details (besonders wichtig zu pr¨ ufen, weil es seit Anfang 2005 wenig Aktivität und Unterst¨ utzung zu geben scheint). SWAP: Bei der Semantic Web Application Platform handelt es sich um Semantic Web Tools des W3C selbst. Dabei gibt es einerseits einige Konverter etwa von SQL nach RDF und andererseits das Cwm Tool als Semantic Web Datenverarbeitungsprogramm. Primär kann Cwm RDF in XML oder N3 Notation einlesen, die RDF Daten in Folge abfragen, filtern, ver¨ andern, etc. (etwa mit SPARQL) und wieder abspeichern. Zusätzlich oglichkeit, Regeln zu definieren und entsprechende Abgibt es auch die M¨ fragen/Schlussfolgerungen auf den RDF Daten zu machen. Alle SWAP

198

8 Weiterer Ausbau

Tools unterliegen dabei der W3C Open Source Lizenz und sind in Python geschrieben. N¨ ahere Informationen findet man unter http://www.w3.org/ 2000/10/swap/ und http://www.w3.org/2000/10/swap/doc/cwm.html. pOWL: Hier handelt es sich um ein Framework ähnlich wie Jena nur auf Basis PHP (und der RDF Parser ist das eigenständige Projekt RAP – RDF API for PHP). Was es dar¨ uber hinaus noch anbietet, ist ein OWL Editor. Dieses Framework ist dabei noch neuer als Jena und daher sollte man hier entsprechende Vorsicht bei einer Verwendung walten lassen. Als Lizenz kommt die GPL zum Einsatz. N¨ ahere Informationen findet man unter: http://powl.sourceforge.net/. SWeDE: Bei dem Semantic Web Development Environment Tool handelt es sich um ein Open Source (eigene Lizenz) Plug-in f¨ ur die bei Entwicklern sehr beliebte Eclipse IDE (Integrated Development Environment) zum Bearbeiten von Ontologien auf OWL Basis. Dazu gibt es insbesondere Unterst¨ utzung bei der Eingabe, Validierung oder auch Visualisierung. Weiters gibt es Konverter zwischen den Formaten RDF/XML, N3 und NTriples. Sogar eine Generierung von Java Code ist möglich (vieles dabei durch die Integration von weiteren Tools). Nähere Informationen findet man unter: http://owl-eclipse.projects.semwebcentral.org/. ¨ Euler: Bei Euler handelt es sich um ein Tool f¨ ur das Uberpr¨ ufen von Schlussfolgerungen aufgrund von vorhandenen Fakten und Regeln. Genauer gesagt k¨ onnen die Daten und Regeln als RDF und OWL vorliegen. Dar¨ uber hinaus wird die SPARQL Abfragesprache unterst¨ uzt. Eine Einbindug wird erleichtert, da es je eine Version in Java, Python und C# (alle Varianten stehen unter der W3C Lizenz zur Verf¨ ugung) gibt. Nähere Informationen findet man unter: http://www.agfa.com/w3c/euler/. Wie man schon an der Auswahl sieht, gibt es eine Reihe von Open Source Vertretern und diese decken auch wieder die drei wichtigsten Programmiersprachen f¨ ur Open Source Systeme (Java, PHP, Python) ab. Es werden auch alle Aspekte von der Modellierung der Ontologie u ¨ ber die Verwendung von RDF und OWL Daten bis hin zum Schlussfolgern mittels Regeln abgedeckt. Gleichzeitig handelt es sich u ¨ berwiegend um relativ neue Systeme und daher wird es noch eines Reifungsprozesses bed¨ urfen, bevor ein breiter Einsatz emp¨ fohlen werden kann. F¨ ur einen weiteren Uberblick seien hier auch noch die folgenden beiden Webseiten empfohlen: http://www.semwebcentral.org/ mit einem guten gesamthaften Ansatz und http://www.manageability.org/blog/ ur weitere (Java) Tools zum automatischen Schlussstuff/rule engines/view f¨ folgern aufgrund von Regeln. Damit kann man folgende Punkte festhalten: Es bestehen eine Reihe von Initiativen, was die technische Umsetzung des Semantic Web betrifft. Es gibt in diesem Bereich auch schon einige interessante Vertreter wie etwa das Jena Framework. Bei einer konsequenten Weiterentwicklung ist zu erwarten, dass es bald eine Reihe von gut einsetzbaren Produkten geben wird. Eine Unsicherheit besteht hier vor allem in der rasanten Weiterentwicklung der Standards

8.3 (Weitere) Integration von Drittsystemen/Datenquellen

199

und insbesondere durch die Einf¨ uhrung neuer Standards, die potenziell Umstellungen erfordern werden. Vor allem aber gibt es prinzipielle Fragen was etwa Ontologien und die damit verbundenen Probleme betrifft. 8.2.3 Zusammenfassung Dieser Abschnitt hat die enge thematische Verwandtschaft von Topic Maps und dem Semantic Web aufgezeigt. Diese basiert dabei zu einem Gutteil auf der Verwendung von Ontologien und generell der Einf¨ uhrung und Benutzung von semantischer Information und Regeln. Ein Unterschied im Ansatz ist, dass das Semantic Web sich prim¨ ar um u ¨ ber das Internet zugängliche Informationen k¨ ummert und Systeme innerhalb einer Organisation weniger im Fokus hat. F¨ ur ein Verst¨ andnis des Semantic Web ist es wichtig, sich die zugrunde liegenden Standards n¨ aher anzusehen. Dabei handelt es sich vor allem um den RDF Standard f¨ ur Metadaten und Beziehungen sowie die drei Varianten der OWL mit ihren verschieden m¨ achtigen Ontologien. Neben f¨ ur das Semantic Web eher aus historischer Sicht wichtigen Standards wie DAML+OIL gibt es auch noch den Verweis auf die Versuche RDF Abfragesprachen zu standardisieren. Zwei schon relativ weit eingesetzte Vertreter sind dabei RDQL und SPARQL (insbesondere letztere erfreut sich aktuell wachsender Beliebheit). Bei der Frage des Zusammenhangs des Semantic Webs mit KM Systemen kann man relativ schnell eine große inhaltliche Nähe feststellen. Gleichzeitig gibt es noch eine Reihe von prinzipiellen Problemen, insbesondere was Ontologien und darauf aufbauende Schlussfolgerungen betrifft. Wenn man sich noch technische Umsetzungen der Semantic Web Technologien ansieht, findet man schon einige interessante Vertreter. Insbesondere aufgrund der sich noch ver¨ andernden Standards sollte man aber eher zur¨ uckhaltend agieren. Anders gesagt gibt es vor allem theoretische“ Probleme, die zu unbefriedigenden ” Ergebnissen dieser Technologie f¨ uhren. Speziell mittlere bis größere KM Initiativen sollten das Thema aber unbedingt im Auge behalten, wenn nicht sowieso besondere Gr¨ unde f¨ ur einen unmittelbaren Einsatz sprechen.

8.3 (Weitere) Integration von Drittsystemen/Datenquellen In den Kapiteln 5, 6 und 7 wurde schon darauf eingegangen, dass man sich bei einem KM System unbedingt um die F¨ ulle an vorhandenen Drittsystemen und Datenquellen k¨ ummern muss. Dabei war der Fokus auf Groupware, CMS und DMS Aspekte ausgerichtet. Im Hinblick auf einen Endausbau“ eines ” KM Systems geh¨ oren nat¨ urlich alle Systeme mit potenziell wichtigen Daten und/oder Funktionen analysiert.

200

8 Weiterer Ausbau

Von einer theoretischen Perspektive her sollten praktisch alle Systeme und Funktionen in das KM System integriert werden. Damit stehen dann alle relevanten Funktionen zur Verf¨ ugung. Weiters kann man dann soweit wie möglich auf den individuellen Benutzer eingehen und eine umfassende Unterst¨ utzung bei allen relevanten Aufgaben anbieten. Praktisch betrachtet gibt es dabei nat¨ urlich eine Reihe von Problemen. Ein ganz wichtiger Aspekt ist etwa die Kostenfrage. Es ist wirtschaftlich kaum vertretbar, alle Systeme einer Organisation in einem KM System zu integrieren. Weiters verliert man mit diesem Ansatz nat¨ urlich deutlich an Flexibilit¨ at: • • •

Upgrades von den Einzelsystemen werden deutlich problematischer Das Abl¨ osen von Systemen erfordert neue Integrationsanstrengungen Und so weiter

Zusammengefasst kann man sagen, dass als Erstes eine Analyse aller bestehenden Drittsysteme und Datenquellen notwendig ist. Dabei geht es um folgende Fragen: • • • • •

Welchen unmittelbaren Nutzen bringt die Integration eines Drittsystems beziehungsweise einer Datenquelle im KM System? Welche zus¨ atzlichen Funktionen kann das KM System nach einer Integration anbieten? Wie teuer beziehungsweise aufwendig ist eine Integration und wie ändern sich die Betriebskosten? Welche Konsequenzen hat eine Integration (zuk¨ unftige Upgrades, Systemwechsel)? Welchen erwarteten Nutzen (vor allem monetär) bringt die Integration?

Im Großen und Ganzen ergibt eine Analyse anhand der obigen Liste einen Business Case f¨ ur eine Integration oder dagegen. Man sollte dabei nicht u ¨ berrascht sein, wenn sich Investitionen typischerweise erst nach einigen Jahren rechnen (man sollte sogar noch einmal genau nachrechnen, wenn dem nicht so ist). Unabh¨ angig von den einzelnen Systemen/Datenquellen m¨ ussen dar¨ uber hinaus einige wichtige Aspekte beleuchtet werden: • • •

Was ist das strategische Ziel der Organisation in Hinblick auf KM? Wie soll die Organisation in Zukunft funktionieren? Welche wirtschaftlichen Ziele der Organisation sollen damit unterst¨ utzt werden?

Diese drei Fragen k¨ onnen einen eventuell schlechten Business Case doch noch rechtfertigen. Potenzielle Systeme, die in Frage kommen, können dabei extrem unterschiedlich sein. Neben einer Standardl¨ osung f¨ ur eine Branche kann es etwa auch eine selbstgeschriebene Altlast“ aus den 1980er Jahren geben. Daher ” kann man hier keine detaillierte Analyse vornehmen sondern nur auf die Notwendigkeit einer individuellen Betrachtung verweisen (insbesondere auf Basis


201

der oben genannten Punkte). Bei zwei Produktkategorien wurden allerdings schon in Abschnitt 3.5.5 Open Source Vertreter vorgestellt. Dabei handelt es sich um sogenannte Business“-Software, also ERP, SCM und CRM Produk” te sowie um Digital Libraries. Diese beiden Kategorien werden daher noch n¨ aher beleuchtet. Dabei fußt die Auswahl gerade dieser Systeme nicht nur“ ” auf Willk¨ ur. Es handelt sich einerseits um sehr wichtige Kategorien und andererseits gibt es entsprechend weit entwickelte Open Source Produkte. 8.3.1 ERP/CRM Produkte Mit dem Begriff Business“-Software soll im Folgenden sowohl ein eher klas” ” sisches“ Produkt wie Compiere als auch CRM Produkte wie openCRX und SugarCRM gemeint sein. Es wurde schon fr¨ uher erwähnt, dass diese Produktkategorie nicht direkt KM unterst¨ utzt oder als KM Tool klassifiziert werden kann. Gleichzeitig gibt es eine Reihe von wichtigen Aspekten in Hinblick auf KM: •

• • •

•

Eine Vielzahl von Daten und Informationen findet sich in genau diesen Systemen. Ohne eine entsprechende Einbindung wird eine Suche im KM System immer nur einen Teil der Informationsbasis einer Organisation abdecken k¨ onnen. Sehr viele Mitglieder einer Organisation werden dieses System nutzen m¨ ussen. Wenn ein KM System separat ist, sind erhöhte Schulungsaufwände und Reibungsverluste in der Bedienung fast unausweichlich. Noch schlimmer als Reibungsverluste sind aber die potenziell resultierenden redundanten Daten. Insbesondere, wenn nicht ausgeschlossen werden ¨ kann, dass es gleichzeitige Anderungen in mehreren Systemen gibt. Die Informationen im Zusammenhang mit den Kunden sind von äußerster Wichtigkeit f¨ ur ein gr¨ oßeres KM System. So wie sich eine Groupware mit der Zusammenarbeit von Mitarbeitern beschäftigt, versucht ein CRM System die Kommunikation mit den Kunden zu optimieren. Soweit ein entsprechendes System schon im Einsatz ist, stellt sich auch noch die Frage, ob eine Einbindung von Informationen und/oder Funktionen kosteng¨ unstig genug machbar ist.

Insbesondere der erste Punkt ist besonders wichtig und bedeutet nicht unbedingt, dass eine Integration von solchen Systemen notwendig wäre. Wie schon mehrfach aufgezeigt, kann auch eine reine Integration von Daten und Informationen in das KM System Sinn machen. Gleichzeitig sollte eine mittlere bis gr¨ oßere Initiative unbedingt darauf achten solche entscheidenden Informationen in das KM System einzubeziehen. Weiters sollte man unabh¨ angig von der KM Initiative u ¨berlegen, ob ein solches System f¨ ur die Organisation Sinn macht. Dabei kann sich eine Ablöse eines (teuren) kommerziellen und eventuell komplizierten Systems möglicherweise relativ rechnen. Insbesondere wenn eine Integration der Informationen

202

8 Weiterer Ausbau

und/oder Funktionen mit hohen Kosten verbunden wäre, sollte man dieses Szenario ernsthaft durchrechnen. Es ist auch wichtig beim Fehlen eines entsprechenden Produkts zu u ¨ berlegen, ob eine Einf¨ uhrung Sinn macht. Damit h¨ atte man eine Wahl zwischen den ¨ Systemen und k¨ onnte verst¨ arkt technische Uberlegungen einbeziehen. Wobei auch hier wieder die zuk¨ unftigen Arbeitsabl¨ aufe im Mittelpunkt stehen sollten. Wenn man jetzt kurz die einzelnen Systeme analysiert, so gibt es eine klare Zweiteilung. Einerseits das schon l¨ anger verf¨ ugbare und eher als ERP beziehungsweise SCM System gedachte Compiere. Andererseits die j¨ ungeren CRM“-lastigeren Produkte openCRX und SugarCRM. Das eine sozusagen ” das SAP“ des Open Source, w¨ ahrend die anderen einen etwas eingeschränk” teren Fokus haben. Technisch betrachtet gibt es ebenfalls eine gewisse Diversität durch die Systeme. Einerseits Java bei Compiere und openCRX (hier noch mit .NET als Alternative) und andererseits PHP bei SugarCRM. Damit hat man eigentlich schon eine Reihe von groben Entscheidungskriterien. Je nach benötigter Funktionalit¨ at und passender Technologie sollte man sich die damit ergebenden ein bis zwei Systeme im Detail anschauen. Wichtig ist vor einer solchen Entscheidung eine Reihe von Themen und Aspekten ber¨ ucksichtigen beziehungsweise im Vorfeld zu analysieren. Ein solches System muss n¨ amlich mittelfristig die benötigten Funktionen anbieten und den Einf¨ uhrungs- und Bedienungsaufwand rechtfertigen. Die allerwichtigsten Punkte sind dabei die Folgenden: • • • •

Unbedingt mit einer Pilotinstallation/phase die praktische Verwendbarkeit testen. Alternativen durchdenken. Etwa eine Verbesserung der vorhandenen Prozesse und/oder Systeme. Bei den Alternativen muss man die Einbindung von wichtigen Informationen in das KM System ber¨ ucksichtigen. Grob u ¨ berschlagen, ob sich so ein System rechnen kann (je kleiner eine Organisation ist, desto schwieriger d¨ urfte das sein).

Man sieht also, dass es sich hier um eine komplexe und schwierige Fragestellung handelt. Theoretisch ist die Sache klar: Einbindung eines mächtigen Systems in das KM System. Praktisch ist das nicht in jedem Fall eine gute Idee. Gleichzeitig muss man aber darauf schauen, die wichtigen Daten trotzdem in das KM System zu bekommen“. Auf diese Fragestellung kann damit ” nur eine individuelle Analyse eine Antwort geben. 8.3.2 Digital Library: Greenstone achtiges Im Bereich der Digital Libraries gibt es vor allem ein populäres und m¨ Open Source Produkt: Greenstone“. Es bietet kurz gesagt die Möglichkeit, ”


203

verschiedene Sammlungen elektronisch zu erfassen und mittels einer Suche zur Verf¨ ugung zu stellen. Die unmittelbarste Anwendung ist dabei nat¨ urlich eine B¨ ucherei. Einerseits geht es um die Verwaltung von physischen Medien, wie etwa B¨ uchern. Andererseits auch um elektronische Dokumente. Hier schließt sich der Kreis zu DMS Systemen. Wobei nat¨ urlich der Einsatzzweck ein deutlich anderer ist. Im Hinblick auf ein KM System gibt es dabei eine Anzahl an relevanten Fragestellungen. Die vielleicht Wichtigste ist dabei, ob es entsprechende Sammlungen u ¨berhaupt gibt. Wenn so etwas vorhanden ist, stellt sich noch die Frage, wie viele Leute von einem effizienteren Zugriff profitieren können. Dabei sollte man nicht nur an eine physische Bibliothek denken, sondern auch (potenziell externe) Dokumentensammlungen, auf die man Zugriff hat. Durch die Einbindung eines solchen Systems bekommt man nämlich auch Zugriff“ ” auf das sehr wertvolle Wissen von Bibliothekaren, die eine treibende Kraft hinter dem aktuellen Zustand von Greenstone sind. Die Diskussion zu Digital Libraries zeigt, dass es sich eher um eine Nische handelt. Die wichtigsten KM-relevanten Szenarien können auch durch DMS Systeme beziehungsweise Funktionen abgedeckt werden. Trotzdem sollte man ¨ entsprechende Uberlegungen nicht vernachl¨ assigen. Eventuell kann es auch Sinn machen, eine Einf¨ uhrung f¨ ur eine vorhandene B¨ ucherei ganz unabhängig von einem KM System zu u ¨ berlegen. Generell sollte man aber eher versuchen, alle vorhandenen Informationen im KM System zu sammeln beziehungsweise konzentrieren. 8.3.3 Zusammenfassung Dieser Abschnitt diskutiert m¨ ogliche Vorgehensweisen, um weitere Datenquellen beziehungsweise Drittsysteme im KM System zu integrieren. Dabei geht es im Prinzip um alle bis jetzt noch nicht diskutierten Systeme mit entsprechenden Daten beziehungsweise Funktionen einer Organisation. Insgesamt betrachtet ist selbstverst¨ andlich eine weitestgehende Integration das Ziel. Wie wichtig es ist, muss dabei die KM Initiative jeder Organisation individuell beantworten. Das ist dann auch schon eines der Entscheidungskriterien. Danach sollte man einmal eine grobe Vorselektion machen und den potenziell interessanten Teil n¨ aher betrachten. Die Analyse muss dann schl¨ ussig die Vor- und Nachteile einer Integration in das KM System aufzeigen, sodass eine Entscheidung m¨ oglich ist. Besonders hervorgehoben wurden dann noch die Produktkategorien Busi” ness“-Software (ERP/CRM) und Digital Libraries. Bei Letzterer sollte eine grobe Analyse wichtige Anhaltspunkte liefern und eine detailliertere Betrachtung in den meisten F¨ allen u ussig machen. Bei der ersten Kategorie kann ¨berfl¨ nur eine genauere Untersuchung Aufschluss bringen. Dabei ist einerseits der Zusammenhang mit einem KM System relevant und andererseits handelt es sich um eine Fragestellung, die auch separat sehr wichtig sein kann.

204

8 Weiterer Ausbau

Zusammengenommen m¨ ussen die Analysen der weiteren vorhandenen Systeme und Datenquellen sowie die genauere Betrachtung von Business“” Software und Digital Libraries aufzeigen, was mit welcher Priorität in das KM System einbezogen werden sollte. Auf der Basis der Vision f¨ ur das KM System und der kurz- und mittelfristigen Ziele der KM Initiative sollten diese Entscheidungen relativ leicht zu treffen sein.

8.4 Exemplarische Erweiterungsm¨ oglichkeiten Nat¨ urlich stellt sich nicht nur die Frage nach weiteren Datenquellen und potenziell zu integrierenden Systemen, wenn es um einen weiteren Ausbau geht. In diesem Abschnitt geht es jetzt um M¨ oglichkeiten, ein KM System weiter auszubauen. Fokus sind dabei die in Abschnitt 3.5.5 vorgestellten Systeme oder Funktionen soweit sie nicht in den noch folgenden Abschnitten separat behandelt werden (vor allem Workflowfunktionen). Das Gemeinsame ist dabei das KM System, das potenziell erweitert werden soll. In sich haben die vorgestellten Systeme keinen großen Zusammenhang. Daher gibt es jeweils eine eigene Gliederungsebene, um die wichtigsten Aspekte kurz anzusprechen. Weiters geht es eher um eine exemplarische Darstellung von interessanten Funktionen. Die Auswahl erhebt nicht den Anspruch, repr¨ asentativ zu sein. Weiters ging es auch nicht um eine Darstellung aller relevanten Vertreter. Je eher also eine Kategorie wichtig erscheint, desto eher sollte man vor einer Entscheidung eine Suche nach weiteren Produkten durchf¨ uhren. Insgesamt gilt auch hier wieder, dass das mittelfristige Ziel f¨ ur das KM System klar sein muss. Genauso m¨ ussen potenzielle Anforderungen bekannt ¨ sein und Uberlegungen u unftigen Arbeitsabläufe angestellt werden. ¨ ber die zuk¨ 8.4.1 Bulletin Board System (BBS): phpBB Im Prinzip wurde der Nutzen eines Bulletin Board Systems schon bei Groupware und CMS Systemen argumentiert. Dort wurde mit dem Begriff Forum operiert. Praktisch betrachtet ist ein Bulletin Boards System fast das Gleiche wie ein Forumsystem (und die theoretischen Unterschiede werden von entsprechend benannten Systemen sowieso ignoriert). Damit ist schon klar, dass eine Erweiterung nur Sinn macht, wenn noch ¨ nichts Aquivalentes im KM System vorhanden ist. Sollte so etwas allerdings wirklich fehlen, so spricht einiges daf¨ ur, diese Möglichkeit einzubinden. Im PHP Umfeld gibt es dabei besonders viele Systeme und das im Titel ersichtliche phpBB ist eines der beliebtesten und mächtigsten. Dieses System im Speziellen unterst¨ utzt verschiedene Datenbanken wie MySQL, MS SQL Server, PostgreSQL oder eine Access/ODBC Kombination. Von der Lizenz her ist die GPL anzuwenden.

8.4 Exemplarische Erweiterungsm¨ oglichkeiten

205

Der wichtige Punkt ist, dass es solche Bulletin Board oder auch Forensysteme einzeln gibt und man daher eine entsprechende Erweiterung eines KM Systems durchaus in Betracht ziehen sollte. Nat¨ urlich gilt auch hier wieder, dass die Arbeitsabl¨ aufe in der Firma entsprechend darauf R¨ ucksicht nehmen m¨ ussen. 8.4.2 Kalenderapplikation: WebCalender Neben Bulletin Board Systemen gibt es auch Kalenderapplikationen einzeln. Wieder gilt hier, dass eine Groupware und h¨ aufig auch ein CMS System so etwas typischerweise schon integriert haben werden. Wenn nicht sollte man auf jeden Fall ernsthaft daran arbeiten, einen Kalender einzubeziehen. Als Beispiel soll hier der PHP basierte WebCalender betrachtet werden. Es handelt sich dabei wirklich nur um einen Kalender, der auch f¨ ur Benutzergruppen gedacht ist (neben der M¨ oglichkeit eines Eventkalender). Die verwendete Lizenz ist wieder die GPL. Im Normallfall sollte man diese Funktionalität schon abgedeckt haben. Wenn nicht, muss man auf jeden Fall versuchen einen Gruppenkalender in das KM System einzubeziehen. Es handelt sich dabei um eine Grundfunktionalit¨ at, auf die man m¨ oglichst nicht verzichten sollte. 8.4.3 Wikimodule wie etwa phpWiki ¨ Uber Wikis wurde schon in fr¨ uheren Kapiteln geschrieben (siehe Seite 75 oder 134), daher soll hier nur noch das Wesentliche beziehungsweise Neue gebracht werden. Ganz kurz gesagt erlauben Wikis das gemeinsame Arbeiten an einem Intra-/Internetdokument. Einerseits handelt es sich um eine unstrukturierte Kommunikationsmethode, andererseits ist es f¨ ur eine Gruppe (beziehungsweise eventuell alle Besucher einer Website) einsehbar. Aus einer KM Sicht sind Wikis eine zwiespältige Sache. Sie ziehen Kommunikation an sich, die damit nicht mehr strukturiert geschieht. Auf der anderen Seite sind viele Leute in einem Wiki wesentlich aktiver und kommunikativer, als sie es sonst w¨ aren. Daher sollte man sich mögliche Einsatzzwecke u berlegen. Soweit noch kein Wiki durch die verschiedenen Teilsysteme dabei ¨ ist, d¨ urfte es eigentlich kein Problem sein, ein Open Source Wiki Module oder System zu finden. Als Beispiel soll hier nur kurz phpWiki erwähnt werden. Wie der Name schon sagt, ist es ein PHP basiertes Modul und unterliegt den Lizenzbedingungen der GPL. Neben der Grundidee erm¨ oglicht es etwa auch Themen und unterst¨ utzt ein Berechtigungssystem (eine etwas längere Beschreibung findet sich in Abschnitt 3.5.5). Zusammengefasst kann man sagen, dass Wikis eine interessante Erweiterung eines KM Systems sind. Wichtig ist, sich vor der Verwendung zu u ¨ berlegen, welche Auswirkungen das auf die Kommunikation haben wird. Ein Wiki Modul oder System zu finden, sollte dagegen kein wirkliches Problem sein. Durch die hohe Beliebtheit gibt es eine Unmenge an Implementierungen gerade im Open Source Bereich.

206

8 Weiterer Ausbau

8.4.4 Open Ticket Request Systeme (OTRS) Nachdem gerade die Nachverfolgung von Kundenanfragen beziehungsweise allgemein auch Supportanfragen ein wichtiges Thema ist, gibt es eine ganze Reihe Open Source Produkte dazu. Bei den PHP Systemen ist so etwas zum Teil auch in Groupware oder CMS Systeme integriert oder als Modul verf¨ ugbar. Schon wegen der behandelten Thematik kann man von einer prinzipiellen Sinnhaftigkeit entsprechender Funktionen im Kontext eines KM Systems ausgehen. F¨ ur eine Bewertung muss man sich dabei eine Reihe von Dingen u ¨ berlegen: • • • •

Wie h¨ aufig gibt es entsprechende Anfragen? Ist eine halbwegs standardisierte Behandlung möglich? Gibt es a ¨hnliche Funktionen im geplanten KM System (insbesondere CRM Funktionen oder eine strukturierte Kommunikation mit diesem Fokus)? Werden eventuell andere Funktionen f¨ ur ¨ ahnliche Zwecke verwendet (und wenn ja, ist das eine gute Idee)?

Eine Analyse der aufgef¨ uhrten Punkte sollte eine Entscheidung f¨ ur oder gegen ein solches Ticket System relativ einfach machen. Aus einer KM Sicht muss man noch sagen, dass nicht jede (sinnvolle) Verwendung eines Ticket Systems wichtig f¨ ur ein KM System ist. Wenn es nämlich nur“ um externe ” Probleme geht, ist es nur“ f¨ ur einen Teil der Organisation interessant. Wenn ” es dagegen auch um interne Probleme geht oder man generell etwas lernen kann, ist es unbedingt f¨ ur ein KM System relevant. Damit noch zu dem Aufh¨ anger“ dieses Abschnitts in Form des Open ” Ticket Request Systems. Eine Beschreibung findet sich schon in Abschnitt 3.5.5 und soll hier nicht wiederholt werden. Anhand dieses unter der GPL stehenden Perl Systems sieht man, wof¨ ur so ein Tool verwendet werden kann. Durch die Konfigurierbarkeit und Erweiterbarkeit sollte eine zumindest oberfl¨ achliche Integration (mit einer Einbindung der Daten im Hintergrund) relativ einfach m¨ oglich sein. Kurz gesagt ist ein Ticket Request System eine f¨ ur viele Organisationen sinnvolle Erweiterung eines KM Systems. Dabei gilt es, eine Reihe von Punkten zu beachten. Nat¨ urlich w¨ are eine enge Integration zu empfehlen. Es ist aber auch eine eher oberfl¨ achliche Integration von Wert f¨ ur ein KM System. 8.4.5 Visualisierungssysteme wie etwa der Matrixbrowser Die meisten der bisher beschriebenen Systeme und Aspekte behandeln das Einbeziehen und Anbieten von Informationen und Funktionen. Visualisierungsaspekte sind dabei meistens im Hintegrund geblieben. Daher soll dieser Abschnitt noch einmal extra darauf hinweisen und aufzeigen, dass es auch Systeme gibt, die man einbeziehen k¨ onnte. ¨ ist dabei, dass es keine optimale Form des ZuEine wichtige Uberlegung griffs auf die Daten und Funktionen eines KM Systems gibt. Einerseits sind die

8.4 Exemplarische Erweiterungsm¨ oglichkeiten

207

zu erledigenden Aufgaben nicht einheitlich genug. Andererseits unterscheiden sich Menschen auch untereinander zu sehr (man braucht nur an die verschiedenen Lerntypen wie etwa motorisch oder akustisch denken). Es wurde ja auch schon entsprechend die Notwendigkeit des Anbietens von verschiedenen Zugriffsm¨ oglichkeiten diskutiert. Besonders wichtig ist dabei die Visualisierung, weil sie bei den meisten Systemen (aus denen voraussichtlich das KM System besteht) zu kurz kommt. Das ist dabei kein Zufall, sondern demonstriert die Schwierigkeit von guten Visualisierungen. Eine sinnvolle Herangehensweise wäre damit das Vorbereiten von ein bis zwei entsprechenden Prototypen. Sobald das KM System und die Prototypen weit genug sind, k¨ onnte man evaluieren, ob die angedachte Visualisierung einen Mehrwert bringt. So eine Untersuchung m¨ usste dabei eine gr¨ oßere Anzahl von Mitarbeitern einschließen. Ein solches Visualierungstool ist der schon in Abschnitt 3.5.5 vorgestellte Matrixbrowser. Bei diesem handelt es sich nicht um ein echtes Open Source Produkt, aber ein interner Einsatz in einem KM System wäre kostenfrei m¨ oglich. Konzeptuell w¨ urde es sich auch eher um ein Add-on“ handeln, ” sodass dieser Aspekt weniger ins Gewicht f¨ allt als sonst. Insgesamt ist es sehr schwierig, m¨ oglichst effiziente“ Visualisierungen ” zu finden. Die vorhandenen M¨ oglichkeiten der Produkte sind eher beschränkt. Daher ist es anzuraten, entsprechende Versuche und Analysen durchzuf¨ uhren. Diese m¨ ussen nicht zwangsl¨ aufig zeitgleich mit der Einf¨ uhrung des KM Systems passieren. Es handelt sich um einen der wenigen Aspekte, den man relativ gefahrlos nach hinten schieben kann (was leider einer der Gr¨ unde f¨ ur seine Vernachl¨ assigung“ ist). ” 8.4.6 E-Mailklassifizierung wie etwa mit POPFile Der letzte Abschnitt zu einem Erweiterungsthema beschäftigt sich mit der Klassifizierung von E-Mails. Das ist in mehrerer Hinsicht ein heikles Thema. Außerdem ist es auch technisch schwierig umzusetzen. Die Brisanz ergibt sich eigentlich aus der Tatsache, dass E-Mails unverschl¨ usselt sind und zur Kommunikation auch geheimster und intimster Informationen benutzt werden. Zus¨ atzlich versch¨ arft wird die Problematik durch die Massen an Spam und Viren, die an fast jede E-Mail Adresse im Internet gesendet werden. Das Idealbild w¨ are, dass unerw¨ unschte E-Mails nicht ausgeliefert werden und eine 100%-ige Trennung der erw¨ unschten E-Mails in die verschiedenen Arbeitsgebiete und private Agenden gelingt. Dies ist aber technisch leider unmöglich (von der Vermischung der Inhalte in E-Mails einmal ganz abgesehen). Da also eine 100%-ige Trennung nicht durchf¨ uhrbar ist, muss man insbesondere in Europa an die Datenschutzgesetze denken. Damit wird eine Reihe von m¨ oglichen Einsatzzwecken ausgeschlossen. (Ein Faktum, das den Perfektionisten nat¨ urlich enorm st¨ oren muss. Wer allerdings keine Sehnsucht

208

8 Weiterer Ausbau

nach Big Brother“ hat, sollte eher froh dar¨ uber sein.) Damit bleiben aber ” immer noch eine Reihe von interessanten Aufgaben: • • •

Das m¨ oglichst weitgehende Aussortieren von Spam Das Vorsortieren von gesch¨ aftlicher E-Mail Das Vorschlagen von f¨ ur Andere interessanten Inhalten

¨ Uber die dahinterliegenden Techniken kann man in Abschnitt 8.7 einiges lesen. Daher soll es hier eher um die Anwendungsperspektive gehen. Wie inzwischen ja schon fast selbstverst¨ andlich ist auch hier eine Kosten/Nutzenanalyse notwendig. Durch die Wichtigkeit von E-Mails f¨ ur die meisten Organisationen und die Massen an Spam, die jeden Tag empfangen werden, gibt es zumindest gute Gr¨ unde so etwas einzuf¨ uhren. Was die anderen Aspekte angeht, stellt sich vor allem die Frage, wie gut die Sortierung arbeitet und wie viel Arbeit sie effektiv abnehmen kann. Ein interessantes Beispiel eines solchen Systems ist POPFile. Wie der Name schon andeutet, schaltet es sich zwischen einen E-Mail Client und den Mail Server. Diese Art der Verwendung wird f¨ ur ein integriertes System eher selten gew¨ unscht sein. Gleichzeitig gibt es aber auch die Möglichkeit das Tool anders einzusetzen und wenn der Mail-Server Teil des KM Systems ist, sollte eine entsprechende Integration durchaus machbar sein. Die verwendete Lizenz ist dabei die GPL. Eine etwas l¨ angere Beschreibung des Tools findet man in Abschnitt 3.5.5. Insgesamt ist das Klassifizieren von E-Mails ein Punkt, der aus heutiger Sicht immer wichtiger werden wird. Das stetige Anwachsen der E-Mail basierten Kommunikation l¨ asst eigentlich gar keinen anderen Schluss zu. Daher ist eine entsprechende Erweiterung des KM Systems anzuraten. Entweder mittels eines separaten Tools wie gerade besprochen oder u ¨ ber eine generelle Möglichkeit zur Klassifizierung von Informationen, die noch vorgestellt wird. 8.4.7 Zusammenfassung ¨ Der Abschnitt u ¨ber exemplarische Erweiterungsmöglichkeiten gibt einen Uberblick u ur ein KM System. ¨ ber interessante Systeme oder Funktionsbereiche f¨ Dabei werden einerseits noch nicht angesprochene Aspekte beleuchtet. Andererseits werden auch ein paar Systeme und Tools kurz diskutiert, die ein KM System entsprechend erweitern k¨ onnen. Das beginnt bei einem BBS System, einem Gruppenkalender oder einem Wiki. Daneben gibt es auch optionale Erweiterungen wie ein Ticket Request System oder erweiterte Visualisierungsm¨ oglichkeiten. Der letzte Punkt ist dann noch die Klassifizierung von E-Mails. Dabei handelt es sich um einen Spezialfall einer Klassifizierung. Wegen der Wichtigkeit und des Vorhandenseins von eigenen Tools wird das Thema hier separat diskutiert. Zusammengefasst kann man sagen, dass es eine Reihe von sinnvollen und wichtigen M¨ oglichkeiten zur Erweiterung eines KM Systems mit Open Source

8.5 Erg¨ anzung von Workflowfunktionen

209

Systemen, Modulen oder Tools gibt. Der entscheidende Punkt ist hier wieder, eine entsprechend ausgearbeitete Vision f¨ ur die KM Initiative zu haben, die es erm¨ oglicht, mittelfristige Ziele f¨ ur das KM System abzuleiten. Zusätzlich geben die einzelnen Abschnitte Hinweise f¨ ur eine entsprechende Kosten/Nutzenrechung. Auf dieser Basis sollte es relativ einfach sein festzulegen ob und wenn ja wann und wie eine Funktion oder ein System eingebunden werden sollte.

8.5 Erg¨ anzung von Workflowfunktionen Der Begriff Workflow und verschiedene Anwendungen sind schon mehrfach beschrieben worden. Insbesondere bei CMS und DMS Systemen ist ein Workflow praktisch Pflicht, um die Berechtigung Informationen zu veröffentlichen entsprechend abzubilden. Gleichzeitig handelt es sich dabei eher um spezialisierte Anwendungen von Workflows (die aber die Wichtigkeit aufzeigen). 8.5.1 Spannungsfeld: Workflows & KM Von einer theoretischen Seite her betrachtet, gibt es ein gewisses Spannungsfeld zwischen KM und Workflows. Das wird zwar von vielen Autoren nicht so gesehen, ist aber in einer Linie mit der Argumentation, dass ein Computer kein Wissen haben kann. Genauso kann er n¨ amlich nicht wissen“, ob ein vorgege” bener Arbeitsablauf eine Ausnahme br¨ auchte oder nicht. Hier unterscheidet sich ein standardisierter Workflow besonders stark von einem organisatorisch festgelegten Arbeitsablauf, bei dem die beteiligten Menschen jederzeit eine Ausnahme machen k¨ onnen. Das aber noch viel wichtigere Argument ist, dass ein standardisierter Arbeitsablauf in den seltensten F¨ allen ein wissensintensiver Prozess ist. Daraus folgt, dass ein Ablauf, der sich komplett als Workflow modellieren lässt, aus KM Sicht nicht besonders wichtig sein d¨ urfte. Ein vollständig definierter Ablauf regelt, welche Informationen wann und woher kommen. Damit gibt es kaum mehr die Notwendigkeit, sich Wissen anzueignen oder zu generieren. Nat¨ urlich muss man einschr¨ ankend hinzuf¨ ugen, dass es sich bei dieser Beschreibung um eine Verallgemeinerung handelt. Nichtsdestotrotz sollte man dieses Spannungsfeld nicht untersch¨ atzen. Gleichzeitig gibt es aber nat¨ urlich M¨ oglichkeiten, Workflows im Sinne einer KM L¨ osung einzusetzen. Hierbei gibt es eine Reihe von Ansatzpunkten, die zum Teil recht unterschiedlich sind und auch entsprechend betrachtet und diskutiert werden sollten. Die drei wichtigsten Kategorien sind dabei: • • •

Workflows f¨ ur die Benutzung des KM Systems beziehungsweise als Teil der KM Initiative Workflows, die eine gewisse N¨ ahe zum KM System und/oder der KM Initiative aufweisen Workflows, die f¨ ur die allgemeine Arbeit der Organisation definiert wurden

210

8 Weiterer Ausbau

¨ Diese Gruppierung von Workflows ist wichtig f¨ ur die Uberlegungen, Workflow Unterst¨ utzung eines KM Systems zu nutzen (eventuell daf¨ ur zusätzlich einzubauen). Aus diesem Grund findet sich in den folgenden Abschnitten jeweils eine detailliertere Diskussion der relevanten Aspekte. 8.5.2 Workflows als Teil einer KM Initiative Der f¨ ur dieses Buch wichtigste Punkt ist die direkte Einbindung von Workflows in das KM System. Dabei gibt es zwei Ausprägungen. Einerseits können einzelne Abl¨ aufe der KM Initiative als Workflow abgebildet sein. Andererseits kann es entsprechende Workflows f¨ ur die Benutzung des Systems geben. Der zweite Punkt kann dabei durchaus ein Ergebnis des ersten sein. Der Unterschied ergibt sich aus der Tatsache, dass es zusätzliche Abläufe rein aus der Fragestellung der Benutzung des KM Systems geben kann. Ein Beispiel k¨ onnte etwa ein komplett definierter Ablauf f¨ ur das Abfragen einer Wis” sensdatenbank“ sein. Aus der Sicht der KM Initiative ist hier potenziell nur wichtig, dass es geschieht. F¨ ur das System ist relevant, wie es geschieht. Eventuell k¨ onnte eine bestimme Reihenfolge und Strukturierung Kosten reduzieren (zum Beispiel f¨ ur die Verwendung von externen Systemen). F¨ ur beide Kategorien muss man aber eine Verwendung von Workflows sehr genau u ¨berlegen. Gerade bei den Kernbereichen der KM Initiative oder des KM Systems k¨ onnen limitierende Workflows leicht mehr Schaden als Nutzen anrichten. Es geht bei KM nicht um Standardisierung, sondern um die Unterst¨ utzung von wissensintensiven Prozessen. Die Aufgabenstellungen, f¨ ur die KM am relevantesten ist, haben meist auch keine klare Strukturierung und sind nicht besonders gleichf¨ ormig. Aus all diesen Punkten heraus ergibt sich die Wichtigkeit, nicht zu viele Einschr¨ ankungen einzuf¨ uhren. Man sollte sich dabei vor Augen halten, dass trotz des Kostendrucks unter dem fast jede Organisation heutzutage steht, eine KM Initiative weder primär noch sekundar u ¨ ber die Kostensicht betrachtet werden darf. Das bedeutet nicht das Abgehen von einer Kosten-/Nutzenrechnung. Es bedeutet aber, dass man nicht versuchen sollte, eine optimale Verwendung des KM Systems zu erreichen. Es gibt hier eine ganze Reihe von wichtigen Argumenten, warum ein KM System nicht zu rigide eingeschr¨ ankt sein sollte: • • • •

Es wird immer verschiedene Nutzertypen geben (Stichwort unterschiedliche Lerntypen). Zum Teil geht es um neue Aufgabenstellungen: Die optimale Vorgehensweise ist gerade nicht bekannt! Es gibt jeweils einen ganz unterschiedlichen Wissensstand der Nutzer. Es geht um das Gewinnen von Wissen und daher um das Schaffen von Neuem: Das kann nicht geplant werden!

Diese Argumente zeigen, dass man sehr vorsichtig beim Thema Workflows als Teil eines KM Systems beziehungsweise einer KM Initiative sein


211

muss. Es heißt aber nicht, dass man unbedingt darauf verzichten muss. Bei Randthemen, die weniger wissensintensiv sind, ist es sinnvoll zu analysieren, ob man Vorteile durch die Verwendung von Workflows erzielen kann. Was die Kerngebiete des KM Systems betrifft, mag es durchaus Sinn machen, optional Workflows anzubieten. Schließlich engen solche Abläufe nicht nur ein sondern k¨ onnen auch unterst¨ utzen und helfen. Die zwangsweise Verwendung eines Workflows im Kern des KM Systems muss aber die absolute Ausnahme sein. Man sollte sich insgesamt auch vor Augen halten, dass nur motivierte Mitarbeiter ein KM System mit Leben erf¨ ullen können. Sie m¨ ussen die Vorteile und den Sinn des Systems einsehen. Weiters muss es Ihnen auch tatsächlich bei der Arbeit helfen. Alle diese Aspekte kann ein zu rigides System leicht zerst¨ oren. Es reicht dabei sicher nicht, wenn ein Chef“ der Meinung ist, dass ” das System noch flexibel genug ist. Wenn sich eine nennenswerte Anzahl von potenziellen Nutzern eingeschr¨ ankt f¨ uhlt, ist es anzuraten, den entsprechenden Systemteil zu ¨ andern. Das ist nat¨ urlich schwierig, wenn man die Kosten niedrig halten will. Gleichzeitig sollte man im Zweifelsfall eher auf ein paar Erweiterungen des KM Systems verzichten, als ein von vornherein zu unflexibles System zu erschaffen“. ” 8.5.3 Workflows mit einer gewissen N¨ ahe zur KM Initiative Diese Kategorie von Abl¨ aufen l¨ asst sich nicht wirklich scharf von den anderen beiden abgrenzen. Bis zu einem gewissen Grad wurde sie auch schon im vorigen Abschnitt als Randthemen behandelt. Es geht dabei um Workflows, denen man eine gewisse inhaltliche N¨ ahe zum KM System oder der KM Initiative nicht absprechen kann, die aber gleichzeitig keine Kernprozesse darstellen. Zum Beispiel ist ein automatisierter Ablauf zur Dokumentenver¨ offentlichung im KM Systems durchaus aus einer theoretischen KM Sicht relevant. Gleichzeitig handelt es sich um einen (hoffentlich) eher simplen Ablauf, der die generelle Arbeit mit dem KM System nur am Rande ber¨ uhrt. Eine andere Kategorie sind Arbeitsabl¨ aufe, die indirekt eine Relevanz f¨ ur das KM System haben, aber nicht unmittelbar dazugehören. Eine Absenzendatenbank etwa wird potenziell einen (Genehmigungs-)Workflow haben. Dieser ist f¨ ur das KM System nicht wichtig. Die generelle Aussage u ugbarkeit be¨ ber die Verf¨ ziehungsweise Anwesenheit eines Mitarbeiters kann dagegen sehr interessant sein (insbesondere f¨ ur erweiterte Groupware Funktionen). Die beiden genannten Kategorien sind an sich die wesentlichen Gruppen, aus denen der Graubereich“ zwischen den beiden anderen Workflow” Kategorien besteht. Man erkennt auch, dass es jeweils Abgrenzungsschwierigkeiten zu der anderen Kategorie gibt. Es ist dabei auch gar nicht wesentlich, immer eine exakte Zuordnung treffen zu k¨ onnen. Wichtig ist, sich dieser unterschiedlichen Gruppen bewusst zu sein und bei der Analyse zur Sinnhaftigkeit eines Workflows auch eine entsprechende Einstufung zu ber¨ ucksichtigen.

212

8 Weiterer Ausbau

Aus einer KM Sicht sind dabei die Workflows, die ein Randthema des KM Systems adressieren, von untergeordneter Bedeutung. Sie können sehr wichtig f¨ ur die Effizienz und die operativen Kosten einer Organisation sein. F¨ ur den Kern einer KM Initiative sind sie nicht wesentlich. Daher sollte man hier vor allem u ¨ berlegen, ob sich ein entsprechender Einsatz lohnt und ob alle Anwendungsf¨ alle in einem noch relativ einfachen Ablauf abgedeckt werden k¨ onnen. Ob ein solcher Ablauf dabei einfach ist, hängt wesentlich von der Aufgabe und nicht von der absoluten Komplexität des Workflows ab. Die Workflows, denen man sich wesentlich intensiver widmen muss, sind die Vertreter der zweiten Untergruppe. Es geht also um Abläufe, die nicht direkt der KM Initiative zuzurechnen sind, aber in irgendeiner Weise (zum Beispiel das Ergebnis) einbezogen werden sollten. Hier wird empfohlen, die KM Aspekte bei der initialen Analyse einmal wegzulassen. In einer zweiten Phase sollte ¨ man diese aber komplett betrachten. F¨ ur den Benutzer relevante Anderungen braucht man nur in Ausnahmef¨ allen machen. Wesentlich wichtiger sind ¨ eventuelle technische Anderungen, um eine m¨ oglichst effiziente Verwendung im KM System zu erm¨ oglichen. Zusammengefasst kann man sagen, dass die zweite Gruppe von Abläufen relativ unabh¨ angig von der KM Initiative betrachtet werden sollte. Soweit es sich um Randgebiete des KM Vorhabens handelt, geht es eher um organisatorische und kostenrelevante Aspekte und weniger um KM selbst. Bei der Gruppe, der f¨ ur KM relevanten nicht-KM“ Abläufe, sollte man sich den KM ” Aspekten erst in einem zweiten Schritt n¨ ahern. Hier muss man aber entsprechend detailliert darauf eingehen. 8.5.4 Workflows f¨ ur die allgemeine Arbeit Bei der letzten großen Gruppe von Workflows handelt es sich um allgemeine Abl¨ aufe einer Organisation, die potenziell automatisiert werden. Wichtig ist vor allem f¨ ur jeden entsprechenden Workflow zu analysieren, ob die vorhandenen Daten Sinn f¨ ur das KM System machen oder nicht. Daraus ergibt sich eine entsprechende Unterteilung. Der eine Teil braucht an sich f¨ ur die KM Initiative nicht weiter betrachtet zu werden. Der andere Teil kann von großer Bedeutung sein. Schließlich handeln manche Firmen einen großen Teil ihrer Routinearbeit in entsprechenden Systemen ab. Der Fokus eines KM Systems liegt hier ganz klar in der Gewinnung und Zug¨ anglichmachung von Informationen. Daf¨ ur m¨ ussen sowohl vorhandene Workflows als auch neu geplante entsprechend analysiert und eventuell modifiziert werden. Wichtig sind dabei vor allem die folgenden Punkte: • • • •

ur das KM System (etwa Dokumente) Direkte Daten f¨ Indirekte Daten (etwa Benutzungsinformationen) Einbeziehen des KM Systems in den Workflow (etwa zur Entscheidungsunterst¨ utzung) Metadaten“ wie den Workflow selbst im KM System zur Verf¨ ugung stellen ”


213

Der sicherlich wichtigste Punkt ist das Einbeziehen der Informationen in das KM System. Wie schon ¨ ofter argumentiert wurde, ist das notwendig, um eine m¨ oglichst komplette Datenbasis f¨ ur das KM System zu haben. Gleichzeitig ist das auch ein im Allgemeinen technisch relativ einfacher Vorgang (Format und Datenmenge k¨ onnten noch am ehesten Schwierigkeiten verursachen). Je nach dem um welchen Ablauf es sich handelt, kann auch der zweite Aspekt (die indirekten“ Daten) von enormer Bedeutung f¨ ur das KM System ” sein. Es ist schwierig, hier besonders konkret zu werden. Die folgende (bis zu einem gewissen Grad willk¨ urliche) Aufz¨ ahlung sollte aber eine Reihe von Anhaltspunkten geben: • • • •

Kontextinformationen zu den Dokumenten, etc. bereitstellen (etwa eine Klassifizierung) Eine Bearbeitungshistorie zu Dokumenten haben Identifizierung von Rollen und Skills (aufgrund der Nutzung beziehungsweise des Treffens von Entscheidungen im Workflow) Eventuell Kommunikationsmuster innerhalb der Organisation entdecken

Ein weiterer (der dritte) Aspekt von Workflows ist die Einbeziehung von Funktionen des KM Systems in den Workflow. Hier kann es sich bis zu einem gewissen Grad auch um eine R¨ uckkoppelung handeln. Dadurch dass die Daten und eine eventuelle Klassifizierung von Dokumenten dem KM System bekannt sind, kann es potenziell Vorschläge zu einer Klassifizierung machen. Eine ganz andere Art der Unterst¨ utzung liegt in den Groupware Funktionen des KM Systems. Hier kann man Informationen mit anderen Mitgliedern der Organisation zum Beispiel in einem Forum austauschen. Direkter sind nat¨ urlich E-Mails oder eine noch unmittelbarere Kommunikation wie ein Chat (neben der simplen M¨ oglichkeit eines Telefonats etwa). Weiters können in vielen F¨ allen auch die abrufbaren Informationen (etwa in einem DMS oder einem Intranet) bei einer Entscheidungsfindung helfen und potenziell sogar direkt einbezogen werden. Beim letzten Aspekt von Workflows geht es um Metadaten“ des Work” flows selbst. Hierbei handelt es sich um die detaillierte Dokumentation eines Arbeitsablaufes einer Organisation. Dabei handelt es sich um hochwertige Informationen f¨ ur das KM System. Gleichzeitig wird man sie nicht in jedem Fall sinnvoll einsetzen k¨ onnen. Wenn keine unmittelbare Verwendung geplant ist, sollte man eher eine einfache M¨ oglichkeit f¨ ur den Zugriff zur Verf¨ ugung stellen und keine weiterf¨ uhrenden Schritte setzen. 8.5.5 Vorgehen bez¨ uglich Workflows & KM Nach der eingehenden Diskussion der unterschiedlichen Arten von Workflows und einem potenziellen Zusammenhang mit dem KM System muss vor allem noch untersucht werden, wie man konkret vorgehen kann. Dabei wird auch

214

8 Weiterer Ausbau

f¨ ur dieses Thema nur eine Art Anleitung gegeben, wie man so eine Analyse f¨ ur eine konkrete Organisation selbst durchf¨ uhren kann. Nat¨ urlich ist die wichtigste Frage wieder, wieweit die KM Initiative und damit das KM System gehen soll. Bei Workflows gibt es daneben noch zwei Aspekte, die man untersuchen sollte. Einerseits die vorhandenen Workflows einer Organisation. Andererseits Abl¨ aufe, die nicht direkt KM relevant sind, wo aber eine Automatisierung Sinn machen w¨ urde. Bei letzterer Kategorie geht es im Prinzip dann um die Analyse, ob es Sinn macht eine Verkn¨ upfung mit dem KM System zu schaffen. Damit hat man im Prinzip zwei unabh¨ angige Fragestellungen. Die eine ist, ob und wenn ja in welchem Ausmaß Workflows f¨ ur die KM Initiative direkt Sinn machen. Die andere, ob es sonst f¨ ur das KM System relevante Workflows oder M¨ oglichkeiten f¨ ur Workflows gibt. Bei diesem Punkt geht es auch um die Wechselwirkung, also die Frage ob das KM System einen nicht prim¨ ar KM-relevanten Workflow verbessern oder ermöglichen kann. Prinzipiell sollte man bei beiden Kategorien von Workflows eher vorsichtig sein. Das Hauptgewicht einer KM Initiative sollte nicht auf Automatisierung gelegt werden. Wissen ist nicht in EDV-Systemen und daher kann eine Automatisierung auch nie Wissen generieren oder dazu verhelfen. Gleichzeitig kann man nat¨ urlich eine deutliche Effizienzsteigerung erzielen. Weiters kann man durchaus sehr wichtige Hilfestellungen f¨ ur den Benutzer bieten. Was die Kategorie der direkt KM-relevanten Workflows angeht, m¨ ussen immer die wissensrelevanten Prozesse im Vordergrund stehen. Davon ausgehend kann man u ¨berlegen, welche Automatisierung dem Nutzer Arbeit abnimmt und seine Aufgaben erleichtert. Es geht dabei selbstverständlich um eine m¨ oglichst effiziente Benutzung des KM Systems. Gleichzeitig muss ¨ man sich immer der Gefahr der Uberregulierung“ bewusst sein. Anders ge” sagt muss immer die M¨ oglichkeit eines alternativen Weges vorhanden sein. Bis zu einem gewissen Grad sollte man auch Abläufe erst nach einer Phase ¨ des Experimentierens der Nutzer festlegen. Die folgende Ubersicht versucht, die wichtigsten Fragestellungen/Themen f¨ ur direkt KM-relevante Workflows zusammenzufassen: • • • • •

Der eigentliche Zweck der KM Initiative muss immer Vorrang vor reinen Effizienz- und Kosten¨ uberlegungen haben (Wissen ist in Menschen nicht in der EDV). Daraus folgt, dass Workflows f¨ ur unmittelbare KM-Prozesse eine Unutzungsfunktion haben m¨ ussen. terst¨ Entweder Workflows f¨ uhren den Benutzer zu seinem Ergebnis. Oder sie unterst¨ utzen bei der Suche/Benutzung. Starre Abl¨ aufe sind eher kein Thema f¨ ur ein KM System (und nicht umgekehrt ein Argument f¨ ur Workflows in KM Systemen) können aber durchaus sinnvoll verkn¨ upfbar sein (in beide oder eine der beiden Richtungen).

Anders gesagt muss man zwei Dinge tun. Einerseits alle sich anbietenden Abl¨ aufe anhand der Fragestellungen analysieren und bewerten. Andererseits


215

am Ende der Analysephase noch nach m¨ oglichen Hilfestellungen durch Automation suchen. Auch im zweiten Fall muss man nat¨ urlich entsprechende Abw¨ agungen durchf¨ uhren. Als Ergebnis sollte man eine eher kleine Anzahl von Kern- beziehungsweise Unterst¨ utzungsprozessen haben, die automatisiert werden k¨ onnen. Bei den nicht direkt KM-relevanten Abl¨ aufen sind die Aspekte Effizienz und Kosten nat¨ urlich besonders wichtig. Auch die Erzwingung von gewissen Abl¨ aufen (zum Beispiel aufgrund gesetzlicher Verpflichtungen) kann eine Motivation sein. F¨ ur das KM System sind diese Punkte nicht wichtig. Unmittelbar relevant ist hier die Frage, welche Daten und Informationen das KM System von den Workflows bekommen und was man damit tun kann. Umgekehrt ist die Frage interessant, welche zusätzlichen Möglichkeiten ein Workflow aufgrund der Daten und Funktionen des KM Systems hat. Vorhandene Workflows einer Organisation sollten in jedem Fall eingehend analysiert werden. Auch wenn es f¨ ur das KM System gar keine entsprechende Automatisierungsfunktionalit¨ at geben sollte, darf man keine potenziell relevante Informationsquelle f¨ ur ein umfassendes KM System außer Acht lassen. Wenn die Funktionalit¨ at und der Umfang des KM Systems schon relativ klar sind, sollte man zwei Dinge tun. Erstens die vorhandenen Workflows noch einmal ansehen und untersuchen, ob das KM System qualitative oder quantitative Verbesserungen erm¨ oglicht. Zweitens f¨ ur potenzielle Automatisierungskandidaten analysieren, ob das KM System einen Workflow erleichtern oder erm¨ oglichen kann. Durch diese letzte Kategorie können dann auch wieder zus¨ atzliche Informationen f¨ ur das KM System verf¨ ugbar werden. Kurz gesagt sollte man alle vorhandenen Workflows analysieren, um festzustellen, ob sie relevante Informationen f¨ ur das KM System liefern können. ¨ Detaillierte Uberlegungen dazu wurden auch schon vorgestellt. Weiters sollte man f¨ ur vorhandene wie auch f¨ ur potenzielle neue Workflows analysieren, ob eine Einbeziehung von Informationen und/oder Funktionen des KM Systems sie wesentlich verbessern k¨ onnte. F¨ ur neu einzuf¨ uhrende Workflows ist dann urlich wieder eine Untersuchung n¨ otig, ob man zus¨ atzliche f¨ ur das KM nat¨ System relevante Daten erhalten kann. 8.5.6 Vorhandene Open Source Basis Nach der intensiven Betrachtung inwieweit man Workflows f¨ ur KM Systeme einsetzen beziehungsweise unterst¨ utzen kann, stellt sich die Frage, was in der Open Source Welt verf¨ ugbar ist. Wie bei allen Beschreibungen in diesem Kapitel geht es weniger um eine Darstellung von möglichst vielen verf¨ ugbaren Systemen als um eine Diskussion von ausgew¨ ahlten, relevanten Systemen. Die beiden n¨ aher betrachteten Kandidaten wurden dabei schon in Abschnitt 3.5.5 vorgestellt. Je nach der eigentlichen Ausformung des geplanten KM Systems wird man einen guten Kandidaten finden oder anderweitig suchen m¨ ussen. Daneben wird auch noch kurz auf Workflowfunktionalität in anderen schon vorgestellten Systemen eingegangen.

216

8 Weiterer Ausbau

Die allgemeinen Aspekte von Workflows sind dabei schon sehr detailliert behandelt worden. Außerdem sind sich die beiden beschriebenen Workflow Engines sehr ¨ ahnlich. Daher wird darauf verzichtet, extra auf die organisatorischen Aspekte bei den Beschreibungen einzugehen. Vielmehr wird noch ¨ einmal ein grober Uberblick u ¨ ber die beiden Systeme gegeben. Je nachdem wie das konkrete KM System aussehen soll, muss f¨ ur eine Entscheidung noch eine eigene Analyse mit Kosten-/Nutzenrechnung durchgef¨ uhrt werden. OpenWFE Bei der Open Workflow Engine“ (OpenWFE) handelt es sich wie der Name ” schon sagt um eine prim¨ ar Java basierte Workflow Engine. Prinzipiell ist sie f¨ ur die Einbindung in andere Systeme gedacht und bietet dementsprechend eine Reihe von Integrationsm¨ oglichkeiten. Die wichtigsten Eckpunkte sind die Möglichkeit eigenen Code als Teil des Workflows ausf¨ uhren zu lassen (Java, Jython oder Python Code) beziehungsweise u ¨ ber ein Web Service (REST) oder C# Interface auf die Engine zuzugreifen. Die verwendete Lizenz ist BSDahnlich und damit sehr offen. ¨ Insbesondere auch im Unterschied zum zweiten diskutierten System gibt es noch einen Webclient zum Definieren der Workflows. Dieser kann eine wichtige Hilfestellung sein, sollte aber nicht als Entscheidungskriterium verwendet werden. Solche Definitionen werden nur von wenigen Leuten gemacht. F¨ ur diese ist so ein Komfort nicht zu verachten, sollte aber ein bestenfalls zweitrangiges Thema sein. Der vielleicht wichtigste Punkt des Systems ist, dass man relativ komplexe Abl¨ aufe mit dem System direkt abbilden kann. Zusätzlich geben die integrierbaren eigenen Codest¨ ucke die M¨ oglichkeit einer Einbindung in das KM System (in beide Richtungen). Die extern zug¨ anglichen Interfaces sind zwar zum Teil etwas ungew¨ ohnlich (in der Auswahl beziehungsweise der Zusammenstellung) aber prinzipiell in Ordnung. OSWorkflow Bei OSWorkflow handelt es sich ebenfalls um eine Java basierte Workflow Engine. Dieses Produkt setzt dabei st¨ arker auf vorhandener Software auf. Es wird etwa das Toolkit OSCore als Basis verwendet und optional OSUser f¨ ur die Benutzerverwaltung (diese Beispiele sind von derselben Quelle wie OSWorkflow selbst). Weiters wird auch die Open Source Scheduling Lösung Quartz benutzt. Das Produkt unterliegt dabei den Bestimmungen der APL. Obwohl es sich um Open Source Software handelt, wird eine kommerzielle Lösung f¨ ur das optionale SOAP Interface eingebunden. Dabei handelt es sich um GLUE (von WebMethods) das nur eingeschränkt ohne Lizenz verwendbar ist. Hier gibt es allerdings den Hinweis auf die Möglichkeit, ein alternatives Open Source Tool zu verwenden (mit entsprechendem Aufwand).


217

Nat¨ urlich besteht wie bei OpenWFE die M¨ oglichkeit, eigenen Code in den Workflow zu integrieren. Hierbei gibt es eine Reihe von Alternativen (Java, diverse Scriptingm¨ oglichkeiten oder etwa OSWorkflow Utility Functions) und M¨ oglichkeiten sich einzuklinken (Trigger, Bedingungen, Berechtigungen, Validatoren oder Auto Funktionen). F¨ ur das Erstellen von Workflows wird ein eigener Editor, der entsprechende Dateien erstellt (Java Swing basierend), angeboten. Intern verwendet diese Engine rein XML und entsprechend arbeitet auch der GUI Designer. Verglichen mit OpenWFE ist der Ansatz sehr ähnlich. Beide Systeme zielen darauf ab, integriert zu werden, und sind ganz oder in größeren Teilen in Java geschrieben. Bei OSWorkflow werden wesentlich mehr weitere Open Source Libraries verwendet. Das kann potenziell ein Vorteil sein (muss es aber nicht). Weiters ist OSWorkflow auch st¨ arker auf Java konzentriert als OpenWFE. Ein Faktum das man bei einer Analyse entsprechend ber¨ ucksichtigen sollte. Workflowunterst¨ utzung in vorgestellten Systemen Neben separaten Workflow Engines bieten auch andere Systeme Workflowfunktionalit¨ at. Wie schon erw¨ ahnt hat etwa praktisch jedes CMS einen gewissen Workflow. Dasselbe gilt f¨ ur DMS Systeme. Gleichzeitig soll auf die einfacheren Vertreter hier nicht n¨ aher eingegangen werden, da sich diese kaum als gr¨ oßere Workflowl¨ osung eignen. Beschrieben werden dagegen etwas allgemeinere L¨ osungen, die je nach Aufgabenstellung f¨ ur kleinere bis mittlere Workflows geeignet sein k¨ onnten. Ein insgesamt relativ interessanter Vertreter f¨ ur kleinere bis mittlere L¨ osungen ist dabei Tiki. Es ist prim¨ ar eine PHP basierte Mischung aus Groupware und CMS System mit nur mittelm¨ aßiger Groupwarefunktionalität (siehe Abschnitt 3.2.5 f¨ ur weitere Details). Zus¨ atzlich gibt es aber noch die Integration einer Workflow Komponente (http://www.openflow.it/). Es handelt sich dabei um eine Zope/Python basierte Entwicklung, die auf der GPL beruht. F¨ ur eine externe Verwendung gibt es die M¨ oglichkeit XML/XMLRPC zu verwenden. Eine Integration ist u ber eine Reihe von Datenbanken relativ einfach ¨ zu bewerkstelligen. Interessant ist das Konzept einer Exception (wenn etwas nicht Definiertes in einem Workflow passiert) und die Möglichkeit, auch geonnen. Insgesamt eine relativ flexible rade ausgef¨ uhrte Workflows a ¨ndern zu k¨ L¨ osung, die Tiki noch interessanter macht. Die gerade beschriebene Workflow Engine Openflow ist dabei keine Tiki Entwicklung. Dort wird sie nur u ¨ ber die so genannte Galaxia Komponente integriert. Direkt entwickelt wurde die Engine f¨ ur Zope, den Python Application Server. Damit gibt es mit Plone noch ein zweites relativ interessantes System, das mit dieser Workflow Engine aufgewertet wird. Nat¨ urlich gilt diese Aussage auch f¨ ur elevateIT, dass ja eine Erweiterung von Plone ist. Auch bei dieser Darstellung geht es nicht um Vollständigkeit. Vielmehr soll aufgezeigt werden, welche Tools noch eine relativ prominente Workflow

218

8 Weiterer Ausbau

Komponente dabei haben. Streng genommen wurde ja auch nur eine einzige weitere Workflow Engine betrachtet. Wer an zusätzlichen Informationen interessiert ist, findet zum Beispiel auf der Webseite http://www.topicus.nl/ topwfm/Tooloverzicht.htm (besucht am 27. Februar 2006) eine kurze Beschreibung weiterer Open Source Workflow Engines und Tools. 8.5.7 Zusammenfassung Der relativ lange Abschnitt u ¨ber Workflowfunktionen in einem KM System zeigt das bestehende Spannungsfeld. Es gibt dabei keine eindeutige Lösung sondern nur Anhaltspunkte, wie man sich am besten verhalten sollte. Eine wichtige Hilfestellung ist dabei eine Aufteilung in drei Kategorien: 1. Workflows als Teil des KM Systems und mit unmittelbarer Relevanz f¨ ur das KM System. 2. Workflows die entweder als Randthema der KM Initiative oder indirekt eine gewisse Relevanz f¨ ur das KM System haben. 3. Workflows die eventuell eine Datenquelle sein können und/oder von dem KM System profitieren k¨ onnen. Insbesondere bei der ersten Kategorie sollte man sehr vorsichtig sein, da ein zu starres Herangehen an KM sicher nicht zum Ziel f¨ uhren wird. Die anderen beiden Kategorien sind dagegen weniger kritisch aber auch weniger wichtig f¨ ur das KM System. Im weiteren Verlauf des Abschnitts wird dann noch näher gezeigt, wie man mit Workflows in einem KM Kontext umgehen sollte. Insbesondere dass man sehr wohl u ¨ berlegen soll, wie man mit Workflows die Benutzung und die Effizienz verbessern kann. Gleichzeitig muss aber immer der wissensintensive KM-Prozess beziehungsweise das zu erreichende Ziel im Vordergrund stehen. Man sollte sich immer vor Augen halten, dass Menschen Wissen haben und nicht etwa ein EDV-System. Auf dieser Basis aufbauend muss man wieder eine entsprechende Analyse aller vorhandenen und potenzieller Workflows durchf¨ uhren. Was vorhandene Open Source Workflow Engines angeht, werden drei Produkte exemplarisch vorgestellt. Zwei davon sind Java basierend und daf¨ ur vorgesehen integriert zu werden. Das Dritte basiert auf Python und ist in verschiedene schon fr¨ uher vorgestellte Systeme integriert. Alle drei Vertreter sind durchaus einen n¨ aheren Blick Wert. Gleichzeitig sollte man aber von den angedachten Workflows und nicht der vorhandenen Funktionalität ausgehen.

8.6 Eingehen auf spezielle eLearning Anforderungen Wie schon in Abschnitt 2.1.1 aufgezeigt wurde, ist es schwierig zu sagen, ob eLearning ein Teil von KM ist oder nicht. Praktisch betrachtet ist das aber

8.6 Eingehen auf spezielle eLearning Anforderungen

219

gar nicht so wichtig. Insbesondere kleine Organisationen werden allerdings typischerweise keinen Bedarf f¨ ur eine eLearning Unterst¨ utzung im KM System haben. Gleichzeitig handelt es sich um ein sehr interessantes Gebiet. Bei einer praktischen Umsetzung bietet es sich sehr wohl an, eine Integration mit/in einem KM System zu implementieren. Dabei gibt es eine Reihe von wichtigen Punkten, die dieser Abschnitt kurz beleuchten wird. Eine Vorstellung oder Analyse von Open Source Systemen f¨ ur eLearning wird es dagegen nicht geben. Dies w¨ urde den Rahmen und Umfang dieses Buches sprengen und ist auch eine potenzielle Erweiterung, die nur von einer Minderheit der prinzipiell angesprochenen Organisationen ben¨ otigt wird (kleine Organisationen haben zwar auch immer wieder Schnittpunkte mit eLearning typischerweise aber keinen umfassenden Bedarf). Daf¨ ur wird noch kurz diskutiert, inwieweit sich schon vorgestellte Systeme oder Systemkategorien f¨ ur eLearning nutzen lassen. 8.6.1 eLearning Definition Bevor n¨ aher auf eLearning eingegangen wird, ist es wichtig, eine Definition von eLearning zu geben. Das ist wesentlich schwieriger als man auf den ersten Blick meinen sollte. Es wird zwar von vielen Leuten u ¨ ber eLearning gesprochen, es gibt aber keine Definition, die von einer Mehrheit der Spezialisten und Forscher akzeptiert w¨ are. Bis zu einem gewissen Grad ist durch das e“ vor Learning nat¨ urlich ” der Aspekt der technischen Unterst¨ utzung des Lernens offensichtlich. Insbesondere in Hinblick auf das Internet. Gemeinsam ist den meisten Definitionen weiters die Bereitstellung von Informationen (Dokumenten) und die Unterst¨ utzung des Lernens selbst mit den M¨ oglichkeiten der EDV. Insbesondere f¨ ur das Lernen auf Entfernung beziehungsweise in Gruppen, die sich physisch nicht oder nur selten treffen. Weiters gibt es den j¨ ungeren Trend, so genanntes Blended Learning“ ” zu erm¨ oglichen und zu unterst¨ utzen. Dabei geht es im Prinzip um die Erkenntnis, dass Lernen auf Distanz und nur mit elektronischen Hilfsmitteln nicht besonders gut funktioniert. Daher versucht man beim Blended Learning, die Techniken und Ans¨ atze des eLearning um menschliche Interaktionen zu erweitern. Ein einfaches Beispiel sind physische Treffen einer Lerngruppe mit einem Tutor. Insgesamt betrachtet gibt es zwei wichtige Trends im eLearning. Einerseits das sogenannte technology-enhanced learning“, das mittels EDV ” versucht traditionelles Lernen zu unterst¨ utzen. Andererseits das sogenannte technology-delivered learning“, das versucht möglichst viele Aspekte in ” der EDV abzubilden und eher untypische Lernsituationen adressiert. Zusammengefasst kann man sagen, dass eLearning ein wenig diffus definiert ist. Im Prinzip geht es um die Ausnutzung der neuen Möglichkeiten der EDV (insbesondere des Internets), um klassisches Lernen zu unterst¨ utzen und

220

8 Weiterer Ausbau

neue M¨ oglichkeiten zu er¨ offnen. Ein Punkt, der auch f¨ ur KM selbst gilt, wird durch den Trend des Blended Learning“ gut illustriert. Eine rein technische ” L¨ osung ist zumindest aktuell nicht ausreichend, um wissensintensive Prozesse zu unterst¨ utzen oder abzubilden. Gleichzeitig kann die EDV eine umfassende Unterst¨ utzung bieten. ¨ 8.6.2 Interessante Uberschneidungen von eLearning mit KM Wenn man eLearning generell betrachtet, dann gibt es eine Reihe von Aufgaben, die zu l¨ osen sind. Dabei sind manche sehr spezifisch, während andere eher von allgemeinerer Natur sind. Die folgende Aufzählung versucht einen ¨ Uberblick u ¨ber die (potenziellen) Aufgaben von eLearning zu bieten: • • • • •

Erstellen des eigentlichen Lernmaterials: Eine der wichtigsten Aufgaben beim eLearning u ¨ berhaupt Das Anbieten des Materials Kommunikationsm¨ oglichkeiten zwischen Lehrenden und Lernenden Verwaltungs-/Administrationsfunktionen (etwa Lehrpläne und Informationen u ¨ber besuchte Kurse) Kommunikationsangebot zwischen den Lernenden beziehungsweise f¨ ur eine Gruppe mit dem/den Lehrenden

¨ Die genannten Punkte pr¨ asentieren dabei die Uberschneidungen mit KM aus einer praktischen“ Perspektive und werden im folgenden Text näher un” tersucht. Vor diesen Aspekten soll aber noch eine kurze etwas theoretischere“ ” Betrachtung angestellt werden. Dabei geht es um die Fragestellung, ob eLearning Teil von KM ist oder nicht. Die einfache Antwort ist sicherlich, dass es technisch betrachtet einige Unterschiede gibt. Wenn man es sich nicht so einfach macht, gelangt man zu dem Punkt, dass sowohl eLearning als auch KM versuchen das Lernen zu unterst¨ utzen. Das steht bei KM (insbesondere bei den technischen Fragen) weniger im Vordergrund, ist aber sehr wichtig. Dieser Argumentation folgend ist man geneigt, eLearning als eine KM Anwendung zu definieren. Gleichzeitig ist eLearning aber weniger auf das im Zentrum von KM stehende Lernen ausgerichtet. Bei eLearning gibt es vorbereitete Materialien und jemanden der die Antwort kennt“. KM setzt dagegen dort an, wo die Antwort entweder ” nicht bekannt oder alternativ unklar ist, wie man zu ihr kommt. Die Lösung in KM kann darin bestehen, einen Lernprozess mit unklarem Ergebnis zu unterst¨ utzen oder auch einen Experten f¨ ur ein Thema zu lokalisieren. Kurz gesagt gibt es einen sehr engen inhaltlichen Zusammenhang von eLearning und KM. Auf einer praktischeren Ebene gibt es aber auch wesentliche Unterschiede. Daher ist es schon prinzipiell schwierig zu entscheiden, ussen oder ob explizite eLearning Funktionen Teil eines KM Systems sein m¨ nicht. Im Kontext von kleineren und mittleren KM Initiativen wird man die Frage nach dem Muss sogar klar verneinen. Gleichzeitig gibt es technisch eine


221

Reihe von (potenziellen) Gemeinsamkeiten, die im Weiteren näher dargestellt werden. Erstellung des Lernmaterials Der erste Punkt dabei ist f¨ ur eLearning sehr wichtig, kann aber nur eingeschr¨ ankt von einem reinen“ KM System adressiert werden. Es gibt daf¨ ur ” recht ausgefeilte eigene Softwaresysteme. Diese sollte man auch unbedingt nutzen, soweit es sich nicht um eine relativ einfache Informationsweitergabe handelt. Vor allem ist hier didaktisches Wissen gefragt und eine entsprechende Unterst¨ utzung durch das Tool. Ein KM System hat typischerweise keine entsprechenden Funktionen, sollte so ein Tool aber wenn möglich integrieren. Wichtig ist vor allem das Einbeziehen solcher zum Teil sehr aufwendig erstellter Unterlagen in die Menge der vorhandenen Informationen. Anbieten des Materials Der Aspekt des zur Verf¨ ugung stellen von eLearning Material kann auf ganz unterschiedliche Weise abgedeckt werden. F¨ ur eLearning ist es vor allem wichtig, die Unterlagen m¨ oglichst in einem Lernkontext anzubieten. Das kann etwa ein allgemeiner oder auch pers¨ onlicher Lern-/Ausbildungsplan sein. F¨ ur ein KM System ist es wichtig, die Zuordnung zu gewissen Themen zu haben. Das prinzipielle Anbieten solcher Informationen stellt auch kein Problem dar. Besonders eignen sich hier CMS beziehungsweise DMS Funktionen. Typischerweise ist die gebotene Funktionalit¨ at mit einer spezialisierten eLearning Software auch durchaus vergleichbar. Kommunikationsm¨ oglichkeiten Eine gute eLearning Software muss weiters eine Reihe von unterschiedlichen Kommunikationsm¨ oglichkeiten zwischen den Lernenden und den Lehrenden anbieten. Dabei h¨ angt der notwendige Umfang von der konkret unterst¨ utzten eLearning Variante“ ab und kann daher stark differieren. Insgesamt aber ” ist es wichtig und notwendig, sowohl strukturierte als auch unstrukturierte Kommunikation anzubieten. Das passt an sich sehr gut zu den Funktionen des KM Systems. Groupware und CMS zusammen bieten eine Vielfalt an M¨ oglichkeiten zur Unterst¨ utzung an. Allerdings kann das Schwergewicht hier durchaus unterschiedlich sein. Verwaltungs-/Administrationsm¨ oglichkeiten Nat¨ urlich ben¨ otigt eine eLearning L¨ osung auch diverse Verwaltungs- und Administrationsfunktionen. Je nachdem wie umfassend die eLearning Unterst¨ utzung und die Realisierung der anderen Funktionen sind, kann es hier

222

8 Weiterer Ausbau

große Unterschiede geben. Gleichzeitig handelt es sich um eine Anforderung, die kaum bis gar nicht in einem bisher beschriebenen KM System abgedeckt ¨ wird. In diesem Punkt gibt es sicherlich nur sehr geringe Uberschneidungen zwischen eLearning und KM. Bei entsprechendem Bedarf ist nat¨ urlich eine Integration empfehlenswert, da die Informationen sehr interessant und relevant f¨ ur ein KM System sind. Schließlich geht es um Zusammenhänge zwischen Themen, F¨ ahigkeiten einzelner Mitarbeiter und vieles mehr. Kommunikationsangebot Prinzipiell ist die Frage des Kommunikationsangebots zwischen den Lernenden beziehungsweise in einer Gruppe mit Lehrenden ganz ähnlich zu den Kommunikationsm¨ oglichkeiten mit einem Lehrenden im Zentrum. Es gibt allerdings einerseits einen wichtigen fachlichen Unterschied und andererseits liegt f¨ ur die technische Realisierung der Schwerpunkt woanders. Es geht hier mehr um die einfache Kommunikation einer Gruppe potenziell auch ohne Lehrenden. Hierf¨ ur eignen sich strukturierte Kommunikationsmethoden kaum. Leider sind Groupware beziehungsweise CMS L¨ osungen aktuell noch weniger auf Online“-Konferenzen (mit oder ohne Bild) ausgerichtet. Gleichzeitig ist aber ” absehbar, dass entsprechende Erweiterungen immer besser und immer mehr werden. In Zukunft k¨ onnten sowohl f¨ ur KM als auch eLearning Peer-2-Peer (P2P) L¨ osungen interessanter werden. Auch aktuell ist diese Technologie sicher f¨ ur eine Reihe von Anwendungen sehr sinnvoll. Zusammenfassung ¨ Insgesamt geht es einerseits um die Frage der Uberschneidungen von eLearning mit KM und andererseits um praktische Aspekte. Bei einer prinzipiellen Betrachtung kann man eine Artverwandtheit von eLearning und KM durchaus feststellen. Allerdings gibt es konkret wesentliche Unterschiede im Rahmen dieses Buches. Daher besteht sicher keine Notwendigkeit einer Integration. Sinnvoll kann sie aber sehr wohl sein. Aus einer mehr praktischen Sichtweise heraus gibt es vor allem zwei Aspekte, die ein KM Systeme, wie es bisher beschrieben wurde, kaum abdeckt. Einerseits das Erstellen des Lernmaterials und andererseits eLearning spezifische Verwaltungs- und Administrationsfunktionen. Bei entsprechendem Bedarf sollte man hier eine Integration von schon existierenden Funktionen ins Auge fassen. Was das Anbieten der Materialen und der verschiedenen Kommunikationsm¨ oglichkeiten zwischen Lehrenden und Lernenden sowie Lernenden untereinander betrifft, hat ein KM System eine ganze Menge zu bieten. Wenn die eLearning Bed¨ urfnisse nicht zu speziell sind, sollte es kein Problem sein, mit vorhandenen Funktionen das Auslangen zu finden.


223

8.6.3 eLearning- Angebot“ von schon vorgestellten Systemen ” Wie schon im letzten Abschnitt beschrieben, können einige der eLearning Anforderungen direkt von Groupware, CMS und/oder DMS Systemteilen adressiert werden. Dabei gibt es prim¨ ar Unterst¨ utzung f¨ ur verschiedene Formen der Kommunikation und des Anbietens der Lernmaterialien. Der Schwerpunkt von Groupware liegt klar in der unstrukturierten Kommunikation, während CMS Funktionen eher das Anbieten der Materialien und der strukturierten Kommunikation abdecken. Gleichzeitig sind das sehr generelle Aussagen, die so nat¨ urlich nicht f¨ ur jedes einzelne System gelten. Groupware Systeme Die gemeinsame Funktion aller (in Abschnitt 3.2 vorgestellten) Groupware Systeme ist nat¨ urlich die Unterst¨ utzung des E-Mail Versandes und Empfangs und damit der aktuell beliebtesten Form der unstrukturierten Kommunikation. Bis auf Tiki unterst¨ utzen auch alle eine Adressverwaltung. Weiters bieten sämtliche Systeme bis auf Kolab/Kroupware und PhpGroupWare eine Unterst¨ utzung f¨ ur eine Dateiverwaltung in der einen oder anderen Form. Damit ist auch eine M¨ oglichkeit zum Anbieten der Materialien und einem generellen Dateiaustausch gegeben. Eine weitere Funktion von allen Systemen ist ein Gruppenkalender, den man zum Beispiel f¨ ur Terminvereinbarungen nutzen kann. Neben den offiziellen Terminen nat¨ urlich auch f¨ ur inoffizielle Treffen abseits“ der Lehrenden. ” Bei den drei PHP basierten L¨ osungen gibt es dar¨ uber hinaus noch einige interessante Funktionen, die man allgemein eher bei den CMS Systemen findet. Es handelt sich dabei insbesondere um Foren, Wikis und eine Möglichkeit f¨ ur einen Chat. Also eine Unterst¨ utzung von strukturierter Kommunikation sowie ganz ungezwungener direkter Verst¨ andigung. Dar¨ uber hinaus gibt es auch M¨ oglichkeiten zur Publizierung von Inhalten und zum Beispiel Abstimmungen (k¨ onnte etwa f¨ ur Termine sinnvoll sein). Kurz gesagt bieten Groupware Systeme eine ganze Reihe von interessanten und relevanten Funktionen f¨ ur eLearning. Insbesondere wenn auch CMS Funktionen direkt unterst¨ utzt werden. F¨ ur eine Bewertung muss man aber immer das gesamte KM System heranziehen, daher d¨ urfte dieser Aspekt in den meisten F¨ allen nicht besonders wichtig sein. CMS Systeme Bei dieser in Abschnitt 3.3 beschriebenen Kategorie gibt es eine große Anzahl von Vertretern. Trotzdem bestehen es in Hinblick auf eLearning eine Reihe utzen das Anbieten von von Gemeinsamkeiten. Praktisch alle Vertreter unterst¨ Artikeln, Dateien und damit das Anbieten von Informationen.

224

8 Weiterer Ausbau

Zur strukturierten Kommunikation bieten viele der Systeme auch Foren an. Dabei handelt es sich um Plone, elevateIT, JBOSS Portal, Mambo/Joomla, XOOPS und phpWebSite. Zus¨ atzlich gibt es teilweise eine schnelle Weiterentwicklung und eine kaum u ¨ berschaubare Zahl an Zusatzmodulen. Daher geh¨ oren vielleicht sogar noch mehr Systeme zu dieser Kategorie. Zur unstrukturierten Kommunikation dienen insbesondere E-Mail und Chat. Die folgenden Systeme haben zumindest eine der beiden Funktionen: Plone, elevateIT, Typo3 und XOOPS. Weiters gilt auch hier die Einschr¨ ankung, dass weitere Systeme in der Zwischenzeit durchaus entsprechende Unterst¨ utzung haben k¨ onnten. Neben den genannten Funktionen gibt es zum Teil noch Groupware Funktionalit¨ aten als Teil der CMS Systeme. Besonders hilfreich sind dabei Adressb¨ ucher und Gruppenkalender. Die folgenden Systeme bieten eine entsprechende Funktionalit¨ at: OpenCMS, Mambo/Joomla und XOOPS. Auch hier stellt die Liste eine Momentaufnahme dar. Was dar¨ uber hinaus f¨ ur eLearning noch sehr hilfreich sein kann (aber nicht muss) ist die Bereitstellung von Wikis. Hierbei handelt es sich um eine j¨ ungere Entwicklung, die daher noch keinen direkten Eingang in viele Systeme gefunden hat. Unmittelbar verf¨ ugen Plone, elevateIT und Xaraya dar¨ uber. Weiters gibt es externe Module wie auch schon in Abschnitt 8.4.3 beschrieben. Insgesamt stellt sich die Situation bei CMS Systemen weniger einheitlich als bei Groupware L¨ osungen dar. Dies liegt vor allem an den sehr unterschiedlichen Zielrichtungen der CMS Systeme. Die Unterst¨ utzung f¨ ur die Bereitstellung von Informationen findet man eigentlich in allen Produkten. Weiterf¨ uhrende M¨ oglichkeiten f¨ ur strukturierte und unstrukturierte Kommunikation bieten nicht alle aber immerhin die meisten Vertreter. Ebenfalls vorhanden sind Groupware Funktionen wie E-Mail, Adressen und Termine. Das ¨ wird aber nur von einer Minderheit angeboten. Uberhaupt noch recht selten ist die direkte Unterst¨ utzung von Wikis, die eine interessante Möglichkeit sind, Zusammenarbeit bei eLearning zu unterst¨ utzen. DMS Systeme DMS Systeme, wie die in Abschnitt 3.4 beschriebenen, bieten nur sehr eingeschr¨ ankte Unterst¨ utzung f¨ ur eLearning. Daher machen sie nur im Kontext eines umfassenderen KM Systems Sinn. Gleichzeitig sind sie sehr gut f¨ ur die Verwaltung aller eLearning relevanter Dateien geeignet, da sie eine gute Ordnung mit G¨ ultigkeitszeitr¨ aumen erm¨ oglichen und alte Versionen verf¨ ugbar machen. Die prim¨ are Unterst¨ utzung eines DMS Systems f¨ ur eLearning besteht in der Verwaltung aller Dateien. Insbesondere nat¨ urlich der Lernmaterialien, die etwa u onnen. Diese Grundfunktionalität ¨ber das Internet angeboten werden k¨ bieten auch alle Systeme an (verschiedene Einschränkungen dieser Lösungen wurden schon in Abschnitt 7.3.6 diskutiert).


225

Dar¨ uber hinaus bieten einige Systeme wie docman, KnowledgeTree, OWL ¨ und Paper Harbour noch Benachrichtigungen bei der Anderung oder Erstellung von Dokumenten. Eine eher seltene Funktion findet man mit Diskussionsforen bei KnowledgeTree. Das ist f¨ ur eLearning nat¨ urlich besonders interessant. Kurz gesagt bieten DMS System vor allem Möglichkeiten f¨ ur das Anbieten von Informationen. Dar¨ uber hinaus gibt es in Einzelfällen noch Benachrichtigungen oder Diskussionsforen als weitere f¨ ur eLearning relevanten Funktionen. Damit ist klar, dass DMS Systeme nur eine ergänzende Rolle spielen k¨ onnen und eine Reihe weiterer Aspekte von anderen Systemen oder Systemteilen abgedeckt werden m¨ ussen. Zusammenfassung Dieser Abschnitt hat das Angebot an eLearning relevanten Funktionen bei den in Kapitel 3 vorgestellten Systemen analysiert. Wichtig ist dabei, jeweils das gesamte geplante KM System zu bewerten und nicht Einzelwertungen zu u ¨ bernehmen. Trotzdem sieht man, dass DMS Systeme nur eine Randstellung innehaben und erst im Kontext eines gr¨ oßeren Systems einen wirklich sinnvollen Beitrag leisten k¨ onnen. Bei den Groupware und CMS Systemen sind es nat¨ urlich insbesondere die Zwitter“-Systeme, die am besten abschneiden. Gleichzeitig ist dieses Er” gebnis nicht wirklich relevant, da ein KM System typischerweise jeweils ein Teilsystem aus jeder Kategorie haben sollte. Nat¨ urlich gibt es von dieser Regel entsprechende Ausnahmen wie etwa Plone oder XOOPS, bei denen ein solcher Ansatz nicht viel Sinn machen w¨ urde. 8.6.4 M¨ ogliche Erweiterungen von eLearning Funktionen Als letzter Punkt wird noch auf m¨ ogliche Erweiterungen von eLearning Funktionen eingegangen. Dabei soll nicht der Bereich der Erstellung der Lernmaterialien oder der Verwaltung und Administration von eLearning Aktivitäten angesprochen werden. Viel mehr geht es um insgesamt u ¨ ber die beschriebenen Funktionen hinausgehende Themen. Dabei sind viele der entsprechenden Aspekte schon f¨ ur KM selbst diskutiert worden. Die Wichtigsten sind dabei: • • • • •

Die Definition und Verwendung offener Standards Verwendung eines integrierten Systems KI Technologien nutzen Semantische Informationen einsetzen Erweiterte Kommunikationsm¨ oglichkeiten anbieten

Diese Themen sind dabei sehr wichtig und passen auch gut zu einem umfassenden KM System. Vom Prinzip her sind diese Punkte auch alle bei KM

226

8 Weiterer Ausbau

selbst zu nennen. Wenn man etwas genauer darauf eingeht, so ist der erste Punkt relativ klar. Je mehr Standards definiert und auch tatsächlich verwendet werden, desto besser funktioniert der Austausch von Daten, etc. Damit könnte man zum Beispiel externe Inhalte einfach in das interne eLearning System u ¨ bernehmen. Auch eine Integration wird wesentlich erleichtert, wenn die betroffenen Systeme auf offenen Standards aufbauen. Die Vorteile eines integrierten Systems wurden schon f¨ ur ein KM System im Detail beschrieben. Je mehr Funktionen und Systemteile zusammen integriert werden, desto besser wird die Grundlage f¨ ur weitere Funktionen und desto einfacher wird es (hoffentlich) f¨ ur den Benutzer. Außerdem gibt es bei einem vollintegrierten System keine Reibungsverluste an den Systemgrenzen mehr. Die Nutzung von KI Technologien f¨ ur KM Systeme wird im Anschluss besprochen und wurde ja schon prinzipiell dargestellt (siehe Abschnitt 3.5.4). Es gibt dabei eine ganze Reihe von potenziellen Anwendungsgebieten und je mehr Informationen in einem vollintegrierten System zur Verf¨ ugung stehen, desto eher wird man so etwas realisieren k¨ onnen. Interessante Ideen sind zum Beispiel das Vorbereiten“ von Multiple Choice Tests“ aufgrund der Lernun” ” terlagen. Weiters kann man auch Vorschl¨ age f¨ ur Kurse aus einem umfassenden Angebot generieren lassen. Einerseits geht es um den Vorschlag einer Teilnahme, andererseits aber auch um das Erstellen eigener Kurse aufgrund von vorhandenem Material. Im Prinzip gibt es f¨ ur die Anwendung keine Grenzen (kommerzielle Systeme wie etwa der SAGrader – siehe www.sagrader.com – bieten etwa eine Unterst¨ utzung bei der Benotung). Man sollte hier aber immer die Kosten-/Nutzenrelation im Auge behalten. Bei dem Punkt u ¨ ber semantische Informationen geht es bis zu einem ¨ gewissen Grad um etwas Ahnliches wie bei der Diskussion u ¨ ber KI. Entsprechende Aspekte sind etwa die Verwendung von Taxonomien und Ontologien, um den Lernenden besser unterst¨ utzen zu k¨ onnen. Teilweise ist das eine der Grundlagen f¨ ur KI Algorithmen. Dar¨ uber hinaus helfen solche semantische Informationen auch enorm bei der Verbesserung von Suchergebnissen oder dem automatischen Anbieten von inhaltlich ¨ ahnlichen Materialien. Beim letzten Punkt u oglichkeiten ¨ber erweiterte Kommunikationsm¨ geht es schließlich darum, den Nachteil der fehlenden physischen Anwesenheit möglichst weitgehend auszugleichen. In diese Richtung gehen nat¨ urlich Groupware Funktionen und teilweise schon beschriebene Erweiterungen. Ein Stichutzung von Communities of Practice (CoP)“ wort ist hier etwa die Unterst¨ ” ur KM sehr aktuelles Thema (also Interessensgemeinschaften), die ja auch ein f¨ darstellt. Insgesamt sieht man, dass es eine Reihe von wichtigen und interessanten Erweiterungen f¨ ur eLearning gibt, die von den in diesem Buch vorgestellten Systemen kaum bis gar nicht adressiert werden. Das sollte man entsprechend ber¨ ucksichtigen, wenn man eLearning in das KM System integrieren will. Solche Zusatzfunktionen sollte man den eigenen Notwendigkeiten entsprechend

8.7 Nutzbarmachen der verf¨ ugbaren Informationen

227

¨ anbieten. Technisch betrachtet gibt es dabei auch einige Uberschneidungen mit generell m¨ oglichen Erweiterungen des KM Systems. 8.6.5 Zusammenfassung Zusammengenommen kann man sagen, dass es keine Antwort auf die Frage gibt, ob man eLearning als Teil von KM unterst¨ utzen muss oder nicht. Einerseits gibt es sehr wichtige Zusammenh¨ ange wie etwa die Unterst¨ utzung von Lernprozessen. Andererseits haben kleinere Organisationen selten einen wirklichen Bedarf f¨ ur eLearning als Teil ihres KM Systems (und auch bei größeren ist das nicht zwangsl¨ aufig gegeben). Gut illustriert wird das Problem schon mit der Problematik, dass es f¨ ur eLearning noch weniger als f¨ ur KM selbst eine eindeutige Definition gibt. Im Prinzip geht es um das Unterst¨ utzen von Lernen mit elektronischen Mitteln und meist u oßere Entfernungen. Im Detail gibt es aber eine ganze Reihe ¨ ber gr¨ von Unterschieden bei den Ansichten der Experten. ¨ Trotzdem kann man eine Vielzahl an Uberschneidungen zwischen eLearning und KM finden. Einerseits wie schon erwähnt inhaltlich und andererseits auch auf der ganz praktischen Ebene der Funktionen, die ein entsprechendes System bieten sollte. Die Unterschiede liegen dabei in der fehlenden Unterst¨ utzung der Erstellung von Lernmaterialien und von eLearning spezifischen Verwaltungs- und Administrationsfunktionen. Dagegen gibt es beim Anbieten von Lernmaterialen und verschiedenster Möglichkeiten der Kommunikation keine Probleme. Prim¨ ar k¨ onnen Groupware und CMS Systeme die eLearning Anforderungen abdecken (mit den gerade genannten Einschränkungen). Einige davon sogar relativ gut, während bei anderen weitere Zusatzmodule sinnvoll sind. DMS Systeme dagegen decken nur einen kleinen Teil der eLearning Funktionen ab. Der eigentlich wichtige Punkt ist aber die Analyse des eigenen KM Systems in Hinblick auf die Anforderungen und ¨ ahnlich der verwendeten Vorgehensweise. Bei der Frage nach m¨ oglichen Erweiterungen gibt es schließlich wieder eine große Gemeinsamkeit mit reinen KM Aspekten. Es geht dabei einerseits um offene Standards, die damit erleichterte Integration eines Systems oder erweiterte Kommunikationsm¨ oglichkeiten. Andererseits geht es um semantische Informationen und den m¨ oglichst sinnvollen Einsatz von KI, die beide eng miteinander zusammenh¨ angen. Auf diesen Feldern wird es sicherlich noch sehr interessante Entwicklungen in den n¨ achsten Jahren geben. Auch aktuell gibt es hier durchaus schon Beispiele, die aber noch keine große Verbreitung gefunden haben und h¨ aufig noch mit Kinderkrankheiten kämpfen.

8.7 Nutzbarmachen der verfu ¨ gbaren Informationen Ein weiterer Aspekt, auf den schon mehrmals hingewiesen wurde, bei dem eine n¨ ahere Analyse noch aussteht, ist das Nutzbarmachen der verf¨ ugbaren

228

8 Weiterer Ausbau

Informationen. Der Schwerpunkt dieses Abschnitts wird dabei auf KI liegen. Gleichzeitig ist KI keineswegs der einzige wichtige Punkt. Es gibt ganz im Gegenteil eine Vielzahl an M¨ oglichkeiten, die zusammengekommenen“ Infor” mationen sinnvoll zu nutzen. Mit diesem Aspekt wird sich der erste Teil dieses Abschnitts besch¨ aftigen. Der Teil danach wird KI näher betrachten. Dabei wird versucht, einen m¨ oglichst praxisnahen Zugang zu wählen und nicht zu weit abzuschweifen. Leider kann n¨ amlich die Thematik im vorliegenden Buch nicht komplett behandelt werden. 8.7.1 Nutzung der Informationen ohne KI Es wurde schon an vielen Stellen in diesem Buch auf die Verwendung von Informationen f¨ ur eine Verbesserung der Funktionen des Systems hingewiesen. Das war auch ein wichtiges Argument, warum ein relativ eng integriertes System deutliche Vorteile gegen¨ uber einer Ansammlung“ von Einzelsystemen ” bietet. Gleichzeitig war dieses Thema nie selbst im Fokus. Was sind dabei die wichtigsten Punkte, die eine möglichst sinnvolle Verwendung aller vorhandenen Informationen voraussetzen? Die folgende Aufzählung versucht, einen entsprechenden Eindruck zu vermitteln und Anregungen zu geben. Dabei wird von einem relativ eng integrierten und kompletten/m¨ achtigen KM System ausgegangen. Im Einzelfall muss man daher entsprechend Abstriche bei der Analyse machen, falls man ein kleineres System anstrebt. • • • • • •

Notwendige Benutzereingaben minimieren Kontext und Historie erfassen und zur Verf¨ ugung stellen Verringerung von Missverst¨ andnissen Abl¨ aufe und Zusammenh¨ ange sichtbar machen Zugriff auf alle verf¨ ugbaren Informationen L¨ osungen wiederverwenden

Notwendige Benutzereingaben minimieren Dieser Aspekt wurde schon mehrfach in diesem Buch erwähnt. Es geht dabei einfach darum, möglichst viele Eingaben automatisch durchzuf¨ uhren. Sinnvoll wird dabei in vielen F¨ allen nur eine Vorausf¨ ullung von Feldern sein, da ein Automatismus nie alle Aspekte ber¨ ucksichtigen kann. Weiters sollte man auch – wo m¨ oglich – dem Benutzer bei der Auswahl von Feldwerten helfen. Dazu ben¨ otigt man nat¨ urlich wieder die Information u ¨ber die möglichen Feldwerte. Diese sollte man in jedem Fall zum Pr¨ ufen der Eingaben verwenden. Mit diesen Aspekten adressiert man mehrere ganz wichtige Punkte. Der f¨ ur das KM System vielleicht Bedeutendste ist, dass die Benutzer einen Mehrwert des Systems unmittelbar erleben k¨ onnen. Die Arbeit wird (hoffentlich) erleichtert und die Bedienung des Systems ist schneller und einfacher. Ein weiterer Aspekt, der auch f¨ ur das KM System selbst von hoher Bedeutung ist,


229

betrifft die wesentlich bessere Datenqualit¨ at. Die Eingaben sind konsistenter und entsprechen vorgegeben Wertebereichen. Aus einer technischen Sicht wird der Zugriff auf im Ergebnis wesentlich konsistentere Daten deutlich einfacher. Als Nebeneffekt wird man vermutlich auch weniger Redundanz in den gespeicherten Daten haben, da man viel mehr mit Referenzen arbeiten kann. Kontext und Historie erfassen und zur Verf¨ ugung stellen Bis zu einem gewissen Grad ¨ ahnlich zum ersten Punkt ist die Frage des Kontextes und der Historie von Informationen. Auf diesen Begriff ist fr¨ uher schon n¨ aher eingegangen worden (siehe etwa Abschnitt 2.3.8). Praktisch betrachtet geht es darum, m¨ oglichst viel an Kontext zu den einzelnen Informationen zu erfassen. Wichtige Beispiele sind etwa ein Kunde, ein Projekt, eventuelle Kommunikationspartner, der Systemstatus, potenziell dazugehörende Informationen (zeitlich naher Zugriff), etc. Dabei sollte man einfach f¨ ur alle vorhandenen Informationen u ¨berlegen, ob sie später Sinn machen können. Im Zweifelsfall geh¨ ort eine Kontextinformation mitabgespeichert. Weiters muss ¨ auch jede Anderung protokolliert werden, sodass eine komplette Geschichte“ ” jeder einzelnen Information zur Verf¨ ugung steht. Dieser Kontext und die Historie werden nat¨ urlich bei der Abfrage entsprechend wieder zur Verf¨ ugung gestellt und k¨ onnen damit der einzelnen Information u ¨ berhaupt erst wieder einen Sinn geben. Vieles was man ohne Kontext findet, kann entweder gar nicht oder nicht richtig eingeordnet beziehungsweise verwendet werden. Dar¨ uber hinaus erm¨ oglichen Kontextinformationen beziehungsweise Bez¨ ugen zur Historie zielgerichteter zu suchen. Zum Beispiel ist es kinderleicht“, alle zu einem Projekt zugehörigen Informationen wieder” zufinden. Dabei ist das keine 1:1 Zuordnung sondern eine Information kann gleichzeitig mehrere Kontexte haben. Zus¨ atzlich sieht man auch alle Veränderungen, die durchgef¨ uhrt wurden. Verringerung von Missverst¨ andnissen Dieser etwas salopp formulierte Punkt bezieht sich auf die Problematik, dass h¨ aufig Informationen den endg¨ ultigen Empf¨ anger entstellt oder nur mehr zum uhrung von Teil erreichen. Dieses Problem hat nat¨ urlich schon vor der Einf¨ EDV Systemen bestehen und wird auch weiter existieren. Gleichzeitig sollte man versuchen die Auswirkungen zu minimieren. Durch ein integriertes System und die Erfassung von Kontextinformationen kann hier eine deutliche Verbesserung erreicht werden. Einerseits ist die Chance wesentlich h¨ oher, dass die originalen Informationen den endg¨ ultigen Empf¨ anger unver¨ andert erreichen. Andererseits hat er sogar zusätzliche Infor¨ mationen n¨ amlich den Kontext. Uber den kann er potenziell noch eine Reihe weiterer relevanter Informationen finden (bei einer technischen Anfrage etwa die Konfiguration, die ein Kunde einsetzt).

230

8 Weiterer Ausbau

Abl¨ aufe und Zusammenh¨ ange sichtbar machen ¨ Ein integriertes System, das gleichzeitig auch noch Kontext und Anderungsinformationen erfasst, erlaubt zus¨ atzlich ein Nachvollziehen von Abläufen. Man kann bis zu einem gewissen Grad nachvollziehen, warum etwas wann passiert ist. Das bedeutet, dass man u ¨ ber reine Abläufe hinaus geht und auch Zusammenh¨ ange erkennen kann. Wenn zus¨ atzlich noch eine offene Informationspolitik besteht (also relativ wenige Einschr¨ ankungen beim Zugriff) erreicht man so einen hohen Grad an Transparenz und Nachvollziehbarkeit. Zusammengefasst handelt es sich sozusagen um ein Ergebnis eines integrierten Systems, das zus¨ atzlich Kontext und Historie erfasst. Das Nachvollziehen selbst kann dabei einerseits u ¨ ber Suchmöglichkeiten und andererseits u oglichst viele andere Zugriffspfade (zum Beispiel u ¨ ber m¨ ¨ ber Projekt, Kunde, etc.) geschehen. Zugriff auf alle verf¨ ugbaren Informationen Ein eng integriertes System hat konsistente Daten und verhältnismäßig wenig Redundanz. Zusammen mit der Zugriffsmöglichkeit auf alle verf¨ ugbaren Daten kann man den Benutzern sehr gute Suchmöglichkeiten zur Verf¨ ugung stellen. Einerseits gibt es weniger Duplikate und andererseits wird in allen der Organisation zur Verf¨ ugung stehenden Informationen gesucht. In fast allen Organisationen bedeutet das eine deutliche Verbesserung des aktuellen Status. In vielen F¨ allen ist das die vielleicht erste Möglichkeit u ¨ berhaupt, in allen vorhandenen Datenbest¨ anden mit vertretbarem Aufwand suchen zu k¨ onnen. Technische Aspekte (Zugriffsgeschwindigkeit, Berechtigungssystem, etc.) sind dabei schon fr¨ uher besprochen worden. Anders gesagt ist das Ergebnis einige M¨ uhen wert. Leider wird man diese häufig auf sich nehmen m¨ ussen. Dieser Aspekt ist auch der wichtigste (aber nicht einzige), der hilft, dass eine Organisation erfolgreicher arbeiten kann. Durch den effizienten Zugriff auf alle Informationen kann man schneller auf alle möglichen Aufgabenstellungen reagieren. Kunden k¨ onnen besser bedient werden, weil man alle vorhandenen Informationen zu vergangenen Kommunikationen hat. Weiters besitzt man oglichkeit, alle internen Informationsquellen wirklich auszunutzen. die M¨ L¨ osungen wiederverwenden Bis zu einem gewissen Grad ist der Aspekt Lösungen wiederverwenden“ der ” Abschluss der bisher genannten Punkte, die einen Nutzen eines integrierten Systems und des Zugriffs auf alle verf¨ ugbaren Informationen repräsentieren. Es gibt zwar kein Patenrezept, das einem eine möglichst häufige und effiziente Wiederverwendung von L¨ osungen erm¨ oglicht. Gleichzeitig gibt es eine Grundvoraussetzung: Das schnelle und einfache Finden einer vorhandenen Lösung.


231

Wenn das nicht gegeben ist, wird es nur relativ selten Wiederverwendung geben. Einschr¨ ankend muss man dazu zwei Punkte anmerken: Einerseits wird auch KI noch einen wichtigen Beitrag zur Wiederverwendung beisteuern. Andererseits sollte man nicht rein auf vorhandene Lösungen setzen. Wiederverwendung kann sehr viel Geld sparen, tut es aber im Einzelfall nicht unbedingt. Dieses Faktum sollte man nie aus den Augen verlieren und nicht nur auf einen m¨ oglichst hohen Grad an Wiederverwendung von alten Ergebnissen setzen. Zusammenfassung Kurz gesagt bietet die Nutzung aller verf¨ ugbaren Informationen selbst ohne KI eine ganze Reihe von unmittelbaren und wichtigen Vorteilen. Zum Teil ist dabei ein eng integriertes und relativ m¨ achtiges“ KM System Voraussetzung. ” Zum Teil kann man die Vorteile auch in kleineren KM Systemen realisieren. Insgesamt l¨ auft es darauf hinaus, die Arbeit des Benutzers zu erleichtern. Der erste Aspekt ist dabei m¨ oglichst viel an Eingaben automatisch vorzunehmen. Daneben geht es um das Abspeichern von allen zum Zeitpunkt der ¨ Benutzung vorhandenen Informationen (also Kontext und Anderungsinformationen). Als Ergebnis kann man mit kompletteren und korrekteren Informationen die Wahrscheinlichkeit f¨ ur Missverst¨ andnisse reduzieren. Weiters ist es m¨ oglich, Abl¨ aufe und Zusammenh¨ ange sichtbar zu machen also Transparenz und Nachvollziehbarkeit zu f¨ ordern. Schließlich kann man auch noch einen effizienten Zugriff auf alle Informationen einer Organisation bieten. Die auf allen genannten Aspekten aufbauende Krönung“ der Nutzung ” aller verf¨ ugbarer Informationen ist dann die größere Wahrscheinlichkeit f¨ ur die Wiederverwendung von L¨ osungen. Hier geht es einfach darum, dass man etwas erst finden muss, bevor man es wiederverwenden kann. Allerdings sollte man immer daran denken, dass bei reiner Wiederverwendung die Wettbewerbsf¨ ahigkeit einer Organisation stetig schlechter wird. Dies ergibt sich einfach aus der Tatsache, dass man bei reiner Wiederverwendung nur unwesentlich besser wird, w¨ ahrend die Konkurrenz die Chance hat, einen mit neuen Ans¨ atzen zu u ¨berholen. 8.7.2 Verwendung von KI und semantischen Informationen Auf KI im Allgemeinen und Open Source im Speziellen wurde schon in den Abschnitten 2.3.7 und 3.5.4 kurz eingegangen. Insgesamt handelt es sich um eine relativ komplexe Thematik. Einerseits bieten sich eine Reihe von Möglichkeiten und Chancen. Andererseits wird man im Rahmen von kleineren Initiativen kaum darauf eingehen k¨ onnen. Wie schon mehrfach angedeutet, gibt es primär zwei Möglichkeiten, KI im Rahmen von KM sinnvoll einzusetzen. Auf der einen Seite als Hintergrundtechnologie von verschiedensten Funktionen wie etwa erweiterten Suchm¨ oglichkeiten. Auf der anderen Seite als eigenständige Funktionalität.

232

8 Weiterer Ausbau

Insbesondere der zweite Ansatz erfordert dabei ein relativ weitgehendes Verst¨ andnis der Materie und sollte nur mit Bedacht eingesetzt werden. F¨ ur ein erfolgreiches und sinnvolles Vorgehen ben¨ otigt man hier nämlich weniger Technologie sondern mehr ein Verst¨ andnis, mit welcher Informationsbasis welche Themenbereiche abgedeckt werden k¨ onnen. Zusätzlich gibt es immer die Möglichkeit, unerwartete neue Aspekte und Informationen zu entdecken. Auch was diesen Aspekt betrifft, sollte man u ugen ¨ ber eine gewisse Erfahrung verf¨ und halbwegs absch¨ atzen k¨ onnen, ob sich so etwas auszahlen kann. H¨ aufig im Zusammenhang mit KI stellt sich auch die Frage von semantischen Informationen und ihrer Bedeutung f¨ ur KM. Die wichtigsten Beispiele f¨ ur separate semantische Informationen sind schon in den Abschnitten 8.1 und 8.2 beschrieben worden. Generell handelt es sich um ein komplexes und schwieriges Thema, das aktuell das wichtigste Gebiet der f¨ ur KM relevanten Forschung darstellt. Dieser direkte Zusammenhang ist eigentlich gar nicht verwunderlich, da eine echte k¨ unstliche Intelligenz Zusammenh¨ ange und Bedeutungen verstehen k¨ onnen muss. Unabh¨ angig von der Frage, ob f¨ ur eine vollständige“ KI nicht ” noch weitere Aspekte notwendig sind, ist ein wirklicher Durchbruch in der Erforschung semantischer Fragen nicht absehbar. Diese Aussage ist insbesondere im Hinblick auf die praktische Anwendbarkeit wichtig. Damit soll nat¨ urlich nicht gesagt werden, dass sich diese Situation nicht ändern kann. Gleichzeitig stellt sich die aktuelle Situation als kontinuierliche Weiterentwicklung in kleinen Schritten dar. 8.7.3 M¨ oglichkeiten und Einsatzzwecke von KI Im Laufe der Jahrzehnte wurden viele Forschungsergebnisse, die entweder Resultate der KI Forschung waren oder relevant daf¨ ur sind, auch f¨ ur profane“ ” Dinge eingesetzt. Dieser Aspekt wird auch schon durch eines der Forschungs¨ gebiete – Knowledge Discovery in Databases (KDD) – illustriert. Uberhaupt gibt es prim¨ ar zwei im aktuellen Zusammenhang wichtige Aspekte. Einerseits das Finden von Informationen bis hin zur Ableitung von Regeln aus den Daten. Andererseits das Schlussfolgern aus den vorhandenen und aufgesp¨ urten“ ” Informationen, Regeln und Zusammenh¨ angen. Der erste Aspekt ist dabei von extremer Bedeutung f¨ ur den zweiten. Gleichzeitig kann man die so gewonnenen Informationen aber auch als Anreicherung der Informationsbasis und generell zur Verwendung der Benutzer des KM Systems bereitstellen. Wie der Titel dieses Abschnitts schon andeutet, ist f¨ ur ein möglichst gutes Ergebnis der KI Technologie der Zugriff auf möglichst viele Informationen notwendig. Weiters muss auch bekannt sein, was einzelne Informationen bedeuten oder bedeuten k¨ onnen. Gerade bei der direkten Verwendung von KI ben¨ otigt man detailliertes Wissen u ¨ber die Bedeutung und die Attribute einzelner Informationen. F¨ ur eine KM Initiative ist es daher in Hinblick auf KI wichtig, ein paar Fragen zu beantworten:


• • • • •

233

Ist es aufgrund des geplanten Umfangs des KM Systems und der KM Initiative sinnvoll sich u aher mit KI zu beschäftigen? ¨ berhaupt n¨ Sind prinzipiell die notwendigen Daten f¨ ur KI Algorithmen verf¨ ugbar beziehungsweise wird das KM System Zugriff darauf bieten? Gibt es konkrete Fragestellungen, die eine Anwendung von KI beantworten soll? Ist das Know-how f¨ ur eine erfolgreiche Anwendung von KI in der Organisation verf¨ ugbar? Oder gibt es externe Dienstleister daf¨ ur? Ist vielleicht prim¨ ar eine indirekte Nutzung von KI (¨ uber Systeme beziehungsweise Systemteile, die KI einsetzen) ausreichend?

Wie man an den Fragestellungen zur Verwendung von KI erkennt, sollte man sich eine Anwendung gut u ¨ berlegen. Gerade im Kontext von kleineren KM Initiativen, die m¨ oglichst rasch positive Ergebnisse zeigen sollen und m¨ ussen, kann KI gr¨ oßere Probleme verursachen als sie löst. Insbesondere wenn wenig KI Know-how bei den beteiligten Parteien vorhanden ist, sollte man m¨ oglichst auf eine direkte Anwendung verzichten. In dieser Entscheidung sollte man sich auch nicht durch die potenziellen Möglichkeiten von KI beirren lassen. Die Vorteile sind zwar zum Teil beeindruckend aber nur schwer zu erreichen. Bis jetzt noch nicht ausreichend beantwortet ist die Frage, was denn KI f¨ ur M¨ oglichkeiten prinzipiell bietet. Wie schon gesagt, sollte man sich nicht davon blenden lassen. Gleichzeitig sieht man sehr gut, welches Potenzial f¨ ur größere KM Initiativen vorhanden ist (beziehungsweise f¨ ur die Weiterentwicklung kleinerer Initiativen): • • • • • • •

Generierung von Begriffshierarchien (Taxonomien bis hin zu so genannten Knowledge Maps); verwendbar f¨ ur Suche, Dokumentennähe, allgemeinen Zugriff, etc. Identifizierung von inhaltlich nahen Dokumenten (bis hin zu Bildern) Generierung von Zusammenfassungen von Dokumenten Auffinden von Mustern in der Systembenutzung (bis hin zu Workflows oder der Zuordnung von Affinit¨ aten von Personen zu Themen) Erkennen von Regeln und Mustern in den Daten plus entsprechender Folgerungen (zum Beispiel als Data Mining bis hin zum Speech Mining) Klassifikation von Dokumenten (¨ ahnlich zu Regeln) Als Hintergrundtechnologie von Suchmaschinen, Optical Character Recognition, etc.

Dabei enth¨ alt die Liste nur die wichtigsten Anwendungen von KI und verwandten Technologien mit Hinblick auf KM. Anders gesagt liegt das größte Potenzial einer deutlichen Verbesserung von KM selbst mittels IT in der Verwendung von KI. Gleichzeitig adressiert dieses Buch eher Organisationen, die ihre IT Unterst¨ utzung f¨ ur KM mit konventionellen Mitteln deutlich verbessern k¨ onnen. Umfassende und integrierte IT Systeme sind eigentlich kaum in Einsatz und man sollte genau abw¨ agen, welche Art von KM System einer

234

8 Weiterer Ausbau

Organisation am meisten helfen kann. Das Risiko des Scheiterns einer auf KI zentrierten KM Initiative ist n¨ amlich gerade in Zeiten knapper IT Budgets nicht zu vernachl¨ assigen. Insgesamt zeigt dieser Abschnitt sehr sch¨ on, dass KI eine Reihe von potenziell m¨ achtigen Technologien repr¨ asentiert. Gerade im Hinblick auf KM findet man eine ganze Reihe von Punkten, die eine umfassende KM Lösung unbedingt adressieren und beinhalten sollte. Gleichzeitig sind viele der Technologien noch jung und/oder nur schwer erfolgreich einzusetzen. Dar¨ uber hinaus macht eine Verwendung auch nur bei einer entsprechend umfassenden Informationsbasis Sinn. Aufgrund dieser schwerwiegenden Argumente werden kleineren Initiativen fast zwangsl¨ aufig auf eine Verwendung verzichten m¨ ussen. (Ausnahmen best¨ atigen hier nat¨ urlich die Regel.) Je umfassender eine Initiative ist, desto weniger wird sie auf die angesprochenen Vorteile verzichten k¨ onnen. Zus¨ atzlich wird auch immer mehr KI Technologie in die verschiedenen Systeme Einzug halten und damit neue M¨ oglichkeiten bieten. 8.7.4 Die Bedeutung semantischer Informationen Ein Punkt, der teilweise auch schon im vorhergehenden Abschnitt angesprochen wurde, ist die Bedeutung semantischer Informationen. Unmittelbar wurde schon mehrmals auf Taxonomien verwiesen. Insbesondere da sie von KI Algorithmen erstellt und auf dem aktuellen Stand gehalten werden können. Weitere ganz wichtige Aspekte von semantischer Information wurden im Abschnitt u ¨ ber das Semantic Web“ (siehe Abschnitt 8.2) diskutiert. Ins” besondere Ontologien sind dabei ein Schl¨ usselbegriff, da sie (wie ansatzweise auch Taxonomien) eine Interpretation“ von vorhandenen Informationen ” durch den Computer erm¨ oglichen. Anders gesagt ist ein Aspekt von semantischer Information ihr Vorhandensein. Das ist allerdings nur dann von Nutzen, wenn sie auch sinnvoll verwendet werden kann. Dazu muss sie als erster Schritt interpretierbar sein. Ein Mensch wird dabei meist wenig Schwierigkeiten haben, wohingegen es f¨ ur einen Computer eine fast unlösbare Aufgabe ist. Genau hier treffen sich Ontologien und die Mittel und Methoden von KI. Anders gesagt ist es f¨ ur eine Reihe der schon beschriebenen Möglichkeiten (von KI aber auch des Semantic Web) notwendig, dass semantische Informationen durch einen Computer verarbeitet werden können. Auch in diesen F¨ allen sollte man nicht zu viel Intelligenz“ des Computers erwarten. Gleich” zeitig kann eine auch nur rudiment¨ are Intelligenz“ zusammen mit den vorhan” denen St¨ arken des Computers (Geschwindigkeit, theoretische Fehlerlosigkeit, etc.) den Menschen deutlich entlasten. Neben“ der Bedeutung von semantischer Information f¨ ur die automa” tische Verarbeitung gibt es auch noch den menschlichen Benutzer des KM urlich ebenfalls in einem hohen Masse von semantiSystems. Dieser kann nat¨ scher Information profitieren. Bei diesem Aspekt gibt es drei wichtige Punkte, die zu beachten sind:


•

• •

235

Automatisches und manuelles Erfassen von semantischer Information muss unterst¨ utzt werden (im einfachsten Fall durch entsprechende Eingabemasken etwa f¨ ur eine thematische Zuordnung einer Information – was häufig auch als Kontext definiert werden kann). Generierung“ semantischer Information durch das System; Hierbei geht ” es um das Finden“ von semantischer Information u ¨ber Regeln und/oder ” KI Algorithmen. Das Anbieten der vorhandenen semantischen Informationen; Hier geht es um eine Bereicherung“ der vorhandenen Informationen, um Zusam” menh¨ ange aufzuzeigen. Ganz wichtig ist hier etwa das Anbieten einer oder mehrerer Taxonomien und/oder Ontologien.

Generell sind dabei viele semantische Informationen f¨ ur einen menschlichen Benutzer nicht notwendig, da diese offensichtlich“ sind. Gerade bei ” interkultureller Zusammenarbeit ist dieser Aspekt aber häufig nicht gegeben. In solchen Situationen kann eine entsprechende Unterst¨ utzung im KM System wichtiger als gew¨ ohnlich sein. Insgesamt sieht man, dass der Schwerpunkt f¨ ur explizite semantische Information in einem KM System auf der Verwendung durch KI Algorithmen liegt. Das ergibt sich im Prinzip durch die Probleme eines Computers, Informationen richtig zu deuten. Die menschliche Sprache ist nur im Kontext (halbwegs) eindeutig und daher ist eine automatische Verarbeitung in vielerlei Hinsicht nur mit einer F¨ ulle an semantischer Information möglich. Das bedeutet aber keineswegs, dass nicht auch Benutzer des KM Systems von semantischer Information profitieren k¨ onnen. Insbesondere zusätzlich generierte Information (wie etwa eine stets aktuelle Taxonomie) können wertvolle Hilfestellungen sein. Dies wird umso wichtiger je eher verschiedene kulturelle Umgebungen mittels des KM Systems zusammenarbeiten (und schon unterschiedliche Bereiche innerhalb einer Organisation können eine drastisch andere Sprache haben). 8.7.5 Praktische Anwendungen Es gibt eine ganze Reihe von praktischen Anwendungen von KI, die ja auch schon zum Teil erw¨ ahnt wurden. Dieser Abschnitt versucht die f¨ ur KM Relevantesten zusammenzufassen und zu pr¨ asentieren. Dabei muss man sich vor Augen halten, dass es keineswegs f¨ ur alles Open Source gibt. Insbesondere wird man selten eine ausgereifte Software finden, die einfach ein gew¨ unschtes Resultat liefert. Taxonomien (Knowledge Maps) Wie schon mehrfach erw¨ ahnt ist es mit KI Methoden möglich, Taxonomien zu erstellen. Diese sind einerseits eine fast unabdingbare Voraussetzung f¨ ur andere Funktionen (wie etwa eine echte inhaltliche Nähe von Dokumenten).

236

8 Weiterer Ausbau

Andererseits gilt es zwei wichtige Punkte zu beachten. Erstens muss eine generierte Taxonomie auch automatisch aktualisiert werden können. Zweitens werden gr¨ oßere Organisationen mehr als eine Taxonomie benötigen. Die Frage von mehreren Taxonomien ist dabei von hoher Bedeutung, um dem Umstand Rechnung zu tragen, dass in verschiedenen Bereichen unterschiedliche Sprachen“ gesprochen werden. So unterscheiden sich etwa die ” Texte und Bedeutungen von W¨ ortern sehr stark zwischen den Bereichen IT und Finanz. Ein KM System muss mit diesen Unterschieden umgehen können und entsprechend mit verschiedenen Taxonomien, um diesem Umstand gerecht zu werden. ¨ Ahnlichkeit von Dokumenten ¨ Es gibt eine Reihe von Methoden, um die Ahnlichkeit von Dokumenten zu bestimmen. Hierbei wird der Begriff KI eher im weiteren Sinne verwendet, da es sich h¨ aufig um statistische Verfahren handelt. Neben dieser Frage ist hier auch noch zu ber¨ ucksichtigen, dass Begriffe in verschiedenen Kontexten unterschiedliche Dinge bedeuten k¨ onnen (von unterschiedlichen Sprachen ganz abgesehen). Um eine echte inhaltliche N¨ ahe zu konstatieren, wird man zusätzlich eine Taxonomie oder Ontologie ben¨ utzen. Damit kann man Dokumente finden, die nicht den gesuchten Begriff enthalten aber eine allgemeinere oder speziellere Ausformung davon. Das demonstriert ganz konkret eine weitere Anwendung von Taxonomien beziehungsweise Ontologien in einem KM System. Insgesamt gibt es hier schon einige Zeit relativ gut funktionierende Systeme (zumindest im kommerziellen Umfeld), die Nutzern die Suche in großen Informationsmengen deutlich erleichtern k¨ onnen. Insbesondere wenn man noch zus¨ atzlich semantische Informationen wie eine Taxonomie ber¨ ucksichtigt, kann man Dokumente finden, die sonst wohl kaum in Betracht aufgefallen wären. Identifizierung von Workflows/Zugriffs- bzw. Nutzungsmustern Ein in Europa bis zu einem gewissen Grad heikles Thema ist die Auswertung von Zugriffs- und Nutzungsmustern. Wenn man an so etwas Interesse hat, sollte man zuerst eine rechtliche Kl¨ arung durchf¨ uhren, bevor man an konkrete Funktionen eines KM Systems denkt. Unabhängig von dieser Frage sind Zugriffs- und Nutzungsmuster des KM Systems nat¨ urlich in vielerlei Hinsicht interessant. Zum Beispiel kann man versuchen, einen Erfolg oder Misserfolg des Systems festzustellen. Insbesondere indem man versucht, Problemstellen und Optimierungspotenzial zu erkennen. Wichtiger f¨ ur den aktuellen Abschnitt ist aber die Möglichkeit, Arbeitsabl¨ aufe festzustellen. Hier sollte man sich vor Augen halten, dass nur bei einer entsprechend h¨ aufigen Durchf¨ uhrung eines relativ strikten Ablaufes eine Automation sinnvoll ist. Gleichzeitig hat ein automatisierter Workflow in solchen allen viele Vorteile. Daher handelt es sich hier um eine interessante Idee f¨ ur F¨


237

Organisationen, wo es relativ viele Routinet¨ atigkeiten gibt, die ähnlich bearbeitet werden m¨ ussen. Dabei ist die Identifizierung von Workflows nur einer vor mehreren Ans¨ atzen, eine Verbesserung zu erreichen. Ein weiterer (zusätzlich m¨ oglicher) Punkt ist die Verwendung von Klassifikation, wie wir bald sehen werden. Suchen von Regeln und Zusammenh¨ angen Bei diesem Punkt ist prim¨ ar eine manuelle“ Suche mit Hilfe von KI Algo” rithmen gemeint. Ein gutes Beispiel f¨ ur eine praktische Anwendung ist die Verwendung von verschiedenen Tools des in Abschnitt 3.5.4 schon kurz angesprochenen WEKA Toolkits. Damit kann etwa das gemeinsame Auftreten von Attributen untersucht werden. Ganz praktisch könnte es etwa um häufig gemeinsam gekaufte Artikel gehen. Weiters ist es möglich, so genannte Entscheidungsb¨ aume generieren zu lassen, deren Regeln potenziell sogar bis dahin unbekannte oder unbeachtete Zusammenhänge aufzeigen. Konkret könnte man zum Beispiel einen Entscheidungsbaum f¨ ur die Vergabe beziehungsweise Ablehnung eines Kredits aufgrund einer Reihe von Attributen generieren lassen. F¨ ur stark standardisierte Produkte ist zusammen mit einem Workflow sogar eine vollautomatische Kreditabwicklung denkbar. Um eine sinnvolle praktische Anwendung zu ermöglichen, m¨ ussen allerdings eine Reihe von Voraussetzungen erf¨ ullt sein. Die beiden Wichtigsten sind das Vorhandensein von relevanten Attributen und eine entsprechend große Anzahl von Datens¨ atzen. Im Zusammenhang mit relevanten Attributen besteht nat¨ urlich auch die Notwendigkeit“, dass es Gesetzmäßigkeiten gibt, ” die u onnen. Die Wichtigkeit einer entsprechenden ¨ berhaupt entdeckt werden k¨ Anzahl von Datens¨ atzen ergibt sich wiederum aus den vielen Unabwägbarkeiten, mit denen ein KI Algorithmus zurechtkommen muss. Ein wichtiges Problem dabei ist, dass es eine gewisse Menge an Datensätzen mit inkorrekten Informationen geben wird (etwa durch Messfehler, etc.). Weiters werden normalerweise nicht wirklich alle relevanten Attribute abbildbar sein. (Bei einem Kredit etwa gibt es schwer vorhersehbare Einflussfaktoren wie Arbeitslosigkeit oder Krankheit.) Neben den beiden gerade beschriebenen wichtigsten Voraussetzungen f¨ ur urlich noch eine Reieinen erfolgreichen Einsatz von KI Technologien sind nat¨ he von anderen Aspekten relevant. Zum Beispiel k¨ onnen externe Einfluss¨ faktoren (etwa der Olschock der 1970er Jahre) gefundene Regeln außer Kraft setzen oder als nicht erfasstes Attribut das Auffinden von Regeln oder Zusammenh¨ angen erschweren. Trotz all dieser Probleme kann man (neben trivialen Ergebnissen) zum Teil erstaunliche Zusammenhänge finden und Regeln mit einer hohen Erfolgswahrscheinlichkeit identifizieren. H¨ aufig noch komplizierter als die manuelle“ Suche ist eine automati” sche Einbindung. Ein relativ einfaches Beispiel ist noch eine Funktion die aufzeigt, welche Kunden zu einem Produkt noch ein anderes gekauft haben (zu finden auf vielen e-Commerce Seiten wie etwa Amazon). Bis zu einem

238

8 Weiterer Ausbau

gewissen Grad werden auch noch auf solchen Analysen beruhende Funktionen vorgestellt (etwa eine Identifizierung von Experten“, die zumindest zum ” Teil so funktioniert).Gleichzeitig gibt es hier sehr viele organisationsspezifische Aspekte, die sich nat¨ urlich in den vorhandenen Attributen der Datensätze niederschlagen. Insgesamt sieht man, dass KI Algorithmen einem dabei helfen können, Zusammenh¨ ange in vorhandenen Datenbest¨ anden aufzusp¨ uren. Das ist allerdings keine triviale Sache und illustriert so noch einmal, dass man nur bei entsprechend vorhandenem Know-how KI in Erwägung ziehen sollte. F¨ ur seine M¨ uhen kann man dann mit neuen Einsichten in das Verhalten von Kunden, etc. belohnt werden. Bei einer automatischen Verwendung solcher Techniken sollte man allerdings vorsichtig sein und jeweils auch den möglichen Schaden bei Fehlfunktionen ber¨ ucksichtigen. Im Endeffekt handelt es sich um ein Spiel mit Wahrscheinlichkeiten, bei denen man leicht sehr viel verlieren kann, wenn man nicht entsprechend Acht gibt. Speech Mining/Analysieren von Video Bei den im Titel genannten Punkten handelt es sich um zwei sehr interessante Ans¨ atze f¨ ur KM, die allerdings aktuell noch nicht f¨ ur eine breite Verwendung geeignet sind. Im Prinzip geht es bei beiden Punkten darum, bisher nur schlecht verf¨ ugbare Informationsquellen m¨ oglichst optimal und einfach einzubinden. Der Begriff des Data Mining ist ja schon gefallen und Speech Mining ist schlicht“ die Ausdehnung dieser Technologie auf das gesprochene Wort. ” ¨ Bei der Analyse von Videos geht es im Prinzip um etwas ganz Ahnliches. Hier wird u ¨ber die Sprache (und Spracherkennung) versucht, weitere Informationen in IT-Systeme einzubinden. Dar¨ uber hinausgehend wird sogar versucht, das bewegte Bild selbst zu analysieren und nicht nur u ¨ ber die Sprache zug¨ anglich zu machen. Aktuell liegt der Schwerpunkt der beschriebenen Aspekte ganz sicher bei der Spracherkennung. (Eine Technologie die u ¨brigens in vielerlei Hinsicht auf KI Algorithmen beruht.) In Folge werden dann eigentlich die ganz normalen Systemteile, die u ur die Suche und Einordnung ¨ berwiegend auf Text basieren, f¨ benutzt. Eine ganz praktische Anwendung von Speech Mining kann etwa das Auswerten und Verf¨ ugbarmachen von Kundengesprächen sein. Bei entsprechend vielen Kunden kann eine solche Auswertung eine F¨ ulle an Informationen liefern. Eine andere Idee ist etwa das Dokumentieren von Entscheidungen in Projekten mittels Video. Im Idealfall kann man damit später nachvollziehen, warum eine gewisse Entscheidung getroffen wurde, und abschätzen, ob die unde immer noch gelten (etwa f¨ ur Designentscheidungen eines IT-Systems). Gr¨ Man sieht, dass Speech Mining und die Analyse von Videos eine F¨ ulle von zus¨ atzlichen M¨ oglichkeiten f¨ ur ein KM System eröffnen. Gleichzeitig handelt es sich hier um Themen, bei denen eine gewisse Sorgfalt angebracht ist. Zus¨ atzlich gibt es noch kaum bis gar keine Open Source Systeme. Daher sollte


239

man ¨ ahnlich wie bei einer direkten Anwendung von KI Algorithmen wirklich genau wissen, was man tut, bevor man sich f¨ ur die Verwendung dieser Technologien entscheidet. Klassifikation von Dokumenten Eine in manchen F¨ allen extrem hilfreiche Anwendung von KI ist das Klassifizieren von Dokumenten. Bis zu einem gewissen Grad geht es hier einfach um eine konsequente Anwendung von schon Beschriebenem. Gleichzeitig handelt es sich um eine in manchen Gebieten beliebte und wichtige Anwendung, sodass eine detailliertere Beschreibung gerechtfertigt ist. Grob gesagt geht es bei der Klassifizierung von allen möglichen Dokumenten wie E-Mails oder Briefen darum, eine Unterteilung vorzunehmen. Eine simple M¨ oglichkeit w¨ are eine Unterscheidung zwischen Anfragen, Rechnungen und Mahnungen, die eine bestimmte E-Mail Adresse regelmäßig empfängt. Aufgrund der automatischen Klassifizierung k¨ onnen diese zielgerichtet weitergeleitet und eventuell auch Workflows gestartet werden. Solche Mechanismen ¨ beruhen h¨ aufig auf einer Ahnlichkeitsanalyse (die schon kurz beschrieben wurde) und das System muss zu Beginn mit einer Reihe von typischen Vertretern der einzelnen Kategorien angelernt“ werden. ” Bei klassischer Post kommt zus¨ atzlich noch die Optical Character Recognition (OCR) dazu, damit das Dokument u ¨ berhaupt maschinell lesbar ist. (OCR benutzt wie Speech Mining selbst eine Reihe von KI Technologien, was aber jetzt nicht relevant ist.) Hier kann man f¨ ur die weitere Analyse noch zus¨ atzliche Merkmale erfassen und so potenziell eine genauere Zuordnung erreichen. Insgesamt bietet die Klassifikation von Dokumenten eine interessante M¨ oglichkeit, Abl¨ aufe zu beschleunigen und Routineaufgaben durch den Com¨ puter erledigen zu lassen. Meist geht es im Kern eigentlich um eine Ahnlichkeitsanalyse von Dokumenten. Wichtig ist vor allem daf¨ ur zu sorgen, dass eine falsche Zuordnung (die immer wieder einmal passieren wird) keine Probleme ausl¨ ost. Identifizieren von Interessen und Know-how Eine weitere Spezialanwendung von im Prinzip schon vorgestellten Mechanismen ist das Identifizieren von Interessen und Know-how der Benutzer eines KM Systems. Dabei geht es um eine ganze Reihe von Themen. Wichtig ist etwa die Feststellung, dass ein KM System bei Vorschlägen, Suchergebnissen, etc. m¨ oglichst die Interessen eines Anwenders ber¨ ucksichtigen sollte (allerdings ohne die prinzipiellen M¨ oglichkeiten einzuschränken). In diesem Zusammenhang ist es nat¨ urlich von großer Bedeutung, das Interessensprofil jedes Nutzers möglichst aktuell zu halten. Nur so kann eine möglichst nutzergerechte Informationsaufbereitung durchgef¨ uhrt werden.

240

8 Weiterer Ausbau

Weiters ist es f¨ ur gr¨ oßere Organisationen (und auch viele mittlere bis klei¨ nere) sehr schwierig, einen Uberblick u ¨ber die Fähigkeiten und das Know-how der einzelnen Mitarbeiter zu behalten. Klassische Ansätze u ¨ ber eine Personalabteilung zeigen dabei immer wieder ihre prinzipiellen Schwächen und werden durch laufende Einsparungen auch im Personalbereich fast unmöglich gemacht. Damit stellt sich nat¨ urlich die Frage, wie gut so etwas automatisiert funktionieren kann. Wichtig ist dabei, dass es sich nicht um eine ideale sondern eine praktische Lösung handelt und man sich ihrer Schw¨ achen bewusst ist. Gleichzeitig funktionieren Beispiele von kommerziellen Systemen (etwa von Lotus) erstaunlich gut. Kurz gesagt sind technische Systeme aufgrund einer Vielzahl von Informationen in der Lage, Affinit¨ aten von Personen mit Themen festzustellen. Das sind nicht zwangsl¨ aufig Experten aber doch Menschen, die einem in irgendeiner Form weiterhelfen k¨ onnen (etwa mit einem Tipp wer eine bestimmte Information haben k¨ onnte). Solche Affinit¨ aten (die auch f¨ ur Interessensprofile genutzt werden können) basieren auf vorhandenen expliziten Informationen sowie der Nutzung des Systems. (Hier gilt es wieder, auf entsprechende datenschutzrechtliche Erfordernisse R¨ ucksicht zu nehmen.) Ganz praktisch gesagt geht es um die Autorenschaft von Dokumenten, E-Mails, Forumseinträgen, Projektmitgliedschaft oder Teilnahme an Besprechungen. Weiters geht es um das Suchen und Lesen von Informationen und so weiter. Mit einer Vielzahl von kleinen und kleinsten Informationen ist es m¨ oglich relativ genau festzustellen, welche Themen einen Nutzer interessieren. Diese Informationen können unter anderem auch zur Aktualisierung der Daten einer Personalabteilung dienen, die so relativ einfach und billig“ zu aktuellen Informationen kommt. ” Ein h¨ aufiges Problem bei der resultierenden Sichtbarkeit“ von Experten ” ¨ ist die Uberlastung von Schl¨ usselpersonen durch Routineanfragen. Hier kann man bis zu einem gewissen Grad mit vorgeschalteten technischen Systemen, die den Zugang einschr¨ anken, das Problem entschärfen. Brutal gesagt handelt es sich aber einfach um eine der Schattenseiten so eines Systems. Man sieht also, dass eine Identifikation der Interessen und des Know-hows einzelner Mitarbeiter eine Reihe von wichtigen und positiven Effekten haben kann. Es bietet sich eine M¨ oglichkeit, den Nutzen des KM Systems deutlich zu verbessern. Gleichzeitig muss man darauf achten, dass potenziell negative Effekte nicht zu stark zum Tragen kommen. Unterschiedliche Sprachen ur viele der KI Algorithmen (und in weiterer Folge f¨ ur den Ein Problem f¨ Nutzen des KM Systems) sind neben den unterschiedlichen Begriffswelten verschiedener Bereiche (wie etwa IT und Finanzwelt) unterschiedliche Sprachen. Im Prinzip funktionieren die besprochenen Algorithmen nat¨ urlich auch mit mehrsprachigen Dokumenten. Gleichzeitig will man aber bei ähnlichen Dokumenten auch solche mit anderssprachigen Inhalten finden. Das ist ein


241

Problem, wenn es sich nicht um einen Fachbegriff mit gleicher Schreibweise handelt. Ein weiteres Problem ist, dass etwa auf einer Taxonomie beruhende Mechanismen eine anderssprachige Taxonomie benötigen. Dazu muss zuerst die andere Sprache erkannt und danach eine entsprechende Taxonomie benutzt werden. Das kleinere“ Problem, das u ¨ brig bleibt, sind Texte in denen die ” Sprache wechselt, da dies nur einen geringen Teil aller Dokumente betreffen sollte. Der eigentlich problematische Punkt ist, dass man kaum Beziehungen zwischen den Begriffen unterschiedlicher Sprachen herstellen kann (wie auch in Abschnitt 8.1.3 erkl¨ art wird). Nat¨ urlich k¨ onnte man ein Wörterbuch benutzen, h¨ atte aber sicher nur m¨ aßigen Erfolg damit. Genau diese Problemstellung wird auch beim Semantic Web oder bei Topic Maps gelöst werden m¨ ussen, wenn diese Standards eine sprach¨ ubergreifende Bedeutung und Verwendung erlangen sollen. ¨ Uberblick Die beschriebenen praktischen Anwendungen von KI können keineswegs einen ¨ kompletten Uberblick bieten. Analysiert und beschrieben werden die f¨ ur KM Systeme wichtigsten und allgemeinsten M¨ oglichkeiten. Wie man an der Diskussion einzelner Punkte sieht, ist das gar nicht einfach. Generell muss jede Verwendung von KI Technologien gut u ¨ berlegt sein. Einerseits gibt es viele relevante Einsatzgebiete, die anders in einer umfassenden KM L¨ osung nur unzureichend adressiert sein werden. Gleichzeitig besteht das Risiko, hohe Aufw¨ ande zu investieren, ohne ein auch nur annähernd praktisch verwendbares System zu bekommen. Erschwerend kommt noch hinzu, dass es auf diesem Gebiet zwar sehr wohl Open Source Systeme gibt, jedoch nicht ann¨ ahernd in derselben Qualit¨ at und Auswahl wie etwa bei CMS Systemen. Damit bleibt eigentlich nur die Schlussfolgerung, dass man KI Technologien direkt nur f¨ ur Spezialf¨ alle oder sehr umfassende KM Systeme verwenden sollte. Das ist nat¨ urlich nur eine Momentaufnahme und auf diesem Gebiet sind sicher noch sehr interessante Entwicklungen zu erwarten. 8.7.6 Zusammenfassung Der Abschnitt u ugbaren Informationen zeigt ¨ ber die Nutzbarmachung der verf¨ das große Potenzial eines umfassenden KM Systems. Dabei geht es um das Aufzeigen und Analysieren der wichtigsten Möglichkeiten und nicht um eine umfassende Darstellung, die den Rahmen dieses Buches sprengen w¨ urde. Wichtig sind dabei einerseits grunds¨ atzliche Fragestellungen sowie klassische“ ” Möglichkeiten, die vorhandenen Informationen zu nutzen. Andererseits geht oglichkeiten, die der Einsatz von KI eröffnet. es um die verschiedenen M¨

242

8 Weiterer Ausbau

Daher wird zuerst diskutiert, welche M¨ oglichkeiten einem die vorhandenen Informationen ohne Verwendung von KI Techniken bieten. Das Ergebnis dreht sich um das Sichtbarmachen von Zusammenhängen und allen verf¨ ugbaren Informationen sowie die Optimierung der Systembenutzung. Viele Informationen, die leicht erfassbar oder sowieso vorhanden sind, stellen eine Voraussetzung f¨ ur das korrekte Verst¨ andnis einer Information dar. Weiters kann man auch Missverst¨ andnisse reduzieren und die Systembenutzung durch sinnvolle Vorausf¨ ullungen von Feldern vereinfachen. Danach geht es um die Verwendung von KI Technologien und semantischer Information. Jede Organisation muss dabei genau u ¨ berlegen, ob die Voraussetzungen f¨ ur einen sinnvollen Einsatz von KI u ¨ berhaupt gegeben sind. Typischerweise sollten nur Organisationen, die größere KM Initiativen planen und sowohl das entsprechende Know-how als auch die notwendigen Daten haben, ernsthaft daran denken, KI zu verwenden. Gleichzeitig kann man erstaunliche Dinge erreichen, wenn die Grundlagen gegeben sind. Ermöglicht ¨ wird etwa die Generierung von Begriffshierarchien, Ahnlichkeiten oder Zusammenfassungen von Dokumenten oder das Erkennen verschiedener Muster in der Benutzung oder den verf¨ ugbaren Daten, um nur einige der wichtigsten Aspekte zu nennen. F¨ ur viele Anwendungen sind dabei semantische Informationen, wie sie etwa Taxonomien oder Ontologien darstellen, erforderlich. Sie ermöglichen es dem Computer erst, den Anschein von Intelligenz zu erwecken und Schlussfolgerungen durchzuf¨ uhren. Hier sollte man einerseits eine umfassende Grundlage zur Verf¨ ugung stellen und andererseits auf eine automatisierte Aktualisierung Wert legen. Nur u ¨ber diese beiden Aspekte ist eine sinnvolle Verwendung m¨ oglich. Der letzte Teil besch¨ aftigt sich dann mit den praktischen Anwendungen. Dabei werden einige wichtige Beispiele aufgezeigt. Dar¨ uber hinaus gibt es nat¨ urlich noch eine große Vielfalt an weiteren Einsatzmöglichkeiten. Einerseits finden sich aktuell noch viele Spezialanwendungen und andererseits ist eine sehr schnelle Weiterentwicklung im Gange. Unter den wichtigsten Anwendungen findet sich federf¨ uhrend das Generieren und Aktualisieren von Knowledge Maps oder Taxonomien, die ja als Basis ¨ f¨ ur viele andere Funktionen dienen. Weiters geht es um die Ahnlichkeit von Dokumenten, um Anwendern eine weitere Möglichkeit zum Finden von relevanten Informationen zu geben. Eine im Vergleich zu den anderen Beispielen sehr direkte Anwendung von KI Technologien ist die Suche von Regeln und Mustern in den Daten. Hier geht es zum Beispiel um das Auffinden von Zusammenh¨ angen (etwa warum ein Kunde ein Produkt kauft) und um das Analysieren von Nutzungsmustern (etwa um einen Workflow zu identifizieren). Ein sehr aktuelles Thema ist auch die Analyse und das Zugänglichmachen von Sprach- und Videodaten. Hier geht es um Sprach- und teilweise Bilderkennung, die auf KI Technologien beruht, um die entsprechenden Informationen zu erschließen. Eine schon fast klassische“ Anwendung ist dagegen das Ein”


243

ordnen von Dokumenten, wie etwa die Einteilung von E-Mails in Anfragen und Beschwerden. Zum Teil aufgrund der Zugriffsmuster und zum Teil aufgrund der prinzipiell vorhandenen Daten kann man auch Interessen und vorhandenes Know-how identifizieren. Damit ist es m¨ oglich, die Nutzung des KM Systems effektiver zu gestalten und Affinit¨ aten von Personen zu gewissen Themen (potenzielle Experten) zu finden. Neben den rein funktionellen Aspekten gibt es auch noch weitere wichtige Fragen. Selbst kleinere Organisationen werden häufig mit Informationen in unterschiedlichen Sprachen zu tun haben (insbesondere Englisch und Deutsch). Im einfachsten Fall wird man diese Problematik einfach ignorieren. Alternativ hat man eine schwierige Aufgabe vor sich, bei der eine wirklich zufriedenstellende L¨ osung aktuell nicht vorhanden ist. Insgesamt sieht man, dass es eine F¨ ulle von Funktionen und Informationen gibt, die eine vollst¨ andige Informationsbasis als Grundlage benötigen. Hier gibt es eine Reihe von sehr interessanten und wichtigen Ausbaumöglichkeiten f¨ ur ein KM System. Einiges davon basiert auf klassischer“ Technologie, ” während anderes auf dem Einsatz verschiedener KI Technologien basiert. Kleinere KM Initiativen sollten sich einen Einsatz wirklich gut u ¨berlegen, während umfassende KM Vorhaben viele Funktionen nur mittels dieser Technologien realisieren k¨ onnen.

9 Zusammenfassung, Abschluss und Ausblick

¨ Dieses Buch gibt einen Uberblick u oglichkeiten, Knowledge Mana¨ber die M¨ gement mittels Open Source Software zu unterst¨ utzen. Dabei geht es einerseits um grunds¨ atzliche Fragen und Ans¨ atze von KM (was ist es u ¨berhaupt; was sollte ein ideales System k¨ onnen). Andererseits geht es um die praktische Anwendbarkeit insbesondere f¨ ur kleinere und mittlere Organisationen. Gleichzeitig handelt es sich dabei um den Hauptteil der Arbeit. Es beginnt mit einer Darstellung der wichtigsten Softwarekategorien und relevanter Open Source Systeme. Es geht weiter um die Frage, welche prinzipiellen technologischen Fragen zu behandeln und beantworten sind. Danach geht es um die Darstellung einer schrittweisen Einf¨ uhrung. Einerseits beginnend mit einer Groupware und andererseits mittels eines CMS Systems als jeweiligem Startpunkt. In Folge sollte man das System jeweils um die anderen Funktionen sowie um DMS Aspekte erweitern. Einerseits zur Adressierung bestimmter Bed¨ urfnisse und andererseits f¨ ur umfassendere KM Initiativen wird dann noch ein weiterer Ausbau von einer Integration von Drittsystemen u ¨ ber das Semantic Web bis hin zur Verwendung von KI Technologien analysiert. Dieser Teil soll vor allem dazu dienen, den Inhalt dieses Buch noch einmal ganz deutlich darzustellen. Gleichzeitig dient er als Basis f¨ ur die anderen Abschnitte dieses Kapitels. ¨ Uber eine reine Zusammenfassung hinausgehend bietet dieses Kapitel auch einen Abschluss. Es geht vor allem um die Frage, wie sich die verschiedenen beschriebenen Teile zusammenf¨ ugen. Damit soll auch ein besseres Gesamtverst¨ andnis erreicht und der Zusammenhang der einzelnen Teile dieses Buches klarer werden. Angesichts der Un¨ ubersichtlichkeit des KM Feldes wird weiters die eingenommene Sichtweise noch einmal extra dargestellt. Der letzte Abschnitt befasst sich dann mit einem Ausblick. Gerade in einem Gebiet wie KM ist das sehr schwierig und daher umso wichtiger. Dazu kommt noch die zum Teil rasante Weiterentwicklung der Open Source Systeme, die so eine Sichtweise noch unverzichtbarer macht. Anders gesagt geht es um die Frage, welche Trends besonders wichtig sind und in welche Richtung sich die beschriebenen Felder weiterentwickeln werden.

246


9.1 Zusammenfassung Eine umfassende Darstellung von KM und Open Source ist im Rahmen eines einzelnen Buches nat¨ urlich nicht m¨ oglich. Um so wichtiger ist es, eine entsprechende Auswahl zu treffen und diese entsprechend zu argumentieren. Die ja immer wieder betonte Schwierigkeit, allgemeing¨ ultige Aussagen treffen zu können, demonstriert besonders gut die Bedeutung dieses Teils. 9.1.1 Einleitung Weder f¨ ur den Begriff KM noch f¨ ur den Terminus Open Source gibt es klare Definitionen. Aus diesem Grund werden zuerst diese beiden Begriffe kurz dargestellt. Dabei beginnt die Schwierigkeit schon bei der fehlenden exakten Definition von Knowledge (Wissen). F¨ ur dieses Buch geht es bei Wissen grob um u ufte Informationen zusammen mit Kontext und Interaktionen von ¨ berpr¨ Personen (also nicht in IT speicherbar). In Folge geht es bei KM grob gesagt um alle Aktivit¨ aten in Zusammenhang mit Daten, Informationen und Wissen. Besonders wichtig ist auch noch die Feststellung, dass IT prinzipiell nicht KM durchf¨ uhren“ kann. Gleichzeitig ben¨ otigt man heutzutage ein (IT) KM ” System zur Unterst¨ utzung einer umfassenden KM Initiative. Was eine n¨ ahere Definition von Open Source angeht, so wird vor allem auf die OSI verwiesen. Dabei handelt es sich nicht um eine allgemein akzeptierte Sichtweise und von daher sollte man immer genau schauen, wenn von Open Source die Rede ist. Der wichtigste Punkt dieser Definition ist, dass der Benutzer den Source Code bekommt und ihn beliebig modifizieren darf. ¨ Im Anschluss wird noch kurz darauf eingegangen, welche Bereiche Ahnlichkeiten zu dem Feld KM und IT haben. Die wichtigsten Vertreter sind dabei Informations- und Groupware Systeme. Darauf folgt eine Darstellung des Fokus dieses Buches, die ausgehend von einer umfassenden Vision eines KM Systems u ogliche Systeme und technische Grundsatzfragen bis zu ¨ ber m¨ verschiedenen Zwischenschritten und Ausbaustufen eines auf Open Source basierenden KM Systems reicht. 9.1.2 Vision eines KM-Systems Manchem Leser mag dieses Kapitel ein wenig praxisfern vorgekommen sein. Dem soll hier gar nicht widersprochen werden. Gleichzeitig ist diese Art der Betrachtung f¨ ur eine Langzeitvision von entscheidender Bedeutung. Insbesondere, da die konkreten“ Ziele von KM von Kosten reduzieren“ bis hin zur ” ” Erh¨ ohung des Innovationspotenzials reichen. Jede Organisation muss entsprechend abw¨ agen, was f¨ ur sie wichtig ist. In diesem Zusammenhang sollte man ebenfalls entscheiden, ob man eLearning (wobei unklar ist, ob es einen Teil von KM darstellt) Unterst¨ utzung ben¨ otigt oder nicht.

9.1 Zusammenfassung

247

Von enormer Bedeutung sind dabei die Voraussetzungen und Grundlagen von KM. Die in diesem Abschnitt angef¨ uhrten Punkte stellen eigentlich die notwendige Basis einer umfassenden KM Initiative dar und sollten auch bei einem kleineren Unterfangen m¨ oglichst beachtet werden. Ob es jetzt um den Willen zu KM und das Wissen u ¨ber das Warum“, eine Kultur des ” ” Teilens und der Zusammenarbeit“, Wahrhaftigkeit“ oder Ziele von KM und ” ” ihre Evaluierung“ geht, die Wichtigkeit ist sofort einsichtig. Auch um Fragen der Motivation (sei sie jetzt extrinsisch oder intrinsisch), des Spannungsfeldes von KM mit Innovation/Kreativit¨ at, von Barrieren und Hindernissen oder generellen organisatorischen Aspekten muss man sich nat¨ urlich k¨ ummern. Es handelt sich dabei um Schl¨ usselelemente einer erfolgreichen KM Initiative und sie sollten dementsprechend behandelt werden. Der Schwerpunkt des Kapitels ist dann eine Darstellung aller von einem vollst¨ andigen KM System zu ber¨ ucksichtigenden Punkte: Erfassen Es werden umfassenden M¨ oglichkeiten (Eingabemöglichkeiten, Formate, . . . ) & Hilfestellungen (wie Vorausf¨ ullungen) zur Eingabe von Informationen ben¨ otigt. (Technisch) Integrieren und Einbinden (Verbinden) Bidirektionale und sonstige notwendige Verbindungen zu Fremdsystemen (Einzelsysteme bis hin zu ERP) geh¨ oren geschaffen. Transformationen Daten m¨ ussen unter anderem aus und f¨ ur Fremdsysteme transformiert oder f¨ ur Endbenutzer aufbereitet werden. Speicherung Einerseits muss das KM Systems selbst Daten wie etwa Kontextinformationen speichern. Andererseits geht es auch um eine integrierende Schicht f¨ ur den Zugriff auf externe und interne Datenbestände. Flexibles & adaptierbares Berechtigungssystem Zur Sicherstellung von Vertraulichkeit ist ein flexibles und adaptierbares Benutzersystem notwendig, das am besten auf einer zentralen Benutzerdatenbank beruhen sollte und Single Sign-On Funktionalit¨ at bietet. Leute miteinander verbinden Ein umfassendes KM System muss verschiedenste Interaktionsformen anbieten und insbesondere strukturierte (etwa Foren) und unstrukturierte (etwa E-Mail) Kommunikation unterst¨ utzen. KI/DM/KDD/ML Die vielleicht spannendsten“ Funktionen eines KM Sys” tems beruhen u ¨ berwiegend auf KI Technologien. Voraussetzung ist entsprechendes Know-how, das es erm¨ oglicht neue Informationen gewinnen zu k¨ onnen. Erfassung, Verwaltung & Pr¨ asentation von Kontext, Links & Historie Solche onnen einem einzelnen Datum u Zusatzinformationen k¨ ¨ berhaupt erst seine Bedeutung geben und m¨ ussen daher entsprechend erfasst, verwaltet und pr¨ asentiert werden. Automation Alles automatisch Machbare (wie etwa eine Expertendatenbank oder eine Klassifikation von Informationen) hilft Benutzer zu entlasten und ist daher entsprechend wichtig.

248


Suchen, Finden und Zugreifen Verschiedene Strukturen (wie eine manuell gepflegte Hierarchie oder eine Taxonomie), eine Volltextsuche, Kontext und u ussen Teil ¨ berhaupt möglichst viele Mittel zur Suche und zum Zugriff m¨ des KM Systems sein. Einbettung in den normalen Arbeitsablauf Um die Akzeptanz zu heben und ein Ignorieren des KM Systems unm¨ oglich zu machen, ist eine Integration in den normalen Arbeitsablauf besonders wichtig. Weitere Aspekte Wichtige weitere Aspekte sind Transparenz, also das Sichtbarmachen etwa durch Kontext und Historie oder auch organisatorische Maßnahmen, Nachvollziehbarkeit (¨ uberwiegend ebenfalls auf Kontext und Historie beruhend) und nichtfunktionale Anforderungen wie Geschwindigkeit und einfache Bedienung, um die Akzeptanz und Nutzung des Systems zu heben. 9.1.3 Vorhandene Open Source Basis Im zugeh¨ origen Kapitel werden wichtige Open Source Lösungen aus den Systemkategorien Groupware, CMS und DMS als Basis eines KM Systems vorgestellt und grob analysiert. Daneben gibt es noch eine F¨ ulle von wichtigen Systemen (etwa Business Software“) und Technologien (etwa Portale und ” Workflow Engines). Die Groupware Systeme kann man dabei in zwei Gruppen einteilen. Einerseits die klassischen“ Systeme, die aus ehemals kommerzieller Software ” entstanden sind. Andererseits relativ junge PHP basierte Weblösungen. Dabei hat eigentlich jedes dieser Systeme seine spezifischen Vor- und Nachteile. In der Kategorie der CMS Systeme gibt es im Vergleich zur Groupware eine deutlich gr¨ oßere Anzahl von Systemen und zum Teil sehr deutliche funktionelle Unterschiede im Hinblick auf KM (besonders wichtig das manchmal fehlende Berechtigungskonzept). Relativ interessant sind die beiden Python/Zope basierenden Systeme (Plone und elevateIT). Bei den PHP Systemen sticht Typo3 als gutes CMS System heraus, während XOOPS ein sehr interessanter Allrounder ist. Bei Java basierten Systemen hat OpenCMS die Nase vorn, w¨ ahrend JBOSS Portal eine rasche Weiterentwicklung durchmacht und ¨ ahnlich wie XOOPS einen Allrounder darstellt. Bei DMS Systemen muss man feststellen, dass es im Open Source Umfeld kaum umfassende und ausgereifte DMS Lösungen gibt. Bei PHP sticht KnowledgeTree besonders hervor und auch OWL scheint interessant. Besonders relevante Java basierte Client/Server Architekturen findet man bei Paper Harbour (eventuell ben¨ otigt man hier die Unterst¨ utzung der Herstellerfirma), xinco-DMS und jLibrary (beides relativ junge Systeme mit entsprechenden Ungewissheiten). Bez¨ uglich Portaltechnologie ist XOOPS ein PHP System, das bis zu einem gewissen Grad die Definition erf¨ ullt. Bei Java basierten Systemen gibt es etwa das als CMS vorgestellte JBOSS Portal oder auch die Produkte Liferay

9.1 Zusammenfassung

249

und Jetspeed. In diesem Umfeld sollte man auch unbedingt auf die Standards JSR 168 und WSRP achten. Grunds¨ atzlich betrachtet werden kleinere Initiativen meistens ohne Portal auskommen, während größere einen Einsatz ernsthaft u ¨ berlegen sollten. Was semantische Information betrifft, werden Topic Maps, Ontologien und das Semantic Web kurz besprochen. In diesem Bereich gibt es leider nur wenige vorhandene und ausgereifte Open Source Systeme. Bei k¨ unstlicher Intelligenz gibt es dagegen etwa das WEKA Paket als einen generellen Vertreter oder POPFile als spezialisierte Applikation. Weitere Systeme bestehen insbesondere aus Business Software wie etwa dem Java basierte Compiere als ERP und SCM System. Ebenfalls auf Java setzt openCRX auf, das primär ein CRM System ist. Mit Schwerpunkt CRM gibt es auch noch das PHP basierte SugarCRM. In speziellen Anwendungsfällen wird auch eine Digital Library wie Greenstone oder ein Visualisierungstool wie der Matrixbrowser Sinn machen. F¨ ur einen weiteren allgemeinen Ausbau eines KM Systems machen Workflow Engines wie etwa die beiden Java basierten Vertreter OpenWFE oder OSWorkflow Sinn. Dar¨ uber hinaus gibt es noch eine Reihe von häufig sinnvollen Erg¨ anzungen wie etwa das Open Ticket Request System (OTRS), phpBB (ein Bulletin Board System) oder phpWiki (wie der Name schon andeutet ein Wiki System). 9.1.4 Technische Basis Dieses Kapitel behandelt Fragen zu einer potenziellen technischen Basis eines KM Systems. Anders gesagt, welche Kombinationen Sinn machen und wie man entscheidet, was man verwenden sollte. Wichtig ist etwa, ob vorhandene Datenbest¨ ande und Systeme einge¨ bunden oder abgel¨ ost werden sollen (etwa auch aus finanziellen Uberlegungen heraus). Bei einer Groupware gibt es das größte Risiko“, das eine Ablöse ” beziehungsweise Einf¨ uhrung nicht sinnvoll sein könnte. Bei CMS und DMS Systemen ist das weniger zu erwarten. Was sonstige Systeme und Entwicklungen betrifft, muss man jeweils eine eigene Analyse durchf¨ uhren. Bei Business Software sollte man aber auf jeden Fall versuchen, zumindest die Daten bidirektional zu integrieren. Problematisch k¨ onnen weiters insbesondere vorhandene Portale und Frameworks“ sein, wo nur eine genaue Analyse und ” Gegen¨ uberstellung im Kontext der KM Initiative Klarheit schaffen kann. Der n¨ achste wichtige Punkt ist die Datenspeicherung mit zwei besonders wichtigen Aspekten: • •

Die Speicherung selbst sowie der Zugriff m¨ ussen sich durch eine möglichst große Offenheit auszeichnen (insbesondere durch eine abstrahierte Zugriffsschicht). Die Verf¨ ugbarkeit und Zuverl¨ assigkeit muss höchsten Anspr¨ uchen gerecht werden.

250


Bei Entscheidungen u ¨ber Basistechnologien muss man eine Evaluierung unbedingt von entsprechend kompetenten Mitarbeitern und Partnern durchf¨ uhren lassen. Die wichtigen Themenbereiche sind dabei: Fachliches Wissen; Wissen u ahigkeit zur Bewertung von Softwarearchitekturen; ¨ber und F¨ Notwendige F¨ ahigkeiten in der Softwareentwicklung; Wissen u ¨ber den Betrieb. Beim Thema der Programmiersprachen gibt es drei Hauptvertreter: Java, PHP und Python mit ihren jeweiligen Vor- und Nachteilen. Daneben sind insbesondere noch Perl, C/C++/Obj-C und .NET bei den vorgestellten Systemen relevant. Diese Fragestellung ist dabei eine grundsätzliche und es ist sicher von Vorteil, m¨ oglichst wenige Sprachen zu verwenden. Dar¨ uber hinaus sind Connectivity und Middlewarethemen wichtig. Web Services, CORBA und/oder RMI werden dabei von vielen Vertretern genutzt. Zus¨ atzlich gibt es noch eine Reihe anderer proprietärer Technologien. Sowohl f¨ ur diesen Bereich als auch f¨ ur die Datenbankanbindung sollte man daher eine entsprechende Abstraktionsschicht verwenden. So etwas kann auch gut durch einen Application Server (etwa dem J2EE Standard gehorchend oder so ¨ ahnlich wie bei XOOPS) abgedeckt werden. Als Krönung“ stellt sich ” noch die Frage, ob Portaltechnologie verwendet werden sollte. Der Trend geht aktuell sicher in diese Richtung und wenn eine entsprechende Verwendung und Integration Sinn macht, sollte man es tun. Alternativ kann man auf möglichst standardisierte/offene Systemteile setzen und später auf ein ausgereiftes Portal umsteigen. 9.1.5 Start mit einem Groupware System Mit Kapitel 5 beginnt die Diskussion u uhrung eines KM Systems ¨ber die Einf¨ startend mit einer Groupware. Dabei ist eine durchdachte KM Initiative eine unverzichtbare Basis, um nachhaltige Verbesserungen erzielen zu können. Ein wichtiger Unterschied ist dabei, ob eine Organisation schon eine Groupware im Einsatz hat oder nicht. Als Ergebnis einer Analyse kann dabei entweder eine Einf¨ uhrung, eine Abl¨ ose oder eine Integration eines Groupware Systems herauskommen. Eine entsprechende Analyse aller technischen, finanziellen und organisatorischen Aspekte sollte eine fundierte Entscheidung ermöglichen. Ein Sonderfall, der gut u ¨ berlegt werden muss, ist dabei die Variante, dass man das KM System gar nicht mit einer Groupware startet. Bei einer Entscheidung f¨ ur eine entsprechende Umsetzung wird man auf jeden Fall vom geplanten Umfang des KM Systems ausgehen, da nur so eine Reihe von organisatorischen oder technischen Fragen (etwa der besten“ Pro” grammiersprache) sinnvoll beantwortet werden kann. Besonders wichtig sind auch praktische Fragen notwendiges Know-how und Ressourcen betreffend. Konkret geht es nat¨ urlich um eine Diskussion der in Abschnitt 3.2 vorgestellten Systeme und ihrer spezifischen St¨ arken und Schwächen. Dar¨ uber hinaus stellt sich auch die Frage der Integration und insbesondere in welchen Situationen Portale wie etwa Jetspeed, Liferay, JBOSS Portal oder auch XOOPS geeignet sind. Weiters k¨ onnen auch CMS Systeme als Integrationsplattform

9.1 Zusammenfassung

251

in Frage kommen. Unabh¨ angig von technischen Details muss das Ziel eine integrierte Datenbasis und ein einheitliches und konsistentes System aus Benutzersicht sein. 9.1.6 Alternativ Start mit einem Content Management System Die wichtigste Alternative zu einem Start mit einen Groupware System ist, eine CMS L¨ osung als Basis zu w¨ ahlen. Die entsprechenden Produkte bieten n¨ amlich neben den bekannten Grundfunktionen eine ganze Reihe von weiteren M¨ oglichkeiten, die in der folgenden Einteilung kurz dargestellt werden: • • • • • • • •

Core CMS Funktionen (also das Editieren von Seiten und alles was dazugeh¨ ort) Erweiterte CMS Funktionen (wie Artikelsysteme, Dateiverwaltung, Kommentare, etc.) Personalisierung (einerseits passende Angebote und andererseits Zugriffskontrolle) Weitere zur Verf¨ ugung gestellte Informationen (wie FAQs, HOWTOs, Blogs, etc.) Strukturierte Kommunikation (wie Foren, Umfragen, etc.) Unstrukturierte Kommunikation (wie Chat, Instant Messaging, E-Mail, etc.) Zusammenarbeit (Collaboration) etwa mit Wikis, Gruppenkalender, etc. Projektunterst¨ utzung

Nat¨ urlich bietet keines der vorgestellten Systeme eine vollständige Unterst¨ utzung dieses Katalogs“, sodass auch hier eine Entscheidung im Rah” men der konkreten KM Initiative zu treffen ist. Eine entsprechende Analyse muss wieder bei schon vorhandenen Systemen starten, die bei CMS Systemen aber seltener einer Einf¨ uhrung (eventuell zusätzlich zu einem bestehenden System) im Weg stehen werden. Weiters ist zu u ¨berlegen, ob wirklich genug f¨ ur einen Start mit einem CMS System spricht (nicht immer ist ein Start mit einer Groupware oder einem CMS System sinnvoll). Wichtige Argumente daf¨ ur w¨ aren etwa ein Fokus auf Informationsdarstellung und Weitergabe f¨ ur den Start eines KM Systems. Im Hinblick auf die verschiedenen Funktionsblöcke eines CMS Systems ist die Analyse des konkreten und mittelfristigen Bedarfs f¨ ur eine Entscheidung besonders wichtig. F¨ ur einen Start mit einem CMS System spricht insbesondere Bedarf f¨ ur Core und erweiterte CMS Funktionen. Ein Fehlen spricht eher dagegen. Eine Diskussion der in Abschnitt 3.3 vorgestellten Systeme zeigt dann, dass es grob vier Gruppen von CMS Systemen gibt. Die Python/Zope und Java basierten sind relativ m¨ achtig“ und prinzipiell geeignet. Bei PHP ” gibt es einerseits die simplen“ beziehungsweise reinen“ CMS Systeme (meis” ” tens ohne ACLs), die nur selten eine sinnvolle Basis f¨ ur ein KM System sein werden, und die m¨ achtigeren“ CMS Systeme mit ACLs, wo es ein paar emp” fehlenswerte Vertreter gibt.

252


F¨ ur eine konkrete Auswahl gibt es dabei drei besonders wichtige Aspekte: Mittelfristige Ziele: Da viele der vorgestellten Systeme unmittelbar eine gute Wahl sind, besteht die Schwierigkeit hauptsächlich darin, ein System zu w¨ ahlen, bei dem eine f¨ ur die KM Initiative sinnvolle mittelfristige Zukunft gegeben ist. Programmiersprache: Hier geht es insbesondere darum unter Ber¨ ucksichtigung des verf¨ ugbaren Know-hows, der vorhandenen Ressourcen sowie der Kosten, eine technisch m¨ oglichst homogene Lösung anzustreben. Technische Basis/Integrationsaspekte: Entweder ist das CMS System die technische Basis f¨ ur das KM System oder es muss sich gut integrieren lassen. Dieser Aspekt ist mittelfristig von enormer Wichtigkeit. Neben den technischen Punkten muss man auch unbedingt organisatorische Aspekte wie die Einbeziehung von Schl¨ usselpersonen in die Analyse, Evaluierung und Gestaltung des zuk¨ unftigen Systems beachten. Eine entscheidende Rolle spielt auch die Einf¨ uhrung des Systems selbst, die etwa unbedingt von Schulungen begleitet werden muss. Gerade in dieser Phase m¨ ussen auch wieder eine Reihe von technischen Fragen behandelt werden. Neben den in Kapitel 4 und 5 behandelten Punkten geht es hier etwa auch darum, wie zuverl¨ assig das System sein muss oder wie die Frage des Backups geklärt wird.

9.1.7 Einbinden Groupware oder CMS bzw. Erweitern um DMS Als erste Ausbaustufe“ eines KM Systems bietet sich eine Erweiterung um ” ein CMS System beziehungsweise Groupware Produkt an. Dabei gibt es drei besonders wichtige Varianten: CMS und Groupware nebeneinander: Aus KM Sicht abzulehnen, da Arbeitsabl¨ aufe nicht innerhalb eines Systems m¨ oglich sind. Eine Teilintegration: Im einfachsten Fall zumindest eine u ¨ bergreifende Suche. Geht bis zur Integration aller Funktionen, die f¨ ur die wichtigsten Arbeitsabl¨ aufe ben¨ otigt werden. Eine Vollintegration: Aus KM Sicht die eindeutig beste Lösung, die den h¨ ochsten Nutzen verspricht. Gleichzeitig die potenziell komplizierteste und teuerste Variante. Daher nicht immer m¨ oglich. Bei der konkreten Frage der Erweiterung einer Groupware um ein CMS System kann man daraus schon eine Reihe von Entscheidungskriterien technischer, organisatorischer und finanzieller Natur ableiten. Auch bei der Umsetzung gibt es wichtige technische Punkte, wie das Sicherstellen einer einfachen und stabilen Architektur und organisatorischer Aspekte, bei denen man sich etwa neue Prozesse unter Einbeziehung der betroffenen Mitarbeiter u ¨ berlegen muss. Was die Erweiterung eines CMS um ein Groupware System betrifft, geht es wieder einerseits um die prinzipielle Sinnhaftigkeit aus der Sicht

9.1 Zusammenfassung

253

der KM Initiative und andererseits um die Art der Einbindung. Im Hinblick auf die schon dargestellten prinzipiellen M¨ oglichkeiten muss hier besonders gut u ¨berlegt werden, wie man mit einer eventuell schon vorhandenen Groupware L¨ osung umgeht und die diffizilen organisatorischen Fragen klärt. Nach den beiden Bl¨ ocken CMS und Groupware stellt sich die Frage, wie wichtig eine m¨ ogliche Erweiterung um DMS Funktionen ist. Da es um das Ablegen und Wiederfinden von allen m¨ oglichen Dokumenten geht, ist die Antwort dabei, dass es eher darum geht, in welcher Form die entsprechenden Aspekte abgedeckt werden (also durch Integration eines DMS Systems oder etwa durch erweiterte Funktionen eines CMS Systems). Die wichtigsten Funktionen eines DMS Systems sind dabei eine hierarchische Struktur, eine Versionsverwaltung, ACL Zugriffsschutz, eine Suchfunktion u ultigkeitszeiträume und/oder ein Archiv, ¨ ber Ordner und Dateiinhalte, G¨ Workflowunterst¨ utzung sowie eventuell virtuelle Ordner und/oder Links. Bessere DMS Systeme haben dar¨ uber hinaus noch weitere Möglichkeiten wie etwa Kommentare zu Dokumenten. Daher kann man feststellen, dass DMS Funktionen einige der in Kapitel 2 genannten Aspekte unterst¨ utzen. Am ehesten trifft das auf die Punkte Speicherung und Berechtigungssystem zu. Ein insgesamt wichtiger Punkt und f¨ ur DMS Funktionen von enormer Bedeutung ist eine Volltextsuche (wie etwa Google f¨ ur das Internet). Dabei m¨ ussen alle h¨ aufig verwendeten Dateiformate einer Organisation unterst¨ utzt werden und die Suchergebnisse immer den aktuellen Datenbestand (zumindest von gestern) widerspiegeln. Auch hier muss nat¨ urlich das Berechtigungsssystem greifen. Was eine Integration von DMS Funktionen in das KM System angeht, muss man wieder vom geplanten kurz- und mittelfristigen Umfang der KM Initiative ausgehen und schon vorhandene Möglichkeiten der ausgewählten CMS und/oder Groupware Systeme ber¨ ucksichtigen. Auch hier ist wieder eine Entscheidung hinsichtlich der Art einer Integration beziehungsweise Abdeckung der Anforderungen insbesondere auch unter Ber¨ ucksichtigung einer Kosten-/Nutzenrechnung notwendig. Bei einer Einf¨ uhrung ist es von enormer Bedeutung alle relevanten Datenquellen zu integrieren. Einerseits kann man einen Vertreter der in Abschnitt 3.4 vorgestellten DMS Systeme wählen oder andererseits vorhandene Funktionen von Groupware/CMS Systemen wie OpenGroupware oder auch XOOPS nutzen. Bei der Einf¨ uhrung ist es wieder notwendig, sich Gedanken u ¨ber die mittelfristige Zukunft der potenziellen Kandidaten zu machen und in Richtung eines möglichst homogenen Systems uber sollte man aber nicht auf die organisatorischen Aspekte zu arbeiten. Dar¨ wie etwa die Einbindung aktueller und zuk¨ unftiger Anwender vergessen. 9.1.8 Weiterer Ausbau Nach der Beschreibung eines relativ allgemeinen“ KM System, das im Maxi” malfall aus je einem Groupware, CMS und DMS System besteht, geht es im Weiteren um m¨ ogliche Ausbauten bis hin zu einem umfassenden KM System.

254


F¨ ur manche Bereiche gibt es dabei eine Vielfalt an Open Source Systemen, während es sich bei anderen um aktuelle Forschungsgebiete handelt. Prinzipiell sehr interessant sind dabei Topic Maps, die auf Taxonomien und/oder Ontologien (die leider nicht automatisch erstellt oder aktualisiert werden k¨ onnen) aufsetzen. F¨ ur dieses noch relativ junge Gebiet gibt es schon vereinzelt gute Open Source Software. Einen Einsatz kann man aber aufgrund der noch vielen offenen theoretischen und praktischen Fragen nur in ¨ Einzelf¨ allen empfehlen. Ahnliches muss man zu den auf Ontologien basierenden Semantic Web Technologien sagen. Die dabei relevanten Standards sind allgemein XML sowie OWL und RDF im Speziellen. Dabei sollte man beide Gebiete insbesondere bei mittleren bis gr¨ oßeren KM Initiativen unbedingt im Auge behalten. Eine konkretere Fragestellung ist die Integration von Drittsystemen und Datenquellen. Gleichzeitig kann man hier nur im Einzelfall aufgrund einer Kosten-/Nutzenanalyse unter Ber¨ ucksichtigung der mittelfristigen Ziele der KM Initiative entscheiden. Interessanter“ ist da schon die Kategorie der ” Business Software (insbesondere ERP und CRM). F¨ ur ein KM System macht ein entsprechender Zusatz oder eine Integration sehr viel Sinn. Gleichzeitig sollte man die damit verbundene Komplexit¨ at auf keinen Fall unterschätzen. Eher ein Spezialfall ist dagegen die Digital Library Greenstone zur Erfassung und Erschließung von Sammlungen aller Art. Dem Kern“ von KM n¨ aher sind andere potenziell relevante Systeme und ” Funktionen wie etwa ein Bulletin Board System, ein Gruppenkalender (wenn keine komplette Groupware integriert ist), ein Ticket Request System, Visualisierungsm¨ oglichkeiten, Klassifizierung von E-Mails und so weiter. Besonders interessant sind auch Wikis, wobei diese Funktion zum Teil schon in CMS oder Groupware Systemen integriert ist. Ein bis zu einem gewissen Grad problematisches Thema sind Workflows. Hier sollte man entsprechend vorsichtig und umsichtig an die Sache herangehen, um den Benutzern des Systems nicht zu viele Vorgaben zu machen und das System nicht zu starr zu gestalten. Gleichzeitig kann ein durchdachter Einsatz den Anwendern viel Arbeit abnehmen. Es gibt dabei eine Reihe von Open Source Workflow Engines, die sich f¨ ur eine Integration in ein KM System eignen. Auch haben einige der beschriebenen CMS und DMS Systeme mehr oder weniger ausgefeilte Workflowfunktionen schon direkt eingebaut. Inhaltlich n¨ aher zu KM aber nicht so allgemein in einem KM System ¨ ben¨ otigt ist Unterst¨ utzung f¨ ur eLearning. Ahnlich wie bei KM selbst gibt es keine klare Definition, man kann aber grob von Lernen mittels Unterst¨ utzung durch IT (meist u ¨ ber Entfernung) sprechen. Zum Teil können die Anforderungen von eLearning durch ein KM System direkt abgedeckt werden, während ussen. Was wichtige Zukunftstheandere Aspekte extra unterst¨ utzt werden m¨ ¨ men von eLearning angeht gibt es wieder eine Reihe von Uberschneidungen etwa die Wichtigkeit von offenen Standards, semantischer Information oder KI Technologien.

9.2 Abschluss

255

Ein besonders spannender Aspekt eines KM Systems ist auch die Nutzbarmachung der gesammelten Informationen. Das geht von simplen Dingen wie der Minimierung notwendiger Benutzereingaben bis hin zu dem Zugriff auf alle verf¨ ugbaren Informationen inklusive Kontext und Historie oder auch in Richtung Wiederverwendung, was ja zuerst ein Finden voraussetzt. Mit semantischer Information und der Verwendung von KI Technologien kann man noch weit dar¨ uber hinaus gehen. Man sollte sich dabei aber u ¨ber die damit verbundene Komplexit¨ at (etwa unterschiedliche Begriffswelten oder Sprachen) und das n¨ otige Know-how unbedingt im Klaren sein. Gleichzeitig kann man damit Begriffshierarchien erstellen, ¨ ahnliche Dokumente finden oder sie klassifizieren, Regeln und neue Informationen entdecken usw. Daher ist eine sehr sorgf¨ altige Abw¨ agung der Vor- und Nachteile unabdingbar, bevor man sich f¨ ur oder gegen eine Verwendung dieser Technologien entschließt.

9.2 Abschluss Nach der relativ detaillierten Zusammenfassung stellt sich die Frage, was die Kernaussagen und Folgerungen aus diesem Buch sein können. Dabei zeigt einem schon der Aufbau des Buches, welche Punkte f¨ ur ein erfolgreiches KM System von enormer Bedeutung sind: Eine grobe Definition des Gebiets und der Begriffe: Auch ein stark an der Praxis orientierter Text ben¨ otigt eine Basis. Insbesondere bei einem schwammig definierten Thema wie KM ist das eine Grundvoraussetzung. Daher ist es notwendig, u ¨ ber die grundlegenden Begriffe und ihre Bedeutung zu diskutieren und sie festzulegen. Der vielleicht wichtigste Aspekt ist, dass ein KM System einfach ein IT System ist, das KM unterst¨ utzt. Von daher muss es sich keineswegs von anderen IT Systemen unterscheiden. Die Vision: Dieser Teil mag vielen Praktikern u ussig erscheinen. Hoffent¨ berfl¨ lich haben sie sich trotzdem die Zeit genommen, diesen Abschnitt zu lesen. Anhand eines umfassenden Systems sollte sich jeder selbst u ¨ berlegen, welche Vision hinter der KM Initiative und dem KM System stehen soll. Nur ¨ so kann man einen klaren Kurs verfolgen und die Ubersicht behalten. ¨ Uberblick u ber die relevante Open Source Software: W¨ a hrend dieses Buch we¨ der einen ersch¨ opfenden noch einen stets aktuellen Stand bieten kann, ist ¨ es trotzdem eine Grundvoraussetzung, einen Uberblick u ¨ ber die relevanten Kategorien von Software und die Funktionen wichtiger Vertreter zu bekommen. Der Fokus liegt dabei ganz klar auf der f¨ ur die untersuchten Fragestellungen sinnvollen Software. ¨ Prinzipielle technische Uberlegungen: Gerade aufgrund der Vielfalt und Diversit¨ at der vorhandenen Open Source Software und dem entscheidenden Einfluss eines KM Systems auf die Leistungsfähigkeit einer Organistion, m¨ ussen die konkreten technischen Entscheidungen auf einem soliden Fun¨ dament beruhen. Als Basis ben¨ otigt man einen groben Uberblick sowie eine entsprechende Bewertung.

256


Schrittweiser Aus- und Aufbau: Praktisch betrachtet wird man ein KM System nur schrittweise einf¨ uhren. Dieser Erkenntnis folgend werden die jeweiligen Aspekte nacheinander und aufeinander aufbauend diskutiert. Ein typisches Ergebnis w¨ are ein Kernsystem“ mit Groupware, CMS und DMS ” Funktionen. F¨ ur umfassendere KM Initiativen gibt es dann noch eine ganze Reihe von m¨ oglichen und hochinteressanten Erweiterungen. Insbesondere KI Technologien in Kombination mit semantischer Information versprechen zu wichtigen Teilen von KM Systemen zu werden. Organisatorische und finanzielle Aspekte: Was sich eigentlich wie ein roter Faden durch das gesamte Buch zieht, ist die Wichtigkeit von organisatorischen und auch finanziellen Fragen. Das beste IT System ist vollkommen nutzlos, wenn es nicht zu den Abl¨ aufen einer Organisation passt. Außerdem muss eine L¨ osung von den Benutzern akzeptiert werden und das kann nur das Ergebnis organisatorischer Maßnahmen sein. Weiters darf man auch nie die finanziellen Aspekte vergessen. Eine korrekte Abschätzung insbesondere der positiven Effekte eines KM Systems ist dabei sehr schwierig. Trotzdem muss man sich dieser Problematik bei jeder potenziellen Erweiterung und Erg¨ anzung stellen. Nicht vergessen sollte man auch die organisatorischen und finanziellen Fragen des Betriebs des KM Systems. Mit dieser Darstellung wird noch einmal betont, dass es bei KM auf die erfolgreiche Kombination einer Reihe von Aspekten ankommt. Wird einer davon nicht ausreichend ber¨ ucksichtigt, kann das Gesamtergebnis nur suboptimal sein. Das ist auch der Hintergrund, warum dieser Text soviel Wert auf die gesamthafte Betrachtung legt. Gleichzeitig wird damit auch die Sinnhaftigkeit und Wichtigkeit der IT Unterst¨ utzung unterstrichen. 9.2.1 Von der Idee KM zum KM System Auf der gerade beschriebenen Basis kann man einen Ablauf f¨ ur die erfolgreiche Einf¨ uhrung eines KM Systems aufzeigen. Das primäre Ziel ist dabei, einen Anhaltspunkt zu bieten und nicht die alleinseligmachende Wahrheit aufzuzeigen. Jede Organisation ist einzigartig und daher kann und muss ihr Weg zu KM ebenfalls ein individueller sein. Auch soll und darf eine Vision nie als konkretes Ziel aufgefasst oder gar verfolgt werden. 1. Ein Verst¨ andnis f¨ ur KM im Generellen und in Bezug auf die eigene Organisation entwickeln 2. Mit Schl¨ usselpersonen zusammen die Vision einer umfassenden organisatorischen Anwendung“ von KM definieren; Diese unbedingt der Organi” sation vorstellen und Feedback einarbeiten 3. Darauf basierend eine entsprechende Vision f¨ ur ein komplettes“ KM Sys” tem festlegen 4. Eine Bestandsanalyse aller potenziell zu integrierenden, zuliefernden oder zu ersetzenden IT Systeme

9.2 Abschluss

257

5. Die Ableitung von unmittelbaren und mittelfristigen Zielen der KM Initiative aus der Vision 6. Definition der notwendigen und sinnvollen Unterst¨ utzung der KM Initiative durch ein KM- Kernsystem“ und seine Ausbaustufen ” 7. Vorentscheidungen f¨ ur die Art der Umsetzung und potenziell zu verwendende Open Source Software (nach entsprechender Analyse) 8. Eine Grobanalyse der Kosten und finanziellen Auswirkungen des geplanten KM Systems 9. Eine Abkl¨ arung der rechtlichen Bestimmungen im Hinblick auf die Auswertung und Integration einer Vielzahl von Daten 10. Zusammen mit Anwendern die betroffenen Arbeitsabläufe feststellen und m¨ oglichst optimale zuk¨ unftige Prozesse definieren 11. Aufgrund der geplanten Arbeitsabl¨ aufe sowie technischer und finanziel¨ ler Uberlegungen Entscheidungen u ¨ ber die zu verwendende Software, den Aufbau des KM Systems und der Einf¨ uhrung 12. Festlegung notwendiger Schulungsmaßnahmen und rechtzeitige Durchf¨ uhrung 13. Nach jedem Zwischenschritt der Einf¨ uhrung des KM Systems zusammen mit den Anwendern m¨ ogliche Verbesserungen erheben und möglichst bald umsetzen 14. Nach erfolgreicher Einf¨ uhrung des unmittelbar geplanten KM Systems mittelfristige Ziele ausarbeiten und die Vision der KM Initiative u ¨ berarbeiten ¨ 15. In Folge konstante Optimierung des Systems und regelmäßige Uberarbeitung der mittel- und langfristigen Ziele aufgrund neuer Entwicklungen innerhalb und außerhalb der Organisation Dieser Darstellung illustriert wieder die Komplexität der Einf¨ uhrung von KM und eines KM Systems in einer Organisation. Damit erklären sich auch viele Fehlschl¨ age, die den Ruf von KM besch¨ adigt haben. In vielen Fällen wurden n¨ amlich nicht auf den einen oder anderen Punkt vergessen sondern einfach ein neues IT System eingef¨ uhrt und die Organisation sollte sozusagen selbst lernen damit umzugehen. Damit war der Fehlschlag vorprogrammiert. Auch die fehlende Einbindung der zuk¨ unftigen Benutzer ist ein häufig begangener Fehler. Hier wird h¨ aufig mit Kosten und anderen Problemen argumentiert. Wenn diese Punkte im Einzelfall wirklich schlagend sein sollten, ist das allerdings kein Argument es ohne eine entsprechende Einbindung zu machen. Hier sollte man ganz im Gegenteil auf eine unmittelbare Einf¨ uhrung eines KM Systems verzichten. Abbildung 9.1 zeigt diesen Kreislauf auch grafisch. Dar¨ uber hinaus kann man sehr gut erkennen, dass KM und damit auch ein KM System nie abgeschlossen sein kann. Es gibt dabei vor allem die Pfeile zu der Definition der kurz- und mittelfristigen Ziele, die immer wieder u ¨berarbeitet und angepasst werden muss. In dem Sinne stehen die beiden letzten“ Punkte auch f¨ ur ex” terne Ereignisse, die direkt oder indirekt Anpassungen im KM System nötig

258


Verständnis für KM & Bezug zur Organisation

Grobanalyse Kosten & finanzielle Auswirkung

Vision der KM Initiative erarbeiten

Vorentscheidung Umsetzung & OSS

Abklärung rechtlicher Fragen

Optimierung und regelmäßige Anpassung

Vision eines „kompletten“ KM Systems erarbeiten

Definition „KM“ Kernsystem & pot. Ausbau

zukünftige Arbeitsabläufe definieren

mittelfristige Ziele festlegen & Vision anpassen

Bestandsanalyse aller relevanten IT Systeme

kurz- und mittelfristige Ziele der KM Initiative

Entscheidung über Technick des KM Systems

Schulungen erarbeiten und durchführen

Feedback geben und einpflegen

Abb. 9.1. Darstellung des Kreislaufes einer KM Initiative und eines KM Systems

9.2 Abschluss

259

machen. Die helleren Linien mit den kleineren Pfeilen zeigen dar¨ uber hinaus, dass es keine eindeutigen Kreise gibt und man je nach konkreter Situation auch eine Abk¨ urzung“ oder sogar den Weg bis zu den grundsätzlichen Defi” nitionen nehmen muss. 9.2.2 Der Schl¨ ussel“ zum Erfolg ” Der gesamte vorliegende Text hat ein großes Thema. Nämlich, wie man konkret vorgehen kann und soll, um einer KM Initiative und einem KM System zum Durchbruch zu verhelfen. Bis zu einem gewissen Grad ist daher dieser Abschnitt eigentlich u ussig. Gleichzeitig sollen hier noch einmal ganz ex¨ berfl¨ plizit die Grundpfeiler einer erfolgreichen KM Initiative aufgezeigt werden: Voraussetzungen und Grundlagen f¨ ur KM schaffen: Der vielleicht wichtigste Aspekt u uhren. Daf¨ ur ¨ berhaupt ist, die KM Initiative selbst zum Erfolg zu f¨ m¨ ussen die in Abschnitt 2.2 vorgestellten Punkte angegangen und eingearbeitet werden. Ohne den Willen zu KM, der entsprechenden Motivation, einer Kultur des Teilens und Zusammenarbeitens oder der Wahrhaftigkeit wird eine KM Initiative keinen durchschlagenden Erfolg erzielen. Auch die Organisation selbst muss darauf ausgerichtet werden was etwa das Entfernen und Errichten von Barrieren bedeutet, eine Beschäftigung mit u ¨ berpr¨ ufbaren Zielen der Initiative und eine kritische Analyse der Beziehung von KM zu Innovation und Kreativit¨ at. Anders gesagt benötigt eine KM Initiative eine solide Basis (was etwa auch der nächste Punkt adressiert) und nur darauf aufsetzend kann ein KM System erfolgreich sein. Einbeziehung der zuk¨ unftigen Nutzer der L¨ osung: Wie schon mehrfach betont ist es von h¨ ochster Wichtigkeit, zuk¨ unftige Nutzer des Systems bei der Einf¨ uhrung einzubinden. Meist k¨ onnen sie gleichzeitig auch die aktuellen Arbeitsabl¨ aufe einbringen. Mit ihnen zusammen kann man dann neue Prozesse definieren und das System entsprechend gestalten. Diese Aspekte k¨ onnen auch bei einer Entscheidung zwischen mehreren Systemvarianten helfen. Eine konkrete kurz- und mittelfristige Zielsetzung: Nur auf dieser Basis sind sinnvolle Entscheidungen f¨ ur oder gegen Bestandteile des KM Systems m¨ oglich. Ein Fehlen entsprechender Ziele bedeutet außerdem, dass es nicht wirklich eine konkrete Zielsetzung f¨ ur die KM Initiative gibt. Ohne wäre auch ein wirklicher Erfolg kaum mehr m¨ oglich. uhrt werden soll: Wie Eine konkrete Analyse was abgelöst, integriert & eingef¨ mehrfach beschrieben wurde, muss f¨ ur jede konkrete Situation analysiert und entschieden werden, ob ein neues System eingef¨ uhrt oder ein vorhandenes integriert wird. Ein Spezialfall“ bei der Einf¨ uhrung ist noch die ” M¨ oglichkeit einer Abl¨ ose. Entscheidungskriterien f¨ ur die anstehende Entscheidung: Dieser Punkt wird soweit wie m¨ oglich in den entsprechenden Kapiteln ausgef¨ uhrt. Ganz konkret geht es darum, eine m¨ oglichst sinnvolle und tragfähige Entscheidung

260


zu treffen. Dies ist nur m¨ oglich, wenn alle potenziell relevanten Punkte gew¨ urdigt wurden. Hier geht es insbesondere um technische und finanzielle Erw¨ agungen. Alle Aspekte die Umsetzung betreffend: Die Einf¨ uhrung eines KM Systems oder von Teilen davon stellt einen ¨ außerst sensiblen Vorgang dar. Praktisch immer muss ein großer Teil einer Organisation seine Arbeitsweise andern. Daher ist es absolut notwendig, alle Aspekte einer Umsetzung von ¨ der technischen Implementierung bis zum Abschalten eventueller Altsysteme und der Unterst¨ utzung der Benutzer durchdacht zu haben. Unmittelbar vor Einf¨ uhrung wird man entsprechende Schulungen durchf¨ uhren und danach unbedingt sinnvolle Hilfestellungen anbieten m¨ ussen. Einarbeiten von Feedback: Schon bei der Planung einer KM Initiative m¨ ussen unbedingt ein bis zwei Feedback-Schleifen“ vorgesehen werden. Manche ” Probleme werden leider erst klar, wenn die eigentlichen Nutzer das System f¨ ur die t¨ agliche Arbeit verwenden. In Folge muss man die R¨ uckmeldungen sammeln und entsprechende Anpassungen des Systems vornehmen. Man sieht, dass es eigentlich nicht einen sondern eine ganze Reihe von Schl¨ usseln“ zum Erfolg gibt. Die entsprechenden Punkte wurden dabei an ” passenden Stellen ber¨ ucksichtigt. Gleichzeitig zeigt erst diese Zusammenstellung die Gesamtheit der u ¨ berwiegend nicht-technischen Aspekte, die u ¨ ber den Erfolg oder Misserfolg einer KM Initiative entscheiden. Damit soll aber nicht der Eindruck erweckt werden, dass die Technik keine wichtige Rolle spielt. Allerdings sollte ein gutes System auf der Basis der vorgestellten Systeme machbar sein. Bei den anderen angesprochenen Aspekten muss vieles in der individuellen Organisation erarbeitet werden.

9.3 Ausblick Ein Ausblick f¨ ur dieses Buch ist einerseits relativ leicht und andererseits sehr schwierig. Leicht ist er deshalb, weil es eine Reihe von relevanten Forschungsgebieten und Technologien gibt, bei denen entsprechende Weiterentwicklungen zu erwarten sind. Schwer ist er vor allem deshalb, weil die Zukunft des Feldes Knowledge Management relativ unklar ist. Es ist eigentlich bis heute nicht gelungen, zu einer exakten Definition zu kommen. Auch konnten die fr¨ uhen Versprechungen, die es gegeben hat, u ¨ berwiegend nicht eingelöst werden. Nat¨ urlich ist auch der unabw¨ agbare Fortschritt in den relevanten Forschungsfeldern ein Problem“. ” Anders gesagt hat es KM bis jetzt nicht geschafft, ein klares Profil zu bekommen. Damit besteht die Gefahr, dass die Karawane“ weiterzieht, wie es ” so sch¨ on heißt. Gleichzeitig ist dieser Aspekt f¨ ur den Inhalt dieses Buches kaum relevant. Daf¨ ur gibt es eine ganz einfache Erklärung. KM, wie es in diesem Buch definiert wurde, ist unabh¨ angig vom verwendeten Namen“ von enormer ” Bedeutung f¨ ur die Wettbewerbsf¨ ahigkeit von Organisationen. (Wer allerdings

9.3 Ausblick

261

trotzdem Interesse an theoretischeren Betrachtungen hat, kann diese etwa in meiner Dissertation [20] finden.) Die technischen Grundlagen kommen sowieso aus den verschiedensten Ecken und entwickeln sich größtenteils unabhängig weiter. Zusammengefasst kann man feststellen, dass es viele f¨ ur KM wichtige Entwicklungen gibt. Diese werden zum Teil unabhängig von diesem Zusammenhang betrieben. Damit kann man sich auf die zugrunde liegenden Trends verlassen. 9.3.1 Wichtige Trends Ein ganz wesentlicher Teil dieses Ausblicks ist es aufzuzeigen, welche Gebiete und Technologien f¨ ur KM relevante Ergebnisse erwarten lassen. Darauf wurde an passender Stelle auch im Text direkt eingegangen, sodass einiges bekannt vorkommen sollte. Neben diesen speziellen“ Punkten gibt es allgemein noch das Thema, dass ” die Ergebnisse von verschiedenen Fachrichtungen zusammenkommen m¨ ussen. Hier hat KM immer noch Probleme, da verschiedene Gruppen das Thema f¨ ur sich vereinnahmen wollen. Weiters stehen hier auch Kommunikationsschwierigkeiten zwischen so unterschiedlichen Gebieten wie Wirtschaft, Philosophie und Informatik einer effektiven Zusammenarbeit im Weg. Dieser Probleme sollte man sich bewusst sein und bei verschiedenen Aussagen immer u ¨ berlegen, von welcher Warte aus sie getroffen wurden. Hier bleibt vor allem zu hoffen, dass sich die Situation in Zukunft bessern wird. Ontologien (und Taxonomien): Eines der aktuell aktivsten von den f¨ ur KM relevanten Forschungsgebieten. Dieser Fokus ergibt sich neben KM auch durch das Semantic Web oder etwa eLearning, um nur die wichtigsten zu nennen. Einerseits ist hier ein Durchbruch in nächster Zeit nicht wahrscheinlich. Andererseits k¨ onnen auch Zwischenergebnisse“ deutliche Ver” besserungen f¨ ur KM Systeme erm¨ oglichen. Sollte es zum Beispiel gelingen, eine komplette allgemeine Ontologie f¨ ur Deutsch zu definieren, könnten auf dieser Basis einige sehr interessante Funktionen realisiert werden. F¨ ur den Praktiker heißt das einfach abwarten und offen f¨ ur entsprechende Neuerungen zu sein. Insbesondere fehlen hier auch noch frei verf¨ ugbare Ergebnisse (und zwar sowohl entsprechende Ontologien als auch wirklich ausgereifte und einfache Software dazu). Speech Mining: Ist eine inzwischen schon relativ fortgeschrittene Methode, um Sprache f¨ ur Informationssysteme zug¨ anglich zu machen. Es gibt eine Reihe von erfolgreichen Pilotinstallationen etwa zur Verf¨ ugbarmachung von Telefonaten mit Kunden. Einer breiten Anwendung stehen hier einerseits die noch verbesserungsw¨ urdige Genauigkeit und andererseits die fehlende Datenbasis“ im Weg. Wegen der generell strengen Handhabung des ” Datenschutzes in Europa muss man hier auch rechtliche Aspekte stärker als in Amerika ber¨ ucksichtigen. Gleichzeitig gibt es aktuell drei wichtige Trends, die Speech Mining zum Durchbruch verhelfen könnten:

262


1. Die Verbesserung der zugrunde liegenden Technologie 2. Der billiger werdende Speicherplatz (aktuell oft ein Problem) 3. Voice over IP als Telefon der Zukunft (sowie auch Videokonferenzen u ¨ber das Internet) Insbesondere Voice over IP k¨ onnte eine unglaubliche Datenbasis f¨ ur Speech Mining schaffen und damit ein enormes Potenzial darstellen. Ein in diesem Zusammenhang interessanter Aspekt ist auch, dass IBM (einer der beiden f¨ uhrenden Hersteller von Spracherkennungssoftware) Ende 2004 Teile seiner Software als Open Source freigegeben hat. Video Analyse: Nicht ganz so weit entwickelt wie Speech Mining ist die Video Analyse. Generell gibt es bei der Interpretation von Bildern noch wesentlich mehr Forschungsbedarf als bei Sprache. Trotzdem existieren auch auf dieser Ebene schon sinnvolle Spezialsysteme. Zusätzlich gibt es nat¨ urlich die M¨ oglichkeit, bewegte Bilder u ¨ber die dazu gesprochene Sprache zug¨ anglich zu machen. Auf jeden Fall wird an diesem Thema intensiv gearbeitet und es gibt immer wieder neue Erkenntnisse. Das bedeutet, dass man hier relevante Ergebnisse erwarten kann. In weiterer Folge wird es sicher auch Open Source geben. Dar¨ uber hinaus kann man auch hier von einer stetig anwachsenden Datenmenge ausgehen, da immer häufig Videokonferenzen u ¨ ber Internet abgehalten werden. Bildanalyse: Bei der Analyse von Bildern handelt es sich um ein sehr interessantes Gebiet. In letzter Zeit sind auch einige relevante Applikationen entwickelt worden. So gibt es etwa eine Suche nach Bildern im Internet als Funktion von Google. Ein Teil dieses Feldes beschäftigt sich auch mit ¨ der Ahnlichkeit von Bildern (wie das ja auch f¨ ur Dokumente möglich ist). F¨ ur ein KM System ist das Ganze sicher kein zentrales Thema. Gleichzeitig sollte man nicht auf eine Integration verzichten, sobald entsprechend leistungsf¨ ahige Open Source Software verf¨ ugbar ist. Enterprise Application Integration (EAI), ...: Ein aktueller Trend in der Softwareentwicklung ist es, immer gr¨ oßere Systeme möglichst einfach und effizient zu integrieren. Das ist einer der technisch noch nicht optimal gelösten Aspekte von KM Systemen. Hier sind keine Durchbr¨ uche zu erwarten. Gleichzeitig sollte man diese Entwicklungen mitverfolgen und entsprechende Ergebnisse und Integrationsplattformen verwenden. Ganz konkret zeigt auch der Aspekt der Verwendung eines Portals zur Integration von Teilsystemen in diese Richtung. Gehirnforschung: Bis zu einem gewissen Grad ist dieses Thema nicht dazupassend. Gleichzeitig sollte man nicht vergessen, dass die Versuche, eine K¨ unstliche Intelligenz zu schaffen, auch am fehlenden Verständnis f¨ ur den menschlichen Geist und das menschliche Gehirn scheitern. Diese Betrachtungen bringen keinen unmittelbaren Nutzen f¨ ur KM und schon gar nicht f¨ ur ein KM System. Man sollte aber auch nicht darauf vergessen, dass hier eines der grunds¨ atzlichen Probleme liegt.

9.3 Ausblick

263

Man sieht, dass es wirklich eine ganze Reihe von spannenden Gebieten gibt, bei denen wichtige Ergebnisse f¨ ur KM Systeme zu erwarten sind. Einerseits bedeutet das, dass man bei Bewertungen in diesem Buch immer auch den Zeitpunkt der Ver¨ offentlichung in Betracht ziehen muss. Andererseits ist das auch ¨ außerst interessant, weil man ein sich ¨ anderndes Thema bearbeiten kann und es h¨ aufig etwas Neues zu lernen und verwenden gibt. 9.3.2 Schl¨ usselfelder f¨ ur KM Unabh¨ angig von der zuk¨ unftigen Entwicklung von KM geht es bei dieser Thematik um essenzielle Themen, denen sich Organisationen in der Zukunft stellen m¨ ussen. Schon Abschnitt 2.2 hat sich ansatzweise mit solchen Fragen besch¨ aftigt. Dabei geht es einerseits um grundlegende Aspekte von KM selbst und andererseits um wichtige Fragestellungen in Hinblick auf KM Systeme. Das weite Feld von KM kann und soll hier nicht komplett behandelt werden. Soziologische Aspekte: Ein ganz wesentlicher Punkt ist die weitere Erforschung von soziologischen Aspekten in Hinblick auf KM. Einerseits um vorhandene Erkenntnisse und Ergebnisse verstärkt in KM einfließen zu lassen und andererseits um wichtige Fragestellungen des KM aufzuwerfen und (Teil-)Antworten zu bekommen. Ganz besonders wichtige Punkte sind etwa die Forschung zu Organisationen und möglichen Organisationsformen oder die Frage von Zusammenarbeit in Gruppen. Psychologische Aspekte: Dieser Punkt ist einerseits wichtig, was Fragen zu einzelnen Individuen einer Organisation betrifft, und andererseits wegen der Wechselwirkungen mit der Soziologie, was etwa Gruppen betrifft. Insbesondere in diesem Zusammenhang gibt es wichtige Fragen (etwa zur Dynamik von potenziell virtuellen Gruppen), deren Beantwortung KM ein gutes St¨ uck weiterbringen kann. Philosophische Aspekte: Das weite Feld der Philosophie hat ebenfalls eine ganze Menge zu KM beizutragen. Insbesondere wenn es um Fragen der Semantik (etwa Ontologien) geht, bestehen hier direkte Ankn¨ upfungspunkte. Dar¨ uber hinaus gibt es eine Reihe von Fragen, die die Wirtschaftswissenschaften, Soziologie und Philosophie gemeinsam behandeln m¨ ussen, etwa was den Aspekt der Motivation von Menschen betrifft. Wirtschaftliche Aspekte: Bis zu einem gewissen Grad hat die dahinterstehende Gruppe KM in Beschlag“ genommen. Unabhängig von diesem wenig ” hilfreichen Ansatz, handelt es sich nat¨ urlich um eine zentrale Fragestellung. KM versucht im Kern die Wettbewerbsfähigkeit von Organisationen u ¨ ber den Faktor Wissen zu verbessern. Hier geht es insbesondere um eine m¨ oglichst ganzheitliche Sicht und um eine weitere Verbesserung des praktisch verf¨ ugbaren Instrumentariums zur Steuerung, Planung, etc. Medizinische“ Aspekte/Gehirnforschung: Wurden schon wegen der Relevanz ” f¨ ur die KI Forschung angef¨ uhrt. Nat¨ urlich sind hier keine ganz direkten Forschungsbeitr¨ age zu erwarten. Gleichzeitig ist ein weiter vertieftes

264


Verst¨ andnis des menschlichen Gehirns und Bewusstseins wichtig f¨ ur KM. Die praktisch verwertbaren Erkenntnisse werden dabei u ¨ berwiegend in Zusammenarbeit mit Soziologen, Psychologen und Philosophen zu erwarten sein (und werden sicher nur“ Schritt f¨ ur Schritt erfolgen). ” Wie man schnell erkennen kann, ist KM von einer Vielfalt von Feldern abh¨ angig. Ein ganz besonderer Schwerpunkt liegt dabei auf einem besseren Verst¨ andnis des Menschen, der als einziger echter Träger von Wissen noch viel zu wenig verstanden wird. Dabei sollte man seinen Blick aber keineswegs nur auf nicht so schnell zu erwartende Durchbr¨ uche etwa in der Erforschung des menschlichen Bewusstseins konzentrieren. Es gibt ganz im Gegenteil schon unmittelbar eine unglaubliche Vielfalt an Erkenntnissen und Forschungsergebnissen, die zusammengenommen einen großen Unterschied f¨ ur KM machen können. Gerade mit einer u ¨ bergreifenden Betrachtung und Integration verschiedener Ans¨ atze und Erkenntnisse kann man sicher am meisten unmittelbar bewegen. Dazu ist es vor allem notwendig, dass Manager ihre noch häufig dominierenden hierarchischen und mechanistischen Denkmuster u ¨berwinden. Allein dieser Punkt hat enormes Potenzial f¨ ur KM.

Glossar

ACL – Access Control Lists Ein Berechtigungssystem basierend auf einer Liste von Gruppen und Benutzern und den jeweils zugeordneten Rechten f¨ ur eine Ressource. In einem Dateisystem typischerweise lesen, andern und/oder l¨ oschen. ¨ Active Directory Ein von Microsoft mit Windows 2000 eingef¨ uhrtes propriet¨ ares Directory Service. Nimmt viele Anleihen an schon zuvor bestehenden Systemen (wie etwa LDAP) und kann daher im Prinzip gut mit anderen Directory Services verglichen werden. ADOdb Ist eine beliebte PHP Library f¨ ur den datenbankunabhängigen Zugriff auf SQL Datenbanken. AI – Artif icial Intelligence siehe K¨ unstliche Intelligenz AP I – Application P rogramming Interf ace Die Programmierschnittstelle. Anders gesagt wird u ¨ ber ein API Funktionalität etwa einer Library zur Verf¨ ugung gestellt. Daher wird h¨ aufig auch die dazugehörige Dokumentation unter diesem Begriff mitverstanden. AP L – Apache License Eine Open Source Lizenz, die f¨ ur das Apache Projekt entstand, und auch dar¨ uber hinaus Verbreitung gefunden hat. Es handelt sich dabei um eine vollwertige Open Source/Free Software Lizenz. Applikationsserver / Application Server Leider gibt es hier keine eindeutige Definition. Am einfachsten l¨ asst sich dieser Begriff daher u ¨ ber eine Abgrenzung definieren. Eine Anwendung hat eine Datenbankschicht, weiters eine Schicht mit Applikations- oder Businesslogik und noch eine Schicht mit der Pr¨ asentation. Die mittlere Schicht ist die Domäne eines Applikationsservers (wobei eine Präsentationsschicht hier durchaus mitlaufen kann). BAP I – Business Application P rogramming Interf ace Schnittstellen und APIs zur Einbindung von Funktionen des ERP Systems SAP R/3. Blog – (W eb-Log) Im Prinzip ein Online Tagebuch. Eine Person teilt in ihrem Blog in unregelm¨ aßigen Abst¨ anden (bis zu täglich) Interessantes mit.

266


BSD License – Berkeley Sof tware Distribution License Die wahrscheinlich drittwichtigste Open Source/Free Software Lizenz. Erlaubt im Gegensatz zur GPL und LGPL, dass abgeleitete Software kommerziell vertrieben werden darf. CM S – Content M anagement System Wie der Name schon sagt, ein IT System zum Verwalten von Inhalten. H¨ aufig als Web-CMS“ f¨ ur Internet ” und Intranet Inhalte gedacht (und meist wird der Begriff CMS mit dieser Bedeutung verwendet). Typischerweise ein System, dass es einer Reihe von Redakteuren erm¨ oglicht eine Seite koordiniert zu betreuen. CRM – Customer Relationship M anagement Die Prozesse und Technologien zur m¨ oglichst effizienten und erfolgreichen Zusammenarbeit“ mit ” dem Kunden. Etwa durch eine zusammengefasste Sichtweise auf alle Informationen u ¨ ber und zu einem Kunden. CSCW – Computer Supported Cooperative W ork Im Prinzip inhaltlich sehr ahnlich zum Begriff Groupware. Es geht um Theorien und Technolo¨ gien zur Unterst¨ utzung von Gruppenarbeit. Der Begriff Groupware wird vor allem f¨ ur die eigentlichen technischen Systeme verwendet, w¨ ahrend CSCW etwa durch Ber¨ ucksichtigung von psychologischen, soziologischen und organisatorischen Aspekten dar¨ uber hinausgeht. CSV – Comma Separated V alues Ein simples Format, das Werte mit einem bestimmten Zeichen (Comma) trennt. Das Trennzeichen ist dabei h¨ aufig ein Beistrich oder Strichpunkt. Wird gerne zum Datenaustausch verwendet, da es leicht verwendet und/oder importiert werden kann. CT I – Computer T elephony Integration Ein allgemeiner Name f¨ ur eine Reihe von Technologien, die eine Verbindung zwischen EDV-Systemen und einer Telefonanlage herstellen. Eine der wichtigsten Funktionen ist dabei das Handhaben von ein- und ausgehenden Anrufen (etwa eine Telefonnummer aus einem Adressbuch am Computer zu wählen). DBM S – Database M anagement System Kurz gesagt eine Datenbank wie etwa MySQL, PostgreSQL, Oracle, DB2, MS SQL Server, Access, . . . Prinzipiell gibt es verschiedene Typen wie etwa hierarchische, relationale, objekt-orientierte oder XML basierte Datenbanken. Das Feld wird dabei aber von den relationalen Datenbanken dominiert (die aufgez¨ ahlten Produkte sind klassische relationale Datenbanksysteme). Directory Service Ein Directory Service bietet eine hierarchische Struktur und erm¨ oglicht das Abspeichern von Attributen bei den einzelnen Knoten. H¨ aufig stellt der Baum eine Organisation und ihre Organisationseinheiten dar. Die Blätter“ sind dann die Benutzer bei denen ” etwa das Passwort oder (unter anderem) Berechtigungen abgespeichert sind. Prinzipiell kann ein Directory Service aber noch f¨ ur viel mehr (und anderes) verwendet werden. DM S – Document M anagement System Wie der Name schon andeutet ein IT System zum Verwalten von Dokumenten. Typischerweise bietet so

9.3 Ausblick

267

ein System abgestufte Berechtigungen, Möglichkeiten zur Suche und Strukturierung, eine Versionskontrolle und vieles mehr. DSS – Decision Support System Fr¨ uher sehr beliebter Begriff f¨ ur Systeme, die prim¨ ar dem Management helfen sollen, Entscheidungen zu treffen. Das kann von einer Informationsaufbereitung bis zum Einsatz von Data Mining und K¨ unstlicher Intelligenz gehen. Dublin Core Ein Standard f¨ ur Metadaten. Im Prinzip gibt es 15 Elemente oder Felder wie Titel, Autor und Thema, die zur Strukturierung von Informationen verwendet werden k¨ onnen. Entstand urspr¨ unglich im Bibliotheksbereich und ist erweiterbar. Eclipse Prinzipiell eine offene Plattform, die ein Framework f¨ ur alle möglichen Anwendungen bietet. Entstanden aus einer Java Entwicklungsumgebung von IBM (immer noch der Haupteinsatzzweck). Mittels (Java) Plug-ins flexibel erweiterbar und f¨ ur alle möglichen Einsatzzwecke verwendbar. Siehe http://www.eclipse.org f¨ ur Details. ¨ EDI – Electronic Data Interchange Der Uberbegriff f¨ ur eine Reihe von Standards zum Austausch elektronischer Nachrichten (wie etwa EDIFACT). Erm¨ oglicht so den automatischen Versand, Empfang und die Verarbeitung von Bestellungen, Rechnungen, etc. Durch ihre hohe Komplexit¨ at werden Standards der EDI-Familie nur relativ selten eingesetzt. In der Zukunft ist außerdem eine Ablöse durch neuere XML basierte Standards zu erwarten. EJB – Enterprise Java Bean Java API f¨ ur die in großen (Enterprise) Anwendungen hilfreichen Abstraktionen etwa der Datenbank. Eigentlich der Kern“ der Java 2 Enterprise Edition und entsprechender App” lication Server. Definiert einerseits Schnittstellen f¨ ur den Aufruf von Services und bietet andererseits auch die Möglichkeit, den Code einfach woanders ausf¨ uhren zu lassen (einem anderen Java Application Server). ERP – Enterprise Resource P lanning Wichtige Kategorie von Business Software. Es geht dabei um die Verwaltung und Planung von Ressourcen meist gr¨ oßerer Organisationen. ES – Expert System Ein Expertensystem ist typischerweise ein IT System, das aufgrund von Regeln und Fakten Schlussfolgerungen zieht. Der Name ergibt sich aus der Idee, dass man das Wissen eines Experten kodieren und das System danach wie der Experte entscheiden kann. Solche Ansätze haben bis jetzt nur eingeschränkte Erfolge vorzuweisen. Extranet Im Prinzip ein Mittelding zwischen einer Internet Homepage“ und ” einem Intranet (nur innerhalb einer Firma). Es ermöglicht den Zugriff auf eine Webpage f¨ ur einen eingeschränkten Benutzerkreis u ¨ ber das Internet (neben einem internen Zugang). F AQ – F requently Asked Questions Eine Sammlung von häufig gestellten Fragen zusammen mit den Antworten. Einerseits werden so bekannte Probleme und Fragen dokumentiert. Andererseits kann man so An-

268


fragen effizienter behandeln (auch wenn die zuständigen Personen gar nicht verf¨ ugbar sind). F T P – F ile T ransf er P rotcol Ein relativ einfaches Internet Protokoll zum ¨ effizienten Ubertragen von Dateien. GP L – General P ublic License Die wichtigste Open Source/Free Software Lizenz. Unterscheidet sich von der LGPL dadurch, dass auch Software die nur“ GPL Teile verwendet selbst unter die GPL gestellt ” werden muss. Groupware Systeme zur Unterst¨ utzung der Zusammenarbeit von Gruppen. H¨ aufig als Teil von CSCW – Computer Supported Cooperative Work – aufgefasst. Bieten typischerweise als Kernfunktionen E-Mail, einen Gruppenkalender, ein (globales) Adressbuch und Aufgaben. HT M L – HyperT ext M arkup Language Der HTML Standard (definiert von dem World Wide Web Consortium [W3C], das verantwortlich f¨ ur Webstandards ist) beschreibt wie eine HTML Seite aufgebaut sein darf und wie sie dargestellt werden soll. Existiert in verschiedenen Versionen bis einschließlich 4.01. Seither gibt es XHTML (HTML als XML formuliert) zur Abl¨ ose. HT T P – HyperT ext T ransport P rotocol Das Transportprotokoll des World Wide Web. Wurde vom W3C definiert und wird etwa f¨ ur den Transport von HTML Dateien oder SOAP Nachrichten verwendet. iCalendar Ein beliebtes Format zum Austausch von Kalenderdaten. Wird beispielsweise von Kolab/Kroupware oder auch Outlook unterst¨ utzt. Es ist in drei Internetstandards (RFCs) definiert: 2445, 2446 und 2447. Historisch betrachtet basiert das iCalender oder iCal Format auf dem alteren vCalendar Format. ¨ IM AP – Internet M essage Access P rotocol Ist ein Internet Protokoll, um auf Nachrichten (meistens E-Mails aber auch Foren, etc. sind möglich) zugreifen zu k¨ onnen. Aktuell wird vor allem Version 4 dieses Protokolls verwendet und dadurch ergibt sich die Abk¨ urzung IMAP4. Im Gegensatz zu POP3 kann man mit IMAP Nachrichten auf dem Server sinnvoll verwalten (etwa u ¨ber Ordner und eine Suche auf dem Server). J2EE – Java 2 Enterprise Edition Eine Reihe von APIs und Definitionen, die einen Java 2 Application Server ausmachen. Basiert dabei auf der Java 2 Standard Edition und stellt etwa auch einen Servlet Container und die Infrastruktur f¨ ur Enterprise Java Beans zur Verf¨ ugung. Mit Einf¨ uhrung der Version 5 wird die Ziffer 2 gestrichen, was das K¨ urzel JEE – Java (Platform) Enterprise Edition – ergibt. J2M E – Java 2 M icro Edition Ein abgespecktes Java, das insbesondere auch auf PDAs und Handies l¨ auft. Enth¨ alt etwa keinen Garbage Collector. J2SE – Java 2 Standard Edition Die Definition eines Core“ Java f¨ ur nor” male Anwendungen. Enth¨ alt alles, was man zum Programmieren von Anwendungen in Java braucht. Darauf aufbauend gibt es noch die J2EE – Java 2 Enterprise Edition.

9.3 Ausblick

269

Java JCA – J2EE Connector Architecture Ein J2EE Standard (API) zur Entkoppelung des Sendens und Speicherns/Behandelns von synchronen Nachrichten. Prim¨ ar eine Abstraktion entsprechender Middleware Systeme (etwa CORBA). Java JM S – Java M essage Service Ein Java Standard (API) zur Entkoppelung des Sendens und Speicherns/Behandelns von Nachrichten unter der Verwendung von Queues (sozusagen eine Abstraktion von Message-Oriented Middleware Systemen wie etwa IBM WebSphere MQSeries). Java Swing Eine Java Library von Sun Microsystems, die das Erstellen von Benutzerschnittstellen erm¨ oglicht. Technisch betrachtet ist es eine GUI (Graphical User Interface) Library. JDBC – Java DataBase Connectivity Ein Java API, dass den datenbankunabh¨ angigen Zugriff auf SQL Datenbanken ermöglicht. JSP – Java Server P ages Eine Technologie von Sun Microsystems bei der Java Code in einer HTML Seite eingebettet werden kann. JSR – Java Specif ication Request Ein JSR wird mittels des Java Community Process eingereicht und diskutiert. Der Vorschlag f¨ ur ein neues Java API wird unter der JSR Nummer diskutiert, bis er akzeptiert (oder auch abgelehnt) wird. Siehe http://jcp.org/ f¨ ur mehr Details. JSR 168 Bei JSR 168 handelt es sich um die Portlet Spezifikation von Java. Anders gesagt wird definiert, wie ein Portlet mit dem Portal Server und anderen Portlets kommunizieren kann. Siehe http://jcp.org/en/ jsr/detail?id=168 f¨ ur Details. JSR 170 Bei JSR 170 handelt es sich um die erste Version einer Content Repository Spezifikation von Java. Es wird dabei eine Schnittstelle f¨ ur die Ablage versionierter Daten definiert. Siehe http://jcp.org/en/ jsr/detail?id=170 f¨ ur Details. Version 2 der Spezifikation wird unter JSR 283 erarbeitet (http://jcp.org/en/jsr/detail?id=283). JSR 283 siehe JSR 170 KI – K u ¨nstliche Intelligenz Der Versuch die menschliche Intelligenz mittels Computer nachzubilden, um etwa sinnvolle Entscheidungen vorschlagen zu k¨ onnen oder den Menschen Arbeit abzunehmen. Obwohl es immer wieder Fortschritte auf diesem Feld gibt, ist ein Durchbruch nicht abzusehen. Gleichzeitig bieten die Zwischenergebnisse“ viele ” M¨ oglichkeiten f¨ ur IT Systeme. KM – Knowledge M anagement In diesem Buch alle Aktivitäten, die sich mit Daten, Informationen und Knowledge (Wissen) beschäftigen. Knowledge Ein leider nicht ganz exakt definierter Begriff. Prinzipiell handelt ufte Information potenziell im Zusames sich bei Knowledge um u ¨ berpr¨ menhang mit Personen, die mit Informationen und anderen Personen interagieren. LDAP – Lightweight Directory Access P rotocol Dieses Protokoll definiert den Zugriff auf X.500 Directory Services und ist im RFC (Request for Comment; Internet Standard) 3377 definiert.

270


LGP L – Lesser General P ublic License Die wahrscheinlich zweitwichtigste Open Source/Free Software Lizenz. Unterscheidet sich von der GPL vor allem dadurch, dass Software die nur“ LGPL Teile verwendet ” selbst nicht unter eine Open Source Lizenz gestellt werden muss. M DA – M odel Driven Architecture Eine von der Object Management Group propagierte Methode der Softwareentwicklung. Dabei werden plattformunabh¨ angige Modelle in einer standardisierten Sprache definiert, die die gesamte Applikation spezifizieren. Daraus wird dann der eigentliche Code generiert. M iddleware Allgemein die Bezeichnung von technischer Infrastruktur zum Verbergen von Komplexit¨ at. Prim¨ ar wird dieser Begriff f¨ ur technische Infrastruktur von verteilten Applikationen verwendet (in diesem Sinn ist etwa CORBA eine Middleware). Kann etwa aber auch eine Abstraktion von Datenbankzugriffen, . . . sein. M IS – M anagement Inf ormation System Eher älterer Begriff f¨ ur alle möglichen Systeme zur Aufbereitung von Informationen f¨ ur das Management. M P L – M ozilla P ublic License Eine Open Source Lizenz, die f¨ ur das Mozilla Projekt entstand und auch dar¨ uber hinaus Verbreitung gefunden hat. Es handelt sich dabei um eine vollwertige Open Source/Free Software Lizenz. N IS/Y P Network Information Services beziehungsweise Yellow Pages: Eine (unter anderem) Benutzerverwaltung, die unter UNIX verbreitet ist (von der Firma Sun Microsystems entwickelt). Generell ein Mechanismus, um Informationen in einem Netzwerk zu verbreiten. Dabei ist NIS der Nachfolger von YP. OAGIS Damit sind Schnittstellen und Formate f¨ ur den Austausch von Daten zwischen großen Firmen gemeint. Diese werden von der Open Applications Group definiert. ODBC – Open Database Connectivity Stellt eine generelle Schnittstelle f¨ ur die Anbindung verschiedener Datenbanken zur Verf¨ ugung. Wurde prim¨ ar von Microsoft f¨ ur Windows eingef¨ uhrt (basierend auf existierenden Standards und in Zusammenarbeit etwa mit X/Open), ist jetzt aber auch auf den vielen anderen Plattformen verf¨ ugbar. OF X – Open F inancial eXchange Ein Format zum Austausch von Finanz¨ informationen (etwa Uberweisungen). Basiert auf Vorläuferformaten von Microsoft und Intuit. OLAP – Online Analytical P rocessing Unmittelbarer Zugriff und Analyse von Daten, um Trends zu erkennen und Statistiken zu generieren, die selbst ein Data Warehouse nicht direkt liefern kann. Meist werden dazu die Daten multi-dimensional ausgewertet. Ontologie Eine Begriffshierarchie, die auch die Bedeutung der einzelnen Begriffe festlegt und Regeln beinhaltet. Damit hat man etwa den Zusammenhang, dass eine Katze ein S¨ augetier ist zusammen mit einer Definition einer Katze (etwa u ¨ ber die Anzahl der Pfoten, etc.) und Re-

9.3 Ausblick

271

geln wie das eine Katze nicht ins Wasser will. Eine formale Ontologie definiert auch noch disjunkte Begriffe und Unterscheidungen zwischen Typen und Rollen, was eine linguistische Ontologie nicht (komplett) tut. Open Source Prinzipiell Software, deren Quellcode zugänglich ist. Im engeren Sinn zusammen mit der Erlaubnis diesen zu modifizieren und weiterzuverbreiten. Ganz ¨ ahnlich verh¨ alt es sich mit Free Software, wobei hier die Free Software Foundation versucht, entsprechende Kriterien festzulegen und sich von der reinen Verf¨ ugbarkeit des Quellcodes zu unterscheiden. P DA – P ersonal Digital Assistant Von der Idee her ein elektronischer Filofax. Verwaltet zumindest Kontakte, den Kalender, Aufgaben und Notizen. Heutzutage meist mit umfassenden Möglichkeiten ausgestattet und oft mit einem Handy zu einem Smartphone kombiniert. P DF – P ortable Document F ormat Ein Dateiformat von der Firma Adobe zum einfachen Dokumentenaustausch. Einerseits gibt es fast u ¨ berall eine Anzeigesoftware und andererseits sieht ein PDF u ¨ berall gleich aus. Daher eignet sich dieses Format sehr gut f¨ ur den Austausch von Dokumenten, die nicht mehr ver¨ andert werden m¨ ussen. P GP – P retty Good P rivacy Einerseits der Name des entsprechenden Programms und andererseits einer Verschl¨ usselungsmethode entwickelt von Phil Zimmermann. Es handelt sich um ein kryptografisches Verfahren, das mit einem ¨ offentlichen (public) sowie einem privaten (private) Schl¨ ussel arbeitet. Dabei wird mit dem öffentlichen Schl¨ ussel (potenziell von jemand Anderem) verschl¨ usselt und mit dem privaten Schl¨ ussel entschl¨ usselt. P HP P EAR – P HP Extension and Add-on Repository Mit PEAR ist eine mit PHP mitgelieferte Library gemeint, die etwa einen datenbankunabh¨ angigen Zugriff gestattet oder auch ein Cache System liefert. P OP 3 – P ost Of f ice P rotocol 3 Ein Internet Protokoll zum Abholen von Nachrichten von einem POP Mailserver. Die Definition findet sich im RFC (Request for Comment) 1939. Aktuell wird primär Version 3 verwendet und damit ergibt sich die Abk¨ urzung POP3. Im Gegensatz zu IMAP gibt es kaum Verwaltungsfunktionen f¨ ur die Nachrichten auf dem Server. REST – Representational State T ransf er Eigentlich eine Reihe von Prinzipien, die einer der HTTP Designer (Roy Fielding) in seiner Doktorarbeit beschrieben hat. Wird heutzutage als Begriff f¨ ur Web Services verwendet, die auf diesen Prinzipien beruhen und XML sowie HTTP benutzen, aber keine weitere Abstraktion bieten (im Gegensatz zu XMLRPC oder SOAP). RSS Bei RSS handelt es sich um ein XML basiertes Format zur Verteilung von Internetinhalten etwa von Nachrichten, die als einzelne RSS Datens¨ atze in einer Datei enthalten sind. Es ist umstritten, wof¨ ur RSS steht (wenn es u ¨berhaupt ein Akronym ist), es könnte aber Rich Si-

272


te Summary, RDF Site Summary oder Real Simple Syndication sein. Dabei sind sehr unterschiedliche Versionen des Standards in Gebrauch (insbesondere 0.9, 0.91, 2.0 und 3), die zum Teil auf dem RDF Standard (siehe Abschnitt 8.2.1 f¨ ur Infos dazu) aufsetzen. S/M IM E – Secure/M ultipurpose Internet M ail Extensions Ein Standard f¨ ur eine Verschl¨ usselung mit einem Verfahren ähnlich PGP sowie einer Definition, wie so etwas in eine E-Mail eingebettet wird. Im Prinzip leitet sich das Verfahren von MIME (ohne S) ab. SASL – Simple Authentication Security Layer Bei SASL handelt es sich um ein Protokoll zur Authentifizierung und Autorisierung von Benutzern und ist im Internet Standard RFC (Request for Comment) 2222 definiert. Prim¨ ar zur Entkoppelung der Applikation von dem verwendeten Authentication System gedacht. SCM – Supply Chain M anagement Die Prozesse und unterst¨ utzenden Technologien, um eine Kette von Lieferanten zu verwalten und optimieren. Ein Autohersteller hat beispielsweise eine Menge Lieferanten, von denen er abh¨ angig ist. Daher muss er sich diesem Aspekt widmen (eventuell auch mit Einbindung von Lieferanten der Lieferanten). Servlet Container Ein Servlet Container implementiert primär den Java Servlet Standard (inklusive der Unterst¨ utzung von JSPs). Dadurch erm¨ oglicht er, Webanwendungen auf Basis Java auszuf¨ uhren. Die Referenzimplementierung ist dabei der Apache Tomcat. Ein Servlet Container ist weiters Teil eines Java Application Servers. (Wurde fr¨ uher Servlet Engine genannt.) SF A – Sales F orce Automation Hier geht es um eine möglichst weitgehende Automatisierung der Verkaufsaktivitäten, um das Verhältnis von Kosten zum Umsatz zu optimieren. Single Sign-On Ein Single Sign-On System merkt“ sich einen Benutzer und ” dessen Berechtigungen auch bei einem Wechsel zwischen verschiedenen Applikationen. Wenn man daran denkt, dass es Personen mit einer zweistelligen Anzahl von Nutzerkennungen gibt, wird die Wichtigkeit so einer Funktion offenkundig. Aber auch bei nur wenigen Systemen ist es wichtig, keine Zeit f¨ ur Anmeldeprozeduren zu verschwenden (von der Bel¨ astigung des Benutzers einmal ganz abgesehen). SM B – Server M essage Block Das wichtigste (Teil-)Protokoll von Windows Netzwerkfreigaben. Wird auch als Common Internet File System (CIFS) betitelt und gestattet einem Windows System eine Freigabe einzubinden (beziehungsweise geht es auch umgekehrt etwa mit einem Linux Rechner). SOAP Ein auf XML und Internettechnologien basierender Standard zum Datenaustausch zwischen verschiedenen Systemen. Stand fr¨ uher f¨ ur Simple Object Access Protocol (was insbesondere auch wegen der Referenz auf Objekte nicht mehr gew¨ unscht ist). SQL – Structured Query Language Abfragesprache f¨ ur relationale Datenbanken. Es gibt verschiedene Versionen des Standards (abgesegnet von

9.3 Ausblick

273

den Organisationen ISO und ANSI) und zusätzlich in praktisch jeder Datenbank eigene Befehle. Trotzdem der Standard f¨ ur die Abfrage von relationalen Datenbanken. T axonomie Eine reine Begriffshierarchie (also ohne Bedeutung der Begriffe oder Regeln dazu). Dokumentiert u ¨ ber- und untergeordnete Begriffe wie etwa den Zusammenhang, dass ein Auto ein Fortbewegungsmittel ist. T opic M ap Von der Idee her eine Analogie zum Index eines Buches. Definiert Begriffe sowie Eigenschaften und Zusammenhänge. Von daher gibt ¨ es Uberschneidungen zu Taxonomien und Ontologien (eine Ontologie l¨ asst sich als Topic Map darstellen). U N IX Hardlinks Ein und dieselbe physische Datei kann in mehreren Verzeichnissen unter demselben Namen angesprochen und verwendet werden. vCalendar Ein beliebtes Format zum Austausch von Kalenderdaten ähnlich zu iCalendar. Wird etwa von Microsoft Outlook unterst¨ utzt. Historisch betrachtet ist vCalendar oder vCal das ältere Format. Die Unterschiede zu iCalendar sind dabei gering und zum Teil implementationsabh¨ angig (wobei im iCalendar Format meist mehr Daten enthalten sind). vCard Ein Dateistandard f¨ ur den Austausch von persönlichen Daten. Wird h¨ aufig im Internet verwendet (etwa als Anhang zu einer E-Mail) kann aber auch bei Handies, etc. eingesetzt werden. V oIP – V oice over IP Hier handelt es sich um die Möglichkeit, u ¨ber das Internet (von daher kommt IP – das Internet Protocol) zu telefonieren. Fr¨ uher wurde meist das H.323 Protokoll verwendet. Aktuell kommt eher das simplere Session Initiation Protocol (SIP) zum Einsatz. Weiters gibt es auch propriet¨ are Produkte wie etwa Skype. W AP – W ireless Access P rotocol Ein HTTP ähnliches Protokoll, das eingef¨ uhrt wurde, um speziell aufbereitete Internetseiten (im WML Format) transportieren zu k¨ onnen. Heute in fast jedem Handy enthalten. W ebDAV Distributed Authoring and Versioning Protocol for the World Wide Web: Ein Internet Protokoll, das den einfachen Austausch von Dateien ahnlich wie mit einem Netzwerklaufwerk ermöglicht und zusätzlich ¨ Versionierung oder etwa einen Locking Mechanismus anbietet. Der Pfad zu einem Dokument ist dabei eine URL. W issen siehe Knowledge W issensmanagement siehe Knowledge Management ur Internetseiten, die daf¨ ur W M L – W ireless M arkup Language Ein Format f¨ gedacht sind per WAP an Handies ausgeliefert zu werden. Im Prinzip ein abgespecktes HTML f¨ ur Handies. Bei WML2 handelt es sich um die zweite Version dieses Standards. W SRP – W eb Services f or Remote P ortlets Ein Standard zum Einbinden von Portlets, die remote (entfernt) laufen. Ausgearbeitet von den OASIS Technical Committees Web Services for Interactive Applicati”

274


ons (WSIA)“ and Web Services for Remote Portals (WSRP)“. Sie” he http://www.oasis-open.org/committees/tc home.php?wg abbrev= wsrp f¨ ur Details. W Y SIW Y G – W hat Y ou See Is W hat Y ou Get Umschreibung daf¨ ur, dass man auf dem Bildschirm dasselbe sieht was etwa auf einem Drucker herauskommen w¨ urde. Im Kontext dieses Buches geht es meist um die Voransicht einer HTML Seite. XM L – eXtensible M arkup Language Ein Standard der maschinen- und menschenlesbare Dokumente in einer Baumstruktur definiert. Historisch betrachtet handelt es sich um eine Vereinfachung von SGML (Structured Generic Markup Langauge). Siehe etwa http://www.w3. org/xml f¨ ur mehr Details. XM LRP C – XM L Remote P rocedure Call Wie der Name schon sagt eine Definition f¨ ur den Aufruf von nicht lokalen (etwa auf anderen Rechnern) Prozeduren oder Methoden mit dem Transportmedium XML. Ist ein Standard ¨ ahnlich zu SOAP.

Literaturverzeichnis

1. Alavi M und Leidner D (2001) Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS Quarterly Vol. 25:107–136 auf Englisch 2. Allen C (2004) Life With Alacrity: Tracing the Evolution of Social Software. http://www.lifewithalacrity.com/2004/10/tracing the evo.html, besucht am 27. Februar 2006, auf Englisch 3. Beck H und Pinto H (2002) Overview of Approach, Methodologies, Standards, and Tools for Ontologies. FAO 2002 (von http://www.fao.org/agris/aos/ Documents/BackgroundPaper.pdf, besucht am 27. Februar 2006) auf Englisch 4. Berners-Lee T, Hendler J und Lassila O (2001) The Semantic Web. Scientific American Mai 2001 (verf¨ ugbar unter: http://www.scientificamerican.com/ article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21&catID=2, besucht am 27. Februar 2006) auf Englisch 5. Bodendorf F (2003) Daten- und Wissensmanagement. Springer, BerlinHeidelberg 6. Brown E, Srinivasan S, Coden A, Ponceleon D, Cooper J, Amir A und Pieper J (2001) Towards speech as a knowledge resource. Proceedings of the 10th International Conference on Information and Knowledge Management Seiten 526–528, ACM Press Atlanta, auf Englisch 7. Br¨ ugge B, Harhoff D und Picot A (2004) Open-Source-Software. Springer, Berlin 8. Carlstedt A und Nordborg M (2002) An Evaluation of Topic Maps. Diplomarbeit, G¨ oteborg University (verf¨ ugbar unter: https://206.191.28.118/docushare/ dsweb/Get/Document-1186/1evaluation+of+topicmap.pdf, besucht am 27. Februar 2006), auf Englisch 9. Costello R und Jacobs D (2003) A Quick Introduction to OWL Web Ontology Language. The MITRE Corporation, (von http://www.iro.umontreal.ca/ ∼lapalme/ift6281/OWL/CostelloQuickIntroOwl.pdf, besucht am 27. Februar 2006) auf Englisch 10. Davenport T (1999) Wenn Ihr Unternehmen w¨ ußte, was es alles weiß . . . : das Praxishandbuch zum Wissensmanagement. 2. Auflage, Moderne Industrie, Landsberg 11. Deutz R (2005) Mambo. Springer, Berlin

276


12. Fensel D (2001) Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce. Springer, Berlin Heidelberg 13. Fl¨ ugge M und Schmidt K (2005) Web Services mit der OWL - Verst¨ andnisvolle Dienste. In: iX 5/2005:136–143, Heise Verlag, Hannover 14. Gadatsch A: Integriertes Knowledge Management. Vieweg, 2002. 15. G¨ otz K und Schmid M (2004) Praxis des Wissensmanagements. Vahlen, M¨ unchen 16. Gruber T (2003) What Is an Ontology? (von http://www-ksl.stanford.edu/kst/ what-is-an-ontology.html, besucht am 27. Februar 2006) auf Englisch 17. Haun M (2000) Handbuch Wissensmanagement: Grundlagen und Umsetzung, Systeme und Praxisbeispiele. Springer, Berlin 18. Heck A (2002) Die Praxis des Knowledge Managements. Vieweg 19. Hoffmann M, Loser K, Walter T und Herrmann T (1999) A Design Process for Embedding Knowledge Management in Everyday Work. Proceedings of the international ACM SIGGROUP conference on Supporting group work Seiten 296–305, ACM Press, Phoenix, auf Englisch 20. H¨ uttenegger G (2003) Knowledge Management & Information Technology – Goals/Problems, Practical Approaches, and Proposed Solution. Doktorarbeit, TU Wien, auf Englisch 21. Institut f¨ ur Rechtsfragen der Freien und Open Source Software (2005) Die GPL kommentiert und erkl¨ art. O’Reilly 22. International Organization for Standardization (ISO) (2002) ISO/IEC 13250:2002 Topic Maps (2nd Edition). http://www.y12.doe.gov/sgml/sc34/ document/0322 files/iso13250-2nd-ed-v2.pdf, besucht am 27. Februar 2006, auf Englisch 23. J¨ anig C (2003) Wissensmanagement – Die Antwort auf die Herausforderung der Globalisierung. Springer, Berlin 24. Jasek D (1999) Distance Learning Defined. Texas Transportation Institute, auf Englisch 25. Kluge J u.a. (2002) Wissen entscheidet. Wie erfolgreiche Unternehmen ihr Know-how managen - eine internationale Studie von McKinsey. Ueberreuter 26. KMCI Diskussionsgruppe zu finden unter: http://groups.yahoo.com/group/ kmci-Virtual-Chapter/ auf Englisch. 27. KPMG Consulting (1998) Knowledge Management: Research Report 1998. (von http://www.brint.com/papers/submit/knowmgmt.pdf, besucht am 27. Februar 2006), auf Englisch 28. KPMG Consulting (1999) Knowledge Management: Research Report 2000. (von http://www.insite.cz/data/kpmg km report2000.pdf, besucht am 27. Februar 2006), auf Englisch 29. Kuppinger M (2000) Vom Intranet zum Knowledge Management – die Ver¨ anderung der Informationskultur in Organisationen. Hanser, M¨ unchen Wien 30. Laurent A (2004) Understanding Open Source & Free Software Licensing. O’Reilly, auf Englisch 31. L¨ uthy W u.a. (2002) Wissensmanagement-Praxis. Einf¨ uhrung, Handlungsfelder und Fallbeispiele. Mensch - Technik - Organisation Bd. 31. vdf Hochschulverlag AG an der ETH Z¨ urich 32. Lucko S und Trauner B (2005) Wissensmanagement. Hanser Fachbuch 33. Maass W und Stahl F (2003) Content Management Handbuch. Net Academy 34. Mainzer K (2003) KI - K¨ unstliche Intelligenz. Grundlagen intelligenter Systeme. Primus Verlag


277

35. Malhotra Y (2002) Why Knowledge Management Systems Fail. Enablers and Constraints of Knowledge Management in Human Enterprises. In: Handbook on Knowledge Management 1: Knowledge Matters Seiten 577–599, Springer, Heidelberg (verf¨ ugbar unter: http://www.brint.org/WhyKMSFail.htm, besucht am 27. Februar 2006), auf Englisch 36. Mandl H (Hrsg.) und Reinmann G (2004) Psychologie des Wissensmanagements. Hogrefe 37. Marwick A (2001) Knowledge Management Technology. IBM Systems Journal Vol. 40 No. 4:814–830 (verf¨ ugbar unter: http://www.research.ibm.com/journal/ sj/404/marwick.pdf, besucht am 27. Februar 2006), auf Englisch 38. McDermott R (1999) Why Information Technology Inspired But Cannot Deliver Knowledge Management. California Management Review, Vol. 41 No. 4:103–117, auf Englisch 39. McKay A (2005) Plone. Addison-Wesley, M¨ unchen 40. Mitchell T (1997) Machine Learning. McGraw-Hill, New York, auf Englisch 41. Nantz B (2005) Open Source .NET Development – Programming with NAnt, NUnit, NDoc, and More. Addison-Wesley, Boston, auf Englisch 42. Neumann R (Hrsg.) (2002) Corporate E-Learning. Strategien, M¨ arkte, Anwendungen. Gabler 43. Osterloh M (1999) Wettbewerbsf¨ ahiger durch Prozess- und Wissensmanagement – mit Chancengleichzeit auf Erfolgskurs. Gabler, Wiesbaden 44. Pepper S (2000) The TAO of Topic Maps. Proceedings of XML Europe 2000, GCA (verf¨ ugbar unter: http://www.ontopia.net/topicmaps/materials/ tao.html, besucht am 27. Februar 2006), auf Englisch 45. Pepper S und Grønmo G (2001) Towards a General Theory of Scope. http: //www.ontopia.net/topicmaps/materials/scope.htm, besucht am 27. Februar 2006, auf Englisch. 46. Petrak J (1997) Data Mining Methoden und Anwendungen. Technischer Bericht osterreichisches Forschungsinstitut f¨ ur K¨ unstliche Intelligenz, Wien ¨ 47. Pfeffer J (2001) Wie aus Wissen Taten werden. So schließen die besten Unternehmen die Umsetzungsl¨ ucke. Campus 48. Probst G (1999) Wissen managen – wie Unternehmen ihre wertvollste Ressource optimal nutzen. 3. Auflage, Zeitung f¨ ur Deutschland, Frankfurter Allgemeine Zeitung, Frankfurt am Main 49. Rath H (2003) The Topic Maps Handbook. Version 1.1 February 6, 2003; http: //www.empolis.com/downloads/empolis TopicMaps Whitepaper20030206. pdf, besucht am 27. Februar 2006, auf Englisch 50. Riempp G (2004) Integrierte Wissensmanagement-Systeme – Architektur und praktische Anwendung. Springer, Berlin 51. Ruggles R. (Hrsg.) (1997) Knowledge Management Tools. ButterworthHeinemann, Boston, auf Englisch 52. Sauerburger H (Hrsg.) (2004) Open-Source Software. dpunkt 53. Schmidt M (2000) Knowledge communities – mit virtuellen Wissensm¨ arkten das Wissen in Unternehmen effektiv nutzen. Addison-Wesley, M¨ unchen (u.a.) 54. Schneider U (2001) Die 7 Tods¨ unden im Wissensmanagement. Kardinaltugenden f¨ ur die Wissens¨ okonomie. Frankfurter Allgemeine Zeitung 55. Smith B (ca. 2002) Ontology and Information Systems. (von http://ontology. buffalo.edu/ontology(PIC).pdf, besucht am 27. Februar 2006) auf Englisch

278


56. Smolnik S und Nastansky L (2001) K-Discovery: Identification of Distributed Knowledge Structures in a Process-Oriented Groupware Environment. Proceedings of Knowledge Technologies Conference 2001 (verf¨ ugbar unter: http://www2.gca.org/knowledgetechnologies/2001/proceedings/Smolnik% 20Paper.pdf, besucht am 27. Februar 2006), auf Englisch 57. Spindler G (2004) Rechtsfragen bei Open Source. Schmidt, K¨ oln 58. Studer R, Oppermann H und Schnurr H (2001) Die Bedeutung Von Ontologien F¨ ur Das Wissensmanagement. Universit¨ at Karlsruhe (elektronisch verf¨ ugbar unter: http://www.ontoprise.de/documents/Bedeutung von Ontologien fuer WM.pdf, besucht am 27. Februar 2006) 59. Trauth E (1999) Who Owns my Soul? The Paradox of Pursuing Organizational Knowledge in a Work Culture of Individualism. Proceedings of the 1999 ACM SIGCPR conference on Computer personnel research Seiten 159–163, New Orleans,, ACM Press, auf Englisch 60. Widhalm R (2001) Topic Maps. Semantische Suche im Internet. Springer 61. Willke H (1998) Systemisches Wissensmanagement. Lucius & Lucius, Stuttgart 62. Willke H (2004) Einf¨ uhrung in das systemische Wissensmanagement. CarlAuer-Systeme 63. Witten I und Frank E (1999) Data Mining: Practical Machine Learning Tools and Techniquens with Java Implementations. Morgan Kaufmann, San Francisco, CA, auf Englisch

Sachverzeichnis

Absenzendatenbank, 81 ACT, 70 ADOdb, 54, 97 Affinit¨ aten, 240, 243 AI – Artificial Intelligence, siehe KI – K¨ unstliche Intelligenz Alavi und Leidner, 2 Amazon, 66, 237 Apache, 34 APL – Apache License, 63 Appalachian State University, 47 Apple iCal, 70 Avantgo, 47, 63 Axis, 64, 73 Backup, 87, 147, 163, 252 BAPI, 69 BaseCMP, 52 Basistechnologie Portal?, 99–101 Contra Portal 100 Pro Portal 100 Basistechnologien – Entscheidung, 88 Application Server 98 Connectivity – Middleware 94 Internes Know-how 88 Know-how Felder 90 Know-how und Evaluierungsgrundlage 88 Partner 89 Programmiersprachen 91 BEA Tuxedo 69, 96 WebLogic 69, 98

Beck und Pinto, 185 Berners-Lee, Sir Tim, 29, 65, 194 BI – Business Intelligence, 62, 82 Bildanalyse, 262 Blended Learning, 219, 220 blueCubs, 56 Boost, 95 Br¨ ugge, Bernd, 5 BSI – Bundesamt f¨ ur Sicherheit in der Informationstechnik, 33 Bucher, Matt, 42 C, 31, 33, 93, 119, 250 C++, 71, 93, 95, 119, 250 C#, 72, 198, 216 CalDAV, 37 calldll, 95 Carlstedt und Nordborg, 188 Cluster, 87 CMS – Content Management System, 27, 35, 36, 37–53, 53, 58, 68, 80, 85, 105, 106, 123–154, 156–163, 169– 171, 174–179, 181, 199, 204–206, 209, 217, 221–225, 227, 241, 245, 248–254, 256 Cocoon, 63, 191 Cold Standby, 87 ComFire, 30 Communities of Practice (CoP), 226 Compiere, 7, 8, 62, 67, 70, 201, 202, 249 Compiere Inc., 68 Contenido, 43, 137, 141

280

Sachverzeichnis

CORBA – Common Object Request Broker Architecture, 69, 95, 96, 97, 250 Costello und Jacobs, 194 CRM – Customer Relationship Management, 7, 18, 28, 62, 67–70, 78, 82, 124, 125, 201–203, 206, 249, 254 CSCW – Computer Supported Cooperative Work, 30 CTI – Computer Telephony Integration, 109 Cwm (SWAP), 197 cxx, 95 Cyc, 183–185 Cyrus IMAP 32–34 DAML+OIL, 65, 194, 195, 195, 199 Data Warehouse, 19 DBMS – Database Management System, 19 Derby, 57, 63, 67 Digital Library, 28, 62, 71, 201–204, 249, 254 Directory Service, 20 DM – Data Mining, 20, 164, 233, 238, 247 DMS – Document Management System, 19, 27, 53–59, 64, 80, 85, 108, 126, 149, 162–179, 181, 199, 203, 209, 213, 217, 221, 223–225, 227, 245, 248, 249, 253, 254, 256 docman, 53, 171–172, 225 Drucker, P. E., 2 DSS – Decision Support Systems, 7 Dublin Core, 40 Durchlaufzeit, 18 EAI – Enterprise Application Integration, 262 Eclipse, 58, 174, 198 EDI – Electronic Data Interchange, 67 EDR, 183–185 eGroupware, 31 Einf¨ uhrung KM System Geplanter Umfang KM System 118 Groupware 105 Ziele (KM Initiative/System) 126 Ziele, mittelfristig 142

EIP – Enterprise Information Portal, 63 EJB – Enterprise Java Bean, 63, 69, 73, 97 eLearning, 12, 182, 218–227, 246, 254, 261 Administration 13 Anbieten des Materials 221 Definition 219–220 Erstellen des Lernmaterials 221 Kommunikationsangebot 222 Kommunikationsm¨ oglichkeiten 221 Verwaltungs/Administrationsm¨ oglichkeiten 221 elevateIT, 41, 48, 136, 141, 217, 224, 248 Empolis, 187 ERP – Enterprise Resource Planning, 7, 18, 28, 57, 62, 67, 78, 82, 124, 125, 201–203, 247, 249, 254 ES – Expert System, 7 Euler, 198 EuroWordNet, 184 Evolution, 31, 32 eXo Platform, 63 Expertendatenbank, 21, 247 Fensel, 185 Firebird, 69 Fl¨ ugge, Matthias, 197 Framework, 83, 249 Frauenhofer IAO Institut, 72 Free Software, 4 Freshmeat, 4 Fresse, Eric, 192 FrontBase, 32 FSF – Free Software Foundation, 4 Gehirnforschung, 262, 263 GLUE, 73, 216 Google, 95, 165, 167, 253, 262 GPL – General Public License, 4 Greenstone, 29, 62, 71, 202–203, 249, 254 Grey, Denham, 2 GroupDAV, 37 Groupware, 7, 27, 53, 58, 68, 74, 75, 78, 84, 105–125, 127, 129, 132, 133, 135–137, 140–142, 144, 145, 149–152, 154, 156–163, 169–171,

Sachverzeichnis 174–179, 181, 188, 199, 201, 204– 206, 211, 213, 217, 221–227, 245, 246, 248–254, 256 Groupware Systeme, 30–37, 78, 121–123, 125, 126 Gruber, 185 Grundwald, Lukas, 74 Harhoff, Dietmar, 5 Hibernate, 43, 73 Historie, 17, 21, 23, 36, 55, 56, 69, 229, 248, 255 Hot Standby, 87 HP – Hewlett Packard, 197 HyperSonic, 63 HyTime, 185 IAO License, 72 IBM, 262 DB2 57, 63, 64, 69, 75 WebSphere 63, 69, 98 MQSeries, 69, 96 iCalendar, 75 IMAP – Internet Message Access Protocol, 34, 123 Informatik, 261 Informationsmanagement, 3, 7, 20 Informix, 34 Innovation, 15 Innovationspotenzial, 11 Institut f¨ ur Rechtsfragen der Freien und Open Source Software, 6 InterBase, 40, 69, 75 ISO, 64, 185 J2EE – Java 2 Enterprise Edition, 63, 67, 69, 98, 250 J2ME, 64 J2SE, 64 Jackrabbit, 57, 58 Java, 32, 33, 37, 41, 42, 52, 56, 58, 63, 64, 71–73, 75, 91, 94, 95, 100, 119, 121, 123, 135–137, 141, 144, 156, 166, 173, 174, 176, 177, 191–193, 197, 198, 202, 216–218, 248–251 Java DataBase Connectivity – JDBC 73, 97 Java Server Faces – JSF 43, 63, 64

281

JCA – J2EE Connector Architecture 67, 69 JMS – Java Message Service 63, 97 Swing 73, 191, 217 JBOSS, 5, 42, 63, 64, 67, 69, 98 Group 42, 43 Portal 42, 48, 52, 63, 123, 137, 141, 177, 224, 248, 250 JDBC, siehe Java DataBase Connectivity Jena, 197, 198 Jetspeed, 63, 64, 123, 249, 250 Jetty, 64 jLibrary, 57, 59, 174, 177, 248 JOnAS, 64, 98 Joomla, 44, 44, 45, 138, 141, 224 JSR 168 – Portlet Standard, 43, 63, 64, 75, 99, 249 JSR 170 – Content Repository Standard v1, 43, 57, 59, 174, 177 JSR 283 – Content Repository Standard v2, 177 Jython, 72, 216 K-Fall – Katastrophenfall, 87 KDD – Knowledge Discovery in Databases, 20, 164, 232, 247 KDE Kontact, 34 KI – K¨ unstliche Intelligenz, 8, 20, 29, 62, 66, 101, 164, 226–228, 231–243, 245, 247, 255, 256, 262, 263 KM – Knowledge Management, 3 Barrieren 16, 247 eLearning, Zusammenhang 12–13 Kreativit¨ at 15, 247 Motivation 14, 247 extrinsisch, 14, 247 intrinsisch, 14, 247 Organisatorische Aspekte 247 Vision 13 Voraussetzungen und Grundlagen 13, 259 Wahrhaftigkeit 14, 247 Zeit, Geld, Strukturen und Traditionen 16 Ziele 11–13 Ziele setzen und u ufen 15 ¨ berpr¨ KM System ¨ Uberblick 24

282

Sachverzeichnis

Automation 21, 247 Berechtigungsfilter 101 Berechtigungssystem 19, 164, 247 DM – Data Mining 20, 164, 247 Einbettung in normalen Arbeitsablauf 23, 248 Erfassen 17, 247 Integrieren & Verbinden 18, 247 KDD – Knowledge Discovery in Databases 20, 164, 247 KI – K¨ unstliche Intelligenz 20, 164, 247 Kontext, Links & Historie 21, 164, 247 Leute verbinden 20, 247 ML – Maschinelles Lernen 20, 164, 247 Nachvollziehbarkeit 23, 164, 248 Nichtfunktionale Anforderungen 24, 248 Einfache Bedienung, 24, 248 Geschwindigkeit, 24, 248 Speicherung 19, 164, 247 Suche, Finden & Zugreifen 22, 247 Technische Basis 101 Transformieren 18, 247 Transparenz 23, 164, 248 Vision 11, 17, 103, 246, 255 Knowledge, 2, 12 Wiederverwendung 15 Knowledge Map, siehe Wissenslandkarte KnowledgeTree, 54, 58, 172, 176, 225, 248 Kolab, 33, 121, 223 Kolab Server 31 Kommunikation, 15, 20 Kontext, 2, 17, 21, 23, 229–231, 235, 236, 247, 248, 255 KPMG, 11 Kreativit¨ at, 15 Kroupware, 31, 33, 121, 223 Laurent, 6 LDAP – Lightweight Directory Access Protocol, 32, 35, 37, 40, 44, 46, 75 Lernen, 12 LGPL – Lesser General Public License, 4

Liferay, 63, 64, 123, 248, 250 Liferay LLC, 64 Lotus Notes, 30, 69, 78, 109, 115 LTM – Linear Topic Map, 191 Lucene, 42, 166 MacOS X, 31 Mambo, 44, 70, 138, 141, 224 Mambo Foundation, 44 Matrixbrowser, 72, 206–207, 249 MaxDB, 64, 69 MDA – Modell Driven Architecture, 68 Mehrdeutigkeit, 21 Microsoft .NET 32, 69, 72, 93, 99, 100, 202, 250 Access 75, 204 Active Directory 32, 35, 40, 54 CRM 70 DCOM 96 Exchange 30, 69, 78, 115 IIS (Internet Information Server) Web Server 69 NetMeeting 20 Office 71, 166 Outlook 30, 32–34, 69, 70, 78, 94, 115 SQL Server 34, 35, 40, 64, 69, 75, 204 Miller, George, 184 Miro, 44 MIS – Management Information Systems, 7 Mitchell, Tom M., 66 ML – Maschinelles Lernen, 20, 164, 247 Mono, 93 Mozilla, 66 MPL – Mozilla Public License, 68 MyFaces, 43 MySQL, 34, 35, 40, 54, 55, 57, 63, 64, 69, 71, 73–75, 204 N-Triples, 197, 198 N3 – Notation 3, 194, 197, 198 Nantz, Brian, 94 Nexist, 64, 192 NeXTStep, 31 NIS – Network Information Services, 75 NO-SOD eDMS, 54, 172 Novell, 121 Groupwise 78

Sachverzeichnis NukesOnJBOSS, siehe JBOSS Portal OAGIS, 67 Obj-C, 31, 32, 93, 119, 123, 250 OCR – Optical Character Recognition, 233, 239 OFX – Open Financial eXchange, 67 OIL – Ontology Reference Layer, 195 OLAP – Online Analytical Processing, 67 Ontologie, 8, 29, 61, 62, 64, 65, 182, 182–185, 185, 187, 188, 190, 192–199, 226, 234–236, 242, 249, 254, 261, 263 formal 183 linguistisch 183 Ontopia, 187, 191, 192 Open Source, 4–6 H¨ aufige Fragen 5 Rechtliche Aspekte 6 Support 5 Weiterentwicklung, fehlende 6 Open Source Software, 27 Basistechnologien 29 CMS – Content Management System 37–53 DMS – Document Management System 53–59 Groupware Systeme 30–37 Kategorien 28 Kategorien & Technologien 27 Open-Xchange, 30, 32, 36, 121 OpenCMS, 41, 43, 52, 136–137, 141, 224, 248 openCRX, 8, 62, 68, 201, 202, 249 OpenCyc, 184 OpenDocMan, 55, 172–173 OpenGroupware, 30, 31, 33, 123, 174–175, 177 OpenLDAP, 31, 34 OpenOffice, 36, 166 OpenWFE, 72, 73, 216, 249 Oracle, 34, 40, 55, 57, 63, 64, 67, 69, 73–75 OSCore, 73, 216 OSI – Open Source Initiative, 4, 246 OSUser, 216 OSWorkflow, 73, 73, 216–217, 249

283

OTRS – Open Ticket Request System, 74, 74, 75, 206, 249 OWL (DMS System), 55, 58, 173, 176, 225, 248 OWL – Web Ontology Language, 65, 194, 194, 195–199, 254 OWL DL 195 OWL Full 195 OWL Lite 195 OWL-S Service Ontologie 196 OWL API, 197 P2P – Peer 2 Peer, 222 Palm PDA, 32, 33, 75 Paper Harbour, 56, 58, 173, 176, 225, 248 Participatory Design, 23 PeopleSoft, 69 Pepper, 186, 187 Perl, 32, 33, 63, 71, 72, 74, 92, 206, 250 Petrak, Johann, 66 PGP – Pretty Good Privacy, 74 Philosophie, 261, 263 PHP, 32–37, 43–48, 52–56, 58, 63, 67, 70, 74, 75, 92, 94, 97–100, 119, 121, 123, 135, 137–141, 144, 156, 171–173, 176, 198, 202, 204–206, 217, 223, 248–251 ADOdb 54, 97 PEAR 53, 97 PHP-Nuke, 40, 42, 45, 46, 48, 138, 141, 142 phpBB, 74, 204–205, 249 PhpGroupWare, 31, 35, 121, 141, 223 JiNN 36 SiteMgr 36 PHProjekt, 31, 34, 121 phpWebSite, 47, 140–141, 224 phpWiki, 74, 75, 205, 249 Picot, Arnold, 5 Planungsdatenbank, 81 Plone, 31, 40, 41, 48, 136, 141, 217, 224, 225, 248 Foundation 41 POP3 – Post Office Protocol 3, 34, 35, 74 POPFile, 66, 74, 74, 207–208, 249

284

Sachverzeichnis

Portal, 29, 35, 60, 63–64, 82, 83, 85, 98, 99–101, 125, 135, 137, 156, 175, 248–250, 262 Portlet, 29, 43, 63, 64, 96, 99 Postfix, 32, 34 PostgreSQL, 32–35, 40, 55, 57, 63, 64, 69, 73–75, 204 PostNuke, 40, 45 pOWL, 198 Produktdatenbank, 81 ProFTPd, 34 Protégé-2000, 192 Python, 31, 32, 37, 40, 48, 72, 92, 94, 95, 97, 98, 119, 135, 136, 141, 144, 156, 192, 198, 216–218, 248, 250, 251 Quartz, 73, 216 RAP – RDF API for PHP, 198 Rath, 187 RDF – Resource Description Framework, 45, 65, 191, 194, 194, 195–199, 254 RDFS – RDF Schema, 194 RDQL – RDF Query Language, 195, 197, 199 REST – Representational State Transfer, 72, 216 RMI, 64, 96, 96, 250 RSS, 40, 42–45, 47, 63, 75 Ruby, 72 S/MIME – Secure/Multipurpose Internet Mail Extensions, 74 SAGrader, 226 Salesforce.com, 70 Samba, 31 SAP, 69, 82, 85, 202 SASL – Simple Authentication Security Layer, 34 Sauerburger, Hein, 5 Schmidt, Kay-Uwe, 197 SCM – Supply Chain Management, 28, 62, 67, 82, 201, 249 SemanText, 191–192, 193 Semantic Web, 8, 29, 61, 65, 182, 183, 191, 193–199, 234, 241, 245, 249, 254, 261 Standards 194

Servlet Container, 63 SFA – Sales Force Automation, 28, 62, 68 SGML, 185 Shannon, 2 Shareholder Value, 11 Siebel, 69 Single Sign-On, 20, 35, 63, 69, 247 Skills Database, siehe Expertendatenbank Skyrix, 30 Smalltalk, 31 Smith, 185 Smolnik and Nastansky, 188 SOAP, 56, 57, 64, 73, 95, 174, 216 Social Software, 30 Sourceforge, 4 Soziologie, 263 SPARQL – SPARQL Protocol And RDF Query Language, 195, 197–199 Speech Mining, 20, 233, 238–239, 261, 262 Spindler, 6 Spracherkennung, 238 Spring, 43, 63, 64, 73 SQLite, 34 Stallman, Richard, 4 StarOffice, 166 Struts, 43, 63, 64, 191 Studer, 185 Sugar.Sales, 70 SugarCRM, 8, 62, 70, 201, 202, 249 Sun RPC, 96 Supporting Technologies Nordic, 56 SuSE OpenExchange, 30 SWAP – Semantic Web Application Platform, 197 SWeDE – Semantic Web Development Environment, 198 SWIG, 95 Swish-E, 175 Sybase, 67 SYSLAB.COM GmbH, 41 Taxonomie, 8, 29, 61, 62, 66, 182, 182–185, 185–188, 190, 193, 194, 226, 233–236, 241, 242, 248, 254, 261

Sachverzeichnis Technische Basis Datenspeicherung 86–88 unabh¨ angige Zugriffsschicht, 87 technology-delivered learning, 219 technology-enhanced learning, 219 Thunderbird, 66 Tibco Rendezvous, 96 Tiki, 31, 35, 121, 140–141, 217, 223 TM4J – Topic Maps 4 Java, 64, 191, 193 TM4Web, 191 tmproc, 192 TMTab, 192 Tolog, 191 Tomcat, 63, 64 Topic Map, 8, 29, 61, 64, 182, 182–193, 193, 199, 241, 249, 254 Association 186 Association Role 186 Association Type 186 Generelle Fragen 187 Occurrence 186 Occurrence Role 186 Open Source Basis 190 SemanText, 191 TM4J, 191 tmproc, 192 Topic 186 Topic Name 186 Topic Type 186 TU M¨ unchen, 41 Typo3, 46, 52, 139, 141, 224, 248 vCalendar, 75 vCard, 68 Velocity, 63 Vertraulichkeit, 19 Video Analyse, 262 Visualisierungstool, 71, 206–207, 249 VoIP – Voice over IP, 108, 262 Volltextsuche, 164–168, 169, 248, 253 Berechtigungssystem 167 Dateiformate 166 Dokumentformate 165 Indexierung 166 Vorhandene Business Software, 82, 85 Vorhandene CMS Systeme, 80 Vorhandene CMS/DMS Systeme, 80–81 Vorhandene Datenbest¨ ande, 81, 85

285

Vorhandene Datenbest¨ ande/Systeme, 77–86 Vorhandene DMS Systeme, 80 Vorhandene Groupware, 78–80 Vorhandene Individualsoftware, 84, 86 Vorhandene Portale, 83, 85 Vorhandene weitere Software ( Diver” ses“), 83 W3C – World Wide Web Consortium, 194, 197 Waikato, 66 Web Service, 95, 97, 250 WebCalender, 74, 75, 205 WebDAV, 40, 123 WebMacro, 63 WebMethods, 73, 216 WEKA, 66, 237, 249 Wiki, 34–36, 40, 46, 62, 64, 75, 117, 126, 129, 134, 140, 205, 208, 223, 224, 249, 251, 254 WikiWikiWeb, 75 Wirtschaft, 261 Wissen, siehe Knowledge Wissenslandkarte, 21, 233, 235–236, 242 Wissensmanagement, siehe KM – Knowledge Management Witten und Frank, 66 WordNet, 183, 184 Workflow, 35, 40, 41, 43, 44, 46, 54–57, 68, 72–74, 126, 136, 162–164, 173–175, 182, 204, 209–218, 233, 236, 237, 239, 242, 253, 254 Engine 29, 62, 67, 72–73, 216–218, 248, 249, 254 WSRP – Web Services for Remote Portlets, 43, 99, 249 Xaraya, 46, 139, 141, 142, 224 xinco-DMS, 56, 57, 58, 173–174, 177, 248 XMLRPC, 32, 217 XOOPS, 40, 45, 46, 48, 51, 52, 63, 98, 123, 124, 137, 139–141, 175, 177, 224, 225, 248, 250, 253 XRMS, 67 XTM – XML Topic Maps, 185, 191, 192, 194 Zope, 31, 37, 40, 48, 97, 98, 136, 141, 144, 156, 217, 248, 251

Open Source Knowledge Management

Open Source, Software Development

Funambol Mobile Open Source

Open source SOA

Open Source Leadership

Open Source Network Administration

Succeeding with open source

Producing Open Source Software

Open Source Leadership

Open Source Democracy

Open source SOA

Open Source Fuzzing Tools

Funambol Mobile Open Source

J2EE Open Source Toolkit: Building an Enterprise Platform with Open Source Tools (Java Open Source Library)

Open for Business - Open Source Inspired Innovation

Open Source Systems Security Certification

Open Source Development with CVS

Handbook of Open Source Tools

Handbook of Open Source Tools

Open Source: Technology and Policy

MySQL based Open Source CMS

Open Source Development with CVS

Open Source Systems Security Certification

Open source development with CVS

The Success of Open Source

Handbook of Open Source Tools

Open Source Development with CVS

The Success of Open Source

Open Source - kurz und bündig

Open Source Knowledge Management

Open Source, Software Development

Funambol Mobile Open Source

Open source SOA

Open Source Leadership

Open Source Network Administration

Succeeding with open source

Producing Open Source Software

Open Source Leadership

Open Source Democracy

Open source SOA

Open Source Fuzzing Tools

Funambol Mobile Open Source

J2EE Open Source Toolkit: Building an Enterprise Platform with Open Source Tools (Java Open Source Library)

Open for Business - Open Source Inspired Innovation

Open Source Systems Security Certification

Open Source Development with CVS

Handbook of Open Source Tools

Handbook of Open Source Tools

Open Source: Technology and Policy

MySQL based Open Source CMS

Open Source Development with CVS

Open Source Systems Security Certification

Open source development with CVS

The Success of Open Source

Handbook of Open Source Tools

Open Source Development with CVS

The Success of Open Source

Open Source - kurz und bündig

Recommend Documents