SlideShare une entreprise Scribd logo
1  sur  17
Télécharger pour lire hors ligne
Innovation durch rechnergestütztes Fehlermanage-
    ment: Ergebnisse des BMBF- Projekts FOQUS
                                     Matthias Jarke, Ralf Klamma

Kurzfassung
Ziel des BMBF-Projekts FOQUS war die Entwicklung von Repräsentationskonzepten und Berechnungsverfah-
ren, die die Arbeit mit Varianten im Fehlermanagement (FM) unterstützen. Das Projekt sollte dazu beitragen,
Abweichungen der Unternehmensleistung von der Kundenerwartung als Chance zu Prozeßverbesserung und
Innovation zu begreifen. Es wurden Werkzeuge entwickelt, die Pflege und Nutzung von Fehlerwissen über
räumliche, zeitliche und konzeptuelle Barrieren hinweg ermöglichen. Betrachtet wurde sowohl das herstellerin-
terne FM während des Entwicklungsprozesses als auch das externe FM im Kontext des Service nach Produktaus-
lieferung. Der Beitrag stellt die Untersuchungsergebnisse, die entwickelten Systemlösungen und deren Evaluie-
rung in den Kontext des "Organizational Learning" Ansatzes nach Nonaka. Die entwickelte Gesamtlösung startet
mit einer flexiblen Formalisierung von Call-Center-Lösungen durch das sog. Eskalationsprinzip des FM, unter-
stützt durch kooperative konzeptuelle Modellierung statische und dynamische Schnittstellendefinitionen zwi-
schen den betroffenen Bereichen mit dem Ziel einer Vermeidung der Informationsüberlastung und stellt zur
Umsetzung sowohl formale (KI-basierte) als auch informelle (hypermediabasierte) Werkzeuge bereit, die zum
einen in eine an das Eskalationsprinzip angepaßte Workflow-Unterstützung, andererseits in Navigationsumge-
bungen zur fallbasierten informellen Wissens-Wiederverwendung einmünden. Konzept und Werkzeugunterstüt-
zung wurden in der Aachener Musterfabrik Aditec installiert und bei einem realen Getriebe-Entwicklungsprozeß
mit gutem Erfolg eingesetzt.



1       Einleitung
Das Zusammenwirken von Workflow-Managementsystemen und Lernen in Organisationen ist erst wenig unter-
sucht worden [KlJa97; Warg97]. Sowohl die Organisationstheorie als auch die Informatik haben noch Klärungen
zu erbringen, inwiewe it Informationstechnologie Lernprozesse effektiv und effizient unterstützen kann. Argyris
und Schön [ArSc78] definieren Lernen in Organisationen als die Entdeckung und Behebung von Fehlern. Huber
[Hube91] betont, daß Lernen in einer Organisation dann stattfindet, wenn durch die Verarbeitung von Informati-
on die Spanne der möglichen Handlungsweisen erweitert werden. Eine lernende Organisation beschreibt Dodg-
son [Dodg93] als ein Unternehmen, das zweckmäßig Strukturen und Strategien konstruiert, um das Lernen in
Organisationen zu fördern und zu maximieren.

Fehlermanagement, hier verstanden als die Systematisierung des reaktiven und proaktiven Umgangs mit Fehlern
im unternehmensübergreifenden Qualitätsmanagement komplexer Produkte, kann als prototypisches Beispiel für
die Gestaltung lernender Organisationen gelten. Das Projekt FOQUS hat den Stand der Praxis eines so verstan-
denen Fehlermanagements im Rahmen des BMBF-Förderprogramms "Produktion 2000" empirisch untersucht
und auf Basis der erkannten Defizite neue Lösungskonzepte prototypisch realisiert und erprobt. In dieser Arbeit
werden die Ergebnisse anhand des Modells der Lernenden Organisation nach Nonaka [Nona94] dargestellt und
evaluiert.




                                                                                                             1
