Driving the Organizational Learning Cycle: The Case of Computer-Aided Failure Management
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,666 views

Nonaka describes the process of creating knowledge in enterprises as an interplay of tacit and explicit knowledge. In the interdisciplinary German FOQUS project, industrial engineers and computer ...

Nonaka describes the process of creating knowledge in enterprises as an interplay of tacit and explicit knowledge. In the interdisciplinary German FOQUS project, industrial engineers and computer scientists have investigated information systems support for this process in the context of a specific knowledge creation strategy, "learning from failures". In the domain of failure management for complex production machinery, Nonaka’s socialization is supported by service-oriented workflows, externalization is supported by a
domain-oriented meta model facilitating the construction of failure models, combination and internalization are supported by formal conflict resolution techniques and informal hypermedia representations. All of these representations are held in a knowledge-based repository. An implementation of the approach is operational in the Aditec demonstration factory at Aachen.

Statistics

Views

Total Views
1,666
Views on SlideShare
1,666
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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