-
Die Erfindung betrifft ein System, das automatisch Materialsammlungen für
unternehmensbezogene Stories generiert. Eine Story ist eine Erzählung, die auf Erfahrungen
von Mitarbeitern einer Unternehmung bei der Ausführung von Geschäftsprozessen
beruht.
-
Aus dem Gebiet des Knowledge Management (siehe Don Cohen, Laurence Prusak: In
good company - How Social Capital makes Organizations work. Harvard Business
School Press, Boston Massachusetts, 2001) ist bekannt, daß der größte Anteil des
Wissens in einem Unternehmen nicht explizit dokumentiert ist. Das Wissen existiert
vielmehr in Form von Erfahrungen in den Köpfen der Mitarbeiter. Dieses Wissen geht
dem Unternehmen mit dem Ausscheiden der betreffenden Mitarbeiter verloren.
Außerdem ist die Anwendung von Geschäftsprozessen nicht im ganzen Unternehmen
einheitlich gut: Mitarbeiter in unterschiedlichen Teilen des Unternehmens können von den
Erfahrungen ihrer Kollegen profitieren, wenn deren Wissen für sie verfügbar ist.
Verschiedene Ansätze beschäftigen sich damit, das implizite Erfahrungs-Wissen zu
sammeln, zu verallgemeinern und wieder in die Geschäftsprozesse einfließen zu
lassen. Ein Beispiel ist die sogenannte Experience Factory (s. Basili, V., G. Caldiera, D.
Rombach (1994): The experience factory. In Marciniak (ed.) Encyclopedia of Software
Engineering, vol 1. John Wiley & Sons, S. 469-476). Hier wird eine Organisation
aufgebaut, die die Erfahrungen in einer Datenbank sammelt, aufbereitet und Projekten zur
Verfügung stellt.
-
Für bestimmte Arten von Wissen, wie z. B. Werte, Verhaltensnormen oder
Überzeugungen sind derartige Datenbanken jedoch ungeeignet. Abstrakte Wissensinhalte werden
nicht verinnerlicht, wenn sie direkt formuliert werden, sondern müssen anhand von
Abläufen und realen Beispielen verdeutlicht werden (s. Cohen, 2001). Daher gewinnt in
der Knowledge Management Literatur das Konzept der Story an Bedeutung (s. D.
Snowden: The Paradox of Story, Journal of Straggly and Scenario Planning, Ark
Publications, November 1999).
-
Eine Story beschreibt, wie ein Protagonist auf ein Problem oder eine Gelegenheit
reagiert und zeigt das Ergebnis dieser Reaktion. Mit einer Story verfolgt der Erzähler ein
Ziel, z. B. die genauere Befolgung eines Geschäftsprozesses. Eine Anekdote ist
dagegen eine "natürliche" Story, mit der nicht unbedingt ein Ziel verfolgt wird. Im Gegensatz
zur Umgangssprache ist mit Anekdote nicht unbedingt eine amüsante Begebenheit
gemeint, sondern einfach eine Erzählung über eine Folge von Ereignissen aus dem
Arbeitsleben.
-
Viele Unternehmen setzen inzwischen Stories zur Verbesserung ihrer
Geschäftprozesse ein (s. Snowden, 1999). Eine typische Vorgehensweise für das Erstellen einer
zielgerichteten Story ist die folgende:
- - Durchführung von Interviews zur Aufnahme von Anekdoten aus (abgeschlossenen)
Projekten.
- - Analyse der Anekdoten zur Identifikation des expliziten und impliziten Wissens.
-
Eine solche Analyse ermittelt:
- - Die Art der Wissensrepräsentation, d. h. in welcher Form liegt das in der Anekdote
angewendete Wissen vor (als Dokument oder allgemeiner: Artefakt, Fähigkeit einer
Person, Heuristik, oder natürliches Talent).
- - Die Art der Anwendung des Wissens (bei Urteil, Entscheidung, Problemlösung, etc.).
- - Die Kernaussage der Anekdote.
- - Definition von Zielen, die durch die Verbreitung der Story erreicht werden sollen, z. B.
genauere Befolgung eines Geschäftsprozesses oder Widerlegung eines Gerüchts.
Ableitung konkreter Anforderungen aus den Zielen.
- - Konstruktion der Story aus geeigneten Elementen der Anekdoten, die zur
Erreichung der Zielen bzw. Anforderungen beitragen.
-
Das Resultat der vorstehend beschriebenen Vorgehensweise ist eine Story, die von
einem Mitarbeiter des Unternehmens erkannt und verstanden wird, da sie auf ihren
Erfahrungen (in Form von Anekdoten) basiert. Die Story ist jedoch insgesamt fiktiv, da sie
die Elemente der Anekdoten zu einer neuen Handlung zusammenfügt.
-
Der oben beschriebene Analyseprozess ist allerdings sehr aufwendig. Bei der
systematischen Konstruktion einer Story anhand von gegebenen Zielen und Anforderungen ist
eine große Menge von Anekdoten zu sichten, aus denen die Elemente der Story
ausgewählt werden müssen. Für diese Sichtung existieren jedoch bislang keine Software-
Werkzeuge.
-
Der Erfindung liegt daher die Aufgabe zugrunde, ein System zur automatischen
Generierung einer Textmaterialsammlung anzugeben, insbesondere zur Generierung einer
Textmaterialsammlung für Stories.
-
Diese Aufgabe wird durch ein System zur automatischen Generierung einer
Textmaterialsammlung gelöst, das die im Anspruch 1 angegebenen Merkmale aufweist. Eine
vorteilhafte Ausgestaltung ist in einem weiteren Anspruch angegeben.
-
Die Erfindung bezieht sich demnach auf ein System zur automatischen Generierung
einer Textmaterialsammlung, insbesondere für eine Story, bei dem eine
Datenverarbeitungseinrichtung vorhanden und dafür eingerichtet ist, mehrere Anekdoten jeweils
als XML-DTD zu speichern, wobei jede Anekdote eine Folge von
Ereignisbeschreibenden Textabsätzen und zugeordnete Annotationen umfasst. Durch
Auswertung von Anforderungen wird damit eine Menge von Textabsätzen als zielgerichtete
Textmaterialsammlung erstellt, wobei die Textabsätze jeweils eine Referenz auf den
Namen der Anekdote, Annotationen des Textabsatzes und den Text des Absatzes als
Bestandteile enthalten. Bei der Auswertung werden als Anforderungsarten Anfragen
berücksichtigt, die beschreiben, dass dem gesuchten Textabsatz eine bestimmte
Annotation zugeordnet sein soll, sowie Ausschlusskriterien, die beschreiben, dass eine
bestimmte Annotation nicht zugeordnet sein soll. Das System ist außerdem dafür
eingerichtet, zuerst durch Auswertung der Anfragen eine Gesamtmenge von Textabsätzen zu
ermitteln, und anschließend anhand der Ausschlusskriterien daraus die gesuchte
Menge von Textabsätzen zu selektieren. Es wird vorzugsweise eine Menge von Anekdoten
verwendet, die von unterschiedlichen Mitarbeitern des Unternehmens geliefert wurden.
-
Eine weitere Beschreibung des Systems erfolgt nachstehend anhand eines in
Zeichnungsfiguren dargestellten Ausführungsbeispiels.
-
Es zeigt:
-
Fig. 1 den Ablauf der Generierung einer Materialsammlung,
-
Fig. 2 ein Beispiel einer Anekdote,
-
Fig. 3 eine durch Annotationen ergänzte Anekdote,
-
Fig. 4 eine XML DTD einer Anekdote,
-
Fig. 5 eine Anekdote als XML-Datei, und
-
Fig. 6 eine Bildschirmdarstellung zur interaktiven Eingabe.
-
Das System arbeitet mit einer Standard-Datenverarbeitungseinrichtung, die
erforderliche Mittel zur Datenspeicherung, -verarbeitung und -ausgabe aufweist. Mittels
geeigneter Software ist das System für eine in Fig. 1 schematisiert dargestellte Arbeitsweise
eingerichtet, bei der zweierlei Informationen, die in einer zweiphasigen Vorgehensweise
ausgewertet werden.
-
Zum einen verwendet das System eine Sammlung von Anekdoten. Diese Anekdoten
wurden von einem Knowledge Management Team in Zusammenarbeit mit den Autoren
der Anekdoten mit Anmerkungen (sogenannten Annotationen) versehen, welche z. B.
die Kernaussagen, Werte, Regeln, die Art der Wissensrepräsentation oder die Art der
Wissensanwendung betreffen. In einer Phase 1 extrahiert das System diese
Anmerkungen.
-
Zum anderen gibt der Benutzer dem System Anforderungen an die zu erstellende Story
vor. Beispielsweise kann eine Anforderung darin bestehen, daß die Story die
Notwendigkeit der Weiterbildung von Mitarbeitern betont.
-
In der zweiten Phase (Phase 2) extrahiert das System durch Abgleich zwischen
Anforderungen und in den Anekdoten enthaltenen Anmerkungen geeignete Absätze für eine
Story aus den Anekdoten.
-
In Phase 1 wird die Sammlung der Anekdoten vom System gelesen und verarbeitet.
Jede der Anekdoten besteht aus zwei Ebenen. In der ersten Ebene enthält sie den
Text, der eine Folge von Ereignissen beschreibt. In der zweiten Ebene besteht sie aus
Anmerkungen, die den Text kommentieren. Diese Anmerkungen werden als
Annotationen bezeichnet. Der Text der Anekdote entspricht einer Wiedergabe von Ereignissen
durch einen Mitarbeiter des Unternehmens, wie sie zum Beispiel im Rahmen eines
Interviews aufgezeichnet wird.
-
Fig. 2 zeigt beispielhaft eine Anekdote bezüglich Erfahrung mit Review Meetings.
-
Fig. 3 zeigt einen Teil dieser Anekdote, ergänzt durch Annotationen. Dabei wurde z. B.
wurde das Buch von Tom Gilb als Artefakt, also explizit repräsentiertes Wissen
eingestuft und die Einführung der Review Meetings als Problemlösung klassifiziert.
-
Text und Annotationen werden vom System in XML (siehe Simon St. Laurent and
Robert Biggar. Inside XML DTDs. McGraw-Hill, 1999) repräsentiert. Eine XML DTD (XML
Dokumententyp-Definition) beschreibt, daß Dokumente aus Absätzen (engl.
paragraphs) bestehen, die wiederum Annotationen enthalten. Ein Ausschnitt einer XML
DTD, der Anekdoten definiert, ist in Fig. 4 wiedergegeben. Eine Annotation besteht
demnach aus einem Attributnamen (att) und einem Wert (value). Zum Beispiel besteht
die in Fig. 3 enthaltene Annotation "Problem: Software-Qualität" aus einem
Attributnamen "Problem" und dem zugeordneten Wert "Software-Qualität".
-
Anekdoten werden von dem System in XML-Dateien gespeichert, die zu der soeben
beschriebenen DTD passen. Als Beispiel ist in Fig. 5 die bereits in Fig. 3 gezeigte
Anekdote als XML-Datei dargestellt. Bei der Verarbeitung der Anekdoten liest das System
die XML-Dateien und prüft sie unter Zuhilfenahme der DTD auf Konsistenz. Es sammelt
alle Annotationen und konstruiert für jede Anekdote ein Verzeichnis der als
Annotationen vorkommenden Attribut-Wert-Paare. Schließlich wird ein Verzeichnis für die
Gesamtheit aller Anekdoten angelegt.
-
Auf Basis dieser Verzeichnisstrukturen kann das System nun zu jedem Attribut-Wert-
Paar effizient feststellen, in welchen Dokumenten bzw. sogar in welchen Absätzen es
vorkommt. Zum Beispiel kann das System nun die Menge aller Anekdoten und Absätze
ermitteln, in denen das Problem der Software-Qualität behandelt wird.
-
In der zweiten Phase erstellt das System die Materialsammlung für die Story. Dazu
werden Anforderungen an die zu erstellende Story ausgewertet. Das System
berücksichtigt dabei zwei Arten von Anforderungen:
- - Anfragen (Find): Die Anforderung beschreibt, daß die Story ein bestimmtes Thema
(d. h. eine bestimmte Annotation <x = y>) beinhalten soll. Zum Beispiel kann
gefordert werden, daß das Buch von Tom Gilb in der Story vorkommt. Dann lautet die
Anforderung Find <"artefakt" = "Buch von T. Gilb">
- - Ausschlußkriterien (Avoid): In diesem Fall beschreibt die Anforderung, daß
Anekdoten, die eine bestimmte Annotation <x = y> enthalten, nicht in der Story
vorkommen sollen. Zum Beispiel kann gefordert werden, daß in der Story Schilderungen
von Code-Reviews (eine bestimmte Art von Review Meetings) nicht vorkommen
sollen. Dann lautet die Anforderung Avoid <"problemloesung" = "Code Review">.
-
Bei der Erstellung der Materialsammlung arbeitet das System der Reihe nach die
Anfragen ab. Zu jeder Anfrage der Form Find <x = y> wird die Gesamtmenge M1 aller
Absätze ermittelt, welche die Annotation <x = y> enthalten. Auf die Gesamtmenge M1 der
gefundenen Absätze werden nun die Ausschlußkriterien angewandt. Ein Absatz erfüllt
ein Ausschlußkriterium Avoid <x = y>, wenn die Annotation <x = y> weder in dem
Absatz selbst, noch in einem anderen Absatz der Anekdote vorkommt.
-
Diejenigen Absätze aus der Gesamtmenge M1, die alle Ausschlußkriterien erfüllen,
werden in die Materialsammlung eingetragen. Der Absatz-Eintrag hat drei Bestandteile:
- - eine Referenz auf den Namen der Anekdote,
- - die Annotationen des Absatzes,
- - den Text des Absatzes.
-
Auf diese Weise werden alle Anfragen der Reihe nach abgearbeitet. Es entsteht eine
Materialsammlung, die in der Reihenfolge der Anfragen als Menge M diejenigen
Absätze enthält, die alle Ausschlußkriterien erfüllen. Absätze, die mehrere Anfragen erfüllen,
werden dabei nur einmal in die Sammlung übernommen (und nicht wiederholt).
-
Als Beispiel wird hierzu wieder die Anekdote aus Fig. 3 betrachtet. Dabei werden drei
Anforderungen an die Story angenommen:
Find <"problemloesung" = "Review Meetings">
Find <"archetyp" = "Projektleiter">
Avoid <"problemloesung" = "Code Reviews">.
-
Das System wertet wie beschrieben die Anfragen der Reihe nach aus. Zu
<"problemloesung" = "Review Meetings"> wird der folgende Absatz gefunden:
"Projektleiter Meier führte daher regelmäßige Review Meetings ein. Er hat die Technik
durch Lesen des Buches von Tom Gilb erlernt."
Nun wird das Ausschlußkriterium geprüft: Keiner der Absätze der Anekdote darf die
Annotation <"problemloesung" = "Code Reviews"> enthalten. Dies ist erfüllt. Somit wird
folgender Eintrag in der Materialsammlung generiert:
"Quelle: Erfahrungen mit Review Meetings
Annotationen: <"problemloesung" = "Review Meetings">
<"artefakt" = "Buch von T. Gilb">
Text: Projektleiter Meier führte daher regelmäßige Review Meetings ein.
Er hat die Technik durch Lesen des Buches von Tom Gilb erlernt."
-
Entsprechend wird die zweite Anfrage ausgewertet, wobei der Paragraph
"Herr Meier moderierte die Meetings" gefunden wird. Wenn wir die Anforderung Avoid
<"problem" = "Software-Qualität"> hinzufügen, wird keiner der Absätze mehr in die
Materialsammlung eingefügt. Da der erste Absatz der Anekdote diese Annotation enthält,
wird die gesamte Anekdote nicht mehr berücksichtigt. Ausschlußkriterien beziehen sich
auf Eigenschaften der Anekdote insgesamt, die nicht in jedem einzelnen Absatz als
Annotation vorkommen müssen.
-
Das beschriebene System ist somit ein System zur automatischen Erstellung von
Materialsammlungen für zielgerichtete Stories. Die Automatisierung ist durch Anwendung
des oben beschriebenen Annotationen-Konzeptes ermöglicht. Eine solche
Automatisierung wäre z. B. nicht durch Information Retrieval Techniken (s. Ricardo Baeza-Yates
und Berthier Ribeiro-Neto: Modern Information Retrieval. ACM Press und Addison-
Wesley, 1999) erreichbar, da diese zu ungenau sind. Es wäre damit zwar möglich, den
Begriff "Review Meeting" in einer Anekdote zu finden, aber der Sinnzusammenhang
Review Meeting als Problemlösung wird erst durch die Annotation gegeben.
-
Da die Materialsammlungen von den Anforderungen geprägt werden, unterstützt das
vorgeschlagene System in besonderem Maße die Formulierung präziser
Anforderungen. Insbesondere wird sichergestellt, daß bei den Anforderungen die korrekten
Attributnamen und Attributwerte verwendet werden, d. h. daß in Anforderungen und
Anekdoten das gleiche Vokabular verwendet wird. Dazu tragen die folgenden Eigenschaften
des Systems bei:
Sicherstellung korrekter Attributnamen in den Annotationen: Die DTD für Sammlungen
von Anekdoten enthält ein Konstrukt zur Auflistung von Attributnamen:
<!ELEMENT attDecl EMPTY>
<!ATTLIST attDecl
attname CDATA #REQUIRED>
-
Das System stellt sicher, daß die Anekdoten nur Annotationen enthalten, deren
Attributnamen in dieser Liste vorkommen. Somit werden Schreibfehler sowie inkonsistente
Attributnamen in den unterschiedlichen Anekdoten vermieden, z. B. meldet das System
einen Fehler, wenn das Attribut "artefakt" deklariert ist, aber "artifact" verwendet wird.
-
Interaktive Eingabe: Bei der Formulierung der Anforderungen wird eine interaktive
Eingabemaske verwendet, wie beispielhaft in Fig. 6 gezeigt ist. Diese Eingabemaske zeigt
alle Attributnamen und Attributwerte an, die in den Anekdoten vorkommen, was die
Anforderungsdefinition wesentlich vereinfacht. Außerdem erhält der Benutzer sofortiges
Feedback auf seine Anforderungen, d. h. es wird während der Anfrageformulierung
unmittelbar die Liste der Anekdoten angezeigt, deren Paragraphen auf die derzeitigen
Anforderungen passen.
-
Das beschriebene System ist nicht nur für Stories, sondern auch für andere Textarten
geeignet, die auf Materialsammlungen aus unterschiedlichen Quellen angewiesen sind,
wie z. B. Berichte oder Artikel.