2       Nonaka`s Modell
Nonaka postuliert ein zyklisches Vier-Modi-Modell, wie Unternehmen dynamisch Wissen erzeugen. Wissen
wird durch das Zusammenspiel von nicht artikuliertem (impliziten) und explizitem Wissen erzeugt. Nicht artiku-
liertes Wissen ist persönliches Wissen, das nur schwer zu formalisieren oder mitzuteilen ist. Explizites Wissen
ist formelles Wissen, das leicht zwischen Individuen und Gruppen ausgetauscht werden kann, z.B. mittels Da-
tenbanken. Nach Nonaka gibt es vier Modi der Wissenstransformation: Sozialisierung, Externalisierung, Kombi-
nation und Internalisierung (vgl. Abb.1).




                            Abb. 1: Wissenserzeugung in Unternehmen [Nona94]

• Sozialisierung beschreibt den Prozeß des Wissenserwerbs von nicht artikuliertem Wissen, wie z.B. Schüler es
  von Meistern durch Beobachtung, Imitation und Praxis lernen [Choo96].

• Externalisierung beschreibt die Umwandlung von implizitem zu explizitem Wissen. Dies wird bspw. durch
  den Einsatz von Metaphern, Analogien oder Modellen erreicht. Gerade die Modellierung wird häufig einge-
  setzt, um strukturiertes Wissen in einem Organisationsgedächtnis zu sammeln [Maso93].

• Ein klassisches Einsatzgebiet der Informatik ist der Prozeß der Wissenskombination durch
  die Transformation von explizitem in explizites Wissen, mittels Techniken wie Reasoning,
  Programmierung, Data Mining und formalem Informationsaustausch.
• Der Kreis wird geschlossen durch die Internalisierung, die explizites Wissen wieder in die
  tägliche Arbeitspraxis zurückbringt.
Wissenserzeugung beginnt - wie beschrieben - beim Individuum. Menschen haben Einsichten und entwickeln
neue Ideen, wie sie ihre Arbeit besser gestalten können. Weil das Kurzzeitgedächtnis begrenzt ist, müssen sie
ihre Ideen aufschreiben und erzeugen dadurch einen persönlichen Informationsspeicher. In den letzten Jahren
wurden Rechnerwerkzeuge entwickelt, um persönliches Wissen sowohl zu externalisieren als auch zu internali-
sieren. Allerdings ist eine Organisation nicht in der Lage, dieses persönliche, explizite Wissen zu nutzen, solange
es nicht mit anderen geteilt werden kann.

Sozialisierung erzeugt ein Organisationsgedächtnis. Allerdings wird dieses Organisationsgedächtnis durch drei
Gefahren bedroht, wenn es nicht expliziert wird:



2
(1) Reorganisation kann effektiv nutzbare Strukturen, Prozesse und Informationen in einem Unter-
    nehmen zerstören.

(2) Die Entlassung, Pensionierung und Fluktuation von gut ausgebildetem Personal kann Löcher in
    ein nicht explizites Organisationsgedächtnis reißen.

(3) Sich ändernde Technologien können zu einem Systemchaos führen und routinemäßig ablaufende
    Prozesse zerstören.

Aus diesen Gründen muß ein Organisationsgedächtnis explizit repräsentiert werden. Diese Repräsentation kann
auf zwei verschiedene Weisen erreicht werden. Zum einen können persönliche Informationssysteme zu einer
Repräsentation des Organisationsgedächtnisses kombiniert werden, zum anderen kann das implizite Organisati-
onsgedächtnis expliziert werden.

Eine Umfrage des FOQUS-Projekts bei 349 Unternehmen [Klam97] demonstrierte erhebliche DV-technische
und organisatorische Probleme, die Externalisierung, Kombination und Internalisierung im Wege stehen. Sie
führen dazu, daß eine Rückführung wichtiger Fehlerinformationen in die planenden Bereiche - Voraussetzung
für Produkt- und Prozeßinnovationen - durch die vorhandenen rechnergestützten Systeme eher behindert als
gefördert wird.

Neue Kombinationen informatischer und organisatorischer Techniken sind daher erforderlich, um eine direktere
Unterstützung des Lernzyklus zu erreichen. Die im FOQUS-Projekt entwickelten Ansätze werden in den folgen-
den Abschnitten beschrieben. Sie geben im wesentlichen erste Antworten auf folgende drei Fragen (s.a. Tab. 1):

• Externalisierung: Wie muß ein formales Modell von Produkt und Prozeß beschaffen sein, damit trotz der
  enormen Variantenvielfalt und Komplexität heutiger Produkte das Erkennen und Darstellen übergreifender
  Probleme und Innovationschancen möglich bleibt?

• Kombination: Wie kann man bei abteilungs- oder unternehmensübergreifenden QM-Prozessen zu einer sys-
  tematischen Wissensaufbereitung und Wissensverteilung kommen, die einerseits das reaktive Fehlermana-
  gement (die Beseitigung aufgetretener Fehler) stetig verbessert, andererseits aber auch das proaktive Fehler-
  management (Fehlervermeidung durch Innovation) unterstützt?

• Internalisierung: Wie kann das gewonnene Wissen - sei es formaler oder informeller Natur - effektiv für die
   Nutzung im Routinebetrieb aufbereitet und verfügbar gemacht werden?




                                                                                                             3
Wissensumwandlung            Schwachstellen                 Symptome                  mögliche Maßnahmen

Externalisierung         Informations-, Ablauf- Arbeit wird nicht oder mehr-        Identifikation und Optimie-
                         und Kommunikationslü- fach erledigt, mangelnde             rung von Informationsflüs-
                         cken                   abteilungsübergreifende             sen und Arbeitsabläufen
                                                Zusammenarbeit                      durch Analyse und Simulati-
                                                                                    on, kooperative Modellie-
                                                                                    rung von Schnittstellen

Kombination              Falsche Software /        Isolierte, proprietäre, schwer   Integrierte oder integrieren-
                         schlecht organisierte     erweiterbare, ineffiziente       de Software-Lösungen,
                         Datenhaltung / Daten-     und änderungsresistente          uniforme Datenhaltung,
                         zugriff                   Software- oder Daten-Inseln,     föderative Informationssys-
                                                   Produktionsdaten nicht           temarchitekturen, Hypertext-
                                                   menschengerecht aufgear-         strukturen, Grafische Anfra-
                                                   beitet                           gesprachen

Internalisierung         Informationsaustausch / Papierflut (nicht aufgaben-        Datenbankbasiertes Doku-
                         Informationsüberfrach-    spezifisch), Medienbrüche,       mentenmanagement ("elekt-
                         tung / Informationsauf-   Verlust von Kontextwissen,       ronische Umlaufmappen"),
                         bereitung / Schlechte     papierbasiert, mangelnder        Intranets, Computer-based
                         Kommunikations- und       Feedback, schlecht struktu-      Learning ("Garten der Ant-
                         Arbeitsablauf-            rierte Berichte, Verzögerun-     worten"), Service-
                         unterstützung             gen, Mißverständnisse            orientiertes Workflow-
                                                                                    Management
Tab. 1: Schwachstellen im Fehlermanagement




3       Unterstützung der Externalisierung: Modellierung va-
        riantenreicher Produkte
Ein zentraler Trend in der Industrie ist das Erlangen von Wettbewerbsvorteilen durch Differenzierung der Pro-
duktpaletten und der zugehörigen Produktionsprozesse in immer vielfältigere Varianten, um eine flexiblere An-
passung an Kundenwünsche zu erreichen. Im Fehlermanagement ergeben sich daraus zwei Probleme:

1. Die Nachvollziehbarkeit der Produktion jeder Variante erfordert umfangreiche Historiendaten, um
   speziellen Reklamationen nachgehen zu können.

2. Für die statistische Prozeßkontrolle und Fehleranalyse sind die Grundgesamtheiten zu klein;
   gleichzeitig sind Fehler, die mehrere Varianten betreffen, nur schwer zu identifizieren.

Das Projekt FOQUS hatte sich daher zum Ziel gesetzt, auf der Basis relationaler Produkt- und Prozeßmodelle,
die mehr und mehr zum industriellen Standard werden [Klam97], Repräsentationskonzepte und Berechnungsve r-
fahren zu entwickeln, die das Arbeiten mit Varianten im Fehlermanagement unterstützen. Der Variantenbegriff
ist allerdings in der Fertigung nicht allgemeingültig definiert. Meist bezieht er sich auf die Spezifikation von
Produkten einer gemeinsamen Produktklasse, definiert durch ihre Funktion (z.B. Staubsauger). Damit entsteht
eine Klassifizierung nach dem wichtigsten Gegenstand der Fertigung, dem Endprodukt.

4
Im Fehlermanagement spielen häufig Informationen auf einer anderen Granularitätsebene eine Rolle: Daß der
Staubsauger A eine Variante des Staubsaugers B ist, bedeutet nicht notwendigerweise, daß dies auch für die
Motoren gilt; denn der Motor kann gerade das Differenzierungskriterium zwischen den Varianten sein. Umge-
kehrt kann ein Motor gerade die ‘Variantenhaftigkeit’ von A und B unterstützen, wenn er in beiden Saugern
verwendet wird.

Die Identifizierung und Nutzung beider Situationen im Fehlermanagement wird in klassischen Modellen nicht
unterstützt. Die Verwendung von Fehlerwissen, das für beide Varianten von Bedeutung ist, hängt dann meist von
der Erfahrung der Benutzer ab.

Ein weiteres Problem besteht darin, daß der Variantenbegriff bei der Nutzung von Fehlerwissen nicht auf das
Produkt beschränkt ist, sondern häufig auch von der Produktions- und Nutzungssituation abhängig ist: Produkt-
fehler treten bspw. nur dann auf, wenn auf Maschine X produziert wird und/oder die Umgebungstemperatur
größer als 40°C wird. Ein solches Fehlerbild kann sich über Produkte erstrecken, die nicht zur selben Produktva-
riante gehören.

Die kurzen Beispiele zeigen, daß eine differenzierte Betrachtung des Variantenbegriffs im Fehlermanagement
notwendig ist. Als Ausgangspunkte für die Definition von Varianten bieten sich fünf Blickwinkel auf Produkte
und Prozesse an:

1. Merkmalsausprägungen
   Produkte oder Prozesse einer Variante unterscheiden sich in der Ausprägung von Merkmalen. Die
   Merkmalsmenge zur Beschreibung des Produktes stimmt bei allen Produkten überein, aber die
   Werte, die Merkmale annehmen, können sich unterscheiden. Beispiel ist die Farbe von Fahrzeugen
   des gleichen Typs. Dabei wird die Farbe, im Gegensatz zur Motorleistung, bei Fahrzeugen kaum
   zur Variantenbildung herangezogen. Sie kann aber im Fehlermanagement bedeutsam sein, wenn
   Fehler in der Lackierung nur bei roten Fahrzeugen auftreten.

2. Merkmalsmengen
   Produkte oder Prozesse einer Variante unterscheiden sich in der Merkmalsmenge. Unterschiede in
   Merkmalsmengen können aber auch verschiedene Varianten kennzeichnen, wie z. B das Merkmal
   “Faltdach“ ein Cabriolet von allen anderen Fahrzeugklassen abgrenzt. Die Unterscheidung zwi-
   schen trennenden und variantenbeschreibenden Merkmalen ist oft ein Gemisch aus standardisierten
   und unternehmensintern historisch gewachsenen Kriterien.

3. Produktstrukturen
   Produkte oder Prozesse einer Variante unterscheiden sich durch Unterschiede in der Struktur, d.h.
   in der Art der Baugruppen (bzw. Prozeßschritte) und ihrem Zusammenwirken. So können bauglei-
   che Fahrzeuge mit unterschiedlichem Motor als Varianten betrachtet werden, was in der Fahrzeug-
   industrie üblich ist. Aber daß zwei Produkte sich in einer Baugruppe unterscheiden, bedeutet nicht,
   daß sie sich in allen Unterbaugruppen unterscheiden. Die Entscheidung über “Variante oder nicht“
   kann für jede Baugruppe neu getroffen werden.

4. Produktnutzungsumstände
   Produkte oder Anlagen werden unter Servicegesichtspunkten auch durch ihre Einsatzumgebung be-
   schrieben. Um beim Fahrzeugbeispiel zu bleiben, ist die Unterscheidung zwischen Stadtwagen und
   Langstreckenfahrzeug ein wichtiges Einsatzkriterium, unter dem auch Fahrzeuge unterschiedlicher
   Typen als Varianten betrachtet werden können.

                                                                                                              5
5. Produktionskontext
   Häufig lassen sich Produktfehler auf einen Fertigungsprozeß oder eine Fertigungsanlage zurück-
   führen. So können Produkte, die von ihrer Nutzung und ihrem Aufbau her nur wenig miteinander
   zu tun haben, trotzdem hinsichtlich des Fehlers Varianten voneinander sein, weil sie auf derselben
   Anlage gefertigt wurden. So könnten verschiedene Kunststoffteile eine hohe Brüchigkeit aufwei-
   sen, weil sie mit zu geringem Preßdruck an einer bestimmten Maschine gefertigt wurden.

Die Identifizierung von Varianten in diesem Fehlerkontextraum verlangt, daß die Repräsentation der zugehöri-
gen Daten zwei Voraussetzungen erfüllt:

1. Die Daten über Produkte, Prozesse, Anlagen und Nutzungskontexte müssen so miteinander ver-
   netzt sein, daß die geschilderten Zusammenhänge nachvollziehbar sind. Das Produkt- und Pro-
   zeßmodell (PPM), Ergebnis der Forschergruppe WibQuS, leistet dies für die Bereiche Produkt,
   Prozeß und Anlage [Pfei96]. Das FOQUS-Fehlerdatenmodell verknüpft das PPM mit der Fehler-
   situation und insbesondere mit den Produktnutzungsumständen.

2. Die Repräsentation und Auswertung von Varianten innerhalb der einzelnen Bereiche Produkt,
   Prozeß, Anlage und Fehlersituation muß ermöglicht werden.

Wie man ermittelt, daß A eine Variante von B ist, hängt von verschiedenen Faktoren ab. Zum einen variiert die
Formalisierbarkeit des Konzepts Variante über einem bestimmten Begriffsraum. Zum anderen verändert sich die
Bedeutung der Variantenbildung für den Benutzer im Zeitablauf. Diese Überlegungen beeinflussen die Auswahl
zwischen den denkbaren Verfahren zur Variantenbildung, von denen zunächst drei in die engere Auswahl ge-
nommen wurden:

1. Attributierung
   Hier wird den Produkten, Prozessen, usw. ein Attribut “Variante_von” zugewiesen, das entweder
   alle Objekte enthält, die als Varianten gelten sollen oder eines, über das transitiv auf andere Varian-
   ten geschlossen werden kann. Dieses Verfahren wird angewandt, wenn die Formalisierung des
   Ähnlichkeitsbegriffs nicht möglich, aber die Erfassung der Ähnlichkeiten von hoher Wichtigkeit
   ist. Das Verfahren ist bei der Eingabe neuer Objekte sehr aufwendig, da stets der gesamte Objekt-
   raum auf ähnliche Objekte abgesucht werden muß.

2. Klassifizierung
   Hier existiert eine Klassenhierarchie, die den Raum der Produkte oder Prozesse vorstrukturiert. Ein
   neuer Begriff wird dann einer Klasse (oder mehreren in verschiedenen Klassenhierarchien) zuge-
   ordnet. Varianten sind dann alle Elemente derselben Klasse und möglicherweise die benachbarter
   Klassen im selben Teil der Klassenhierarchie. Über die Bildung der Klassenhierarchien liegt hier
   eine implizite Formalisierung des Variantenbegriffs vor, die schon bei der Eingabe zur Benutzer-
   führung ausgenutzt werden kann.

3. Ähnlichkeitsanalyse
   Der Variantenbegriff wird nicht explizit in die Repräsentation aufgenommen, d.h. der Benutzer
   muß bei der Eingabe von Objekten keine Rücksicht darauf nehmen. Auf den gesammelten Daten
   werden automatische Ähnlichkeitsuntersuchungen (semantische Distanz, statistische Clusteranaly-
   se) durchgeführt, die dann zur Variantenbildung genutzt werden. Dieser Ansatz ist sinnvoll, wenn
   entweder die Ähnlichkeit gut formalisierbar ist oder als Rekonstruktionsmittel, wenn zum Design-
   zeitpunkt des Systems kein Wert auf den Variantenbegriff gelegt wurde.


6
Im Projekt FOQUS fiel die Entscheidung zur Variantenrepräsentation für Klassifizierungshierarchien bezüglich
der Aspekte Produkt, Prozeß, Anlage und Fehler(kontext). Diese Entscheidung liefert einen akzeptablen Kom-
promiß zwischen Aufwand für die Repräsentation, Transparenz des verwendeten Variantenbegriffs und Nutz-
barkeit im täglichen Gebrauch:

• Zwar müssen die Klassenbäume im Designprozeß aufgebaut und anschließend gewartet werden,
  doch der Aufwand für den einzelnen Benutzer ist deutlich niedriger als bei der expliziten Attribu-
  tierung; dort muß beim Einfügen einer neuen Variante stets der gesamte Suchraum nach möglichen
  Varianten abgesucht werden. Die Gefahr der Unvollständigkeit oder der zu stark subjektiven Ein-
  ordnung durch den Benutzer wird dadurch gemildert.

• Im Vergleich zur Ähnlichkeitsanalyse ist zwar der Aufwand der Variantenverwaltung höher, aber
  auch die Transparenz der verwendeten Variantenstruktur. Zwar ist die Ähnlichkeitsanalyse objekti-
  ver (weil indirekter) als die Klassenhierarchiebildung, doch hat diese den Vorteil, daß sie einfach
  an die Belange des Unternehmens angepaßt werden kann. Schließlich sind die Daten, mit denen
  gearbeitet werden muß, oft hierarchisch strukturiert und eine Mischung aus numerischen und typi-
  sierten Daten, die für die Ähnlichkeitsanalyse erst mit hohem Aufwand aufbereitet werden müßten.

• Schließlich ist die Bildung von Klassen und die Einordnung von Objekten in diese ein Vorgang,
  der dem Benutzer natürlich erscheint und dessen Bedeutung sich dem Benutzer mehr oder weniger
  intuitiv erschließt. Klassifizierungs- und Aggrgationshierarchien lassen sich auf natürliche Weise
  mit objektorientierten Modellierungskonzepten abbilden.

Wie Klassenhierarchien genutzt werden, um nach Varianten zu suchen, sei am folgenden Beispiel näher erläu-
tert. Es soll auch zeigen, auf welche Weise die Kopplung von Klassifikationshierarchien mit Aggregationshie-
rarchien (Produkt- oder Prozeßbäume) zum einen Zusammenhänge verkompliziert, zum anderen aber auch hilft,
die Suche nach ähnlichen Fehlerfällen zu steuern, wenn man eine adäquate Präsentation der Strukturen für den
Benutzer findet. Ein Werkzeug, das dies leistet, wird in Abschnitt 5 vorgestellt.

Abb. 2 zeigt Produktbäume zu drei Produkten (Staubsauger, Haartrockner und Bohrmaschine), die hinsichtlich
der Fehleranalyse zunächst einmal nichts miteinander zu tun haben. Die Dekomposition und ihre Verbindung mit
den Klassifikationshierarchien (hier: Motoren und Trafos) zeigt aber auf, wie auf verschiedenen Dekompositi-
onsstufen völlig unterschiedliche Variantenbeziehungen bestehen können, die bei der Suche nach Fehlerfällen
ausgenutzt werden können:

   Angenommen, ein Servicetechniker soll bei einem Kunden einen defekten Staubsauger reparieren.
   Er stellt fest, daß der Fehler im Motor zu suchen ist. Neben verschiedenen Staubsaugern, die den-
   selben oder einen ähnlichen Motor benutzen, wird ihm außerdem noch ein Haartrockner als Varian-
   te hinsichtlich des Motors angeboten, weil dieser in einem benachbarten Knoten der Klassenhierar-
   chie angesiedelt ist.




                                                                                                          7
Staubsauger                                                                             Haartrockner
                                                               Motoren


                  Gehäuse                 Motor                                                           Gehäuse                  Motor



                                Antrieb                                                 Trafos                          Antrieb


                  Deckel    Boden           Stromversorgung                                               Träger    Auslaß          Stromversorgung



                                 Welle      Rotor                                                                        Welle      Rotor

                                                                        Bohrmaschine


                                                              Gehäuse                 Motor



                                                                            Antrieb


                                                              Körper    Bohrkopf        Stromversorgung



                                                                             Welle      Wicklung



                              Abb. 2: Bezüge zwischen Aggregation und Klassifikation

Wird die Fehlerquelle im Laufe der Analyse genauer als die Stromversorgung identifiziert, verändert sich auch
der Variantenkontext. Der Haartrockner gehört nicht mehr zu den Varianten hinsichtlich des Trafos, weil dessen
Stromversorgung zu einem anderen Teilbaum der Hierarchie “Trafos“ gehört. Statt dessen kommt eine Bohrma-
schine zur Menge der Varianten.

Mit Hilfe der Aggregationshierarchien läßt sich demnach der Analyseprozeß des Fehlermanagements strukturie-
ren. Die Beziehungen zwischen objektorientierten Aggregations- und Klassifikationshierarchien erlaubt eine
multidimensionale (Produkt, Prozeß, Anlage, Fehlerkontext) Strukturierung der Analyseschritte unter Ausnut-
zung der Variantenbeziehung.



4       Sozialisierungs- und Kombinationsunterstützung
        durch kooperative konzeptuelle Modellierung
Zentrales Ziel bei der Entwicklung von DV-technischen Lösungen für das industrielle Fehlermanagement mit
praktischer Relevanz für kleine und mittlere Unternehmen ist die Beseitigung von informationellen, konzeptuel-
len und technologischen Barrieren, die Erzeugung und gemeinsame Nutzung von Fehlerwissen in verteilten
Fehlermanagementprozessen verhindern.

Ein Beispiel soll die Komplexität der Aufgabe ve rdeutlichen. Im Call Center eines Fertigungsbetriebes für
Industriegetriebe wird eine Kundenbeschwerde über ein neu erworbenes Getriebe für den industriellen Einsatz
aufgenommen. Im konkreten Fall verliert das Getriebe Öl. Aus den bisherigen Erfahrungen des Call Centers
kann dieses keinen direkten Ratschlag zur Behebung des Problems geben. Aus diesem Grund wird ein Repara-
turauftrag an einen Monteur vergeben. Dieser fährt zum Kunden und versucht, den Fehler vor Ort zu beheben. Er
entdeckt, daß die Dichtungsringe des Getriebes an der Antriebswelle nicht korrekt montiert wurden, was die
Ursache des Fehlergeschehens ist. Er repariert das Getriebe, indem er neue Dichtringe einsetzt. Um weitere Auf-
treten dieses Fehlerbildes in Zukunft zu verhindern, wird die weitere Behandlung dieses Fehlers an die Abteilun-
gen im Fertigungsbetrieb weitergegeben, die mit der Behebung des Fehlerbildes an der Quelle, in unserem Fall
bei der Montage, verantwortlich sind. Jede verantwortliche Abteilung versucht, die tieferen Ursachen des Feh-

8
lerbildes herauszufinden und Abstellmaßnahmen aufgrund der vorgenommenen Analysen zu definieren. Der
Erfolg der Maßnahmen muß dokumentiert und an die verantwortlichen Stellen weitergeleitet werden. Nach ve r-
schiedenen Annahmen und Versuchen den Fehler an seiner Quelle zu beseitigen, wird schließlich die grundle-
gende Ursache ermittelt. Ein Fehler im Montagehandbuch für das Getriebe in der Montageplanung wurde an die
Montage weitergeleitet. Die Qualitätskontrolle war nicht in der Lage, den Fehler zu diagnostizieren, weil die
Kontrollroutinen nicht effektiv angewendet wurden.

Das Beispiel zeigt zwei Typen für Lernen in Organisationen. Auf der einen Seite kann das Call Center über eine
schnelle Reparaturmaßnahme unterrichtet werden, auf der anderen Seite können Montageplanung und Qualitäts-
kontrolle bei zukünftigen Fertigungsläufen das Problem an der Quelle abstellen.

Will man derartige Vorgänge systematisieren, so setzt dies eine formal fundierte Analyse kooperativer Prozesse
voraus, die ihrerseits auf gemeinsamen Begriffswelten der Anwendungsdomänen beruhen. In der Literatur wur-
den bisher hauptsächlich operationale Kooperationsprozesse untersucht. Dagegen gibt es nur erste Ansätze zur
Mitmodellierung des längerfristigen Wissensmanagement [Choo96; Deck96; Pete96].


4.1     Das Eskalationsprinzip
Der Prozeß der Lernens in Organisationen startet mit der Sozialisierung persönlichen, nicht artikulierten Wis-
sens. Falls ein Fehler in verschiedenen Abteilungen bearbeitet werden muß, um das Problem zu analysieren und
geeignete Abstellmaßnahmen zu definieren, können zwei Probleme beobachtet werden. Zum einen gibt es keine
Zuordnung von Verantwortlichkeiten, was zu Verzögerungen in der Bearbeitung eines Fehlerbildes und zur
Reduktion der Effektivität der Fehlerbehebung führen kann, zum anderen können Verantwortlichkeiten mehr-
fach zugeordnet sein, was zu sich aufschaukelnden Behinderungen im Prozeß führen kann. Um das Wissen um
die Verantwortlichkeiten in Fehlermanagementprozessen in der Organisation nutzbar zu mache, wird das Eskala-
tionsprinzip für abteilungsübergreifende Prozesse vorgeschlagen. Zielsetzung bei diesem Strukturprinzip ist die
geordnete Bearbeitung von Fehlern durch die systematische Identifizierung von Verantwortlichkeitsbereichen.

Das Eskalationsprinzip beschreibt somit einen Sozialisierungsmechanismus, der die Bearbeitung von Fehlerbil-
dern und den Austausch von Wissen über Fehlern zwischen Verantwortungsbereichen regelt. Die Elemente des
Eskalationsprinzips sind in Abb. 3 aufgeführt.

Mikro- und Makroprozesse im Fehlermanagement werden wie folgt unterschieden. Mikroprozesse beschreiben
Aktionen, die lokal in einem Verantwortungsbereich durchgeführt werden müssen, um das Fehlerbild zu bearbei-
ten. Es gibt drei Schritte, die strukturell in jedem Verantwortungsbereich gleich sind, aber für die verschiedene
Verantwortungsbereiche abhängig von der lokalen Aufgabe und den Fertigkeiten der Bearbeiter verschieden
implementiert sind.




                                                                                                               9
Abb. 3: Eskalationsprinzip der Fehlermanagements

1. Der Fehlererfassungsschritt

     Erfassen ist der Prozeß des Informationssammlung und -dokumentation von verfügbaren Fehlerdaten. Auf
     der einen Seite können diese Daten für automatisierbare Diagnoseprozessen maschinenlesbar aufbereitet sein,
     auf der anderen Seite können sie dazu dienen, Bearbeiter in späteren Phasen der Eskalation zu unterstützen,
     die mit dem Fehlerbild arbeiten müssen, ohne die Fakten zu kennen. Der Einsatz von Multimedia zur Ve r-
     deutlichung des Kontextwissen kann Unsicherheit und Mehrdeutigkeit reduzieren [DaLe86]. Ein Modell zum
     Einsatz von elektronischen Umlaufmappen [KaRa91] als Kapselungsmechanismus für Kontextwissen kann
     in [Klam98] nachgelesen werden.

2. Der Fehleranalyseschritt

     Analysieren ist der Prozeß der Interpretation der verfügbaren Information, um mögliche Ursachen eines Feh-
     lerbildes zu ermitteln und anwendbare Maßnahmen zu definieren. Wie erwähnt kann dieser Schritt sowohl
     durch Menschen als auch durch Softwarewerkzeuge unterstützt werden. Falls keine lokale Lösung des Prob-
     lems möglich ist oder der Bearbeiter weiterreichende Ursachen des Fehlerbildes annimmt, wird das Fehler-
     bild eskaliert.

3. Der Fehlerkorrekturschritt

     Korrektur ist der Prozeß der Durchführung und Verfolgung von Abstellmaßnahmen für die Fehlerbehebung.
     Der Erfolg oder Mißerfolg solcher Maßnahmen wird an alle in der Eskalationskette beteiligten Bearbeiter
     weitergeleitet.

Der Makroprozeß beschreibt Eskalationsschritte. Mit jeder Eskalation wird das Fehlerbild an einen oder mehrere
neue Verantwortungsbereiche weitergeleitet. Die Bedingungen für die Weiterleitung legen manchmal langfristi-
ge Abmachungen zwischen Abteilungen fest, die in kooperativ erstellten Modellen dokumentiert sind; alternativ
können sie zum Zeitpunkt der Weiterleitung verhandelt werden. Der letztere Ansatz ist unter dem Stichwort
serviceorientierte Workflows bekannt [Flor88; Medi92; Schä96]. Beispielhaft sei hier das System Coordinator
von Action Technologies Inc. genannt. Allerdings fokussieren diese Ansätze auf den formalen Vertragsabschluß
zwischen Kunden und Anbietern von Dienstleistungen und beziehen kaum das notwendige Kontextwissen ein.



10
4.2     Formale Modellierung der Interaktionen
Die Organisationsstruktur des Eskalationsprinzips ist nicht externalisiert und deshalb noch nicht ausreichend, um
das Wissen entlang der Eskalationsketten gemeinsam zu nutzen. Im folgenden wird eine Modellierungstechnik
vorgestellt, die es ermöglicht, aufgrund formaler Prozeßbeschreibungen das gemeinsam nutzbare Wissen zu
externalisieren.




                            Abb. 4: Metamodell des Organisationsgedächtnisses

Um sowohl Mikro- als auch Makroprozesse zu beschreiben, die sowohl die Weitergabe notwendigen Kontext-
wissens entlang der Eskalationskette sichern als auch eine Repräsention des Organisationsgedächtnisses darstel-
len, ist eine formale Beschreibungssprache notwendig. Der Kern der Sprache bildet ein Prozeßmodell, das von
McMenamin und Palmer [McPa84] vorgeschlagen wurde. Eine Eingabe (hier ein Objekt) wird von einem Sys-
tem konsumiert und manipuliert, wodurch eine Ausgabe produziert wird. Das System wird in diesem Fall durch
Prozesse beschrieben, die Arbeits- und Informationsflüsse darstellen. Bearbeitet werden die Prozesse durch A-
genten, die von Werkzeugen unterstützt werden.

Die formale Sprache ist in der Wissensrepräsentationssprache Telos [Mylo90] definiert. Sie verfolgt drei Zwe-
cke:

(1) Definition des Informations- und Arbeitsflusses von Fehlermanagementprozessen,

(2) Definition von Schnittstellen für abteilungsinterne und abteilungsübergreifende Koordination und
    Kommunikation,

(3) Spezifikation für die Implementierung oder Wiederverwendung von Werkzeugen in den einzelnen
    Mikroprozessen sowie von Workflows auf der Makroprozessebene, die durch Workflowtechnolo-
    gie unterstützt werden können.




                                                                                                              11
Abb. 5: Beispiel für autonom erstellte Mikroprozesse

Der eigentliche Modellierungsprozeß wurde durch das Meta-Datenbankmanagementsystem ConceptBase
[Jark95; Jarke97] unterstützt, das zum einen als konzeptuelles Modellierungswerkzeug dient, aber auch das Re-
pository für das Organisationsgedächtnis auf der Schemaebene darstellt. Abb. 4 zeigt den Bildschirmabzug der
ConceptBase-Definition der oben beschriebenen Sprache. Mit formalen Konfliktlösungstrategien, die in Con-
ceptBase realisiert sind, konnten die in Fallstudien von den Abteilungen autonom erstellten Prozesse zu Makro-
prozessen mit definierten Schnittstellen integriert werden. In Abb. 5 sind drei Mikrologiken (Reklamationserfas-
sung im Call Center, Reklamationsbearbeitung durch einen Serviceingenieur und eine FMEA-Sitzung aus dem
Bereich Produktentwicklung) abgebildet. Das Ziel der Modellierung ist die Integration dieser Prozesse, um kurz-
fristige reaktive Prozesse mit langfristigen Verbesserungsprozessen in der Produktentwicklung zu koppeln. Die
Beschreibung und Integration der autonomen Mikroprozesse sichert ein gemeinsames Verständnis über verwe n-
dete Konzepte und Workflows, das auch gekoppelte Informationssysteme mit definierten Schnittstellen zwischen
einzelnen Verantwortungsbereichen definiert sowie Bearbeiter für Aufgaben des Fehlermanagement und das
austauschbare Wissen zwischen Verantwortungsbereichen in jedem Eskalationsschritt identifiziert.

Mit der Sprache kann eine formale Repräsentation eines Organisationsgedächtnisses konstruiert werden. Die
Reorganisation von Arbeits- und Informationsflüssen kann auf Basis der Organisationsgedächtnisses geplant
werden, Änderungen werden im Repository widergespiegelt. Effekte der Fluktuation von Personal und technolo-
gische Änderungen werden durch die Verknüpfung der Konzepte Agent, Prozeß und Werkzeug gemildert.

5       Internalisierung: Werkzeuge zur Weitergabe und Nut-
        zung von Wissen
Basierend auf der Spezifikation der abteilungsinternen und abteilungsübergreifenden Workflows und Informati-
onszugriffe kann die Internalisierung des Wissens in die Arbeitspraxis durch ein Workflow-Managementsystem

12
(WFMS) unterstützt werden. Dieses nutzt die explizite Darstellung des Organisationsgedächtnisses, um die
Workflows und Informationsflüsse auf definierte Weise zu operationalisieren. Eine ausführliche Darstellung
dieses Internalisierungspfades ist in [Klam98] zu finden.




                                       Abb. 6: Garten der Antworten

Einen anderen Weg der Internalisierung von sozialisiertem, externalisiertem und kombiniertem Wissen beschrei-
tet das computergestützte Training. Im Projekt FOQUS wurde die "AnswerGarden"-Metapher [AcMa90;
AcMc96] genutzt, um die unternehmensweite Nutzung von multimedial repräsentiertem Wissen zu ermöglichen.
Die Metapher des "Garten der Antworten" ist dem Wildwuchs der World Wide Web direkt entgegengesetzt. Wie
in einem Garten werden Wege zu interessanten Plätzen im Organisationsgedächtnis angelegt und in Systemen
von Webseiten abgebildet. So können die Benutzer im Intranet auf diesen Wegen "wandeln". Im Projekt FOQUS
sind es Fehlerfälle, die über auf konzeptuellen Variantenmodellen basierenden Zugriffspfade erreicht werden,
um bspw. bei der Neukonstruktion einer Variante schon auf das Fertigungswissen anderer Varianten zurückgrei-
fen zu können (Abb. 6). Falls die Wege im Garten dem Benutzer nicht erfolgversprechend erscheinen oder er
keine dokumentierten Fehlerfälle zu seinem Problem findet, kann er auf jeder Seite eine elektronische Nachricht
zu dem im Sinne der Eskalation verantwortlichen Bearbeiter schicken. Diese Zuordnung wurde durch die Exter-
nalisierung in der Repräsentation des Organisationsgedächtnisses erreicht.




                                                                                                            13
Abb. 7: Matrixwerkzeug zur Fehlerdatensuche

Die Metapher “Suchen nach Fehlerdaten“ geht davon aus, daß die Daten zu Fehlerfällen in einer expliziten Hie-
rarchie von Varianten abgespeichert sind (vgl. Abschnitt 3). Auf diese Daten kann mit einer Datenmanipulati-
onsprache zugegriffen werden. Im Projekt FOQUS ist dies die Sprache SQL. Da der Aufwand zum Erlernen
dieser Sprache von Benutzern im FM nicht erwartet werden kann, wurde mit dem sogenannten Matrixwerkzeug
eine geeignete Präsentationsform für Anfragen auf der Hierarchie der Varianten entwickelt, die an einem konkre-
ten Anwendungsszenario beschrieben werden soll (vgl. Abb. 7).

In der Montage eines bestimmten Getriebes sind Probleme beim Zusammenschrauben der Gehäuseteile entstan-
den. Der Bearbeiter will nun Daten zu ähnlichen Fehlerfällen gewinnen. Ihn interessieren also Fehlerfälle zu
geometrischen Attributen. Zusätzlich will der Bearbeiter den Suchraum auf bestimmte Produkte - Getriebetypen
mit diesem Gehäusen - und bestimmte Prozesse bzw. Anlagen, auf denen diese Gehäuse gefertigt sind, ein-
schränken.

Im mittleren Teil des Bildes befindet sich eine Matrix, welche die Variationsmöglichkeiten Struktur, Produkt
und Prozeß/Anlage abbildet. Der Benutzer will Fehlerdaten zu den Attributen Länge, Höhe, Breite, Material und
Maße zu einem Produkt Getriebe mit einem bestimmten Gehäuse (P = Part of) ermitteln. Dazu weiß er, daß
Getriebe YZ eine Variante dieses Getriebes ist. Zusätzlich trägt er ein, daß nur Fehlerfälle ausgegeben werden
sollen, die mit Prozeß B (M = made with) auf Anlage B (W = worked on) gefertigt wurden. Drückt der Anwe n-
der nun den Knopf “Abfrage starten“ im oberen Bereich des Werkzeuges, wird aus dieser matrixbasierten Kon-
figuration der Anfrage eine SQL-Anfrage erzeugt, die alle Fehlerfälle zurück liefert, die dieser Beschreibung
entsprechen. Diese Fälle werden in einem weiteren Fenster für den Benutzer aufbereitet.



6       Erfahrungen und Ausblick
In dieser Arbeit wurde ein Rahmenwerk für die Unterstützung von Lernprozessen in Organisationen durch rech-
nergestütztes Fehlermanagement vorgestellt. Dieser Ansatz wurde in der Demonstrationsfabrik Aditec an der

14
RWTH Aachen implementiert. Die Ingenieure der Aditec konstruierten mit Hilfe der im Projekt entwickelten
Werkzeuge ein einfaches, aber voll funktionsfähiges Getriebe für den industriellen Einsatz in mehreren Varian-
ten. Die Getriebevarianten wurden in der Aditec in kleiner Stückzahl gefertigt und montiert [Pfei97]. Ingenieure,
Arbeiter und Kunden entdeckten und bearbeiteten eine Reihe von Fehlern, die innerhalb der 15-monatigen Lauf-
zeit des Projektes in einer Wissensbank dokumentiert wurden. Wiederholfehler konnten signifikant reduziert
werden, was auch durch weitere Fallstudien bei Industriepartnern belegt werden konnte.

Einige der dokumentierten Fehlerbilder offenbaren deutlich die komplexe und verteile Natur eines Fehlerge-
schehens. In einem Fall konstruierte ein Ingenieur die Antriebswelle für eine Getriebevariante. Anschließend
schrieb er eigenhändig ein NC-Programm zur Fertigung der Welle. Jedoch war es nicht möglich, mit diesem NC-
Programm die Welle auf der Drehmaschine der Aditec zu fertigen. Der Werkzeugrevolver mit der Wende-
schneidplatte kam beim Schruppvorgang zu nahe an den Reitstock der Maschine, so daß der Maschinenbediener
den Drehvorgang aus Sicherheitsgründen abbrechen mußte, um eine Kollision zu vermeiden. Dies kennen die
Maschinenbediener aus ihrer Praxis; es wurde aber vom Ingenieur übersehen, der nicht mit dem Reitstock der
Drehmaschine vertraut war. Die Lösung, die letztendlich realisiert und dokumentiert wurde, war, beim Schrupp-
vorgang weniger Material und beim Schlichten mehr Material bei einer geringeren Schnittiefe wegzunehmen.

Ein neues Projekt mit der Aditec soll die Frage klären, ob die erfolgreiche Unterstützung von Fehlermanage-
mentprozessen auch auf die Kernprozesse der Aditec - Fertigung und Schulung - ausgedehnt werden kann. Vor-
stellbar sind auch Prozesse im Bereich der Dienstleistungen oder der Software-Entwicklung.

                                                Danksagung
Das FOQUS-Projekt wurde vom BMBF im Rahmen des Programms "Produktion 2000" gefördert. Die Projekt-
partner am WZL der RWTH Aachen (Prof. Dr. Dr.h.c. T. Pfeifer) und am IBK der Universität Kaiserslautern
(Prof. Dr. Dr.h.c. G. Warnecke) haben wesentliche Beiträge zur Konzeption und Realisierung spezieller Kompo-
nenten für das interne und externe Fehlermanagement im Rahmen der hier beschriebenen Gesamtarchitektur
geleistet. Besonderer Dank gebührt auch Dr. Peter Peters, der bis zu seinem Wechsel zu McKinsey&Co. die
Arbeiten am Lehrstuhl für Informatik V koordinierte.



7       Literatur
[AcMa90] Ackerman, M. S.; Malone, T.: Answer Garden: A Tool for Growing Organizational Memo-
   ry. In: Proc. of ACM Conf. on Office Information Systems, 1990, S. 31-39.

[AcMc96] Ackerman, M.S.; McDonald, D.W.: AnswerGarden2: Merging Organizational Memory with
   Collaborative Help. In: Cooperating Communities: Proceedings ACM Conference on Computer-
   Supported Cooperative Work (Cambridge, Mass.), New York: ACM Press, 1996, S. 97-105.

[ArSc78] Argyris, C.; Schön, D.: Organizational Learning: A Theory of Action Perspective, 1978.

[Choo96] Choo, C.: The Knowing Organization: How Organizations Use Information to Construct
   Meaning, Create Knowledge, and Make Decisions. In: International Journal of Information Mana-
   gement, 16(5), 1996, S. 329-340.

[DaLe86] Daft, R.; R. Lengel R.: Organizational Information Requirements, Media Richness and
   Structural Design. In: Management Science, 32(5), 1986, S. 554-571.


                                                                                                              15
[Deck96] Decker, S. et al.: A Unifying View on Business Process Modeling and Knowledge Enginee-
   ring. In: Proceedings 10th Knowledge Acquisition Workshop, Banff, Canada, University of Calga-
   ry, 1996, S. 34/1-34/16.

[Dodg93] Dodgson, M.: Organizational Learning: A Review of Some Literatures. In: Organizational
   Studies 14(3), 1993, S. 375-394.

[Flor88] Flores, F. et al.: Computer Systems and the Design of Organizational Interaction. In: ACM
   Transactions on Information Systems 6(2), 1988, S. 153-172.

[Hube91] Huber, G.: Organizational Learning: The Contributing Processes and the Literatures. In:
   Organization Science, 2(1), 1991, S. 88-115.

[Jark95] Jarke, M. et al.: ConceptBase - a Deductive Object Base for Meta Data Management. In:
    Journal of Intelligent Information Systems, 4(2), 1995, S. 157-192.

[Jark97] Jarke, M. et al.: Coordinating Distributed Organizational Knowledge. In: Data & Knowledge
    Engineering, 23(3), Sep. 1997, S. 247-268.

[KlJa97] Klamma, R..; Jarke, M.: Supporting Organizational Learning Processes through Failure Ma-
   nagement. In: Proceedings of the 7th International Workshop on Information Technologies and
   Systems (WITS'97), Atlanta, Georgia, USA, Dezember 1997, S. 66-71.

[Klam97] Klamma, R.. et al.: Eine Untersuchung der DV-Unterstützung von Informations- und Ar-
   beitsflüssen im Qualitätsmanagement bei kleinen und mittleren Unternehmen der Fertigungsindust-
   rie. In: Proceedings des EMISA-Fachgruppentreffens über Workflows, Bonn, Gesellschaft für In-
   formatik, 1997, S.70-80.

[Klam98] Klamma, R.. et al.: Workflow Support for Failure Management in Federated Organizations.
   In: Proceedings of 31st Hawai'i International Conference on System Sciences, IEEE Computer So-
   ciety Press, 1998, S. 302-311.

[KaRa91] Karbe, B.; Ramsperger, N.: Concepts and Implementation of Migrating Office Processes",
   In: Brauer, W.; Hernandez D. (Hrsg.): Verteilte künstliche Intelligenz und kooperatives Arbeiten,
   Berlin, 1991, pp. 136-147.

[Maso93] Mason, R.: Strategic Information Systems: Use of Information Technology in a Learning
  Organization. In: Proceedings of 26th Hawai'i International Conference on System Sciences, 1993,
  S. 840-849.

[McPa84] McMenamin, S.M.; Palmer, J.F.: Essential System Analysis, 1984.

[Medi92] Medina-Mora, R.. et al.: The Action Workflow Perspective to Workflow Management
  Technology. In: Proc. 4th CSCW Conf., Toronto 1992, S. 281-288.

[Mylo90] Mylopoulos, J. et al.: Telos - a Language for Representing Knowledge about Information
  Systems. In: ACM Transactions on Information Systems, 8(4), 1990, S. 325-362.

[Nona94] Nonaka, I.: A Dynamic Theory of Organizational Knowledge Creation. In: Organization
   Science, No. 1, 1994, S. 14-37.

[Pete96] Peters, P.: Planning and Analysis of Information Flow in Quality Management, Dissertation,
   RWTH Aachen, 1996.


16
[Pfei96] Pfeifer, T. (Hrsg.): Wissensbasierte Systeme in der Qualitätssicherung, Berlin, 1996.

[Pfei97] Pfeifer T. (Hrsg.): Fehlermanagement mit objektorientierten Technologien in der qualitätsori-
   entierten Produktion. Forschungszentrum Karlsruhe, FZKA-PFT 183, 1997.

[Schä96] Schäl, T.: Workflow Management Systems for Process Organizations. LNCS 1096 (Diss.
   RWTH Aachen 1995), Berlin, 1996.

[Warg97] Wargitsch, C. et al.: WorkBrain: Merging Organizational Memory and Workflow Manage-
  ment Systems. In: Proc. of Workshop Knowledge-Based Systems for Knowledge Management in
  Enterprises, 9-12. September, Freiburg, 1997.




                                                                                                   17

Contenu connexe

En vedette

Feuerwehr
FeuerwehrFeuerwehr
FeuerwehrWolle1
 
Gow
GowGow
GowL__S
 
Unvergessen
UnvergessenUnvergessen
UnvergessenWolle1
 
10 Fehler des Web Controlling
10 Fehler des Web Controlling10 Fehler des Web Controlling
10 Fehler des Web ControllingTelekom MMS
 
ER PAELLON
ER PAELLONER PAELLON
ER PAELLONkampi79
 
Ein Ohr – alle Infos: So kommunizieren Ihre Systeme im Contactcenter
Ein Ohr – alle Infos: So kommunizieren Ihre Systeme im ContactcenterEin Ohr – alle Infos: So kommunizieren Ihre Systeme im Contactcenter
Ein Ohr – alle Infos: So kommunizieren Ihre Systeme im Contactcenter3cdialog
 
Schlipsträger werden - Sinnsuche zum Berufseinstieg
Schlipsträger werden - Sinnsuche zum BerufseinstiegSchlipsträger werden - Sinnsuche zum Berufseinstieg
Schlipsträger werden - Sinnsuche zum BerufseinstiegJens Oberender
 
Prof. Dr. Piller open innovation
Prof. Dr. Piller open innovationProf. Dr. Piller open innovation
Prof. Dr. Piller open innovationintegro
 
Kritische Erfolgsfaktoren für Business Strategien in Virtuellen Welten
Kritische Erfolgsfaktoren für Business Strategien in Virtuellen WeltenKritische Erfolgsfaktoren für Business Strategien in Virtuellen Welten
Kritische Erfolgsfaktoren für Business Strategien in Virtuellen WeltenBokowsky + Laymann GmbH
 
Grundformen Digitaler Bibliotheken
Grundformen Digitaler BibliothekenGrundformen Digitaler Bibliotheken
Grundformen Digitaler BibliothekenJakob .
 
Umwelt schonen mit intelligenter IT
Umwelt schonen mit intelligenter ITUmwelt schonen mit intelligenter IT
Umwelt schonen mit intelligenter ITkerstenr
 
Prozessleitsystem in der Quarzsandaufbereitung
Prozessleitsystem in der QuarzsandaufbereitungProzessleitsystem in der Quarzsandaufbereitung
Prozessleitsystem in der QuarzsandaufbereitungThomas Schulz
 
Iphone App Geocaching
Iphone App GeocachingIphone App Geocaching
Iphone App Geocachingbetter office
 
ALGUNAS DESPEDIDAS
ALGUNAS DESPEDIDASALGUNAS DESPEDIDAS
ALGUNAS DESPEDIDASelrecreo
 
Awareness durch Microinformationen
Awareness durch MicroinformationenAwareness durch Microinformationen
Awareness durch MicroinformationenCommunardo GmbH
 
Communardo Trendforum 22.06.2011: Collaboration Workplace, Ilja Hauß
Communardo Trendforum 22.06.2011: Collaboration Workplace, Ilja HaußCommunardo Trendforum 22.06.2011: Collaboration Workplace, Ilja Hauß
Communardo Trendforum 22.06.2011: Collaboration Workplace, Ilja HaußCommunardo GmbH
 
Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...
Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...
Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...Bokowsky + Laymann GmbH
 
Drupal 7 auf Amazon Web Services
Drupal 7 auf Amazon Web ServicesDrupal 7 auf Amazon Web Services
Drupal 7 auf Amazon Web ServicesSven Paulus
 

En vedette (20)

Feuerwehr
FeuerwehrFeuerwehr
Feuerwehr
 
Dsvdoc
DsvdocDsvdoc
Dsvdoc
 
Gow
GowGow
Gow
 
Unvergessen
UnvergessenUnvergessen
Unvergessen
 
10 Fehler des Web Controlling
10 Fehler des Web Controlling10 Fehler des Web Controlling
10 Fehler des Web Controlling
 
ER PAELLON
ER PAELLONER PAELLON
ER PAELLON
 
Ein Ohr – alle Infos: So kommunizieren Ihre Systeme im Contactcenter
Ein Ohr – alle Infos: So kommunizieren Ihre Systeme im ContactcenterEin Ohr – alle Infos: So kommunizieren Ihre Systeme im Contactcenter
Ein Ohr – alle Infos: So kommunizieren Ihre Systeme im Contactcenter
 
Schlipsträger werden - Sinnsuche zum Berufseinstieg
Schlipsträger werden - Sinnsuche zum BerufseinstiegSchlipsträger werden - Sinnsuche zum Berufseinstieg
Schlipsträger werden - Sinnsuche zum Berufseinstieg
 
Prof. Dr. Piller open innovation
Prof. Dr. Piller open innovationProf. Dr. Piller open innovation
Prof. Dr. Piller open innovation
 
Kritische Erfolgsfaktoren für Business Strategien in Virtuellen Welten
Kritische Erfolgsfaktoren für Business Strategien in Virtuellen WeltenKritische Erfolgsfaktoren für Business Strategien in Virtuellen Welten
Kritische Erfolgsfaktoren für Business Strategien in Virtuellen Welten
 
Grundformen Digitaler Bibliotheken
Grundformen Digitaler BibliothekenGrundformen Digitaler Bibliotheken
Grundformen Digitaler Bibliotheken
 
Umwelt schonen mit intelligenter IT
Umwelt schonen mit intelligenter ITUmwelt schonen mit intelligenter IT
Umwelt schonen mit intelligenter IT
 
Prozessleitsystem in der Quarzsandaufbereitung
Prozessleitsystem in der QuarzsandaufbereitungProzessleitsystem in der Quarzsandaufbereitung
Prozessleitsystem in der Quarzsandaufbereitung
 
Iphone App Geocaching
Iphone App GeocachingIphone App Geocaching
Iphone App Geocaching
 
ALGUNAS DESPEDIDAS
ALGUNAS DESPEDIDASALGUNAS DESPEDIDAS
ALGUNAS DESPEDIDAS
 
Awareness durch Microinformationen
Awareness durch MicroinformationenAwareness durch Microinformationen
Awareness durch Microinformationen
 
Communardo Trendforum 22.06.2011: Collaboration Workplace, Ilja Hauß
Communardo Trendforum 22.06.2011: Collaboration Workplace, Ilja HaußCommunardo Trendforum 22.06.2011: Collaboration Workplace, Ilja Hauß
Communardo Trendforum 22.06.2011: Collaboration Workplace, Ilja Hauß
 
Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...
Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...
Immersion statt Konfusion - Neue Wege der Zusammenarbeit durch den Einsatz Vi...
 
Drupal 7 auf Amazon Web Services
Drupal 7 auf Amazon Web ServicesDrupal 7 auf Amazon Web Services
Drupal 7 auf Amazon Web Services
 
Parentezco
ParentezcoParentezco
Parentezco
 

Similaire à Driving the Organizational Learning Cycle: The Case of Computer-Aided Failure Management

Neue Besen kehren gut und die alten wissen wo der Dreck liegt. Wissensmanagement
Neue Besen kehren gut und die alten wissen wo der Dreck liegt. WissensmanagementNeue Besen kehren gut und die alten wissen wo der Dreck liegt. Wissensmanagement
Neue Besen kehren gut und die alten wissen wo der Dreck liegt. WissensmanagementFÖHR Agentur für Innovationskulturen
 
(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...
(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...
(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...advise+ GmbH
 
Benchlearning Projekt Social Intranet 2012 (#blp12)
Benchlearning Projekt Social Intranet 2012 (#blp12)Benchlearning Projekt Social Intranet 2012 (#blp12)
Benchlearning Projekt Social Intranet 2012 (#blp12)Cogneon Akademie
 
Eine Transformation: von interner Social Software zur Unterstützung von Gesch...
Eine Transformation: von interner Social Software zur Unterstützung von Gesch...Eine Transformation: von interner Social Software zur Unterstützung von Gesch...
Eine Transformation: von interner Social Software zur Unterstützung von Gesch...Edwin Kanis
 
Informelle Wissensarbeit - Die lernende Organisation im Wandel
Informelle Wissensarbeit - Die lernende Organisation im WandelInformelle Wissensarbeit - Die lernende Organisation im Wandel
Informelle Wissensarbeit - Die lernende Organisation im WandelHendrik Kalb
 
Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...
Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...
Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...Matthias Görtz
 
MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...
MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...
MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...MiPo-Konferenz / Hochschule Aalen
 
Vernetzte Organisation ICT Tweet’n Greet 9.4.2014 Zürich
Vernetzte Organisation ICT Tweet’n Greet 9.4.2014 ZürichVernetzte Organisation ICT Tweet’n Greet 9.4.2014 Zürich
Vernetzte Organisation ICT Tweet’n Greet 9.4.2014 ZürichAlexander Richter
 
Wissensreifung - eine neue Perspektive auf den Umgang mit Wissen
Wissensreifung - eine neue Perspektive auf den Umgang mit WissenWissensreifung - eine neue Perspektive auf den Umgang mit Wissen
Wissensreifung - eine neue Perspektive auf den Umgang mit WissenAndreas Schmidt
 
20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement
20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement
20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagementheiko.vogl
 
Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?
Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?
Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?Know How! AG
 
512kb mit Prof. Dr. Eric Schoop
512kb mit Prof. Dr. Eric Schoop512kb mit Prof. Dr. Eric Schoop
512kb mit Prof. Dr. Eric SchoopProTechnology GmbH
 
Keynote Baumgartner
Keynote BaumgartnerKeynote Baumgartner
Keynote Baumgartnerelsa20
 
Mit People Tagging zum Kollaborativen Kompetenzmanagement
Mit People Tagging zum Kollaborativen KompetenzmanagementMit People Tagging zum Kollaborativen Kompetenzmanagement
Mit People Tagging zum Kollaborativen KompetenzmanagementSimone Braun
 
Whitepaper Wissensmanagement
Whitepaper WissensmanagementWhitepaper Wissensmanagement
Whitepaper WissensmanagementJustRelate
 
Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0
Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0
Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0Telekom MMS
 

Similaire à Driving the Organizational Learning Cycle: The Case of Computer-Aided Failure Management (20)

Neue Besen kehren gut und die alten wissen wo der Dreck liegt. Wissensmanagement
Neue Besen kehren gut und die alten wissen wo der Dreck liegt. WissensmanagementNeue Besen kehren gut und die alten wissen wo der Dreck liegt. Wissensmanagement
Neue Besen kehren gut und die alten wissen wo der Dreck liegt. Wissensmanagement
 
(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...
(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...
(L)earning Organization – Lernende Organisation Wissen als Erfolgsfaktor im U...
 
Benchlearning Projekt Social Intranet 2012 (#blp12)
Benchlearning Projekt Social Intranet 2012 (#blp12)Benchlearning Projekt Social Intranet 2012 (#blp12)
Benchlearning Projekt Social Intranet 2012 (#blp12)
 
HM Managementsysteme
HM ManagementsystemeHM Managementsysteme
HM Managementsysteme
 
Eine Transformation: von interner Social Software zur Unterstützung von Gesch...
Eine Transformation: von interner Social Software zur Unterstützung von Gesch...Eine Transformation: von interner Social Software zur Unterstützung von Gesch...
Eine Transformation: von interner Social Software zur Unterstützung von Gesch...
 
Effiziente eArbeitswelten - topsoft 2010_03_24 12:00
Effiziente eArbeitswelten - topsoft 2010_03_24 12:00Effiziente eArbeitswelten - topsoft 2010_03_24 12:00
Effiziente eArbeitswelten - topsoft 2010_03_24 12:00
 
Digital Leadership_1_2017
Digital Leadership_1_2017Digital Leadership_1_2017
Digital Leadership_1_2017
 
Informelle Wissensarbeit - Die lernende Organisation im Wandel
Informelle Wissensarbeit - Die lernende Organisation im WandelInformelle Wissensarbeit - Die lernende Organisation im Wandel
Informelle Wissensarbeit - Die lernende Organisation im Wandel
 
Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...
Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...
Social Software @ Work - Wissensmanagement und E-Learning im Angesicht von Us...
 
MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...
MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...
MiPo'11: Planung ermöglicht Spontaneität: Tools und Prozesse für Mitarbeiter ...
 
Vernetzte Organisation ICT Tweet’n Greet 9.4.2014 Zürich
Vernetzte Organisation ICT Tweet’n Greet 9.4.2014 ZürichVernetzte Organisation ICT Tweet’n Greet 9.4.2014 Zürich
Vernetzte Organisation ICT Tweet’n Greet 9.4.2014 Zürich
 
Wissensreifung - eine neue Perspektive auf den Umgang mit Wissen
Wissensreifung - eine neue Perspektive auf den Umgang mit WissenWissensreifung - eine neue Perspektive auf den Umgang mit Wissen
Wissensreifung - eine neue Perspektive auf den Umgang mit Wissen
 
20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement
20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement
20100629 m09 wissenswege_methoden_fuer_das_persoenliche_wissensmanagement
 
Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?
Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?
Enterprise 2.0 für alle? Welche neuen Kompetenzen sind gefragt?
 
512kb mit Prof. Dr. Eric Schoop
512kb mit Prof. Dr. Eric Schoop512kb mit Prof. Dr. Eric Schoop
512kb mit Prof. Dr. Eric Schoop
 
Keynote Baumgartner
Keynote BaumgartnerKeynote Baumgartner
Keynote Baumgartner
 
Mit People Tagging zum Kollaborativen Kompetenzmanagement
Mit People Tagging zum Kollaborativen KompetenzmanagementMit People Tagging zum Kollaborativen Kompetenzmanagement
Mit People Tagging zum Kollaborativen Kompetenzmanagement
 
Whitepaper Wissensmanagement
Whitepaper WissensmanagementWhitepaper Wissensmanagement
Whitepaper Wissensmanagement
 
Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0
Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0
Der Enterprise 2.0 Irrtum: Wissensmanagement im Enterprise 2.0
 
Das 1x1 des Blended-Learning
Das 1x1 des Blended-Learning Das 1x1 des Blended-Learning
Das 1x1 des Blended-Learning
 

Plus de Ralf Klamma

An Augmented Reality Framework for Gamified Learning
An Augmented Reality Framework for Gamified LearningAn Augmented Reality Framework for Gamified Learning
An Augmented Reality Framework for Gamified LearningRalf Klamma
 
The Legacy of ROLE - Where are we at the workplace?
The Legacy of ROLE - Where are we at the workplace?The Legacy of ROLE - Where are we at the workplace?
The Legacy of ROLE - Where are we at the workplace?Ralf Klamma
 
Gamification of Community Information Systems
Gamification of Community Information SystemsGamification of Community Information Systems
Gamification of Community Information SystemsRalf Klamma
 
The Legacy and the Future of Research Networks in Technology-Enhanced Learning
The Legacy and the Future of Research Networks in Technology-Enhanced LearningThe Legacy and the Future of Research Networks in Technology-Enhanced Learning
The Legacy and the Future of Research Networks in Technology-Enhanced LearningRalf Klamma
 
DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...
DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...
DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...Ralf Klamma
 
Learning Analytics: Trends and Issues of the Empirical Research of the Years ...
Learning Analytics: Trends and Issues of the Empirical Research of the Years ...Learning Analytics: Trends and Issues of the Empirical Research of the Years ...
Learning Analytics: Trends and Issues of the Empirical Research of the Years ...Ralf Klamma
 
A Short Swim through the Personal Learning Pool
A Short Swim through the Personal Learning PoolA Short Swim through the Personal Learning Pool
A Short Swim through the Personal Learning PoolRalf Klamma
 
Scaling up digital learning support for smart workforce development in cluste...
Scaling up digital learning support for smart workforce development in cluste...Scaling up digital learning support for smart workforce development in cluste...
Scaling up digital learning support for smart workforce development in cluste...Ralf Klamma
 
Scaling Community Information Systems
Scaling Community Information SystemsScaling Community Information Systems
Scaling Community Information SystemsRalf Klamma
 
Technical Challenges for Realizing Learning Analytics
Technical Challenges for Realizing Learning AnalyticsTechnical Challenges for Realizing Learning Analytics
Technical Challenges for Realizing Learning AnalyticsRalf Klamma
 
Technology-Enhanced Learning at the Workplace – From islands of automation to...
Technology-Enhanced Learning at the Workplace – From islands of automation to...Technology-Enhanced Learning at the Workplace – From islands of automation to...
Technology-Enhanced Learning at the Workplace – From islands of automation to...Ralf Klamma
 
ACIS Annual Report 2014
ACIS Annual Report 2014ACIS Annual Report 2014
ACIS Annual Report 2014Ralf Klamma
 
Blueprint for Software Engineering in Technology Enhanced Learning Projects
Blueprint for Software Engineering in Technology Enhanced Learning ProjectsBlueprint for Software Engineering in Technology Enhanced Learning Projects
Blueprint for Software Engineering in Technology Enhanced Learning ProjectsRalf Klamma
 
Navigation Support in Evolving Communities by a Web-based Dashboard
Navigation Support in Evolving Communities by a Web-based DashboardNavigation Support in Evolving Communities by a Web-based Dashboard
Navigation Support in Evolving Communities by a Web-based DashboardRalf Klamma
 
Community Learning Analytics – A New Research Field in TEL
Community Learning Analytics – A New Research Field in TELCommunity Learning Analytics – A New Research Field in TEL
Community Learning Analytics – A New Research Field in TELRalf Klamma
 
Do Mechanical Turks Dream of Big Data?
Do Mechanical Turks Dream of Big Data?Do Mechanical Turks Dream of Big Data?
Do Mechanical Turks Dream of Big Data?Ralf Klamma
 
Advanced Community Information Systems Group (ACIS) Annual Report 2013
Advanced Community Information Systems Group (ACIS) Annual Report 2013Advanced Community Information Systems Group (ACIS) Annual Report 2013
Advanced Community Information Systems Group (ACIS) Annual Report 2013Ralf Klamma
 
Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...
Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...
Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...Ralf Klamma
 
Keynote Learning Layers Developer Camp 2013
Keynote Learning Layers Developer Camp 2013Keynote Learning Layers Developer Camp 2013
Keynote Learning Layers Developer Camp 2013Ralf Klamma
 
Supporting Professional Communities in the Next Web
Supporting Professional Communities in the Next Web Supporting Professional Communities in the Next Web
Supporting Professional Communities in the Next Web Ralf Klamma
 

Plus de Ralf Klamma (20)

An Augmented Reality Framework for Gamified Learning
An Augmented Reality Framework for Gamified LearningAn Augmented Reality Framework for Gamified Learning
An Augmented Reality Framework for Gamified Learning
 
The Legacy of ROLE - Where are we at the workplace?
The Legacy of ROLE - Where are we at the workplace?The Legacy of ROLE - Where are we at the workplace?
The Legacy of ROLE - Where are we at the workplace?
 
Gamification of Community Information Systems
Gamification of Community Information SystemsGamification of Community Information Systems
Gamification of Community Information Systems
 
The Legacy and the Future of Research Networks in Technology-Enhanced Learning
The Legacy and the Future of Research Networks in Technology-Enhanced LearningThe Legacy and the Future of Research Networks in Technology-Enhanced Learning
The Legacy and the Future of Research Networks in Technology-Enhanced Learning
 
DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...
DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...
DevOpsUse for Large-Scale Social Requirements Engineering @ SIG WELL - EC-TEL...
 
Learning Analytics: Trends and Issues of the Empirical Research of the Years ...
Learning Analytics: Trends and Issues of the Empirical Research of the Years ...Learning Analytics: Trends and Issues of the Empirical Research of the Years ...
Learning Analytics: Trends and Issues of the Empirical Research of the Years ...
 
A Short Swim through the Personal Learning Pool
A Short Swim through the Personal Learning PoolA Short Swim through the Personal Learning Pool
A Short Swim through the Personal Learning Pool
 
Scaling up digital learning support for smart workforce development in cluste...
Scaling up digital learning support for smart workforce development in cluste...Scaling up digital learning support for smart workforce development in cluste...
Scaling up digital learning support for smart workforce development in cluste...
 
Scaling Community Information Systems
Scaling Community Information SystemsScaling Community Information Systems
Scaling Community Information Systems
 
Technical Challenges for Realizing Learning Analytics
Technical Challenges for Realizing Learning AnalyticsTechnical Challenges for Realizing Learning Analytics
Technical Challenges for Realizing Learning Analytics
 
Technology-Enhanced Learning at the Workplace – From islands of automation to...
Technology-Enhanced Learning at the Workplace – From islands of automation to...Technology-Enhanced Learning at the Workplace – From islands of automation to...
Technology-Enhanced Learning at the Workplace – From islands of automation to...
 
ACIS Annual Report 2014
ACIS Annual Report 2014ACIS Annual Report 2014
ACIS Annual Report 2014
 
Blueprint for Software Engineering in Technology Enhanced Learning Projects
Blueprint for Software Engineering in Technology Enhanced Learning ProjectsBlueprint for Software Engineering in Technology Enhanced Learning Projects
Blueprint for Software Engineering in Technology Enhanced Learning Projects
 
Navigation Support in Evolving Communities by a Web-based Dashboard
Navigation Support in Evolving Communities by a Web-based DashboardNavigation Support in Evolving Communities by a Web-based Dashboard
Navigation Support in Evolving Communities by a Web-based Dashboard
 
Community Learning Analytics – A New Research Field in TEL
Community Learning Analytics – A New Research Field in TELCommunity Learning Analytics – A New Research Field in TEL
Community Learning Analytics – A New Research Field in TEL
 
Do Mechanical Turks Dream of Big Data?
Do Mechanical Turks Dream of Big Data?Do Mechanical Turks Dream of Big Data?
Do Mechanical Turks Dream of Big Data?
 
Advanced Community Information Systems Group (ACIS) Annual Report 2013
Advanced Community Information Systems Group (ACIS) Annual Report 2013Advanced Community Information Systems Group (ACIS) Annual Report 2013
Advanced Community Information Systems Group (ACIS) Annual Report 2013
 
Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...
Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...
Community Learning Analytics - Challenges and Opportunities - ICWL 2013 Invit...
 
Keynote Learning Layers Developer Camp 2013
Keynote Learning Layers Developer Camp 2013Keynote Learning Layers Developer Camp 2013
Keynote Learning Layers Developer Camp 2013
 
Supporting Professional Communities in the Next Web
Supporting Professional Communities in the Next Web Supporting Professional Communities in the Next Web
Supporting Professional Communities in the Next Web
 

Driving the Organizational Learning Cycle: The Case of Computer-Aided Failure Management

  • 1. Innovation durch rechnergestütztes Fehlermanage- ment: Ergebnisse des BMBF- Projekts FOQUS Matthias Jarke, Ralf Klamma Kurzfassung Ziel des BMBF-Projekts FOQUS war die Entwicklung von Repräsentationskonzepten und Berechnungsverfah- ren, die die Arbeit mit Varianten im Fehlermanagement (FM) unterstützen. Das Projekt sollte dazu beitragen, Abweichungen der Unternehmensleistung von der Kundenerwartung als Chance zu Prozeßverbesserung und Innovation zu begreifen. Es wurden Werkzeuge entwickelt, die Pflege und Nutzung von Fehlerwissen über räumliche, zeitliche und konzeptuelle Barrieren hinweg ermöglichen. Betrachtet wurde sowohl das herstellerin- terne FM während des Entwicklungsprozesses als auch das externe FM im Kontext des Service nach Produktaus- lieferung. Der Beitrag stellt die Untersuchungsergebnisse, die entwickelten Systemlösungen und deren Evaluie- rung in den Kontext des "Organizational Learning" Ansatzes nach Nonaka. Die entwickelte Gesamtlösung startet mit einer flexiblen Formalisierung von Call-Center-Lösungen durch das sog. Eskalationsprinzip des FM, unter- stützt durch kooperative konzeptuelle Modellierung statische und dynamische Schnittstellendefinitionen zwi- schen den betroffenen Bereichen mit dem Ziel einer Vermeidung der Informationsüberlastung und stellt zur Umsetzung sowohl formale (KI-basierte) als auch informelle (hypermediabasierte) Werkzeuge bereit, die zum einen in eine an das Eskalationsprinzip angepaßte Workflow-Unterstützung, andererseits in Navigationsumge- bungen zur fallbasierten informellen Wissens-Wiederverwendung einmünden. Konzept und Werkzeugunterstüt- zung wurden in der Aachener Musterfabrik Aditec installiert und bei einem realen Getriebe-Entwicklungsprozeß mit gutem Erfolg eingesetzt. 1 Einleitung Das Zusammenwirken von Workflow-Managementsystemen und Lernen in Organisationen ist erst wenig unter- sucht worden [KlJa97; Warg97]. Sowohl die Organisationstheorie als auch die Informatik haben noch Klärungen zu erbringen, inwiewe it Informationstechnologie Lernprozesse effektiv und effizient unterstützen kann. Argyris und Schön [ArSc78] definieren Lernen in Organisationen als die Entdeckung und Behebung von Fehlern. Huber [Hube91] betont, daß Lernen in einer Organisation dann stattfindet, wenn durch die Verarbeitung von Informati- on die Spanne der möglichen Handlungsweisen erweitert werden. Eine lernende Organisation beschreibt Dodg- son [Dodg93] als ein Unternehmen, das zweckmäßig Strukturen und Strategien konstruiert, um das Lernen in Organisationen zu fördern und zu maximieren. Fehlermanagement, hier verstanden als die Systematisierung des reaktiven und proaktiven Umgangs mit Fehlern im unternehmensübergreifenden Qualitätsmanagement komplexer Produkte, kann als prototypisches Beispiel für die Gestaltung lernender Organisationen gelten. Das Projekt FOQUS hat den Stand der Praxis eines so verstan- denen Fehlermanagements im Rahmen des BMBF-Förderprogramms "Produktion 2000" empirisch untersucht und auf Basis der erkannten Defizite neue Lösungskonzepte prototypisch realisiert und erprobt. In dieser Arbeit werden die Ergebnisse anhand des Modells der Lernenden Organisation nach Nonaka [Nona94] dargestellt und evaluiert. 1
  • 2. 2 Nonaka`s Modell Nonaka postuliert ein zyklisches Vier-Modi-Modell, wie Unternehmen dynamisch Wissen erzeugen. Wissen wird durch das Zusammenspiel von nicht artikuliertem (impliziten) und explizitem Wissen erzeugt. Nicht artiku- liertes Wissen ist persönliches Wissen, das nur schwer zu formalisieren oder mitzuteilen ist. Explizites Wissen ist formelles Wissen, das leicht zwischen Individuen und Gruppen ausgetauscht werden kann, z.B. mittels Da- tenbanken. Nach Nonaka gibt es vier Modi der Wissenstransformation: Sozialisierung, Externalisierung, Kombi- nation und Internalisierung (vgl. Abb.1). Abb. 1: Wissenserzeugung in Unternehmen [Nona94] • Sozialisierung beschreibt den Prozeß des Wissenserwerbs von nicht artikuliertem Wissen, wie z.B. Schüler es von Meistern durch Beobachtung, Imitation und Praxis lernen [Choo96]. • Externalisierung beschreibt die Umwandlung von implizitem zu explizitem Wissen. Dies wird bspw. durch den Einsatz von Metaphern, Analogien oder Modellen erreicht. Gerade die Modellierung wird häufig einge- setzt, um strukturiertes Wissen in einem Organisationsgedächtnis zu sammeln [Maso93]. • Ein klassisches Einsatzgebiet der Informatik ist der Prozeß der Wissenskombination durch die Transformation von explizitem in explizites Wissen, mittels Techniken wie Reasoning, Programmierung, Data Mining und formalem Informationsaustausch. • Der Kreis wird geschlossen durch die Internalisierung, die explizites Wissen wieder in die tägliche Arbeitspraxis zurückbringt. Wissenserzeugung beginnt - wie beschrieben - beim Individuum. Menschen haben Einsichten und entwickeln neue Ideen, wie sie ihre Arbeit besser gestalten können. Weil das Kurzzeitgedächtnis begrenzt ist, müssen sie ihre Ideen aufschreiben und erzeugen dadurch einen persönlichen Informationsspeicher. In den letzten Jahren wurden Rechnerwerkzeuge entwickelt, um persönliches Wissen sowohl zu externalisieren als auch zu internali- sieren. Allerdings ist eine Organisation nicht in der Lage, dieses persönliche, explizite Wissen zu nutzen, solange es nicht mit anderen geteilt werden kann. Sozialisierung erzeugt ein Organisationsgedächtnis. Allerdings wird dieses Organisationsgedächtnis durch drei Gefahren bedroht, wenn es nicht expliziert wird: 2
  • 3. (1) Reorganisation kann effektiv nutzbare Strukturen, Prozesse und Informationen in einem Unter- nehmen zerstören. (2) Die Entlassung, Pensionierung und Fluktuation von gut ausgebildetem Personal kann Löcher in ein nicht explizites Organisationsgedächtnis reißen. (3) Sich ändernde Technologien können zu einem Systemchaos führen und routinemäßig ablaufende Prozesse zerstören. Aus diesen Gründen muß ein Organisationsgedächtnis explizit repräsentiert werden. Diese Repräsentation kann auf zwei verschiedene Weisen erreicht werden. Zum einen können persönliche Informationssysteme zu einer Repräsentation des Organisationsgedächtnisses kombiniert werden, zum anderen kann das implizite Organisati- onsgedächtnis expliziert werden. Eine Umfrage des FOQUS-Projekts bei 349 Unternehmen [Klam97] demonstrierte erhebliche DV-technische und organisatorische Probleme, die Externalisierung, Kombination und Internalisierung im Wege stehen. Sie führen dazu, daß eine Rückführung wichtiger Fehlerinformationen in die planenden Bereiche - Voraussetzung für Produkt- und Prozeßinnovationen - durch die vorhandenen rechnergestützten Systeme eher behindert als gefördert wird. Neue Kombinationen informatischer und organisatorischer Techniken sind daher erforderlich, um eine direktere Unterstützung des Lernzyklus zu erreichen. Die im FOQUS-Projekt entwickelten Ansätze werden in den folgen- den Abschnitten beschrieben. Sie geben im wesentlichen erste Antworten auf folgende drei Fragen (s.a. Tab. 1): • Externalisierung: Wie muß ein formales Modell von Produkt und Prozeß beschaffen sein, damit trotz der enormen Variantenvielfalt und Komplexität heutiger Produkte das Erkennen und Darstellen übergreifender Probleme und Innovationschancen möglich bleibt? • Kombination: Wie kann man bei abteilungs- oder unternehmensübergreifenden QM-Prozessen zu einer sys- tematischen Wissensaufbereitung und Wissensverteilung kommen, die einerseits das reaktive Fehlermana- gement (die Beseitigung aufgetretener Fehler) stetig verbessert, andererseits aber auch das proaktive Fehler- management (Fehlervermeidung durch Innovation) unterstützt? • Internalisierung: Wie kann das gewonnene Wissen - sei es formaler oder informeller Natur - effektiv für die Nutzung im Routinebetrieb aufbereitet und verfügbar gemacht werden? 3
  • 4. Wissensumwandlung Schwachstellen Symptome mögliche Maßnahmen Externalisierung Informations-, Ablauf- Arbeit wird nicht oder mehr- Identifikation und Optimie- und Kommunikationslü- fach erledigt, mangelnde rung von Informationsflüs- cken abteilungsübergreifende sen und Arbeitsabläufen Zusammenarbeit durch Analyse und Simulati- on, kooperative Modellie- rung von Schnittstellen Kombination Falsche Software / Isolierte, proprietäre, schwer Integrierte oder integrieren- schlecht organisierte erweiterbare, ineffiziente de Software-Lösungen, Datenhaltung / Daten- und änderungsresistente uniforme Datenhaltung, zugriff Software- oder Daten-Inseln, föderative Informationssys- Produktionsdaten nicht temarchitekturen, Hypertext- menschengerecht aufgear- strukturen, Grafische Anfra- beitet gesprachen Internalisierung Informationsaustausch / Papierflut (nicht aufgaben- Datenbankbasiertes Doku- Informationsüberfrach- spezifisch), Medienbrüche, mentenmanagement ("elekt- tung / Informationsauf- Verlust von Kontextwissen, ronische Umlaufmappen"), bereitung / Schlechte papierbasiert, mangelnder Intranets, Computer-based Kommunikations- und Feedback, schlecht struktu- Learning ("Garten der Ant- Arbeitsablauf- rierte Berichte, Verzögerun- worten"), Service- unterstützung gen, Mißverständnisse orientiertes Workflow- Management Tab. 1: Schwachstellen im Fehlermanagement 3 Unterstützung der Externalisierung: Modellierung va- riantenreicher Produkte Ein zentraler Trend in der Industrie ist das Erlangen von Wettbewerbsvorteilen durch Differenzierung der Pro- duktpaletten und der zugehörigen Produktionsprozesse in immer vielfältigere Varianten, um eine flexiblere An- passung an Kundenwünsche zu erreichen. Im Fehlermanagement ergeben sich daraus zwei Probleme: 1. Die Nachvollziehbarkeit der Produktion jeder Variante erfordert umfangreiche Historiendaten, um speziellen Reklamationen nachgehen zu können. 2. Für die statistische Prozeßkontrolle und Fehleranalyse sind die Grundgesamtheiten zu klein; gleichzeitig sind Fehler, die mehrere Varianten betreffen, nur schwer zu identifizieren. Das Projekt FOQUS hatte sich daher zum Ziel gesetzt, auf der Basis relationaler Produkt- und Prozeßmodelle, die mehr und mehr zum industriellen Standard werden [Klam97], Repräsentationskonzepte und Berechnungsve r- fahren zu entwickeln, die das Arbeiten mit Varianten im Fehlermanagement unterstützen. Der Variantenbegriff ist allerdings in der Fertigung nicht allgemeingültig definiert. Meist bezieht er sich auf die Spezifikation von Produkten einer gemeinsamen Produktklasse, definiert durch ihre Funktion (z.B. Staubsauger). Damit entsteht eine Klassifizierung nach dem wichtigsten Gegenstand der Fertigung, dem Endprodukt. 4
  • 5. Im Fehlermanagement spielen häufig Informationen auf einer anderen Granularitätsebene eine Rolle: Daß der Staubsauger A eine Variante des Staubsaugers B ist, bedeutet nicht notwendigerweise, daß dies auch für die Motoren gilt; denn der Motor kann gerade das Differenzierungskriterium zwischen den Varianten sein. Umge- kehrt kann ein Motor gerade die ‘Variantenhaftigkeit’ von A und B unterstützen, wenn er in beiden Saugern verwendet wird. Die Identifizierung und Nutzung beider Situationen im Fehlermanagement wird in klassischen Modellen nicht unterstützt. Die Verwendung von Fehlerwissen, das für beide Varianten von Bedeutung ist, hängt dann meist von der Erfahrung der Benutzer ab. Ein weiteres Problem besteht darin, daß der Variantenbegriff bei der Nutzung von Fehlerwissen nicht auf das Produkt beschränkt ist, sondern häufig auch von der Produktions- und Nutzungssituation abhängig ist: Produkt- fehler treten bspw. nur dann auf, wenn auf Maschine X produziert wird und/oder die Umgebungstemperatur größer als 40°C wird. Ein solches Fehlerbild kann sich über Produkte erstrecken, die nicht zur selben Produktva- riante gehören. Die kurzen Beispiele zeigen, daß eine differenzierte Betrachtung des Variantenbegriffs im Fehlermanagement notwendig ist. Als Ausgangspunkte für die Definition von Varianten bieten sich fünf Blickwinkel auf Produkte und Prozesse an: 1. Merkmalsausprägungen Produkte oder Prozesse einer Variante unterscheiden sich in der Ausprägung von Merkmalen. Die Merkmalsmenge zur Beschreibung des Produktes stimmt bei allen Produkten überein, aber die Werte, die Merkmale annehmen, können sich unterscheiden. Beispiel ist die Farbe von Fahrzeugen des gleichen Typs. Dabei wird die Farbe, im Gegensatz zur Motorleistung, bei Fahrzeugen kaum zur Variantenbildung herangezogen. Sie kann aber im Fehlermanagement bedeutsam sein, wenn Fehler in der Lackierung nur bei roten Fahrzeugen auftreten. 2. Merkmalsmengen Produkte oder Prozesse einer Variante unterscheiden sich in der Merkmalsmenge. Unterschiede in Merkmalsmengen können aber auch verschiedene Varianten kennzeichnen, wie z. B das Merkmal “Faltdach“ ein Cabriolet von allen anderen Fahrzeugklassen abgrenzt. Die Unterscheidung zwi- schen trennenden und variantenbeschreibenden Merkmalen ist oft ein Gemisch aus standardisierten und unternehmensintern historisch gewachsenen Kriterien. 3. Produktstrukturen Produkte oder Prozesse einer Variante unterscheiden sich durch Unterschiede in der Struktur, d.h. in der Art der Baugruppen (bzw. Prozeßschritte) und ihrem Zusammenwirken. So können bauglei- che Fahrzeuge mit unterschiedlichem Motor als Varianten betrachtet werden, was in der Fahrzeug- industrie üblich ist. Aber daß zwei Produkte sich in einer Baugruppe unterscheiden, bedeutet nicht, daß sie sich in allen Unterbaugruppen unterscheiden. Die Entscheidung über “Variante oder nicht“ kann für jede Baugruppe neu getroffen werden. 4. Produktnutzungsumstände Produkte oder Anlagen werden unter Servicegesichtspunkten auch durch ihre Einsatzumgebung be- schrieben. Um beim Fahrzeugbeispiel zu bleiben, ist die Unterscheidung zwischen Stadtwagen und Langstreckenfahrzeug ein wichtiges Einsatzkriterium, unter dem auch Fahrzeuge unterschiedlicher Typen als Varianten betrachtet werden können. 5
  • 6. 5. Produktionskontext Häufig lassen sich Produktfehler auf einen Fertigungsprozeß oder eine Fertigungsanlage zurück- führen. So können Produkte, die von ihrer Nutzung und ihrem Aufbau her nur wenig miteinander zu tun haben, trotzdem hinsichtlich des Fehlers Varianten voneinander sein, weil sie auf derselben Anlage gefertigt wurden. So könnten verschiedene Kunststoffteile eine hohe Brüchigkeit aufwei- sen, weil sie mit zu geringem Preßdruck an einer bestimmten Maschine gefertigt wurden. Die Identifizierung von Varianten in diesem Fehlerkontextraum verlangt, daß die Repräsentation der zugehöri- gen Daten zwei Voraussetzungen erfüllt: 1. Die Daten über Produkte, Prozesse, Anlagen und Nutzungskontexte müssen so miteinander ver- netzt sein, daß die geschilderten Zusammenhänge nachvollziehbar sind. Das Produkt- und Pro- zeßmodell (PPM), Ergebnis der Forschergruppe WibQuS, leistet dies für die Bereiche Produkt, Prozeß und Anlage [Pfei96]. Das FOQUS-Fehlerdatenmodell verknüpft das PPM mit der Fehler- situation und insbesondere mit den Produktnutzungsumständen. 2. Die Repräsentation und Auswertung von Varianten innerhalb der einzelnen Bereiche Produkt, Prozeß, Anlage und Fehlersituation muß ermöglicht werden. Wie man ermittelt, daß A eine Variante von B ist, hängt von verschiedenen Faktoren ab. Zum einen variiert die Formalisierbarkeit des Konzepts Variante über einem bestimmten Begriffsraum. Zum anderen verändert sich die Bedeutung der Variantenbildung für den Benutzer im Zeitablauf. Diese Überlegungen beeinflussen die Auswahl zwischen den denkbaren Verfahren zur Variantenbildung, von denen zunächst drei in die engere Auswahl ge- nommen wurden: 1. Attributierung Hier wird den Produkten, Prozessen, usw. ein Attribut “Variante_von” zugewiesen, das entweder alle Objekte enthält, die als Varianten gelten sollen oder eines, über das transitiv auf andere Varian- ten geschlossen werden kann. Dieses Verfahren wird angewandt, wenn die Formalisierung des Ähnlichkeitsbegriffs nicht möglich, aber die Erfassung der Ähnlichkeiten von hoher Wichtigkeit ist. Das Verfahren ist bei der Eingabe neuer Objekte sehr aufwendig, da stets der gesamte Objekt- raum auf ähnliche Objekte abgesucht werden muß. 2. Klassifizierung Hier existiert eine Klassenhierarchie, die den Raum der Produkte oder Prozesse vorstrukturiert. Ein neuer Begriff wird dann einer Klasse (oder mehreren in verschiedenen Klassenhierarchien) zuge- ordnet. Varianten sind dann alle Elemente derselben Klasse und möglicherweise die benachbarter Klassen im selben Teil der Klassenhierarchie. Über die Bildung der Klassenhierarchien liegt hier eine implizite Formalisierung des Variantenbegriffs vor, die schon bei der Eingabe zur Benutzer- führung ausgenutzt werden kann. 3. Ähnlichkeitsanalyse Der Variantenbegriff wird nicht explizit in die Repräsentation aufgenommen, d.h. der Benutzer muß bei der Eingabe von Objekten keine Rücksicht darauf nehmen. Auf den gesammelten Daten werden automatische Ähnlichkeitsuntersuchungen (semantische Distanz, statistische Clusteranaly- se) durchgeführt, die dann zur Variantenbildung genutzt werden. Dieser Ansatz ist sinnvoll, wenn entweder die Ähnlichkeit gut formalisierbar ist oder als Rekonstruktionsmittel, wenn zum Design- zeitpunkt des Systems kein Wert auf den Variantenbegriff gelegt wurde. 6
  • 7. Im Projekt FOQUS fiel die Entscheidung zur Variantenrepräsentation für Klassifizierungshierarchien bezüglich der Aspekte Produkt, Prozeß, Anlage und Fehler(kontext). Diese Entscheidung liefert einen akzeptablen Kom- promiß zwischen Aufwand für die Repräsentation, Transparenz des verwendeten Variantenbegriffs und Nutz- barkeit im täglichen Gebrauch: • Zwar müssen die Klassenbäume im Designprozeß aufgebaut und anschließend gewartet werden, doch der Aufwand für den einzelnen Benutzer ist deutlich niedriger als bei der expliziten Attribu- tierung; dort muß beim Einfügen einer neuen Variante stets der gesamte Suchraum nach möglichen Varianten abgesucht werden. Die Gefahr der Unvollständigkeit oder der zu stark subjektiven Ein- ordnung durch den Benutzer wird dadurch gemildert. • Im Vergleich zur Ähnlichkeitsanalyse ist zwar der Aufwand der Variantenverwaltung höher, aber auch die Transparenz der verwendeten Variantenstruktur. Zwar ist die Ähnlichkeitsanalyse objekti- ver (weil indirekter) als die Klassenhierarchiebildung, doch hat diese den Vorteil, daß sie einfach an die Belange des Unternehmens angepaßt werden kann. Schließlich sind die Daten, mit denen gearbeitet werden muß, oft hierarchisch strukturiert und eine Mischung aus numerischen und typi- sierten Daten, die für die Ähnlichkeitsanalyse erst mit hohem Aufwand aufbereitet werden müßten. • Schließlich ist die Bildung von Klassen und die Einordnung von Objekten in diese ein Vorgang, der dem Benutzer natürlich erscheint und dessen Bedeutung sich dem Benutzer mehr oder weniger intuitiv erschließt. Klassifizierungs- und Aggrgationshierarchien lassen sich auf natürliche Weise mit objektorientierten Modellierungskonzepten abbilden. Wie Klassenhierarchien genutzt werden, um nach Varianten zu suchen, sei am folgenden Beispiel näher erläu- tert. Es soll auch zeigen, auf welche Weise die Kopplung von Klassifikationshierarchien mit Aggregationshie- rarchien (Produkt- oder Prozeßbäume) zum einen Zusammenhänge verkompliziert, zum anderen aber auch hilft, die Suche nach ähnlichen Fehlerfällen zu steuern, wenn man eine adäquate Präsentation der Strukturen für den Benutzer findet. Ein Werkzeug, das dies leistet, wird in Abschnitt 5 vorgestellt. Abb. 2 zeigt Produktbäume zu drei Produkten (Staubsauger, Haartrockner und Bohrmaschine), die hinsichtlich der Fehleranalyse zunächst einmal nichts miteinander zu tun haben. Die Dekomposition und ihre Verbindung mit den Klassifikationshierarchien (hier: Motoren und Trafos) zeigt aber auf, wie auf verschiedenen Dekompositi- onsstufen völlig unterschiedliche Variantenbeziehungen bestehen können, die bei der Suche nach Fehlerfällen ausgenutzt werden können: Angenommen, ein Servicetechniker soll bei einem Kunden einen defekten Staubsauger reparieren. Er stellt fest, daß der Fehler im Motor zu suchen ist. Neben verschiedenen Staubsaugern, die den- selben oder einen ähnlichen Motor benutzen, wird ihm außerdem noch ein Haartrockner als Varian- te hinsichtlich des Motors angeboten, weil dieser in einem benachbarten Knoten der Klassenhierar- chie angesiedelt ist. 7
  • 8. Staubsauger Haartrockner Motoren Gehäuse Motor Gehäuse Motor Antrieb Trafos Antrieb Deckel Boden Stromversorgung Träger Auslaß Stromversorgung Welle Rotor Welle Rotor Bohrmaschine Gehäuse Motor Antrieb Körper Bohrkopf Stromversorgung Welle Wicklung Abb. 2: Bezüge zwischen Aggregation und Klassifikation Wird die Fehlerquelle im Laufe der Analyse genauer als die Stromversorgung identifiziert, verändert sich auch der Variantenkontext. Der Haartrockner gehört nicht mehr zu den Varianten hinsichtlich des Trafos, weil dessen Stromversorgung zu einem anderen Teilbaum der Hierarchie “Trafos“ gehört. Statt dessen kommt eine Bohrma- schine zur Menge der Varianten. Mit Hilfe der Aggregationshierarchien läßt sich demnach der Analyseprozeß des Fehlermanagements strukturie- ren. Die Beziehungen zwischen objektorientierten Aggregations- und Klassifikationshierarchien erlaubt eine multidimensionale (Produkt, Prozeß, Anlage, Fehlerkontext) Strukturierung der Analyseschritte unter Ausnut- zung der Variantenbeziehung. 4 Sozialisierungs- und Kombinationsunterstützung durch kooperative konzeptuelle Modellierung Zentrales Ziel bei der Entwicklung von DV-technischen Lösungen für das industrielle Fehlermanagement mit praktischer Relevanz für kleine und mittlere Unternehmen ist die Beseitigung von informationellen, konzeptuel- len und technologischen Barrieren, die Erzeugung und gemeinsame Nutzung von Fehlerwissen in verteilten Fehlermanagementprozessen verhindern. Ein Beispiel soll die Komplexität der Aufgabe ve rdeutlichen. Im Call Center eines Fertigungsbetriebes für Industriegetriebe wird eine Kundenbeschwerde über ein neu erworbenes Getriebe für den industriellen Einsatz aufgenommen. Im konkreten Fall verliert das Getriebe Öl. Aus den bisherigen Erfahrungen des Call Centers kann dieses keinen direkten Ratschlag zur Behebung des Problems geben. Aus diesem Grund wird ein Repara- turauftrag an einen Monteur vergeben. Dieser fährt zum Kunden und versucht, den Fehler vor Ort zu beheben. Er entdeckt, daß die Dichtungsringe des Getriebes an der Antriebswelle nicht korrekt montiert wurden, was die Ursache des Fehlergeschehens ist. Er repariert das Getriebe, indem er neue Dichtringe einsetzt. Um weitere Auf- treten dieses Fehlerbildes in Zukunft zu verhindern, wird die weitere Behandlung dieses Fehlers an die Abteilun- gen im Fertigungsbetrieb weitergegeben, die mit der Behebung des Fehlerbildes an der Quelle, in unserem Fall bei der Montage, verantwortlich sind. Jede verantwortliche Abteilung versucht, die tieferen Ursachen des Feh- 8
  • 9. lerbildes herauszufinden und Abstellmaßnahmen aufgrund der vorgenommenen Analysen zu definieren. Der Erfolg der Maßnahmen muß dokumentiert und an die verantwortlichen Stellen weitergeleitet werden. Nach ve r- schiedenen Annahmen und Versuchen den Fehler an seiner Quelle zu beseitigen, wird schließlich die grundle- gende Ursache ermittelt. Ein Fehler im Montagehandbuch für das Getriebe in der Montageplanung wurde an die Montage weitergeleitet. Die Qualitätskontrolle war nicht in der Lage, den Fehler zu diagnostizieren, weil die Kontrollroutinen nicht effektiv angewendet wurden. Das Beispiel zeigt zwei Typen für Lernen in Organisationen. Auf der einen Seite kann das Call Center über eine schnelle Reparaturmaßnahme unterrichtet werden, auf der anderen Seite können Montageplanung und Qualitäts- kontrolle bei zukünftigen Fertigungsläufen das Problem an der Quelle abstellen. Will man derartige Vorgänge systematisieren, so setzt dies eine formal fundierte Analyse kooperativer Prozesse voraus, die ihrerseits auf gemeinsamen Begriffswelten der Anwendungsdomänen beruhen. In der Literatur wur- den bisher hauptsächlich operationale Kooperationsprozesse untersucht. Dagegen gibt es nur erste Ansätze zur Mitmodellierung des längerfristigen Wissensmanagement [Choo96; Deck96; Pete96]. 4.1 Das Eskalationsprinzip Der Prozeß der Lernens in Organisationen startet mit der Sozialisierung persönlichen, nicht artikulierten Wis- sens. Falls ein Fehler in verschiedenen Abteilungen bearbeitet werden muß, um das Problem zu analysieren und geeignete Abstellmaßnahmen zu definieren, können zwei Probleme beobachtet werden. Zum einen gibt es keine Zuordnung von Verantwortlichkeiten, was zu Verzögerungen in der Bearbeitung eines Fehlerbildes und zur Reduktion der Effektivität der Fehlerbehebung führen kann, zum anderen können Verantwortlichkeiten mehr- fach zugeordnet sein, was zu sich aufschaukelnden Behinderungen im Prozeß führen kann. Um das Wissen um die Verantwortlichkeiten in Fehlermanagementprozessen in der Organisation nutzbar zu mache, wird das Eskala- tionsprinzip für abteilungsübergreifende Prozesse vorgeschlagen. Zielsetzung bei diesem Strukturprinzip ist die geordnete Bearbeitung von Fehlern durch die systematische Identifizierung von Verantwortlichkeitsbereichen. Das Eskalationsprinzip beschreibt somit einen Sozialisierungsmechanismus, der die Bearbeitung von Fehlerbil- dern und den Austausch von Wissen über Fehlern zwischen Verantwortungsbereichen regelt. Die Elemente des Eskalationsprinzips sind in Abb. 3 aufgeführt. Mikro- und Makroprozesse im Fehlermanagement werden wie folgt unterschieden. Mikroprozesse beschreiben Aktionen, die lokal in einem Verantwortungsbereich durchgeführt werden müssen, um das Fehlerbild zu bearbei- ten. Es gibt drei Schritte, die strukturell in jedem Verantwortungsbereich gleich sind, aber für die verschiedene Verantwortungsbereiche abhängig von der lokalen Aufgabe und den Fertigkeiten der Bearbeiter verschieden implementiert sind. 9
  • 10. Abb. 3: Eskalationsprinzip der Fehlermanagements 1. Der Fehlererfassungsschritt Erfassen ist der Prozeß des Informationssammlung und -dokumentation von verfügbaren Fehlerdaten. Auf der einen Seite können diese Daten für automatisierbare Diagnoseprozessen maschinenlesbar aufbereitet sein, auf der anderen Seite können sie dazu dienen, Bearbeiter in späteren Phasen der Eskalation zu unterstützen, die mit dem Fehlerbild arbeiten müssen, ohne die Fakten zu kennen. Der Einsatz von Multimedia zur Ve r- deutlichung des Kontextwissen kann Unsicherheit und Mehrdeutigkeit reduzieren [DaLe86]. Ein Modell zum Einsatz von elektronischen Umlaufmappen [KaRa91] als Kapselungsmechanismus für Kontextwissen kann in [Klam98] nachgelesen werden. 2. Der Fehleranalyseschritt Analysieren ist der Prozeß der Interpretation der verfügbaren Information, um mögliche Ursachen eines Feh- lerbildes zu ermitteln und anwendbare Maßnahmen zu definieren. Wie erwähnt kann dieser Schritt sowohl durch Menschen als auch durch Softwarewerkzeuge unterstützt werden. Falls keine lokale Lösung des Prob- lems möglich ist oder der Bearbeiter weiterreichende Ursachen des Fehlerbildes annimmt, wird das Fehler- bild eskaliert. 3. Der Fehlerkorrekturschritt Korrektur ist der Prozeß der Durchführung und Verfolgung von Abstellmaßnahmen für die Fehlerbehebung. Der Erfolg oder Mißerfolg solcher Maßnahmen wird an alle in der Eskalationskette beteiligten Bearbeiter weitergeleitet. Der Makroprozeß beschreibt Eskalationsschritte. Mit jeder Eskalation wird das Fehlerbild an einen oder mehrere neue Verantwortungsbereiche weitergeleitet. Die Bedingungen für die Weiterleitung legen manchmal langfristi- ge Abmachungen zwischen Abteilungen fest, die in kooperativ erstellten Modellen dokumentiert sind; alternativ können sie zum Zeitpunkt der Weiterleitung verhandelt werden. Der letztere Ansatz ist unter dem Stichwort serviceorientierte Workflows bekannt [Flor88; Medi92; Schä96]. Beispielhaft sei hier das System Coordinator von Action Technologies Inc. genannt. Allerdings fokussieren diese Ansätze auf den formalen Vertragsabschluß zwischen Kunden und Anbietern von Dienstleistungen und beziehen kaum das notwendige Kontextwissen ein. 10
  • 11. 4.2 Formale Modellierung der Interaktionen Die Organisationsstruktur des Eskalationsprinzips ist nicht externalisiert und deshalb noch nicht ausreichend, um das Wissen entlang der Eskalationsketten gemeinsam zu nutzen. Im folgenden wird eine Modellierungstechnik vorgestellt, die es ermöglicht, aufgrund formaler Prozeßbeschreibungen das gemeinsam nutzbare Wissen zu externalisieren. Abb. 4: Metamodell des Organisationsgedächtnisses Um sowohl Mikro- als auch Makroprozesse zu beschreiben, die sowohl die Weitergabe notwendigen Kontext- wissens entlang der Eskalationskette sichern als auch eine Repräsention des Organisationsgedächtnisses darstel- len, ist eine formale Beschreibungssprache notwendig. Der Kern der Sprache bildet ein Prozeßmodell, das von McMenamin und Palmer [McPa84] vorgeschlagen wurde. Eine Eingabe (hier ein Objekt) wird von einem Sys- tem konsumiert und manipuliert, wodurch eine Ausgabe produziert wird. Das System wird in diesem Fall durch Prozesse beschrieben, die Arbeits- und Informationsflüsse darstellen. Bearbeitet werden die Prozesse durch A- genten, die von Werkzeugen unterstützt werden. Die formale Sprache ist in der Wissensrepräsentationssprache Telos [Mylo90] definiert. Sie verfolgt drei Zwe- cke: (1) Definition des Informations- und Arbeitsflusses von Fehlermanagementprozessen, (2) Definition von Schnittstellen für abteilungsinterne und abteilungsübergreifende Koordination und Kommunikation, (3) Spezifikation für die Implementierung oder Wiederverwendung von Werkzeugen in den einzelnen Mikroprozessen sowie von Workflows auf der Makroprozessebene, die durch Workflowtechnolo- gie unterstützt werden können. 11
  • 12. Abb. 5: Beispiel für autonom erstellte Mikroprozesse Der eigentliche Modellierungsprozeß wurde durch das Meta-Datenbankmanagementsystem ConceptBase [Jark95; Jarke97] unterstützt, das zum einen als konzeptuelles Modellierungswerkzeug dient, aber auch das Re- pository für das Organisationsgedächtnis auf der Schemaebene darstellt. Abb. 4 zeigt den Bildschirmabzug der ConceptBase-Definition der oben beschriebenen Sprache. Mit formalen Konfliktlösungstrategien, die in Con- ceptBase realisiert sind, konnten die in Fallstudien von den Abteilungen autonom erstellten Prozesse zu Makro- prozessen mit definierten Schnittstellen integriert werden. In Abb. 5 sind drei Mikrologiken (Reklamationserfas- sung im Call Center, Reklamationsbearbeitung durch einen Serviceingenieur und eine FMEA-Sitzung aus dem Bereich Produktentwicklung) abgebildet. Das Ziel der Modellierung ist die Integration dieser Prozesse, um kurz- fristige reaktive Prozesse mit langfristigen Verbesserungsprozessen in der Produktentwicklung zu koppeln. Die Beschreibung und Integration der autonomen Mikroprozesse sichert ein gemeinsames Verständnis über verwe n- dete Konzepte und Workflows, das auch gekoppelte Informationssysteme mit definierten Schnittstellen zwischen einzelnen Verantwortungsbereichen definiert sowie Bearbeiter für Aufgaben des Fehlermanagement und das austauschbare Wissen zwischen Verantwortungsbereichen in jedem Eskalationsschritt identifiziert. Mit der Sprache kann eine formale Repräsentation eines Organisationsgedächtnisses konstruiert werden. Die Reorganisation von Arbeits- und Informationsflüssen kann auf Basis der Organisationsgedächtnisses geplant werden, Änderungen werden im Repository widergespiegelt. Effekte der Fluktuation von Personal und technolo- gische Änderungen werden durch die Verknüpfung der Konzepte Agent, Prozeß und Werkzeug gemildert. 5 Internalisierung: Werkzeuge zur Weitergabe und Nut- zung von Wissen Basierend auf der Spezifikation der abteilungsinternen und abteilungsübergreifenden Workflows und Informati- onszugriffe kann die Internalisierung des Wissens in die Arbeitspraxis durch ein Workflow-Managementsystem 12
  • 13. (WFMS) unterstützt werden. Dieses nutzt die explizite Darstellung des Organisationsgedächtnisses, um die Workflows und Informationsflüsse auf definierte Weise zu operationalisieren. Eine ausführliche Darstellung dieses Internalisierungspfades ist in [Klam98] zu finden. Abb. 6: Garten der Antworten Einen anderen Weg der Internalisierung von sozialisiertem, externalisiertem und kombiniertem Wissen beschrei- tet das computergestützte Training. Im Projekt FOQUS wurde die "AnswerGarden"-Metapher [AcMa90; AcMc96] genutzt, um die unternehmensweite Nutzung von multimedial repräsentiertem Wissen zu ermöglichen. Die Metapher des "Garten der Antworten" ist dem Wildwuchs der World Wide Web direkt entgegengesetzt. Wie in einem Garten werden Wege zu interessanten Plätzen im Organisationsgedächtnis angelegt und in Systemen von Webseiten abgebildet. So können die Benutzer im Intranet auf diesen Wegen "wandeln". Im Projekt FOQUS sind es Fehlerfälle, die über auf konzeptuellen Variantenmodellen basierenden Zugriffspfade erreicht werden, um bspw. bei der Neukonstruktion einer Variante schon auf das Fertigungswissen anderer Varianten zurückgrei- fen zu können (Abb. 6). Falls die Wege im Garten dem Benutzer nicht erfolgversprechend erscheinen oder er keine dokumentierten Fehlerfälle zu seinem Problem findet, kann er auf jeder Seite eine elektronische Nachricht zu dem im Sinne der Eskalation verantwortlichen Bearbeiter schicken. Diese Zuordnung wurde durch die Exter- nalisierung in der Repräsentation des Organisationsgedächtnisses erreicht. 13
  • 14. Abb. 7: Matrixwerkzeug zur Fehlerdatensuche Die Metapher “Suchen nach Fehlerdaten“ geht davon aus, daß die Daten zu Fehlerfällen in einer expliziten Hie- rarchie von Varianten abgespeichert sind (vgl. Abschnitt 3). Auf diese Daten kann mit einer Datenmanipulati- onsprache zugegriffen werden. Im Projekt FOQUS ist dies die Sprache SQL. Da der Aufwand zum Erlernen dieser Sprache von Benutzern im FM nicht erwartet werden kann, wurde mit dem sogenannten Matrixwerkzeug eine geeignete Präsentationsform für Anfragen auf der Hierarchie der Varianten entwickelt, die an einem konkre- ten Anwendungsszenario beschrieben werden soll (vgl. Abb. 7). In der Montage eines bestimmten Getriebes sind Probleme beim Zusammenschrauben der Gehäuseteile entstan- den. Der Bearbeiter will nun Daten zu ähnlichen Fehlerfällen gewinnen. Ihn interessieren also Fehlerfälle zu geometrischen Attributen. Zusätzlich will der Bearbeiter den Suchraum auf bestimmte Produkte - Getriebetypen mit diesem Gehäusen - und bestimmte Prozesse bzw. Anlagen, auf denen diese Gehäuse gefertigt sind, ein- schränken. Im mittleren Teil des Bildes befindet sich eine Matrix, welche die Variationsmöglichkeiten Struktur, Produkt und Prozeß/Anlage abbildet. Der Benutzer will Fehlerdaten zu den Attributen Länge, Höhe, Breite, Material und Maße zu einem Produkt Getriebe mit einem bestimmten Gehäuse (P = Part of) ermitteln. Dazu weiß er, daß Getriebe YZ eine Variante dieses Getriebes ist. Zusätzlich trägt er ein, daß nur Fehlerfälle ausgegeben werden sollen, die mit Prozeß B (M = made with) auf Anlage B (W = worked on) gefertigt wurden. Drückt der Anwe n- der nun den Knopf “Abfrage starten“ im oberen Bereich des Werkzeuges, wird aus dieser matrixbasierten Kon- figuration der Anfrage eine SQL-Anfrage erzeugt, die alle Fehlerfälle zurück liefert, die dieser Beschreibung entsprechen. Diese Fälle werden in einem weiteren Fenster für den Benutzer aufbereitet. 6 Erfahrungen und Ausblick In dieser Arbeit wurde ein Rahmenwerk für die Unterstützung von Lernprozessen in Organisationen durch rech- nergestütztes Fehlermanagement vorgestellt. Dieser Ansatz wurde in der Demonstrationsfabrik Aditec an der 14
  • 15. RWTH Aachen implementiert. Die Ingenieure der Aditec konstruierten mit Hilfe der im Projekt entwickelten Werkzeuge ein einfaches, aber voll funktionsfähiges Getriebe für den industriellen Einsatz in mehreren Varian- ten. Die Getriebevarianten wurden in der Aditec in kleiner Stückzahl gefertigt und montiert [Pfei97]. Ingenieure, Arbeiter und Kunden entdeckten und bearbeiteten eine Reihe von Fehlern, die innerhalb der 15-monatigen Lauf- zeit des Projektes in einer Wissensbank dokumentiert wurden. Wiederholfehler konnten signifikant reduziert werden, was auch durch weitere Fallstudien bei Industriepartnern belegt werden konnte. Einige der dokumentierten Fehlerbilder offenbaren deutlich die komplexe und verteile Natur eines Fehlerge- schehens. In einem Fall konstruierte ein Ingenieur die Antriebswelle für eine Getriebevariante. Anschließend schrieb er eigenhändig ein NC-Programm zur Fertigung der Welle. Jedoch war es nicht möglich, mit diesem NC- Programm die Welle auf der Drehmaschine der Aditec zu fertigen. Der Werkzeugrevolver mit der Wende- schneidplatte kam beim Schruppvorgang zu nahe an den Reitstock der Maschine, so daß der Maschinenbediener den Drehvorgang aus Sicherheitsgründen abbrechen mußte, um eine Kollision zu vermeiden. Dies kennen die Maschinenbediener aus ihrer Praxis; es wurde aber vom Ingenieur übersehen, der nicht mit dem Reitstock der Drehmaschine vertraut war. Die Lösung, die letztendlich realisiert und dokumentiert wurde, war, beim Schrupp- vorgang weniger Material und beim Schlichten mehr Material bei einer geringeren Schnittiefe wegzunehmen. Ein neues Projekt mit der Aditec soll die Frage klären, ob die erfolgreiche Unterstützung von Fehlermanage- mentprozessen auch auf die Kernprozesse der Aditec - Fertigung und Schulung - ausgedehnt werden kann. Vor- stellbar sind auch Prozesse im Bereich der Dienstleistungen oder der Software-Entwicklung. Danksagung Das FOQUS-Projekt wurde vom BMBF im Rahmen des Programms "Produktion 2000" gefördert. Die Projekt- partner am WZL der RWTH Aachen (Prof. Dr. Dr.h.c. T. Pfeifer) und am IBK der Universität Kaiserslautern (Prof. Dr. Dr.h.c. G. Warnecke) haben wesentliche Beiträge zur Konzeption und Realisierung spezieller Kompo- nenten für das interne und externe Fehlermanagement im Rahmen der hier beschriebenen Gesamtarchitektur geleistet. Besonderer Dank gebührt auch Dr. Peter Peters, der bis zu seinem Wechsel zu McKinsey&Co. die Arbeiten am Lehrstuhl für Informatik V koordinierte. 7 Literatur [AcMa90] Ackerman, M. S.; Malone, T.: Answer Garden: A Tool for Growing Organizational Memo- ry. In: Proc. of ACM Conf. on Office Information Systems, 1990, S. 31-39. [AcMc96] Ackerman, M.S.; McDonald, D.W.: AnswerGarden2: Merging Organizational Memory with Collaborative Help. In: Cooperating Communities: Proceedings ACM Conference on Computer- Supported Cooperative Work (Cambridge, Mass.), New York: ACM Press, 1996, S. 97-105. [ArSc78] Argyris, C.; Schön, D.: Organizational Learning: A Theory of Action Perspective, 1978. [Choo96] Choo, C.: The Knowing Organization: How Organizations Use Information to Construct Meaning, Create Knowledge, and Make Decisions. In: International Journal of Information Mana- gement, 16(5), 1996, S. 329-340. [DaLe86] Daft, R.; R. Lengel R.: Organizational Information Requirements, Media Richness and Structural Design. In: Management Science, 32(5), 1986, S. 554-571. 15
  • 16. [Deck96] Decker, S. et al.: A Unifying View on Business Process Modeling and Knowledge Enginee- ring. In: Proceedings 10th Knowledge Acquisition Workshop, Banff, Canada, University of Calga- ry, 1996, S. 34/1-34/16. [Dodg93] Dodgson, M.: Organizational Learning: A Review of Some Literatures. In: Organizational Studies 14(3), 1993, S. 375-394. [Flor88] Flores, F. et al.: Computer Systems and the Design of Organizational Interaction. In: ACM Transactions on Information Systems 6(2), 1988, S. 153-172. [Hube91] Huber, G.: Organizational Learning: The Contributing Processes and the Literatures. In: Organization Science, 2(1), 1991, S. 88-115. [Jark95] Jarke, M. et al.: ConceptBase - a Deductive Object Base for Meta Data Management. In: Journal of Intelligent Information Systems, 4(2), 1995, S. 157-192. [Jark97] Jarke, M. et al.: Coordinating Distributed Organizational Knowledge. In: Data & Knowledge Engineering, 23(3), Sep. 1997, S. 247-268. [KlJa97] Klamma, R..; Jarke, M.: Supporting Organizational Learning Processes through Failure Ma- nagement. In: Proceedings of the 7th International Workshop on Information Technologies and Systems (WITS'97), Atlanta, Georgia, USA, Dezember 1997, S. 66-71. [Klam97] Klamma, R.. et al.: Eine Untersuchung der DV-Unterstützung von Informations- und Ar- beitsflüssen im Qualitätsmanagement bei kleinen und mittleren Unternehmen der Fertigungsindust- rie. In: Proceedings des EMISA-Fachgruppentreffens über Workflows, Bonn, Gesellschaft für In- formatik, 1997, S.70-80. [Klam98] Klamma, R.. et al.: Workflow Support for Failure Management in Federated Organizations. In: Proceedings of 31st Hawai'i International Conference on System Sciences, IEEE Computer So- ciety Press, 1998, S. 302-311. [KaRa91] Karbe, B.; Ramsperger, N.: Concepts and Implementation of Migrating Office Processes", In: Brauer, W.; Hernandez D. (Hrsg.): Verteilte künstliche Intelligenz und kooperatives Arbeiten, Berlin, 1991, pp. 136-147. [Maso93] Mason, R.: Strategic Information Systems: Use of Information Technology in a Learning Organization. In: Proceedings of 26th Hawai'i International Conference on System Sciences, 1993, S. 840-849. [McPa84] McMenamin, S.M.; Palmer, J.F.: Essential System Analysis, 1984. [Medi92] Medina-Mora, R.. et al.: The Action Workflow Perspective to Workflow Management Technology. In: Proc. 4th CSCW Conf., Toronto 1992, S. 281-288. [Mylo90] Mylopoulos, J. et al.: Telos - a Language for Representing Knowledge about Information Systems. In: ACM Transactions on Information Systems, 8(4), 1990, S. 325-362. [Nona94] Nonaka, I.: A Dynamic Theory of Organizational Knowledge Creation. In: Organization Science, No. 1, 1994, S. 14-37. [Pete96] Peters, P.: Planning and Analysis of Information Flow in Quality Management, Dissertation, RWTH Aachen, 1996. 16
  • 17. [Pfei96] Pfeifer, T. (Hrsg.): Wissensbasierte Systeme in der Qualitätssicherung, Berlin, 1996. [Pfei97] Pfeifer T. (Hrsg.): Fehlermanagement mit objektorientierten Technologien in der qualitätsori- entierten Produktion. Forschungszentrum Karlsruhe, FZKA-PFT 183, 1997. [Schä96] Schäl, T.: Workflow Management Systems for Process Organizations. LNCS 1096 (Diss. RWTH Aachen 1995), Berlin, 1996. [Warg97] Wargitsch, C. et al.: WorkBrain: Merging Organizational Memory and Workflow Manage- ment Systems. In: Proc. of Workshop Knowledge-Based Systems for Knowledge Management in Enterprises, 9-12. September, Freiburg, 1997. 17