Was wir wissen ..
[ zurück ]
[ über diese Site ]
[ Hyper-Lexikon ]
[ KnowPort ]
( ==> english )
Know-Net (WP02) - Allgemeine Benutzeranforderungen
KnowPort (KNOWLEDGE PORTFOLIO) ist ein Teilprojekt des EU-Esprit-Projektes KnowNet (KNOWLEDGE MANAGEMENT WITH INTRANET TECHNOLOGIES) für die Entwicklung von Informationstechnologien zur Unterstützung und Verbesserung der Lernfähigkeiten und
Lerneffizienz von Individuen, Teams und Organisationen.
KnowPort erforscht die Ebene des INDIVIDUELLEN Wissensmanagement mit dem Ziel ein Werkzeug "KnowPort" (SW-Tool und Methode) zu entwickeln, welches Wissensarbeitenden ermöglicht, persönliches
Wissen zu managen (Wissensportfolio), so dass Lernen und Wissensaustausch (knowledge sharing) unterstützt und verbessert werden.
KnowPort besteht aus 4 Teilprojekten (MailTack, FileTack, TaskTack, WordTack),
die je eigene user requirements - Spezifikationen besitzen. Hier werden deshalb nur generelle Ausführungen gemacht. Unsere tool-unspezifischen Anforderungen sind sehr nahe an den Anforderungen unseres Partners UBS, der wesentliche Unterschied betrifft die Hierarchisierung von Zugriffen, die in einer Bank von essentieller Bedeutung ist, die aber auf individueller Ebene natürlich entfällt.
1. Allgemeine Betrachtungen (General considerations)
Die Identifikation von Wissen
Wir verstehen unser Projekt als individuelles oder persönliches Wissensmanagement. Wir beschäftigen uns damit, wie wir Wissen erwerben, nutzen und aufheben (knowledge sharing). Von der Beschäftigung mit diesen Fragen
versprechen wir uns Einsicht und damit verbunden einen adäquateren Umgang mit Wissen. Unter Wissens-"Management" verstehen wir also in erster Linie die Aufgabe Wissen zu identifizieren, und zwar in doppeltem Sinne: wir wollen einen Begriff von Wissen und unser Wissen entwickeln. Die dabei entwickelten und verwendeten Methoden und Werkzeuge fungieren als
gegenständliche Resultate unseres Projektes.
Da wir unser Projekt als individuelles Wissensmanagement verstehen, könne wir uns fragen,
welche Anforderungen wir selbst an unser Produkt stellen. Wir verzichten dabei auf die Repräsentativität
von Umfragen, gewinnen aber natürlich viel spezifischeres und gründlicheres Wissen, als in Umfragen
je zu erheben ist. Insbesondere steht uns in diesem Verfahren auch das sogenannte versteckte
Wissen (tacit knowledg) zur Verfügung. Ausserdem können wir die Anforderungen laufend - on the
track - nachführen, wenn das durch neue Einsichten angezeigt ist.
Da wir Werkzeuge und Techniken entwickeln, kann das entstehende Wissen als ist Technologie aufgefasst werden. In diesem Sinne betreiben wir die Entwicklung der Wissens-Werkzeuge, um unser Begreifen von Wissen zu entwickeln.
Die Anforderungen an unsere Produkte ergeben sich mithin in unserer Forschung selbst, die user-requirements
beschreiben demnach die Mittel, die wir beim Herstellen dieser Mittel verwenden. Diese Selbstbezüglichkeit ist
eine Folge davon, dass "Wissen" selbst selbstbezüglich ist. Wir entwickeln nicht irgendwelche Werkzeuge, sondern solche, die uns bei unserer Entwicklung im Wissensprozess dienen. Wir implizieren damit zu wissen, was Wissen ist. Die Werkzeuge und deren Verwendung machen dann explizit, was wir unter Wissen verstehen.
Was immer Wissen auch ist, es zeigt sich mindestens zum Teil in Daten, die als externe
Gedächtnisse fungieren. Wir unterscheiden verschiedene datenbezogene Handlungen wie sprechen, telefonieren, schreiben, e-mailen usw. Wir kümmern uns aber vorderhand spezifisch um datenbezogene Handlungen, die sich in elektrisch geschriebenen Texten niederschlagen, die man auf dem Computer (Inter- und Intranet) verarbeiten kann.
2. Wissensrelevante Merkmale unser Tätigkeit
2.1. Der holistische Engineeringprozess
Am Anfang sprechen wir darüber, was wir konstruieren, respektive welche unserer Tätigkeiten wir wie
systematisieren und in Werkzeugen vergegenständlichen wollen. Wir tragen Ideen in Form von Werkzeugen und Texten über Wissen zusammen, die uns nützlich scheinen. Um Uebersicht zu behalten, ordnen wir die Texte, wir verwalten sie.
Wir überlegen uns, wie wir das am besten tun (best practise). Damit verbunden stellen wir eine Wunschliste auf, in welcher steht, was wir gerne hätten und deshalb konstruieren wollen.
Wir dokumentieren, was wir zusammentragen:
- es gibt Bücher und Artikel über Wissen und Wissensmanagement
- Experten, die man befragen kann
- wir haben eigene Texte zu diesen oder andern Themen, in welchen Dinge zum Thema stehen
- wir haben elektrische und konventionelle Korrespondenz zum Thema
- wir erinnern uns an Gespräche, Vorträge usw
- es gibt Werkzeuge, Software
- es gibt psychologische Theorien und Methoden
Alles, was wir unter dem Gesichtspunkt der Entwicklung von Wissen sammeln, lässt sich als "Artefakt" auffassen. Eine Teilmenge der Artefakte, die uns interessieren, sind Texte.
Eine Aufgabe - die wir unbewusst immer schon lösen - ist das Ordnen dieser Artfakte,
das Anordnen, das in Relationen setzen usw. Wir können also beobachten, was wir mit den
Artefakten tun. Die Texte verwalten wir auf einem Server, auf den wir alle zugreifen können.
Wir verknüpfen die Texte über Links und bauen so eine Struktur.
- Natürlich sind die Texte, die wir zusammentragen, nicht drunter und drüber in der Welt
verstreut, sie sind bereits in Ordnungen eingebettet. Deshalb ist stark von den Quellen und von
den Textsorten abhängig, wie wir mit den Texten umgehen.
- Innerhalb dieser Dokumente unterscheiden wir weitere Kategorien, die verschiedene Arten von Wissen enthalten und deshalb unter dem Gesichtspunkt des Wissensmanagement verschieden behandelt werden. E-mails (Briefe) beispielsweise enthalten anderes Wissen als Berichte. E-mails sind normalerweise bruchstückhaft, weil sie einen aktuellen Kommunikationsprozess dokumentieren, während Berichte themenbezogen, systematisch und ganzheitlich aufgebaut sind. Wir haben deshalb vorerst die vier oben erwähnten Teilprojekte unterschieden, in welchen wir uns mit verschiedenen Sichtweisen auf Daten beschäftigen.
Unsere Werkzeuge und Methoden müssen uns dabei unterstützen. Genauere Anforderungen werden in den Teilprojekten erläutert.
2.2. Die Organisation des Wissens
Idealtypisch ist Wissen in der Enzyklopädie. Die Enzyklopädie ist aber zwangsläufig kontextneutral und enthält kein Wissen über aktuelle Fälle. Beispielsweise steht in keiner Enzyklopädie, was der Aktienhändler mir gestern am Telefon empfohlen hat, oder welche Bedingungen an ein bestimmtes Angebot geknüpft waren, das ich vor ungefähr vier Wochen erhalten habe. In der Praxis will man aber sehr häufig auf solches kontextgebundenes, aktuelles Wissen zurückgreifen.
Um dieses Problem zu lösen, werden wir im KnowPort-Projekt einen aktionsorientierten Ansatz verfolgen, welcher sich auf unser Trace-your-Tack-Prinzip stützt: Protokolliere (trace) deinen Wissenskurs im Laufe der Fahrt (knowledge on tack), um im Wissens-Ozean auf dem richtigen Kurs zu segeln! KnowPort wird also beim Protokollieren von wissensrelevanten Ereignissen während der Anwendung von persönlichem Wissen im Kontext einer laufenden Tätigkeit zum Einsatz kommen.
Wir konzentrieren uns also auf die Input-Seite der Dokumentenverwaltung, so dass die Retrival-Anforderungen kleiner werden. Wir wollen den Prozess unterstützen, in welchem Informationen in die Wissens-Basis eingebunden werden. Automatisierbare
Prozesse werden automatisiert. Interaktive Prozesse durch Visualisierungen unterstützt.
3. Toolspezifische Anforderungen
3.1. Allgemeine Anforderungen
3.1.1. Hardware- und Softwareplattform
Unsere Werkzeug sollen auf den gängigen Computern/Betriebssystemen einsetzbar sein, vorab auf PC und Workstation
mit Windows und Netzbrowsern.
3.1.2. Sicherheit, Zuverlässigkeit
Sicherheit, Zuverlässigkeit und sind im Bereich der vorhandenen Hardware/Software definiert. Das persönliche
Wissensmanagement stellt keine zusätzlichen Anforderungen.
3.2. Grundlegende KM.-Anforderungen
3.2.1 Integration mit gängigen Tools
KM umfaßt viele verschiedene Gebiete wie Informationswiedergewinnung, Dokumentmanagement, Vorgangsmanagement, den Kalender/Terminierung, Projektmanagement, und Textabbau. Damit das KM.-Werkzeug als eine homogene Umgebung dienen kann, die verschiedenen Zwecken dient, könnte es notwendig sein, einen Zugang zu anderen Werkzeugen und Dienstleistungen zu haben (z. B. Datenbanken, Tagesordnungen oder andere KM.-Werkzeuge). Eine nahtlose Kollaboration|Mitarbeit mit anderen Werkzeugen und Quellen, die den Austausch von Daten ermöglichen, scheint damit wichtig zu sein.
3.2.2. Wissensorganisation und Umorganisation
Unsere Werkzeuge sollen keine bestimmte Organisationsstrukturen erzwingen. Wissen muss beliebig zerlegt und verlinkt werden können. Es ist extrem wichtig, daß das Werkzeug das Reorganisieren der Daten-/Wissensbasis ermöglicht. Dies umfaßt die Neuerstellung, Neubenennung und das Löschen von Kategorien, das Verschieben und verlinken von Dokumente etc. Solche Aktivitäten sollten jederzeit möglich sein.
3.3. Dokumenthandhabung und Management
3.3.1. Integration von bestehenden Dokumenten
Die Integration von bestehenden Dokumenten ist ein anzustrebendes Ziel. Insbesondere HTML-Dokumente sollten
mit ihrer Verlinkung übernommen werden können. Das Abgleichen von bearbeiteten Dateien sollte im Sinne des Windows-Aktenkoffers unterstützt werden. Die Integration von gedruckten Dokumente (scannen und OCR lesen) sollte unterstützt werden.
3.3.2. Integration von Dokumenttypen und -formate
Es sollten möglichst viele Dokumenttypen und -formate unterstützt werden, insbesondere die Formate
der verbreiteten Text- und Graphik-Softwarepakete (Word, Exel, Adobe, Correl usw)
3.3.3. Metainformation
Die Dokumente sollten als Objekte mit beliebigen Eigenschaften wie Autor, Datum, Version usw.
ausgezeichnet werden können
3.3.4. Sequenzbildung zwischen auf sich beziehenden Dokumenten
Beiträge zu den Diskussionen, die an verschiedenen Orten gelagert werden, sollen in Sequenzen gebracht werden können.
3.3.5. Ontologie-/thesauri und Klassifizierung
Klassifizierungen sollten durch Ontologien und Thesauri unterstützt werden. Da die automatische Ableitung von Inhaltsbeschreibungen noch experimentell ist, ist ein mixed mode mit kurzen, eher allgemeinen, von Hand zugewiesenen Inhaltsbeschreibungen zusätzlich zu automatisch abgeleiteten möglicherweise die beste Lösung.
Die Klassifizierung vom Dokumenten gelingt am besten innerhalb der Domäne eines Thesaurus oder einer Ontologie. Solche konzeptuellen Modelle müssen zuerst aufgebaut und kontinuierlich gewartet werden. Beide Aufgaben erfordern eine Handarbeit, können aber von automatischen Verfahren gestützt werden.
3.3.6. Cluster und Pattern-Erkennung
Mustererkennung ist auf verschiedenen Ebenen einsetzbar. Sie kann benutzt werden um domänenspezifische Thesauri zu vergrößern. So könnten die automatische Ableitung von Inhaltsbeschreibungen verbessert werden.
Raffiniertere Analysewerkzeuge können typische Zugangsmuster von verschiedenen Benutzern erkennen und unterstützen.
3.3.7. Dokument und Link-Unterhalts-Werkzeuge
Werkzeuge sollten dem Wissensmanager helfen, unverbundene Links, veraltete Dokumente (d.h. das nach einem gewissen Datum nicht modifizierte), zyklische Links, etc zu finden.
3.3.8. Retrievability von Dokumenten
Man sollte die Dokumente suchmaschinenspezifisch charakterisieren können, damit sie von der Suchmaschine
auch wirklich gefunden werden, wenn sie der Suchanfrage entsprechen.
3.4. Ergonomic requirements
Die Werkzeuge sollen an verbreitete Softwareoberflächen angeglichen werden, so dass sich der Benützer nicht umgewöhnen muss, wo dies nicht mit massiven Vorteilen verbunden ist.
Die Werkzeuge sollen deutliche feedbacks geben und keine unsinnigen Fragen stellen.