Das BMBF-Projekt FOQUS zielte darauf ab, die Handhabung von Varianten im Fehlermanagement durch neuartige Repräsentationskonzepte und Berechnungsverfahren zu unterstützen, um Abweichungen von Unternehmensleistungen als Chancen für Prozessverbesserungen und Innovationen zu nutzen. Es wurden Werkzeuge entwickelt, die den Austausch von Fehlerwissen erleichtern und bei der Anwendung von Workflowmanagementsystemen helfen, um das Lernen in Organisationen zu fördern. Die Umsetzungen in der Aachener Musterfabrik zeigen, dass diese Ansätze das Fehlermanagement in der realen Praxis erfolgreich unterstützen können.

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