Vernetztes Verbesserungsmanagement mit einem Unternehmensgedächtnis-Repository

Transkript

1 Vernetztes Verbesserungsmanagement mit einem Unternehmensgedächtnis-Repository Von der Fakultät für Mathematik, Informatik und Naturwissenschaften der Rheinisch-Westfälischen Technischen Hochschule Aachen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften genehmigte Dissertation vorgelegt von Diplom-Informatiker Ralf Klamma aus Bardenberg, jetzt Würselen Berichter: Universitätsprofessor Dr. Matthias Jarke Universitätsprofessor Dr. Klaus Henning Tag der mündlichen Prüfung: 31. August 2000 D 82 (Diss. RWTH Aachen)

2

3 Danksagung Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Lehrstuhl für Informatik V der RWTH Aachen. Zu Beginn möchte ich denjenigen Personen danken, mit denen ich während dieser Zeit zusammenarbeiten durfte. Ihre zahlreichen fachlichen und persönlichen Beiträge, Diskussionen und Gespräche haben Einfluß auf meine Arbeit genommen. Mein Dank gilt besonders Prof. Dr. Matthias Jarke, der mir die Durchführung dieser Arbeit ermöglichte und mich in allen Belangen leitete und unterstützte; Prof. Dr. Klaus Henning für das Interesse an der Arbeit und die Bereitschaft, das Koreferat zu übernehmen; meinen Kollegen am Lehrstuhl, Dr. Bettina von Buol, Dr. Ralf Dömges, Peter Haumer, Stefanie Kethers, Jörg Köller, Thomas List, Dr. Peter Peters, Prof. Dr. Klaus Pohl, Christoph Quix, Dr. Mareike Schoop, Stefan Sklorz, Dr. Peter Szczurko und Klaus Weidenhaupt für die vielen Diskussionen und die gute Zusammenarbeit; den Studenten und Diplomanden, Axel Stolz, Sylvia Schlaphof, Uwe Katzke, Steffen Pohlen, Wolfgang Thyen, Wolfram Hußmann, Nico Hamacher und Georg Lietz für die Realisierung der Systeme und ihre konstruktive Mitarbeit; Gabriele Höppermanns und Irene Wicke für die ermüdenden Korrekturen und manches mehr; den Kollegen und Mitarbeitern im Projekt FOQUS, Dr. Peter Peters und Dr. Peter Szczurko, beim Lehrstuhl für Fertigungsmeßtechnik und Qualitätsmanagement des WZL der RWTH Aachen, beim Lehrstuhl für Fertigungtechnik und Betriebsorganisation FBK der Universität Kaiserslautern und bei den Firmen Plato, Ideal Standard, Sartorius und ADITEC ggmbh; Franz-Josef Stepprath von der ADITEC ggmbh für seine Bereitschaft, Dinge mit mir auszuprobieren; den Veranstaltern und Teilnehmern des Doktorandenseminars der WI 99 für die konstruktiven Diskussionen und dem Sponsor für die freundliche Übernahme der Kosten; allen übrigen Mitarbeiterinnen und Mitarbeitern, studentischen Hilfskräften und Diplomanden am Lehrstuhl für das angenehme Arbeitsklima und ihre Unterstützung; meinen Eltern; Michaela, Zooey und Donna für ihre Liebe und ihr Verständnis. Manches kann man nicht verbessern. Aachen, im Mai 2000 Ralf Klamma

4

5 Kurzfassung Das nachhaltige vernetzte Verbesserungsmanagement (VVM) betrachtet Fehlerwissen als primäre Wissensquelle für Verbesserungen an Produkten und Prozessen in Unternehmen. Dieses Fehlerwissen ist innerhalb und außerhalb der Unternehmen verteilt und seiner Nutzung stehen Barrieren entgegen, die es zu überwinden gilt. Daher geht diese Arbeit vornehmlich drei Fragestellungen nach: Wie kann Fehlerwissen entlang eines verteilten Produktlebenszyklus gesammelt und trotz der bestehenden räumlichen, zeitlichen und konzeptuellen Barrieren auch genutzt werden? Wie kann Fehlerwissen organisiert werden, so daß auch in einer von Variantenvielfalt geprägten Produktion trotz der resultierenden Komplexität des Wissens aus Fehlern gelernt werden kann? Wie sollen Verbesserungsprozesse gestaltet werden, so daß eine verteilte Bearbeitung von Fehlerwissen ermöglicht und unterstützt wird? Aufgrund eines Wissenstransformationsansatzes wird die nachhaltige Organisation von Fehlerwissen trotz des auf Unternehmen lastenden vielfältigen Änderungsdrucks durch die prozeß- und variantenorientierte Speicherung von Fehlerwissen in einem Unternehmensgedächtnis-Repository geleistet. Dieses Repository aktiviert die vernetzte Nutzung von Fehlerwissen in virtuellen Verbesserungsteams, die bei der koordinierten Bearbeitung von Fehlerfällen im Unternehmen unterstützt werden. Der Ansatz bildet die Grundlage für den Entwurf und die Realisierung eines VVM-Systems und die Umsetzung in Software-Werkzeuge für das Reklamationsmanagement. Diese Systeme werden in Fallstudien evaluiert. Die Arbeit trägt mit ihren Ergebnissen zur Konservierung von Fehlerwissen, zur Nachvollziehbarkeit von Wissenstransformationen, zur Förderung des Wissenstransfers, zur Koordinationsunterstützung für verteiltes Arbeiten und zur aufgabenspezifischen Bearbeitung von Fehlerfällen bei.

6

7 Abstract Networked improvement management is defined as the systematic collection and use of failure knowledge in the distributed product cycle. To have failure knowledge is to know what is not right or what one must not do. Failure knowledge is acquired in the process of handling customer or production problems. The knowledge need to be transferred between organisational units, between competencies, and between processes. Primary research questions could be formulated as follows: How can an organisation overcome spatial, temporal, and conceptual barriers for collecting and using failure knowledge in the distributed product life cycle? How can an organisation organise failure knowledge in an organisational memory repository to enable and enhance learning in a complex variant oriented production environment? How can an organisation model improvement processes to support the distributed handling of failure cases? The thesis deploys a knowledge transformation approach to construct an organisational memory repository. The repository allows the process oriented storage of failure cases and considers the change pressures in knowledge intensive companies. The repository plays also an active part in networking virtual improvement teams. These teams are supported in the coordinated handling of failure cases. The repository approach has been realised in a software tool suite and evaluated in case studies. Thesis findings contribute to the conversation of failure knowledge, traceability of knowledge transformations, encouragement of knowledge transfer, coordination support for distributed work, and task specific handling of failure cases.

8

9 Inhaltsverzeichnis 1Einleitung Problembeschreibung Fokus und Ziele der Arbeit Aufbau der Arbeit Begrifflichkeiten des Verbesserungsmanagements Qualität und Fehler Produktlebenszyklus Beherrschung von Variantenreichtum Prozeß- und Kundenorientierung Team- und Wissensorientierung Fallstudie: Navigation in Fehlerfällen Fallstudie: Lenkung fehlerhafter Produkte Fallstudie: Fehlererfassung in der Fertigungskette Zusammenfassung Nachhaltigkeit und Vernetzung Dynamische Wissensumwandlung Modi der Wissenstransformation Fehlerwissen Typen von Fehlerereignissen Implizites und explizites Wissen

10 ii INHALTSVERZEICHNIS 3.2 Lernen im Verbesserungsmanagement Nachhaltigkeit Kooperative Informationssysteme im VVM Ansätze zur kooperativen Informationssystementwicklung Bedrohungen der Nachhaltigkeit Kopplung operativer Prozesse mit dem Gedächtnis Unternehmensgedächtnis Mnemonische Prozesse auf Unternehmensgedächtnis-Systemen Rollen in mnemonischen Prozessen Fehlerstrukturwissen Variantenbegriff Repräsentation von Varianten Vernetzung Beschreibungselemente des Eskalationsmodells Service-orientierte Workflows Rollen in E skalationen Replizierte elektronische Vorgangsmappen E skalationsstrategien Gesamtansatz des nachhaltigen vernetzten Verbesserungsmanagements Zusammenfassung Rechnergestütztes Verbesserungsmanagement in der Praxis Aufbau und Durchführung der Befragung Bedeutung des Fehlermanagements Ist-Situation des Fehlermanagements Detailanalyse der DV-Organisation Grad der DV-technischen und organisatorischen Vernetzung Informationsflüsse im Fehlermanagement Arbeitsflüsse im Fehlermanagement

11 INHALTSVERZEICHNIS iii Datenhaltung im Fehlermanagement Softwarenutzung im Fehlermanagement Defizite in der DV-Organisation des Verbesserungsmanagements Zusammenfassung Informationssysteme im Verbesserungsmanagement Workflow-gestützte Helpdesk-Systeme Repository-Technologien für das VVM WibQuS: Repository und Qualitäts-Trader FOQUS: Kooperative Modellierung von Arbeits- und Informationsflüssen Nachhaltige Bewahrung aktivitätsorientierten Wissens Verknüpfung im Rahmen kooperativer Informationssysteme Gestaltung der Wissensbasis Gestaltung mnemonischer Prozesse Analyse und Bewertung existierender Lösungen Versionierung und Konfiguration replizierter Vorgangsmappen Versionierung der Vorgangsdurchführung Aufgaben- und rollenspezifische Unterstützung Replikation Analyse und Bewertung existierender Lösungen Untersuchung von Systemen zur Versionierung und Konfiguration Zusammenfassung Ein nachhaltiges vernetztes Verbesserungsmanagement-System Architektur eines VVM-Systems Ein Unternehmensgedächtnis-Repository fürdasvvm Gesamtdarstellung des Repositories Anpassungen des fokussierten M 2 -Modells Aufgaben des Unternehmensgedächtnis-Systems

12 iv INHALTSVERZEICHNIS Ein Metamodell für das Unternehmensgedächtnis-System Aufbau elektronischer Vorgangsmappen Fehlermappenmodell Fehlerdatenmodell Versionierung und Konfiguration replizierter Vorgangsmappen Versionierung Konfiguration Replikation Mnemonische Prozesse Generierung von Wissensprofilen Modellierung zur Laufzeit Ein Mappenmanager fürelektronischevorgangsmappen E in Anfragemanager Zusammenfassung Evaluierung des Ansatzes Evaluierungsmodell Fallstudie: Reklamationsmanagement im Anlagenbau Fallstudie: Verbesserungsmanagement heterogener Computernetze Fallstudie: Verbesserungsmanagement des Seminarbetriebs Zusammenfassung Zusammenfassung und Ausblick E rgebnisse Bewertung Weiterführende Forschungsarbeiten

13 Abbildungsverzeichnis 1.1 Lernen aus Fehlerwissen als Basis für Wettbewerbsvorteile (adaptiert aus [ZHB99]) Lebenszyklus industrieller Produkte E FQM Portfolio: Methoden des Verbesserungsmanagements Garten der Antworten - Bruch des Stirnrads Garten der Antworten - Bruch einer Wendeschneidplatte Modi der Wissensumwandlung (adaptiert aus [NT95]) Fehlerereignisse als Wissensquelle Fehlertypen (adaptiert aus [Dha98]) Archetypisches Modell westlicher Wissensgenerierungsprozesse nach Hedlund und Nonaka [HN93] (adaptiert aus [Wie96, S. 258]) Archetypisches Modell japanischer Wissensgenerierungsprozesse nach Hedlund und Nonaka [HN93] (adaptiert aus [Wie96, S. 258]) Kooperative Informationssysteme (adaptiert aus [DMDJ + 97]) Globales Vorgehensmodell für die Gestaltung informationssystem-gestützter Organisationsstrukturen (adaptiert aus[jab97, S. 8]) Gedächtnis des Verbesserungsmanagements als kooperatives Informationssystem Einordnungsschema für Unternehmensgedächtnisse Gozintograph für zwei Endprodukte (adaptiert aus [Sch88]) Produktmodell für Mechanikprodukte (adaptiert aus [RG91])

14 vi ABBILDUNGSVERZEICHNIS 3.12 E skalationsmodell (adaptiert aus [KPJ00]) Verteilte Prozeßorganisation (adaptiert aus [Sch96a]) Darstellung service-orientierter Workflows Workflow-Modell des vernetzten Verbesserungsmanagements E lektronische Vorgangsmappe System zur Fehlerfallbearbeitung - Anwendungsszenarien Rahmenwerk des nachhaltigen vernetzten Verbesserungsmanagements im Überblick Anregungen für ein Verbesserungsmanagement der Zukunft (adaptiert aus [Pfe97]) DV-Organisation im Fehlermanagement Informationsaustausch im Fehlermanagement Arbeitsflüsse im Fehlermanagement Softwarenutzung im Fehlermanagement Modell eines Helpdesk-Systems Häufigkeit der untersuchten Werkzeuge in kommerziellen Systemen Durchschnittliche Abgeschlossenheit der E benen IRDS Rahmenwerk für Repository-Gestaltung WibQuS Metamodell zur Integration von Methoden (adaptiert aus [Pet96, Szc96]) WibQuS Trader Architektur (adaptiert aus [Szc96]) FOQUS-Sprachmodell (adaptiert aus [KPJ98]) Modell zur Informationsflußanalyse (adaptiert aus [KPJ98]) Alternative graphische Palette (ConceptBase-Bildschirmabzug) Beispiel Reklamationsbearbeitung (ConceptBase-Bildschirmabzug) Verknüpfung der Mikroprozesse (ConceptBase-Bildschirmabzug) Strukturierte Informationsflüsse (ConceptBase-Bildschirmabzug) Arbeitsflüsse (ConceptBase-Bildschirmabzug) Zusammenführen verschiedener Datentypen

15 ABBILDUNGSVERZEICHNIS vii 5.15 Rollenspezifische Konfiguration Architektur des Verbesserungsmanagements (adaptiert aus [KPJ98]) Gesamtdarstellung des Repositories Metamodell nach Ramesh (adaptiert aus [Ram97]) Unterstützung von Aufgaben und Dokumenten Mnemonische Prozesse und Geschäftsprozesse als Objekte des Unternehmensgedächtnisses Wissensagenten nutzen mnemonische Prozesse Geschäftsprozesse Gesamtmodell im Überblick Metamodell nach Deiters (adaptiert aus [Dei97]) Vorgangs-Prozeßmodell des VVM Rollenmodell Fehlerdatenmodell Vorgangsmappe - Version - Bearbeiter Versionierung von Vorgangsmappen E R-Modell der Versionsinformationen Abbildung von Versionen in Tabellen der relationalen Datenbank Konfigurationsmodell für Vorgangsmappen Replikationsmechanismus Beispiele für Wissensträgerkarten Wissensprofil eines Mitarbeiters im Unternehmensgedächtnis-System (Bildschirmabzug) Prozeßablauf aus Sicht des Koordinators Prozeßablauf aus Sicht des Durchführers Prozeßablauf aus Sicht des Prüfers Prozesse Formatvorlage erzeugen und Montagebuch ändern Mnemonischer Prozeß Asking an Expert Mnemonischer Prozeß Akquisition

16 viii ABBILDUNGSVERZEICHNIS 6.27 Möglichkeiten bei der Weiterleitung Architektur der VVM Arbeitsplätze Interaktion beim Laden einer Mappe Interaktion beim Weiterleiten einer Mappe Interaktion beim Beobachten einer Mappe Mappenwerkzeug - Versionsübersicht (Bildschirmabzug) Versionsgraph (Bildschirmabzug) Variantenorientiertes Suchwerkzeug für Fehlerfälle (Bildschirmabzug) Beziehungen zwischen Aggregations- und Klassifikationshierarchien Designstudie für einen phasenorientierten Analyseprozeß (Bildschirmabzug) Evaluierungsmodell für VVM nach [MKP97] Ermittlung der unternehmensspezifischen Werkzeugbedeutung durch paarweisen Vergleich (Ausschnitt aus der Gesamttabelle) Vergleich von HDS mit den Anforderungen des E benenmodells Fehlerfallbearbeitung im Verbesserungsmanagement Strukturierte Eingabe von Wissen (Bildschirmabzug) Kontextualisierte Wissensspeicherung in einem Unternehmensgedächtnis- System

17 Tabellenverzeichnis 2.1 E rzeugnisspektrum von 349 befragten Unternehmen Herausforderungen an Lenkung fehlerhafter Produkte Kategorien der Fehlerfallerfassung in der Schleiferei Herausforderungen an Fehlererfassung in Prozeßketten Mnemonische Prozesse in der Literatur Prozesse der Wissenssuche und -wiedergewinnung (adaptiert aus [O L98a]) Verkaufsregionen von 349 befragten Unternehmen Herausforderungen in der DV-Unterstützung des VVM E bene 0 - Workflow-Kern Ebene 1 - Minimaler Helpdesk Ebene 2 - Vollständige Information E bene 3 - E rweiterter Workflow E bene 4 - E xterner Zugriff Erweiterungsmöglichkeiten Untersuchte Unternehmensgedächtnis-Systeme Anforderungen Untersuchte Systeme Anforderungen Vorgangsmappensegmente Software-Werkzeugtypen Rechteprofile

18 x TABELLENVERZEICHNIS 7.1 Herausforderungen im Reklamationsmanagement E inzelgewichte zum paarweisen Vergleich von Werkzeugen Herausforderungen an die Systemadministration Benutzungshäufigkeit des Systems Herausforderung an ein Unternehmensgedächtnis-System Benutzungshäufigkeit des Systems

19 Kapitel 1 Einleitung Nur was nicht aufhört, wheh zu thun, bleibt im Gedächtniss. Friedrich Nietzsche Das Lernen aus Wissen über fehlerhafte Produkte, Dienstleistungen und Prozesse in möglicherweise unternehmensübergreifenden Wertschöpfungsketten ist ein strategischer Wettbewerbsfaktor von Unternehmen [War92, Her98]. Sei es im internen Produktionsprozeß [Pfe93] oder in der schwierigen Schnittstelle zu Kunden und anderen Unternehmen [SS98], [MO98], die Erzeugung, Wartung und Nutzung von Fehlerwissen kann zu erheblichen Verbesserungen der Produktqualität, zu stärkerer Kundenbindung und zu innovativen Produkten führen 1. Diesem Trend wird in der Wirtschaft beispielsweise durch die Einführung von Call-Centers oder unternehmensweiten Wissensmanagementprogrammen Rechnung getragen. Gegenüber der weitgreifenden Bedeutung, die dem Wissensmanagement in Theorie und Praxis zugeschrieben wird (vgl. [Spe96, Bür98, PR98, Roe99, FB00]), tauchen Scheitern, Versagen, Fehler machen, Störungen usw. als Quelle des Lernens im Verhältnis selten auf. Fehlerwissen oder auch negatives Wissen (im außermoralischen Sinn) ist das Wissen um das, wie etwas nicht ist oder falsch ist (deklaratives Fehlerwissen), oder was man nicht tun soll (prozedurales Fehlerwissen) [Ose94]. Die Bedeutung des Fehlerwissens liegt laut Oser darin, daß auf seinem Hintergrund das positive Wissen schärfer sei; positives Wissen werde durch negatives Wissen geschützt und gestützt. Der Fehler und das Fehlermachen sind die Grundvoraussetzung für den Erwerb von Fehlerwissen. Abbildung 1.1 zeigt den Zusammenhang grafisch anschaulich [ZHB99]. Ein Lernzyklus aus Erzeugung, Veränderung und Verständnis von Fehlerwissen führt über die unternehmensspezifische Integration und Nutzung zu einem Sonderwissensbestand [Kre98]. Diese spezifischen Kompetenzen können zur Generierung von innovativen Produkten, Dienstleistungen und Prozessen genutzt wer- 1 Laut einer vom Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) durchgeführten Unternehmensstudie zum Thema Wissensmanagement [BWPW98] wurden diese Punkte als wichtigste Erwartungen an ein verbessertes Management von Wissen genannt.

20 2 Einleitung den, die Wettbewerbsvorteile erbringen. Lernen Fehlerwissen Erzeugung, Veränderung, Verstehen von Fehlerwissen Unternehmens spezifische Integration und Nutzung Kompetenzen Generierung von Innovationen (Leistungen, Verfahren) Wettbewerbs vorteile Abbildung 1.1: Lernen aus Fehlerwissen als Basis für Wettbewerbsvorteile (adaptiert aus [ZHB99]) Aus diesem Kontext heraus untersucht die vorliegende Arbeit informatische Unterstützung für das nachhaltige vernetzte Verbesserungsmanagement (VVM), hier definiert als systematische, informationssystem-gestützte und zielgerichtete Erfassung, Verwaltung und reaktiv-proaktive Nutzung von Fehlerwissen. 2 Erkannte Mängel an Produkten oder Prozessen und brachliegende Potentiale der Produkt- und Prozeßgestaltung eröffnen Unternehmen der Fertigungsindustrie, wenn systematisch genutzt, neue Marktchancen und verbessern die Ressourcennutzung. Fehlerwissen bildet die Grundlage des nachhaltigen vernetzten Verbesserungsmanagements. Dieses erste Kapitel gibt eine Einführung in die Forschungsthematik und Relevanz des nachhaltigen vernetzten Verbesserungsmanagements. In Abschnitt 1.1 wird der Praxisund Forschungshintergrund dieser Arbeit herausgearbeitet. Abschnitt 1.2 präzisiert den informatischen Forschungsfokus dieser Arbeit. Abschließend wird in Abschnitt 1.3 die Gliederung dieser Arbeit erläutert. 2 Die Begriffe Nachhaltigkeit und Vernetzung im Rahmen des Verbesserungsmanagements werden in Kapitel 3 detailliert erläutert. Vorausgreifend sei erwähnt, daß sich Nachhaltigkeit auf die langfristige, ressourcenschonende Organisation von Fehlerwissen und Vernetzung auf die kurzfristige Bildung von Verbesserungsteams bezieht.

21 1.1 Problembeschreibung Problembeschreibung Mit einer prognostizierten Umwandlung der Industrienationen in Wissensgesellschaften steigt die Bedeutung der Ressource Wissen für Unternehmen [Nor98, Kre98]. Als wesentliche Triebkräfte werden genannt: der strukturelle Wandel weg von arbeits- und kapitalintensiven hin zu informations- und wissensintensiven Aktivitäten, die Globalisierung der Wirtschaft und die durch neue Informations- und Kommunikationstechnologien ausgelösten Möglichkeiten der Informations- und Preistransparenz [Nor98, O L98a]. Das Management der Ressource Wissen ist somit eine ernstzunehmende Aufgabe einer Organisation. Nähert man sich dem Thema Wissensmanagement auf einer abstrakten Ebene, so wird Wissensmanagement zunächst als wertschöpfender Prozeß eines Unternehmens definiert; Davenport und Prusak schreiben [DP98a]: Knowledge Management is a formal, structured initiative to improve the creation, distribution, or use of knowledge in an organization. It is a formal process of turning corporate knowledge into corporate value. Eine solche Definition läßt der konkreten Ausgestaltung breiten Raum. Holsapple und Joshi [HJ99] haben beispielsweise fünf existierende Rahmenwerke zum Wissensmanagement untersucht und folgende analytische Aussagen getroffen: Wissensressourcen, d.h. Angestellte, Kunden, Prozesse, Strukturen und Kulturen werden in den Rahmenwerken willkürlich und wenig differenzierend verwendet. Es gibt keine gemeinsame oder standardisierte Charakterisierung der Aktivitäten zur Handhabung von Wissen. Es gibt keine gemeinsame oder standardisierte Charakterisierung, welche Einflüsse es auf die Durchführung des Wissensmanagements gibt. Kein Rahmenwerk subsumiert alle anderen. Statt einer Konsolidierung steigt die Anzahl der Rahmenwerke zum Thema Wissensmanagement an (vgl. auch [PRR97, Bür98, Leh00]). Beachtet man den engen Zusammenhang von Wissen und Lernen [Leh00], darf es nicht verwundern, daß im Bereich des Lernens von Organisationen eine ähnliche Vielzahl von Ansätzen herrscht [Wie96]. Nähert man sich dem Thema Wissensmanagement von der Praxis, herrscht auch dort eine verwirrende Vielzahl von organisatorischen und technologischen Lösungsansätzen vor. Eine kleine Auswahl zeigt die Vielfalt der Möglichkeiten, das Thema Wissensmanagement anzugehen: Wissenslandkarten für die Explizierung und Visualisierung von personenbezogenem Wissen [Sch98a, BZ98], Organisationshandbücher [BDMQ95], Projekt-, Best-Practice-, Lessons-Learned-Datenbanken [BP98, OS98, Din99], Lernarenen [Rom96], Techniken zur Gestaltung von wissensverwaltenden Intranets [LMK98, Noa98, Hön99, BVO99], Data- Mining Verfahren [DRSS97] und Data Warehouses [Erd97, JLVV99]. Die (Wirtschafts-)Informatik hat eine Reihe von Ansätzen für die Informationssystem- Unterstützung des Wissensmanagements hervorgebracht, 3 die in der Praxis auf positive 3 Einige Aufsätze versuchen, diese technologischen Ansätze systematisch in Rahmenwerke des Wis-

22 4 Einleitung Resonanz gestoßen sind (vgl. [Bür98, MK99, BVO99, Leh00]). Daher sind die Investitionen in Informationssysteme für das Wissensmanagement gestiegen. Dies beinhaltet allerdings einige Gefahren. Erstens ist Wissensmanagement kein Selbstzweck. Die Akquisition von informationssystem-basiertem Wissen ist nicht kostenlos und muß daher in Relation zu dem zu erwartenden Nutzen stehen. Zweitens können Investitionen in informationstechnologischen Infrastrukturen des Wissensmanagements das Niveau der Unterstützbarkeit für Jahre fixieren, selbst wenn der technologische Wandel mittlerweile in Monaten gemessen wird. Drittens müssen gerade typischerweise wissensintensive Unternehmen mit schnellen und häufigen Wechseln von Personal, Technologien und Prozessen ihr erworbenes Wissen bewahren, um ihr zukünftiges Handeln zu steuern [Sta92]. Angesichts dieser Problematik ist das nachhaltige vernetzte Verbesserungsmanagement ein möglicher Einstiegspunkt in ein unternehmensweites Wissensmanagement: Das Qualitätsmanagement als unternehmerische Querschnittsaufgabe dient wohldefinierten Zielen wie der Sicherung von Wettbewerbsvorteilen und hat viele Unternehmensbereiche bereits durchdrungen. Als Ansatz zum Wissensmanagement des Qualitätsmanagements führt das VVM bestehende organisatorische, methodische und informationstechnologische Ansätze im Qualitätsmanagement evolutionär weiter. Das heißt aber auch, daß bisherige Ansätze berücksichtigt werden müssen. Fehlerwissen schärft und stützt das positive Qualitätswissen. Fehlerereignisse erzeugen und steuern qualitäts- und innovationsfördernde Prozesse im gesamten Unternehmen, auch in einem turbulenten Umfeld. Dazu müssen die für ein Unternehmen zugänglichen Quellen von Fehlerwissen miteinander nachhaltig vernetzt werden. 4 Die konkreten Aufgaben des VVM als Ansatz des Qualitätsmanagements fokussieren die Gestaltung von informationstechnologischen Lösungen auf das organisatorisch und personell Machbare und verhindern eine nicht zielgerichtete Vorgehensweise bei der Einführung des Wissensmanagements. 1.2 Fokus und Ziele der Arbeit Aus Sicht der Informatik kann die Arbeit auf die folgenden drei Fragestellungen fokussiert werden, um informationstechnologische Lösungen für das VVM zu gewinnen: 1. Wie kann Fehlerwissen entlang des Produktlebenszyklus gesammelt und trotz der bestehenden räumlichen, zeitlichen und konzeptuellen Barrieren auch genutzt werden? Der Lebenszyklus eines Produktes erstreckt sich von der Planung bis zur Entsorgung. Die wertschöpfende Prozeßgestaltung zielt auf die Abdeckung des gesamten Produktlebenszyklus ab. Relevantes Fehlerwissen kann in jeder Phase dieses Zyklus anfallen. sensmanagements einzuordnen (vgl. [WDA99, Hab00]), tragen aber damit nicht zur Konsolidierung der Rahmenwerke bei. 4 Bullinger et al. [BWPW98]: Die Vernetzung, effiziente Nutzung und Multiplikation dezentral vorhandenen Wissens, im Gegensatz zu streng linearer, funktionaler Arbeitsteilung, schafft neue Wertschöpfung.

23 1.2 Fokus und Ziele der Arbeit 5 Deshalb muß die Sammlung bzw. Nutzung von Fehlerwissen während des gesamten Zyklus möglich sein, insbesondere ist es wichtig, daß Fehlerwissen aus späten Phasen, z.b. Reklamationen oder Beschwerden von Kunden, in frühen Bereichen, beispielsweise der Produktplanung, zur Verfügung steht. Die extrem verteilte Sammlung und Nutzung von Fehlerwissen führt einerseits zu konzeptuellen Problemen beim Nachvollziehen von Fehlerereignissen, andererseits können zwischen Sammlung und Nutzung von Fehlerwissen erhebliche zeitliche und räumliche Abstände liegen, so daß eine zeitliche Aufbewahrung und ortsunabhängige Nutzung des Fehlerwissens notwendig ist. Zur informationssystem-gestützten Organisation der Wissensrepräsentationen und zur Verzahnung mit Repräsentationen anderer Geschäftsprozesse ist ein unternehmensweites Gedächtnissystem (UGS) (engl.: Organizational Memory System) notwendig (vgl. z.b. [OR91, SZ95, KA97, ABH + 98, LMK98]). Das UGS soll den Transfer von Fehlerwissen zwischen Abteilungen, zwischen Hierarchiestufen und zwischen Prozessen im Unternehmen fördern. 2. Wie kann Fehlerwissen organisiert werden, so daß auch in einer von Variantenvielfalt geprägten Produktion trotz der resultierenden Komplexität des Wissens aus Fehlern gelernt werden kann? Die Gestaltung von Produkten und Prozessen wird durch die zunehmende Transparenz und Globalisierung der Märkte zunehmend kundenspezifischer. Insbesondere ist die Fertigung von Einzel- und Kleinserien in kleinen und mittelständischen Betrieben von zunehmender Variantenbildung geprägt. Fehlerwissen bleibt aber häufig auf den Bedeutungshorizont des einzelnen Produktes oder Prozesses beschränkt. Um die Nutzung von Fehlerwissen innerhalb variantengeprägter Fertigung zu intensivieren, ist es notwendig, dieses Wissen in andere Produkt- oder Produktionskontexte zu transferieren. Dazu muß über dem gespeicherten Fehlerwissen Strukturwissen aufgebaut werden, das dieses Fehlerwissen mit den wertschöpfenden Prozessen eines Unternehmens variantenorientiert kombiniert. Wertschöpfende Prozesse arbeiten mit Variantenmodellen, die zumeist Merkmalsausprägungen, Merkmalsmengen und Produktstrukturen umfassen. Im Management komplexer und varianter Produktinformationen wurden mit der Einführung von Produktionsplanungs- und Steuerungs (PPS)-Systemen [Sch88, RG91, RA95] wichtige Standards geschaffen. Im Verbesserungsmanagement ist eine zusätzliche Betrachtung des Produktlebenszyklus, d.h. von Produktnutzungsumständen (z.b. Wissen aus der Reklamationsbearbeitung) und des Produktionskontextes (verknüpftes Wissen über Produkte, Prozesse und Anlagen), in die Variantenbildung einzubeziehen. Durch die Nutzung von Variantenwissen lassen sich einzelne Phasen des Lebenszyklus, z.b. die Konstruktion, nachhaltiger gestalten. 3. Wie sollen Verbesserungsprozesse gestaltet werden, so daß eine verteilte Bearbeitung von Fehlerwissen ermöglicht und unterstützt wird? Anders als in vielen betrieblichen Informationssystemen zur Definition, Gestaltung und Operationalisierung von wiederholbaren, stark strukturierten und vorwärtsgerichteten Prozessen macht es die Natur von Fehlerereignissen schwierig, wenn nicht unmöglich, diese Informationssysteme zur Gestaltung von Verbesserungsprozessen

24 6 Einleitung einzusetzen. Dementsprechend verläuft die Bearbeitung von Fehlern (Reklamationen oder betriebliche Störungen) zum großen Teil ad hoc. Ziel muß es sein, diese Praxis so zu gestalten, daß dennoch eine notwendigerweise verteilte Bearbeitung von Fehlerwissen unterstützt wird. Daher gilt es, grundlegende Prinzipien der verteilten Bearbeitung von Fehlerwissen aufzudecken und diese adäquat informationstechnologisch zu unterstützen. Eine flexible Formalisierung des Verbesserungsmanagements erweitert die Erfahrungen, die bei der Realisierung von Funktionen zur Endkundenunterstützung gemacht wurden [KPJ98, JK98]. Obwohl prinzipielle Unwägbarkeiten beim Auftreten von Fehlern die Gestaltung flexibler Prozesse verlangt, sind für die Gestaltung von VVM-Prozessen wertvolle Forschungsarbeiten aus dem Management verteilter betriebswirtschaftlicher Prozesse vorhanden. Dort kommen zunehmend flexible Groupware-Lösungen [Teu96, Sch96b], wie z.b. gemeinsame Informationsräume [BAB + 97, RG96], unternehmensweite Diskussiongruppen [MGL + 87, LMY88, Syr97] und fallbasierte WFMS [OV96], zum Einsatz. Meines Erachtens bietet das VVM einzigartige Möglichkeiten für das Verständnis, die Gestaltung und die Optimierung der Informationstechnologie in Unternehmen. Die mit der Arbeit verbundenen Ziele will ich im einzelnen kursorisch diskutieren. Erkenntnisziel: Das VVM ist als Ansatz des Qualitätsmanagements ein Subsystem des Unternehmens, das alle anderen Systeme der Organisation durchdringt. Ein vertieftes Verständnis dieses Subsystems trägt somit zum besseren Verständnis der gesamten Organisation bei. Dazu möchte ich analog zu den Erkenntnissen der Hirnforschung argumentieren. 5 In der Hirnforschung sind unter anderem zwei Erkenntnisse bemerkenswert. Zum Verständnis der Funktionsweise des Gehirns hat erstens die Untersuchung pathologischer Fälle entscheidend beigetragen [Ecc93]. Zweitens lassen neuere Untersuchungen (vgl. z.b. [Dam89]) den Schluß zu, daß das Gehirn in der Lage ist, Funktionsstörungen zu kompensieren. In Analogie zur Hirnforschung kann die Analyse pathologischer Verhaltensweisen und die Diagnose fehlerhafter Produkte vertiefte Einsichten in die Funktionsweise von Unternehmen bieten. Dieser Richtung der Analyse können im Bereich des Organisationalen Lernens und der Organisationsgedächtnisse, z.b. March [MO76, Mar91], Argyris und Schön [AS78, AS96] und Landry [Lan97, Lan98, Lan99], zugeordnet werden. Aufgrund theoretischer Untersuchungen und empirischer Befunde will ich die Herausforderungen des VVM charakterisieren und in dieser Arbeit Ansätze der Informatik liefern, die zur Lösung der nachhaltigen Vernetzungsproblematik im Verbesserungsmanagement beitragen. 5 Anthropomorphisierende Metaphern, wie sie vor allem in der Organisationsforschung im Zusammenhang mit Organisationgedächtnissen [Pau89, WU91, BK96, Con92, HdSK96, Spe96, MM97, HDK98, Her98] und dem Lernen von Organisationen [AS78, FL85, NT95, Wie96] verwendet werden, werden im Kontext der Arbeit kenntlich gemacht und ihre Verwendung behutsam eingeschränkt.

25 1.3 Aufbau der Arbeit 7 Gestaltungsziel: Die grundlegende Verteilung, abteilungs- und unternehmensübergreifende Natur des VVM, welche die durchgängige Gestaltung qualitätsorientierter Arbeits- und Informationsflüsse mit Rückkopplungen erfordert, zeigt gleichermaßen die Grenzen und Chancen moderner Informationstechnologie. Nicht die Integration von Informationstechnik steht als Gestaltungsziel im Vordergrund, sondern die Vernetzung von Wissensarbeitern. Die mit der Einführung von CIM (engl.: Computer Integrated Manufacturing) Bausteinen verbundenen Beobachtungen der Kommunikations- und Informationsverengungen [Hub98] und der rasche Wandel der technologischen und organisatorischen Gestaltungsmöglichkeiten auf der einen Seite, und der Erfolg von Vernetzungstrategien seit der Einführung des World Wide Web auf der anderen Seite, haben der Metapher Vernetzung weitaus höhere Bedeutung eingeräumt. Die Gestaltungspotentiale existierender (informationstechnologischer) Ansätze dazu, sowohl aus der Praxis als auch aus der Forschung, sind groß. Ein Ziel dieser Arbeit ist es, diese Potentiale durch sorgfältige Analyse zu kombinieren. So sind Helpdesks [Bar92, MM96, Wal99], die Kunden bei ihren Aufgaben unterstützen oder Call- Centers [SS98, Gra99], die Kundenwünsche, Bestellungen usw. aufnehmen und weiterleiten, typische Funktionen moderner, kundenorientierter Unternehmen. Helpdesk- Systeme, die tatsächlich viele notwendige Werkzeuge bereitstellen, bilden dabei den Nukleus für die Gestaltung von informationstechnologischen Strategien zur nachhaltigen Vernetzung des Verbesserungsmanagements. Prognoseziel: Das VVM erzeugt in der Praxis gleichermaßen Rationalisierungs- und Innovationspotentiale. Durch die Anwendung des Gelernten auf aktuelle Prozesse und Produkte werden Einsparungen möglich, die die Produktivität eines Unternehmens erhöhen und gleichzeitig ermöglichen, die Erfahrungen zur Gestaltung neuer Produkt- und Prozeßgenerationen zu nutzen. Die konkreten praktischen Zielsetzungen, die mit diesen Mitteln erreicht werden sollen, liegen in graduellen Verbesserungen der reaktiven und proaktiven Verbesserungsprozesse, z.b. die Verringerung der Antwortzeiten und der Anzahl der ausgelösten Eskalationen bei einem Produktfehler bei gleichzeitiger Erhöhung der Analyse- und Maßnahmequalität. 1.3 Aufbau der Arbeit Die Arbeit stellt zunächst in Kapitel 2 Begrifflichkeiten und Entwicklungen im Verbesserungsmanagement vor. Im Mittelpunkt von Kapitel 3 steht die Konzeptualisierung des hier verfolgten Ansatzes im Verbesserungsmanagement auf Grundlage der Begriffe Nachhaltigkeit und Vernetzung. Die existierenden Barrieren bei der Gestaltung von VVM-Systemen in der Praxis werden in Kapitel 4 anhand empirischer Befunde charakterisiert und der Stand der Technik bei der Realisierung von VVM-Systemen in Kapitel 5 fokussiert aufgearbei-

26 8 Einleitung tet. In Kapitel 6 wird der in Kapitel 3 konzipierte Gesamtansatz durch ein VVM-System umgesetzt. Eine Validierung wichtiger Teile wird in Kapitel 7 geleistet. Eine Zusammenfassung der wichtigsten Ergebnisse und ein Ausblick schließen die Arbeit ab. Die detaillierte Gliederung der Arbeit im einzelnen sieht folgendermaßen aus: Kapitel 2: Eine begriffliche und entwicklungsgeschichtliche Analyse charakterisiert Prozeß-, Kunden-, Wissens- und Teamorientierung als die wesentlichen Trends im Verbesserungsmanagement. Drei Unternehmens-Fallstudien decken wichtige Aufgaben beim Management von Fehlerwissen auf. Kapitel 3: Die informationssystem-gestützte Erzeugung, Aufbewahrung und Nutzung von Fehlerwissen in Unternehmen steht im Mittelpunkt dieses Kapitels. Der Lösungsansatz zur Erzeugung, Speicherung und Nutzung des Fehlerwissens vereinigt einen domänenspezifischen Workflow-Ansatz zur Vernetzung von virtuellen Verbesserungsteams mit einer nachhaltigen Aufbewahrungs- und Lernstrategie in einem Unternehmensgedächtnis-System. Die Synthese der beiden Ansätze wird über einen Wissenstransformationsansatz geleistet, der für die Gegebenheiten des VVM adaptiert wird. Kapitel 4: Die Erfahrungen mit dem rechnergestützten Verbesserungsmanagement werden in einer zweistufigen Fragebogenerhebung dokumentiert, analysiert und bewertet. Die Analyse der bestehenden Praxis des rechnergestützten Verbesserungsmanagements führt Informations- und Komplexitätsbarrieren sowie technologische und konzeptuelle Barrieren auf, die durch den heutigen Einsatz von Informationstechnologien keinesfalls überwunden werden. Kapitel 5: Bisherige informationstechnologische Lösungen für das Verbesserungsmanagement werden hinsichtlich ihrer Eignung für die Umsetzung des in Kapitel 3 konzipierten Gesamtansatzes fokussiert untersucht und bewertet. Kapitel 6: In diesem Kapitel wird ein VVM-System konzipiert. Ein modulares, kooperatives und änderungsorientiertes Modellierungsrahmenwerk zur Gestaltung eines Gedächtnis-Repositories für das VVM wird mittels Metamodellierungstechniken unterstützt. Dadurch werden die Repräsentationen kurzfristiger operativer Verbesserungsprozesse mit den Repräsentationen von mnemonischen Prozessen, das sind Prozesse der Wissenserzeugung, der -aufbewahrungs- und -nutzung, konzeptuell gekoppelt. Dadurch kann Wissen prozeßorientiert bewahrt und genutzt werden, aber auch zwischen verschiedenen Prozessen transportiert werden, so daß eine Wissenslogistik im Verbesserungsmanagement entsteht. Die Kopplung wird durch einen Ansatz erweitert, der die Variantenvielfalt in der Produktion berücksichtigt. Die im Repository gespeicherten Repräsentationen von Objekten, Prozessen und Agenten und die Aufzeichnungsspuren der Fehlerfallbearbeitung können genutzt werden, um aus Fehlern zu lernen. Die operative Unterstützung des VVM-Systems beruht auf einer flexiblen Formalisierung von teamorientierten Verbesserungsprozessen, die mit replizierten elektronischen Vorgangsmappen unterstützt werden. Für die Steuerung

27 1.3 Aufbau der Arbeit 9 der replizierten elektronischen Vorgangsmappen wird ein Versionierungs- und Konfigurationsansatz vorgestellt, der die Verbesserungsprozesse aufgabenspezifisch und nachvollziehbar unterstützt. Kapitel 7: Mittels eines umfassenden Evaluierungsmodells werden Realisierungen von VVM-Systemen, die dem Gesamtansatz folgen, in Einzelfallstudien untersucht und bewertet. Kapitel 8: Die Kernergebnisse dieser Dissertation werden kurz zusammengefaßt, und ein Ausblick auf die weitere Anwendung und Erweiterung des Forschungsansatzes beschließt diese Arbeit.

28 Kapitel 2 Begrifflichkeiten des Verbesserungsmanagements Jede einzelne Aktivität setzt Wissen voraus. Für alles Handeln und erst recht für alle Kommunikation ist Wissen unentbehrlich. Niklas Luhmann Das Ziel dieses Kapitels ist es, Begrifflichkeiten intuitiv einzuführen, die für die Gestaltung von Informationssystemen im Verbesserungsmanagement wichtig sind, und die zentralen Entwicklungen im Verbesserungsmanagement zu klären, um eine Grundlagefür dieadäquate Organisation und Nutzung von Fehlerwissen in Unternehmen zu schaffen. Die Fragen nach der Bewahrung von Fehlerwissen und dem effizienten Umgang mit Fehlerwissen sind mit den eingangs genannten Fragestellungen (vgl. Abschnitt 1.2) verbunden. Diese Fragestellungen verlangen einen im gesamten Produktlebenszyklus kommunizierbaren Wissensbegriff, der die für das Unternehmen benötigten Facetten abdeckt (vgl. Abschnitte 2.1 bis 2.3). Dieser Wissensbegriff muß die organisatorischen (vgl. Abschnitt 2.4) und methodischen (vgl. Abschnitt 2.5) Weiterentwicklungen des Verbesserungsmanagements aufgreifen. Die Hauptentwicklungen des Verbesserungsmanagements sind zum einen die zunehmende, durch neue Wettbewerbsbedingungen ausgelöste Kunden- und Prozeßorientierung, zum anderen die zunehmende Wissens- und Teamorientierung, welche die komplexe und verzahnte Qualitätssicherung neuer Produktionsmethoden adressieren. Das Management von Fehlerwissen ist eine eigenständige Aufgabe innerhalb einer qualitätsorientierten Unternehmensstrategie, denn in allen Prozessen und Regelkreisen des Qualitätsmanagements besteht die Notwendigkeit, Wissen über fehlerhafte Produkte und Prozesse auszutauschen.

29 2.1 Qualität und Fehler 11 Fehlerwissen ist über den gesamten Produktlebenszyklus eines Produktes verteilt und nicht immer unmittelbar abrufbar. unternehmensübergreifende Wertschöpfungsketten erschweren den Zugriff auf Fehlerwissen und den Transport von Fehlerwissen in einem extrem verteilten Produktlebenszyklus. moderne Produktionsmethoden mit hohen Varianten- und geringen Stückzahlen erschweren die Anwendung klassischer, statistischer Qualitätskontrollmethoden. unabhängig nebeneinander existierende Ansätze verwalten isolierte Fehlerwissensbestände und kommen zu unterschiedlichen Bewertungen. von Fehlern verursachte Kosten können schwer ermittelt werden. 2.1Qualität und Fehler Der Qualitätsbegriff hat sich über die Zeit gewandelt und neue Facetten hinzugewonnen. Obwohl in visionären und philosophischen Ansätzen des Qualitätsmanagements diese Wandlungen nachvollzogen oder gar vorweggenommen wurden (vgl. [Dem86, Tag89, Blä90, Fei91, Pfe93]), bleibt in der Praxis der Begriff des Qualitätsmanagements oft mit produktionsnahen Aufgaben der Qualitätskontrolle, der Qualitätssicherung und der Qualitätssicherungsnachweisführung verbunden. Mit dem Begriff der Qualität ist unhintergehbar der Begriff des Fehlers verbunden. Der Verwässerung des Qualitätsbegriffs durch die notwendige Ausweitung auf die gesamte Performanz eines Unternehmens wird durch eine stärkere Konzentration auf den Fehlerbegriff entgegnet. Der Einzelfallcharakter des Fehlers mit seinen Facetten schärft das Qualitätsbewußtsein durch die Demonstration der Folgen bei Nichterfüllung von Qualitätszielen, -kriterien oder -merkmalen. Im folgenden werde ich die Begriffe Qualität und Fehler in mehreren Hinsichten diskutieren. Zunächst werden die Wandlungen des Qualitätsbegriffs nachvollzogen und der Fehlerbegriff als notwendiger Gegenbegriff eingeführt. Unter dieser Voraussetzung werden Facetten des Fehlerwissens, die Bewertung von Fehlerereignissen, der Umgang mit Varianten und die Nutzung von Fehlerwissen in der Praxis, anhand von Fallstudien diskutiert. Das deutsche Institut für Normung (DIN) definiert Qualität in der DIN [DIN87] als die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. 1 Der Begriff Qualität ist nach Horváth und Urban [HU90, S. 5ff] allerdings aufgrund dreier Faktoren schwer zu fassen. Erstens unterliegt der Begriff einem zeit- und umweltbedingten Wandel. Zweitens definieren unterschiedliche Interessengruppen Kunden, Hersteller, Lieferanten, Gesetzgeber (implizit oder explizit) unterschiedliche Qualtitätsvorstellungen mit unterschiedlicher Reichweite, je nachdem, ob sich das Wort Einheit auf Produkte oder Herstellungsprozesse bezieht. Die Problematik eines Unternehmens liegt in der Gleichzeitigkeit der Erfüllung von Qualitätsforderungen, denn drittens 1 In Kurzform empfiehlt Geiger [Gei88, S.38f]: Realisierte Beschaffenheit bezüglich einer Qualitätsforderung.

30 12 Begrifflichkeiten des Verbesserungsmanagements gibt es eine Verlagerung von der Qualitätsbeurteilung eines Endproduktes zur Beurteilung der gesamten Marktleistung, einschließlich der immateriellen Komponenten. So sind neben den eigentlich auf dem Markt angebotenen Produkten und Dienstleistungen auch die Fertigungsprozesse und die Umweltverträglichkeit Qualitätsforderungen unterworfen, was wiederum auf den ersten Punkt zurückführt. Zusammengefaßt wird aus Herstellersicht in [HU90, S. 8] Qualität als die Eignung der Unternehmensgesamtleistung zur Erfüllung aller an sie gerichteten Anforderungen definiert. Während die Hersteller damit primär die Qualität ihrer Leistungserstellungsprozesse im Blick haben, ist für den Kunden die Problemlösungsqualität eines Unternehmens von Bedeutung. Juran ([Jur79], zitiert in [HU90, S. 5], [SM87, S. 3]) definiert Qualität als Eignung eines Produktes für seinen Verwendungszweck (engl.: fitness for use) und führt aus: The basic buildung block on which fitness for use is built is the quality characteristic. Any feature (property, attribute, etc.) of the products, materials, or processes which is needed to achieve fitness for use is a quality characteristic. Diese veränderte Sicht der Qualität hat sich in verschiedenen neueren Qualitätsmodellen niedergeschlagen, z.b. das dienstleistungsorientierte ServAs [HR94] oder das europäische Qualitätsmodell EFQM [Sim99]. 2 Eine erste negative Bestimmung des Qualitätsbegriffes aus Kundensicht wird durch Stauss und Seidel [SS98, S. 375] geleistet. Sie definieren: Sämtliche Unzufriedenheitsäußerungen vonkundensindbeschwerden. AlsReklamationen bezeichnet man die Untergruppe von Beschwerden, in denen sich Kunden bei ihrer Forderung auf einen Rechtsanspruch berufen. Hier kehrt die emotionale Komponente der Unzufriedenheit zurück, die in vorhergehenden (aber auch in nachfolgenden) Bestimmungen seltsam unterbestimmt blieb. Mangelnde Qualität kann ärgerlich sein, sie kann Zeit und Geld kosten, sie kann sogar menschliches Leben fordern. Es ist erkennbar, daß Beschwerden bzw. Reklamationen aufgrund einer vermuteten oder tatsächlichen Abweichung von einer Qualitätsforderung gestellt werden. Dies gilt auch für die Herstellersicht hinsichtlich der innerbetrieblichen Leistungserstellungsprozesse, wo in diesem Zusammenhang von einem Fehler gesprochen wird, wobei fehlerhafte Produkte (Ausschuß, Nacharbeit) [HU90, S. 117 ff.] von fehlerhaften Leistungserstellungs- oder Logistikprozessen unterschieden werden. Die DIN [DIN87] definiert einen Fehler als Nichterfüllen einer Forderung und grenzt ihn von einer bloßen Abweichung ab, die als das Bestehen eines Unterschiedes zwischen einem Merkmalswert oder einem dem Merkmal zugeordneten Wert und einem Bezugswert definiert wird. Klapper [Kla93, S. 26] kritisiert 2 Auffallend ist die Reichweite japanischer Qualitätsdefinitionen. So definiert Ishikawa [Ish80]: The word quality applies not only to products but also to services and work. Quality Control is the effort of an entire enterprise, to develop, design, manufacture, inspect, market and service products that will satisfy the customers at the time of purchase and give them satisfaction for a long time after purchase. Fast schon buddhistisch ist die Definition von Taguchi [Tag89]: Qualität entspricht dem Verlust, den ein Produkt für die Gemeinschaft nach seiner Bereitstellung verursacht, im Gegensatz zu jenen Verlusten, die durch seine Funktionen hervorgerufen werden. Diese Definition verdeutlicht den hohen Stellenwert der Gemeinschaft gegenüber dem Individuum in Japan (vgl. auch [NT95]).

31 2.1 Qualität und Fehler 13 diese Auffassung in zweierlei Hinsicht. Erstens spricht er von einer fertigungsbezogenen Definition, da Kundenaspekte ausgeblendet werden. Zweitens kann man Abweichungen gleichwohl den Charakter eines Fehlers zuweisen, da eine Abweichung das Risiko von Ausfällen usw. erhöht. Die bisherige Diskussion zeigt zwei Dinge. Zum einen hat sich der positiv gefaßte Qualitätsbegriff auf den gesamten Lebenszyklus eines Produktes samt dessen immateriellen Komponenten und den dazu notwendigen leistungserzeugenden Prozessen ausgedehnt, zum anderen setzt er sich aus unterschiedlichen Sichten zusammen. Problematisch ist daher die Definition von Qualitätsinformationen auf meßbare, d.h. objektiv feststellbare Tatbestände. Scheer und Trumpold [ST96, S. 7] definieren Qualitätsinformationen als bewertete Abweichung [...], die das Ergebnis des Vergleichs einer Sollausprägung mit der entsprechenden Istausprägung eines (Qualitäts-)Merkmals ist. Diese Definition bezieht sich auf die Realisierung von rechnergestützten Qualitätssicherungssystemen (engl.: Computer Aided Quality Assurance (CAQ) Systems). Die dortigen Funktionalitäten beziehen sich in erster Linie auf die Planung, Durchführung, Auswertung und Verwaltung von Prüfungen und den zugehörigen Prüfmitteln [TRLH93, GS99]. Gleichwohl ist die zunehmende Kundenund Prozeßorientierung des Qualitätsmanagements (vgl. Abschnitt 2.4) aus dieser historischen Perspektive nicht zu verstehen. Gerade Ausdehnung und Sichtenbildung 3 machen den Qualitätsbegriff schwer faßbar. Deshalb faßt eine konkrete Bestimmung des Begriffs Verbesserungsmanagement zu kurz, die auf einen positiven, rein auf objektiven Kriterien beruhenden, alle Kundenaspekte ausblendenden Qualitätsbegriff beruht. Im Gegensatz dazu bietet aber eine negative Bestimmung nicht nur einen weiteren, natürlichen Ansatzpunkt für die Definition von Verbesserungen, sondern auch eine unerschöpfliche Quelle von konkreten Einzelfällen als wissenserzeugenden Faktor. Diese Einzelfälle sollen hier als Fehlerfälle bezeichnet werden. Wissen, das zur Bearbeitung des Fehlerfalls genutzt oder bei der Bearbeitung erzeugt wird, bezeichne ich als Fehlerwissen. Der Begriff Fehlerbild bezeichnet den zu einem bestimmten Bearbeitungszeitpunkt gültigen Bestand von Fehlerwissen. Ein Fehler ist schließlich eine Menge von gleichartigen Fehlerfällen. In dieser Arbeit soll das Auftreten eines Fehlers, sei er als Beschwerde oder Reklamation von einem Kunden artikuliert worden, sei er durch ein CAQ-System nach einem festgelegtem Prüfplan entdeckt worden, als Fehlerereignis bezeichnet werden. 3 Die in der Praxis getroffene Unterscheidung zwischen planungsnahen, produktionsnahen und kundennahen Verbesserungsprozessen führt gerade zu einem der Hauptprobleme: dem mangelnden Informationsfluß zwischen den verschiedenen Phasen eines Produktlebenszyklus.

32 14 Begrifflichkeiten des Verbesserungsmanagements 2.2 Produktlebenszyklus Der Produktlebenszyklus eines industriell gefertigten Produktes umfaßt alle Stufen von der Produktidee bis zur Entsorgung eines Produktes (vgl. Abbildung 2.1) 4. Peters [Pet96, S. 53] beschreibt die Definition eines Lebenszyklus mit den zugehörigen Prozessen als Ausgangspunkt eines jeden Qualitätsmanagementsprogramms. Daß die Frage nach der Nutzung von Fehlerwissen in produzierenden Betrieben (zumindest) eine unternehmensweite Aufgabe ist, wird auch aus folgendem Zusammenhang ersichtlich. Herterich schreibt in seinem Beitrag über den Einsatz von Unternehmensgedächtnis-Systemen in Industriebetrieben [Her98, S. 56]: Besonders komplex gestaltet sich die redundanzfreie Verwaltung von Wissen zum Qualitätsmanagement, da die Funktionalität dieser Wissensgruppe nahezu in allen anderen Wissensgruppen enthalten ist. Entsorgung Marktanalyse Service Konzept Call Center Entwicklung Kundennutzung Konstruktion Lager/Auslieferung Planung Q Kontrolle Fertigungsplanung Montage Fertigung Abbildung 2.1: Lebenszyklus industrieller Produkte Der Produktlebenszyklus als Qualitätskreis ist nach DIN [DIN87] in drei grobe Phasen aufgeteilt.in der Planungsphase werden Qualitätselemente für planerische Prozesse und Produkt betrachtet, in der Realisierungsphase geht es um produktionsnahe Verbesserungsprozesse und in der Nutzungsphase geht es vornehmlich um gebrauchsnahe Bereiche, z.b. die Ausgestaltung der Kundenschnittstelle. Weitere gebräuchliche Begriffe sind z.b. Beschwerde- oder Reklamationsmanagement [SS98] für gebrauchsnahe Bereiche und Qualitäts- oder Fehlermanagement für realisierungsnahe Bereiche [Pfe93]. Der Kundenbegriff muß in diesem Zusammenhang im Sinne des Total Quality Management (TQM) und 4 Lebenszyklen handwerklich hergestellter Produkte und Dienstleistungen mögensichinvielenbereichen unterscheiden, gleichwohl existieren sie.

33 2.3 Beherrschung von Variantenreichtum 15 der Prozeßorientierung [Oak89, Dem86, Fei91, Sch96a] erweitert werden. Kunden sind nicht nur Endnutzer von Produkten, sondern können im gesamten Produktlebenszyklus als Leistungsempfänger auftreten (vgl. Abschnitt 2.4). Aus allen Stufen des Produktlebenszyklus können somit von Kunden Verbesserungen an bestehenden und zukünftigen Produkten und Prozessen eingefordert werden. Jegliche Qualitätsphilosophie kennzeichnet daher den Fehler als Chance zur Verbesserung. Aus Fehlern soll und muß gelernt werden. 2.3 Beherrschung von Variantenreichtum Unterschiedliche Produkttypen haben natürlicherweise unterschiedliche Produktlebenszyklen. Das Erzeugnisspektrum reicht von Massenprodukten in großer Stückzahl, Produkten mit hoher Variantenzahl bis hin zu Sonder- und Einzelanfertigungen (vgl. Tabelle 2.1). Auffallend ist der Variantenreichtum der Produktpalette von kleinen und mittelständischen Unternehmen (vgl. Tabelle 2.1) 5. In 68 % der Unternehmen, die dazu Angaben gemacht hatten, werden auch Standarderzeugnisse in Varianten hergestellt, 79 % gaben an, kundenspezifische Varianten ihrer Typen herzustellen, und Kundenwünsche werden in 79 % der Unternehmen gefertigt. Nur 29 % der Firmen gaben an, überhaupt Standarderzeugnisse ohne Varianten herzustellen. Produktlebenszyklen sind im allgemeinen unternehmensüber- Angaben in % Ja Nein Keine Angabe Standarderzeugnisse ohne Varianten Standarderzeugnisse mit Varianten typisierte Erzeugnisse mit kundenspezifischen Varianten Erzeugnisse nach Kundenspezifikationen Tabelle 2.1: Erzeugnisspektrum von 349 befragten Unternehmen greifend, da Produkte zum einen von Kunden des Unternehmens genutzt werden, zum anderen in der Regel nicht vollständig von einem Unternehmen gefertigt werden. Deshalb sind Fragestellungen des Verbesserungsmanagements notwendigerweise unternehmensübergreifend. Was macht mein Kunde mit meinem Produkt? oder was macht der Kunde meines Kunden mit meinem Produkt? sind typische Fragen, um präventiv in der Produktion mögliche Nutzungssituationen zu berücksichtigen. Aus den Wünschen, die Produktpaletten und die zugehörigen Produktionsprozesse in immer vielfältigere Varianten auszudifferenzieren, um damit eine flexible Anpassung an Kundenwünsche und die Erlangung von Wettbewerbsvorteilen zu erlangen, ergeben sich zwei Probleme im Verbesserungsmanagement: 5 Eine detaillierte Darstellung der zugrundeliegenden Unternehmensbefragung ist in Kapitel 4 zu finden

34 16 Begrifflichkeiten des Verbesserungsmanagements 1. Die Nachvollziehbarkeit der Produktion jeder Variante erfordert umfangreiche Historiendaten, um speziellen Fehlerfällen oder Fehlerbildern nachgehen zu können. Gerade Routine- und Verbesserungsinnovationen stellen aber einen großen Teil des Änderungsmanagements dar. Sie beruhen auf leichten Variationen an Produkten und Prozessen. Fehlerwissen aus den Varianten würde verlorengehen. 2. Für die statistische Prozeßkontrolle, darauf basierenden Verfahren oder die allgemeine Fehleranalyse sind die Grundgesamtheiten in variantenintensiven Fertigungen zu klein. Gleichzeitig sind Probleme, die mehrere Varianten betreffen, in traditionellen Produkt- und Prozeßmodellen nur schwer zu identifizieren. Nach den begrifflichen Bestimmungen zur Organisation und Nutzung Fehlerwissen innerhalb des Verbesserungsmanagements sollen nun die wesentlichen Leitbegriffe im Verbesserungsmanagement Wissensorientierung, Prozeßorientierung, Teamorientierung und Kundenorientierung durch die wesentlichen organisatorischen und methodischen Entwicklungen charakterisiert werden. Damit werden die zur Realisierung des Verbesserungsmanagements zur Verfügung stehenden Optionen gekennzeichnet. 2.4 Prozeß- und Kundenorientierung Während sich Prozeß- und Kundenorientierung bis in die neuen Qualitätsmodelle zumindest der europäischen Fertigungsindustrie nachweisen lassen, ist die konkrete Entwicklung von Informationssystemen auf der Grundlage kooperativer, kundenorientierter Workflow-Modelle zumindest in der Wirtschaftsinformatik noch nicht ausreichend berücksichtigt. Ich rekapituliere kurz ein zentrales Qualitätsoptimierungskonzept, welches Prozeß- und Kundenorientierung als zentrale Elemente beinhaltet. Das derzeitige Ende einer langen Entwicklung, die in den 80er Jahren mit einer zunehmenden Betonung von präventiven Methoden sowie Prozeß- und Kundenorientierung begann, ist das Qualitätsoptimierungskonzept EFQM der Europäischen Qualitätsvereinigung (engl.: European Foundation for Quality Management) [Sim99]. Es belegt in eindrucksvoller Weise den Siegeszug ganzheitlicher, prozeßorientierter Qualitätsauffassungen, die in Abschnitt 2.1 aufgeführt wurden. Im Gegensatz zur ISO 9000ff., die keine Ergebnisse vorschreibt, ist es ein Selbstbewertungsinstrument, ohne das Ziel der Zertifizierung im Auge zu haben. Das EFQM kann mit seiner 50 % Ausrichtung auf Ergebnisse als Reaktion auf die zunehmende Entwicklung der Serviceorientierung gedeutet werden, die durch die Einrichtung neuer Dienstleistungszentren (Call-Centers) belegt ist, aber auch als Reaktion auf die Kritik an der ISO 9000ff., wie sie z.b. von Erb [Erb99] geäußert wurde: Das Aufdecken von Qualitätslücken führt nicht per se zur nachhaltigen Qualitätsverbesserung. Die ISO 9000 Zertifizierung ist keine Qualitätsgarantie für tatsächliche Abläufe.

35 2.4 Prozeß- und Kundenorientierung 17 Häufig fehlt die Motivation zur Umsetzung von Qualitätsmaßnahmen. Prozesse zur kontinuierlichen Qualitätsverbesserung werden nicht immer von allen Beteiligten getragen. Gerade die Umsetzung von abteilungsübergreifenden Qualitätsmaßnahmen scheitert oft am abteilungszentrierten Denken und fehlender Kooperation über Abteilungsgrenzen hinweg. Qualitätsmaßnahmen sind nicht immer allen präsent. Neue Mitarbeiter und Mitarbeiterinnen sind möglicherweise gar nicht über bestehende Qualitätsrichtlinien informiert. Ansätze zur Qualitätsverbesserung versanden oft spätestens nach der ersten Zertifizierung. Befähiger 50 % Ergebnisse 50 % Mitarbeiter 9% Mitarbeiter Ergebnisse 9% Führung 10 % Politik & Strategie 8% Prozesse 14 % Kunden Ergebnisse 20 % Schlüssel- Leistungen Ergebnisse 15 % Partnerschaften & Ressourcen 9% Gesellschaft Ergebnisse 6% Innovation und Lernen Abbildung 2.2: EFQM Das EFQM-Modell (vgl. Abbildung. 2.2) setzt sich aus 5 Wirkungs- oder Befähigerkriterien (Führung, Politik & Strategie, Mitarbeiter(orientierung), Partnerschaften & Ressourcen und Prozesse) sowie 4 Ergebniskriterien (Kunden(zufriedenheit), Mitarbeiter(zufriedenheit), Gesellschaft(liche Verantwortung/Image) und Schlüsselleistungen (Geschäftsergebnisse)) zusammen, die mit 50 % Gewichtung den ergebnisorientierten Charakter des Modells verdeutlichen. Die stärksten Einzelpositionen sind Kunden (20 %), Schlüsselleistungen (15 %) und Prozeßorientierung (14 %). Im Modell wird das Management von Wissen und Ressourcen (9 %) zusammengefaßt mit dem Management von Finanzen, Gebäuden, Technologie usw. Simon [Sim99] kritisiert die Untergewichtung der Innovationsorientierung im EFQM- Modell, betont aber gleichzeitig den Lernschleifen-Charakter des Modells. Natürlich unterliegen Qualitätsmodelle der Veränderung. Das ursprüngliche Modell wurde aufgrund der geäußerten Kritik in einigen Details bei Beibehaltung des Layouts überarbeitet. So wurde

36 18 Begrifflichkeiten des Verbesserungsmanagements der Rückfluß Innovation und Lernen als Pfeil zugefügt, um zusammen mit den bisherigen Pfeilen Befähiger und Ergebnisse einen geschlossenen Zyklus zu bilden. Obwohl das Modell weit über bisherige Qualitätsmanagement-Ansätze wie die ISO 9000ff. hinausgeht und eine besondere Betonung auf den Lern- und Innovationscharakter legt, ist das Modell aus informatischer Sicht in mehrfacher Hinsicht problematisch: Wenn man Führung, Prozesse und Politik & Strategie unter Organisation zusammenfaßt (32 %) wird sofort die Unterbestimmung von Technologie (ein nicht näher spezifizierter Anteil von 9 %) und Mitarbeitern (8 %) als Befähiger des Verbesserungsmanagements deutlich. Die Betrachtung von Wissen und Information als verfügbare Ressourcen wie Gebäuden, Maschinen oder Technologien verkennt die Dynamik der Wissensnutzung und -produktion in den Prozessen. 2.5 Team- und Wissensorientierung Krebs [Kre98, S. 144ff] erwartet, daß der Anteil der wissensintensiven Unternehmen gegenüber den bisher vorherrschenden kapital- und arbeitsintensiven Unternehmen steigen wird. Als Hauptproblem wissensintensiver Unternehmen charakterisiert Krebs den Kampf gegen das Herumirren von Informationen und Wissen im Unternehmen. Starbuck zitierend kennzeichnet er wissensintensiv als nicht notwendigerweise informationsintensiv, da eher extensiv Wissen in Aktivitäten genutzt wird, ohne eine große Anzahl von Informationen zu verarbeiten. Weiterhin stellt er die Bedeutung der esoterischen Expertise als systematischen und differenzierten Sonderwissensbestand im Gegensatz zu allgemein verfügbare, Wissen heraus. Neutraler kann man solche Unternehmen als wissensorientierte Unternehmen bezeichnen [Nor98]. Was bedeuten diese Vorüberlegungen für das Verbesserungsmanagement? Verfahren der (kontinuierlichen) Qualitätsverbesserung sind schon in den 30er Jahren dieses Jahrhunderts systematisch untersucht worden. Shewart entwickelte damals Qualitätskontrollstatistisken für Produktionsprozesse (vgl. [She31], [Pet96, S. 48f],). Der von ihm entwickelte Shewart-Zyklus der kontinuierlichen Verbesserung ermöglichte die Anwendung seiner statistischen Methoden. Diese Methoden sind reaktiv und auf Produktionsprozesse beschränkt. Präventives Qualitätsmanagement verlangt den Aufbau, Austausch und die Nutzung von Wissen sowie die Beteiligung der Mitarbeiter und Kunden über den gesamten Produktlebenszyklus. Deshalb ergänzen in der Verbesserungsmanagementpraxis heute wissens- und teamorientierte Ansätze des Lernens reaktive Verfahren. Qualitätsphilosophien wie TQM [Fei91] und Kaizen [Ima86] sowie die Einführung von Qualitätsstandards wie CMM [MS99], ISO 9000 [DIN90] und EFQM haben zur team- und wissensorientierten Organisation des Qualitätsmanagements, z.b. in Qualitätszirkeln [Pfe93], beigetragen. Teamorientierten Methoden

37 2.5 Team- und Wissensorientierung 19 wie Quality Function Deployment (QFD) mit dem House of Quality [HC88, Aka90] und Fehlermöglichkeits- und -einflußanalyse (FMEA) [Blä90, S. 110ff], [KW92] haben sich in einigen Unternehmen, insbesonders in der Automobil(zuliefer)industrie als Präventionsmaßnahmen durchgesetzt. Regelmäßige Durchführungen von Audits, Schulungs- und Qualifizierungsmaßnahmen und Best-Practice Foren [PRS + 99] erhöhen die Wissensstandards zusätzlich. Das Beschwerde- oder Reklamationsmanagement [SS98] ist durch die stärkere Kundenorientierung vieler Unternehmen zu einer bedeutenden Methode zur Erlangung von Fehlerwissen auf Kundenseite geworden. In Abbildung 2.3 sind einige Methoden des Verbesserungsmanagements in die Dimensionen der Begrifflichkeiten des Verbesserungsmanagements und des Produktlebenszyklus eingeordnet worden. Die Abbildung verdeutlicht, daß alle Methoden in der Abdeckung sowohl der Begrifflichkeiten als auch des Lebenszyklus beschränkt sind. Deshalb muß gespeichertes Fehlerwissen, welches durch die (möglicherweise rechnergestützte) Anwendung dieser Methoden entsteht, in andere Bereiche transportiert und dabei auch in neue begriffliche Kontexte transformiert werden. Beschwerde / Reklamation Begrifflichkeiten Betriebliches Vorschlags wesen Reklamations management Qualität / Fehler Fehlermöglichkeits und Einflußanalyse Statistische Prozeß kontrolle Anforderungen / Erwartungen Quality Function Deployment Lebenszyklus Marktanalyse Entwicklung Produktion Nutzung Abbildung 2.3: Portfolio: Methoden des Verbesserungsmanagements Als Beispiel soll die Methode der Fehlermöglichkeits und -einflußanalyse (engl.: Failure Mode and Effects Analysis (FMEA)) die teamorientierte Nutzung von Fehlerwissen in der Produkt- und Prozeßentwicklung reflektieren. FMEA werden für neue Produkte oder neue Prozesse durchgeführt. FMEA-Arbeit ist Teamarbeit, die in FMEA-Sitzungen durchgeführt werden, zu denen alle betroffenen Fachbereiche eingeladen werden. Daher liegt FMEA auch nicht in der Verantwortung der Qualitätsmanagement-Abteilung, sondern in den Leitungen der Fachbereiche. Die QM-Abteilungen koordinieren die Arbeiten und halten die benötigten

38 20 Begrifflichkeiten des Verbesserungsmanagements Dokumente konsistent. Ohne auf den Prozeß der FMEA-Durchführung näher eingehen zu können (vgl. [Blä90] für weitere Informationen), lassen sich zwei Beobachtungen feststellen. 1. Durch die Durchführung von FMEA in großer Zahl entsteht eine Wissensbasis mit präventivem Fehlerwissen. Das bedeutet, die Verwaltung und Nutzung dieser Wissensbasis für weitere FMEA-Durchführungen in varianten Produkten und Prozessen oder andere reaktive und präventive Verbesserungsmaßnahmen wird zur eigenständigen Aufgabe. 2. Je besser die Rechnerunterstützung und je besser die rechnergestützte FMEA in ein Verbesserungsmanagementsystem integriert ist, desto effektiver läßt sich das erzeugte Wissen verwalten, verteilen und nutzen. Die Möglichkeiten der präventiven Verbesserungsmöglichkeiten werden aber nicht ausreichend genutzt. Es existieren eine Vielzahl von informationstechnologischen Lösungen für Teilbereiche und Methoden des Verbesserungsmanagements. Entwicklungs- und Produktionssysteme sowie werkzeuggestützte Verbesserungsmanagementmethoden ermöglichen die reaktiv-präventive Behandlung von Fehlern und tragen zur Qualitätssteigerung von Produkten und Prozessen bei. Allerdings erfordern viele dieser Methoden die komplexe Erhebung und Verarbeitung von Informationen. Die Problembeschreibung des Projektes Wib- QuS aber faßt die Situation zusammen [Pfe96, S.1]: Doch obwohl die Grundkonzepte und Methoden zur Einführung wirksamer Qualitätsmanagementmaßnahmen schon lange bekannt sind und die ISO 9000 Hilfestellung bei der Bewertung gibt, gelingt es nur selten, das Qualitätsmanagement dauerhaft, effizient und flexibel in die Arbeitsabläufe eines Unternehmens einzubetten. Produktionsplanungs- und -steuerungs-systeme (PPS) [Ros80, Sch88] sowie Workflow-Management-Systeme (WFMS) [WK96, Jab97] unterstützen traditionell vorwärtsgerichte, stabile und mäßig parallele Informations- und Arbeitsflüsse. Die Schließung von Qualitätsregelkreisen [Pfe93] bedarf der systematischen Rückführung von Informationen aus späten Phasen des Produktlebenszyklus (Nutzung beim Kunden oder Fertigung) in frühe Bereiche der Produktplanung und -entwicklung. In der Praxis hängt vieles von einzelnen personengebundenen Kompetenzen oder vom Zufall ab, denn die häufig anzutreffende Ad-Hoc-Natur von Verbesserungsprozessen behindert die effiziente Aufzeichnung und Nutzung von Fehlerwissen. Drei Fallstudien illustrieren die Aufgaben, die mit dem Management von Fehlerwissen verbunden sind. Eine erste Fallstudie realisierte einen navigierbaren, variantenorientierten Fehlerfallkatalog für eine Getriebeproduktion. Die zweite Fallstudie aus dem Bereich des Reklamationsmanagements schildert die Schwierigkeiten, Fehler korrekt zu klassifizieren, wenn keine ausreichende Fehlerwissensbasis vorliegt, die eine systematische und korrekte Identifikation fehlerhafter Produkte leistet. Daneben wird deutlich, daß auf eine Vielzahl von Unternehmensdaten zugegriffen werden muß. Die dritte Fallstudie aus dem Produktionsbereich verdeutlicht den kooperativen Charakter der Fehlerfallerfassung und Fehlerfallbearbeitung in abteilungsübergreifenden Prozessen, die durch Informationssysteme unterstützt werden können.

39 2.6 Fallstudie: Navigation in Fehlerfällen Fallstudie: Navigation in Fehlerfällen Ein erster Ansatz zur Berücksichtigung des gesamten Lebenszyklus eines Produktes unter Berücksichtigung der Varianten ist der Garten der Antworten [JK97, JK98]. Ziele waren: Die Verbesserung der Kommunikation zwischen Entwicklung und Produktion, auch durch multimediale Elemente. Die Klassifikation von Fehlerfällen durch flexible Kategorisierung, wodurch mehrere Wege zu einem Fehlerfall führen können. Die Verbindung zu implizitem Expertenwissen. Aufbauend auf einer sowohl produkt- als auch lebenszyklusbezogenen Variantenbildung und der AnswerGarden-Metapher von Ackerman [AM90] (vgl. Abschnitt 5.3.4) wurde ein erstes variantenorientiertes Unternehmensgedächtnis-System für das Fertigungsbeispiel eines Getriebes gestaltet. Das Unternehmensgedächtnis-System gestattet die fallbasierte Suche nach Fehlerursachen und möglichen Maßnahmen in der laufenden Fehlerfallbearbeitung. Sollte eine Suche nicht erfolgreich sein, besteht an bestimmten Knoten die Möglichkeit, Experten in den betrachteten Gebieten per von dem gerade bearbeiteten Fehlerfall zu unterrichten und um Rat zu fragen. Jeder aufgetretene Fehlerfall wurde über eine der folgenden fünf Kategorien in das System eingepflegt: Produkt: In diesem Teil des Systems sind die Fehlerfälle nach den Produkten, die im Unternehmen hergestellt werden, organisiert. Wählt man eines dieser Produkte an, so werden zunächst die Produktvarianten des Produktes angezeigt. Eine weitere Auswahl führt zu den Baugruppen der Variante. Unter den Baugruppen sind die Fehlerfälle aufgeführt. Abbildung 2.4 zeigt einen Ausschnitt aus dem Fehlerfall Bruch des Stirnrads im System. Eine markierte Konstruktionszeichnung erleichtert die Identifikation des Fehlerortes. Die Konstruktionszeichnung wird auch genutzt, um ein variantenunabhängiges, sensitives Produktbild zu schaffen, wobei der Benutzer nur noch mit der Zeichnung interagiert, um sich per graphischer Auswahl von Fehlerorten einen Überblick über die dort auftretenden Fehlerfälle zu schaffen. Prozeß: Hier werden die Fehlerfälle nach den Bearbeitungsprozessen im Unternehmen organisiert. Wählt man einen Prozeß aus, z.b. Fertigung, so werden die Fehler an den Produktvarianten und die Fehler an den Anlagen angezeigt. In Abbildung 2.5 ist der Fehlerfall Bruch einer Wendeschneidplatte dokumentiert. Beim Drehen einer Welle für das Getriebe war beim Schlichten mehr Aufmaß als geplant vorhanden. Dies resultierte aus einem Fehler beim Schruppvorgang, bei dem als Maßnahme weniger Material weggenommen wurde. Daher war die Wendeschneidplatte überfordert. Als Maßnahme wurde das NC-Programm so geändert, daß nun zweimal geschlichtet wurde, was zu einem längeren Schlichten führte, die Wendeschneidplatte aber nicht mehr brechen ließ. Anlage: In diesem Teil werden die Fehlerfälle nach den Anlagen und Systemen organisiert, die das Unternehmen verwendet. Wählt man eine Anlage aus, so wird man zunächst

40 22 Begrifflichkeiten des Verbesserungsmanagements Abbildung 2.4: Garten der Antworten - Bruch des Stirnrads zu den Typen von Anlagen geführt und danach zu den tatsächlich vorhandenen Anlagen und Systemen. Fehler: Fehlerfälle können zu Fehlern kategorisiert werden. Die Kategorisierung ist unternehmens- und anwendungsspezifisch. In diesem Teil des Gartens der Antworten werden spezifische Kategorien gebildet, über die man zu den Fehlerfällen unter den gewählten Kategorien gelangt. Einsatzumstände: Die Umstände, unter denen Produkte beim Kunden eingesetzt werden, bilden eine weitere Möglichkeit der Organisation von Fehlerwissen. Externe Kunden wurden während der Fertigung durch einen Prüfplatz simuliert. Der Fehlerfall Bruch des Stirnrads, der weiter oben beschrieben wurde, trat unter Stoßbelastung nach einer dreistündigen Prüfzeit auf Der Garten der Antworten ist eine manuell erstellte Sammlung von Fehlerfällen, die bei der Konstruktion, Fertigung, Montage und Prüfung dreier Getriebevarianten in einer Fabrikationsanlage auftraten. Der Aufwand der Realisierung war relativ gering, da es sich um eine begrenzte Anzahl von Produkten, Prozessen, Anlagen und Fehlerfällen handelte. Es ist aber ersichtlich, daß die Erzeugung und Wartung von Fehlerwissen im Praxisbetrieb manuell nicht durchführbar ist. Die Erfahrungen bei der Realisierung des Gartens

41 2.7 Fallstudie: Lenkung fehlerhafter Produkte 23 Abbildung 2.5: Garten der Antworten - Bruch einer Wendeschneidplatte der Antworten waren ein wichtiger Ausgangspunkt für die Realisierung eines nachhaltigen vernetzten Verbesserungsmanagementsystems. Wichtig ist neben der Speicherung des expliziten Wissens ein Zugang zu Experten eines Gebiets, da nur ein Bruchteil des verfügbaren Wissens tatsächlich aufgenommen werden kann. Die multimediale Darstellung der Fehlerfälle förderte die Kommunikation zwischen den Abteilungen. Neben dem reinen Fehlerfall sollte die Bearbeitungshistorie mit aufgenommen werden, da gerade sie wichtige Erkenntnisse über Vorgehensweisen und Fehler des Verbesserungsmanagements enthält. Der Aufwand der Erstellung muß wesentlich gesenkt werden. 2.7 Fallstudie: Lenkung fehlerhafter Produkte Reklamations- oder Beschwerdemanagement gilt als unternehmerische Herausforderung und bildet zusammen mit dem Zufriedenheitsmanagement den Kern einer Kundenbindungstrategie [SS98]. Gerade im Bereich des Beschwerdemanagements ist es wichtig, ne-

42 24 Begrifflichkeiten des Verbesserungsmanagements ben den Daten über das Beschwerdeobjekt auch andere Erfassungsinformationen aufzunehmen, z.b. das Ausmaß der Verärgerung und die Handlungsabsicht des Beschwerdeführers, den Bezug des Beschwerdeführers zum Beschwerdevorfall oder die Stellung des Beschwerdeführers gegenüber dem Unternehmen [SS98, S. 122ff]. Die Messung der Kundenzufriedenheit ist problematisch, da sie nicht allein von der Abweichung von definierbaren Qualitätsmerkmalen eines Produktes abhängt, sondern von der subjektiven Erwartungshaltung eines Kunden (vgl. [SS98, S. 39 ff], [Sch96a, S. 11] 6 ). Eine Unternehmens-Fallstudie der Schnittstelle Kunde und Unternehmen wurde innerhalb des Projekts AdCo [JK99] in einem norddeutschen Unternehmen der Medizintechnik durchgeführt. Die Herstellung chirurgischer Geräte und Implantate zeichnet sich durch hohe Anforderungen an die Erfüllung medizinischer, medizintechnischer und rechtlicher Qualitätsmaßstäbe aus. Untersuchungsfeld der Studie war die Lenkung fehlerhafter Produkte (Qualitätsmanagement-Element nach DIN EN ISO ), die von Kunden in das Unternehmen kommen und die Schnittstelle von Reklamationsmanagement und Änderungsmanagement, also die Umsetzung von Maßnahmen zur Verbesserung von Prozessen und Produkten im Unternehmen. Anlaß der Fallstudie war der Wunsch des Unternehmens, die Prozeßgestaltung für die beiden beschriebenen Prozesse durch den Lehrstuhl für Informatik V der RWTH Aachen begutachten zu lassen. Die Soll-Prozesse waren in einem einjährigen Zeitraum sehr elaboriert mittels strukturierter Ablaufdiagramme, bestehend aus Tätigkeiten und Entscheidungen, die zu Verzweigungen führen, dargestellt worden. Die Abteilung Qualitätsmanagement (QM) hatte aber Schwierigkeiten mit der Einführung der Soll-Prozesse. Diese Schwierigkeiten waren der QM-Abteilung selbst nicht erklärlich, so daß eine externe Begutachtung der Soll-Prozesse zu einem Durchbruch verhelfen sollte. Die Begutachtung wurde in eintägigen Workshops durchgeführt, in denen die Mitglieder des Modellierungsteams, bestehend aus Mitarbeitern des QM, der Reparaturabteilung, der Fakturierung und des Eingangs- Warenlagers, arbeitsplatzorientierte Informationsflußanalysen [NJJ + 96] unter der Moderation von Lehrstuhlmitgliedern durchführten. Beim ersten Workshop wurde zunächst eine Ist-Modellierung der Prozesse durch die Mitglieder des Teams durchgeführt, die durch eine darauffolgende Schwachstellenanalyse folgende Ziele für den Prozeß Lenkung fehlerhafter Produkte definierten: Kontinuierliche Prozeßverbesserung einheitliche Benutzer- und Kundenschnittstelle Verläßlichkeit und Transparenz Kostenzuordnung 6 Schäl gibt folgende Definition von Kundenzufriedenheit: Customer satisfaction is the intangible aspect of quality which the customer expresses about the global properties and characteristics which allow a product, or a service, to satisfy the customer s explict as well as implicit needs. Customer satisfaction is a result of a good communicative relation which serves to manage commitments and breakdowns within a customer/supplier chain. 7 Sicherstellung, das als fehlerhaft erkannte Produkte für die weitere Benutzung oder eine unbeabsichtigte Verwendung gesperrt werden. Die weitere Behandlung der fehlerhaften Teile, d.h. Nacharbeit und Wiederholprüfung, Reparatur oder Ausschuß, muß festgelegt werden.

43 2.7 Fallstudie: Lenkung fehlerhafter Produkte 25 Minimierung der beteiligten Organisationseinheiten Korrekte Klassifikation der fehlerhaften Produkte Einheitliche Behandlung fehlerhafter Produkte aus In- und Ausland Verfügbarkeit der vollständigen Produktinformationen (einheitliche Fehlerschlüssel) Problem Ursache Mögliche Maßnahme Einheitliche Kundenschnittstelle Mangelnde Verläßlichkeit und Transparenz der Lenkung Zu viele Schnittstellen Minimierung der beteiligten Organisationseinheiten fehlerhafter Produkte Ad hoc Lenkung Kontinuierliche Prozeßverbesserung Personenabhängige Bearbeitung Verbindliche Prozesse Keine systematische Fehleranalyse möglich Keine Klassifikation Korrekte und systematische Klassifikation fehlerhafter Produkte Keine Kostenzuordnung möglich Ad hoc Interpretation von Fehlerursachen Keine Kostenzuordnung Keine Ermittlung von Fehlerkosten Einheitliche Behandlung fehlerhafter Produkte aus Aus- und Inland Verfügbarkeit der vollständigen Produktinformationen (einheitlicher Fehlerschlüssel) Tabelle 2.2: Herausforderungen an Lenkung fehlerhafter Produkte Bei der Analyse der Ergebnisse des Workshops wurde deutlich, daß die Probleme besonders in der Interpretation des Fehlerbildes und in der für Kunden und Mitarbeiter gleichermaßen undurchsichtigen organisatorischen Struktur der Fehlerbearbeitung lagen. Dazu kam eine fehlende Kostenzuordnung. Tabelle 2.2 faßt die Ziele (mögliche Maßnahmen), die Ursachen und die zugrundeliegenden Probleme noch einmal zusammen. Die Bearbeitung von Fehlern hängt bei diesem Unternehmen vordringlich von der Klassifikation eines eingegangenen Werkstücks ab. Folgende Klassen werden im Unternehmen verwendet: Complaint (eine an nationale und internationale Behörden meldepflichtige Reklamation mit definierter Reaktionszeit) Reklamation Garantiefall Reparatur mit oder ohne Kulanz Behindert wurde die Klassifikation weiterhin durch die vielfältigen Möglichkeiten eines Produktes, in das Unternehmen zu gelangen. Daraus resultierten unterschiedliche Wege fehlerhafter Werkstücke durch das Unternehmen. Durch Reklamationen können Änderungen an Prozessen und Produkten im Unternehmen ausgelöst werden. Zentral für das Änderungsmanagement ist eine Sammlung von Dokumenten, die zum einen aus organisatorisch geprägten Anträgen, zum anderen aus technischen Dokumenten bestehen, teilweise mit schon eingetragenen Änderungswünschen. Diese Sammlung begleitet einen Änderungsvorgang vom Moment der Eingabe bis hin zum validierten oder verifizierten Ende der Ände-

44 26 Begrifflichkeiten des Verbesserungsmanagements rungsmaßnahme. Insgesamt stellt das Reklamationsmanagement einen wichtigen Untersuchungsgegenstand für das Verbesserungsmanagement dar. Fehlerwissen wird vom Kunden in das Unternehmen gebracht. Um es nutzbar zu machen, müssen Unternehmen es aber in eine für sie nutzbare Form bringen. Die Organisation des Reklamationsmanagements hat einen entscheidenden Einfluß auf das Bild des Kunden vom Unternehmen. Neben kurzen Reaktionszeiten (vgl. Abschnitt 4.4.3) ist auch Zuordbarkeit von Verantwortlichkeiten für den Kunden entscheidend ( One Face to the Customer, [Sch96a, S. 14], Complaint Ownership [SS98, S. 68]). Dazu ist es notwendig, eine systematische und korrekte Klassifikation des Fehlerfalls als Fehler vorzunehmen, z.b. um die notwendige Klärung zu ermöglichen, ob es sich um eine berechtigte und/oder meldepflichtige Reklamation oder um einen kostenpflichtigen Reparaturfall handelt. Die Klassifikation verlangt eine Wissensbasis, die eine Interpretation des vorliegenden Fehlerbildes nicht nur aufgrund von fehlerhaften Produkteigenschaften ermöglicht, z.b. ein durchgebrannter Elektromotor in einem chirurgischen Instrument, sondern auch aufgrund der Stellung des Kunden zum Unternehmen, z.b. Großklinikum mit hohem Transaktionsvolumen, und der Nutzungsumstände, z.b. Arzt hat chirurgische Säge mit Gewalt in das falsche Antriebsmodul plaziert, usw. Eine solche Wissensbasis geht notwendigerweise über die Speicherung und Nutzung von Qualitätsdaten hinaus. Sie muß Informationen aus anderen Unternehmensbereichen nutzen können, z.b. aus dem Vertrieb. Eine solche Wissensbasis stellt anderen Unternehmensbereichen im umfangreicheren Maße Wissen zur Verfügung. 2.8 Fallstudie: Fehlererfassung in der Fertigungskette Im Bereich der Fertigung sind Abweichungen von Soll-Wert Indikatoren für Qualitätsprobleme, wenn die Meß- oder Prüfwerte bestimmte Toleranzgrenzen überschreiten. Aber schon beim Prüfen durch Mitarbeiter spielt die Interpretation eines Sachverhaltes eine Rolle. So ist zum Beispiel die Qualität der Sichtprüfung von Werkstücken von der Leistungsfähigkeit, der Erfahrung und dem Können des Einzelnen abhängig, was auch in der Entlohnung berücksichtigt wird. Beim untersuchten Unternehmen handelt es sich um einen metallverarbeitenden Betrieb, der seine Produkte in mittlerer Losgröße (100 bis Stück) fertigt, wobei die Fertigungsschritte Kernherstellung, Gießen, mechanische Bearbeitung, Schleifen, Polieren, Galvanisierung und Montage umfassen. Kern der Fehlererfassung war eine Sichtkontrolle der Werkstücke durch Werker in der Schleiferei. Fehlerfälle umfassen Blasen, Kratzer und ähnliches an verschiedenen Stellen der Werkstücke. Bei dieser Prüfung, die alle Werkstücke durchlaufen, werden diese in vier Kategorien (vgl. Tabelle 2.3) eingeteilt und über mechanische Zähluhren im Akkord verbucht. Als wesentliche Gründe für den Einsatz einer informationssystem-gestützten Lösung für

45 2.8 Fallstudie: Fehlererfassung in der Fertigungskette 27 GUT FNA ANA SR Gutteile Firmennacharbeit: Teile mit Fehlern, die nicht der Schleiferei angerechnet werden und deshalb wie Gutteile bezahlt werden Arbeiternacharbeit: Teile mit Schleiferfehlern, die nicht bezahlt werden Schrott: unbrauchbare Teile Tabelle 2.3: Kategorien der Fehlerfallerfassung in der Schleiferei das Verbesserungsmanagement hat die Fallstudie [Poh97] die in Tabelle 2.4 aufgeführten Probleme erkannt: Problem Papierwirtschaft Ursache Mangelnde DV-Unterstützung Mögliche Maßnahme Schaffung einer Wissensbasis für Korrekturmaßnahmen Erfassung in Datenbank statt Tabellenkalkulation Produktivität der Teams und Prüfer vergleichbar machen Übersichtliche Auswertung Keine systematische Fehleranalyse möglich Keine ausreichenden Informationsflüsse entlang der Wertschöpfungskette Keine Systematik zur Objektivierung von Fehlerstellen Mangelndes Feedback zwischen Abteilungen und Kompetenzkonflikte Mangelnde DV-Unterstützung Rückmeldung durch grafische Auswertung der Fehlerstellen (Punktwolken) Schaffung abteilungsübergreifender Informationsflüsse Unterstützung der internen Umgestaltung von hierarchischen Strukturen zu vernetzten Teams Erhaltung von Wissen über Fertigungsschritte hinweg Nutzung von Teilemarkierungen Tabelle 2.4: Herausforderungen an Fehlererfassung in Prozeßketten Die im Rahmen einer Diplomarbeit implementierten Lösungen sorgten für die systematische Erfassung und Auswertung der Fehlerereignisse und haben mittlerweile die manuelle Erfassung und teilautomatische Auswertung ersetzt. Erkennbar wurde, daß mit lokalen Verbesserungen die grundsätzliche Problematik abteilungsübergreifender Informationsflüsse nicht in den Griff zu bekommen war. Es wurde die Bildung von Teams angeregt, deren Mitglieder aus den Abteilungen entlang der Wertschöpfungskette stammen sollten, um die Kommunikationsstrukturen bei der systematischen Ursachenbekämpfung zu verbessern. Dafür bildete das Erfassungs- und Auswertungssystem eine Grundlage.

46 28 Begrifflichkeiten des Verbesserungsmanagements 2.9 Zusammenfassung In diesem Kapitel wurden die zugrundeliegenden Annahmen des Verbesserungsmanagements (Team-, Prozeß-, Wissens- und Kundenorientierung) anhand begrifflicher und historischer Untersuchungen explizit gemacht. Dadurch soll die Basis für die informatische Unterstützbarkeit geschaffen werden. Im Gesamtprozeß des Verbesserungsmanagements sind folgende Bedingungen zu beachten, welche die notwendige Einbindung in Qualitätsstrategien wie das EFQM betonen: Verbesserungsmanagement ist eine unternehmensübergreifende Aufgabe: Obwohl z.b. die Kompetenz für die Durchführung von Qualitätssicherungsmethoden bei den QM-Abteilungen liegt, sind durch die Einführung wissens- und teamorientierter Verfahren auch andere Unternehmenseinheiten beteiligt. Zudem führen zunehmende Kunden- und Prozeßorientierung weg von einer abteilungs- und unternehmensinternen Gestaltung des Verbesserungsmanagements, hin zu einer Einbeziehung des gesamten Produktlebenszyklus in der gesamten unternehmensübergreifenden Wertschöpfungskette. Damit ist in vielen Fällen eine notwendige Transformation des Unternehmens verbunden. Ohne eine Führungsrolle der Unternehmensführung, wie sie auch vom TQM gefordert wird, läßt sich das Verbesserungsmanagement nicht implementieren. Die Gestaltung von Verbesserungsmanagementprozessen muß prozeß- und kundenorientiert erfolgen: Wenn die Steigerung von Mitarbeiter- und Kundenzufriedenheit nicht im Mittelpunkt des Unternehmensinteresses liegen, die gesellschaftliche Verantwortung eines Unternehmens nicht ausreichend berücksichtigt wird, kann das Verbesserungsmanagement nicht greifen. Erfolgt die Gestaltung von Prozessen des Verbesserungsmanagements nicht kundenzentriert, wird die Bearbeitung von Reklamationen für den Kunden undurchsichtig. Das Unternehmen ist nicht in der Lage, Informationen zum aktuellen Bearbeitungsstand und zur Fertigstellung der Dienstleistung zu geben. Daher ist es notwendig, Prozesse des Verbesserungsmanagements kundenzentriert zu gestalten. Folgende Kernpunkte bei der Organisation und Nutzung von Fehlerwissen wurden festgehalten: Fehlerwissen ist grundsätzlich fallbasiert und besitzt viele Facetten. Die mögliche Emotionalität des Fehlererlebens erzwingt die Nutzung reichhaltiger Medien zur Wiedererlebbarkeit. Kunden stellen eine wichtige Quelle von Fehlerwissen dar. Eine eindeutige Kundenschnittstelle erhöht die Transparenz für den Kunden. Fehlerwissen kann im gesamten Produktlebenszyklus erzeugt und genutzt werden, wodurch Fehlerwissen speicherbar, transportierbar und (u.u. in neue begriffliche Kontexte übersetzt) abrufbar sein muß. Für die Behebung von Fehlern müssen übergreifende Informationsflüsse geschaf-

47 2.9 Zusammenfassung 29 fen werden, wobei die Teambildung die notwendigen Kommunikationsstrukturen zur Verfügung stellt. Fehlerwissen dient als Grundlage für Produkt- und Prozeßverbesserung. Die systematische und korrekte Klassifikation von Fehlern verlangt eine Fehlerwissensbasis und den Zugriff auf verteilte Unternehmensdaten.

48 Kapitel 3 Nachhaltigkeit und Vernetzung bei der Organisation und Nutzung von Fehlerwissen Probleme sind Gelegenheiten, zu zeigen, was man kann. Duke Ellington Ziel dieses Kapitels ist die Schaffung eines theoretischen Rahmenwerkes zur Realisierung von Informationssystemen für das Verbesserungsmanagement. Wesentliches Kennzeichen des Rahmenwerkes ist die Verbindung nachhaltig angelegter Wissensorganisation mit der raschen Bildung vernetzter Verbesserungsteams, die kooperativ und koordiniert Fehlerfälle lösen. Für die konkrete Gestaltung und Nutzung von Fehlerwissen motiviere ich einen organisationstheoretisch begründeten Ansatz auf der Grundlage der Transformation von Fehlerwissen (vgl. Abschnitt 3.1), der die Fragen beantwortet, wie und wo Wissen im Verbesserungsmanagement entsteht, und wie Organisationen dieses Wissen effizient zum Lernen aus Fehlern (vgl. Abschnitt 3.2) unter der Prämisse kooperativer Informationssysteme nutzen können. Dies erlaubt, Beziehungen, die zwischen den einzelnen Facetten der eingesetzten Informationssysteme bestehen, in den Blick zu nehmen. Darauf aufbauend untersuche ich informatisch motivierte Ansätze zur Gestaltung von Unternehmensgedächtnis- Systemen und entwickle einen Ansatz zur langfristigen Wissensorganisation, der Wissensprozesse als primäre Ressource zur Erzeugung und Bewahrung von Fehlerwissen kennzeichnet (vgl. Abschnitt 3.3). Die kurzfristige Bildung von vernetzten Verbesserungsteams zur kooperativen und koordinierten Bearbeitung von Prozessen im Verbesserungsmanagement erfolgt über ein sogenanntes Eskalationsprinzip des Verbesserungsmanagements (vgl. Abschnitt 3.4).

49 3.1 Dynamische Wissensumwandlung Dynamische Wissensumwandlung Nach Nonaka und Takeuchi [NT95] erzeugen Unternehmen Wissen dynamisch nach einem zyklischen Vier-Modi-Modell durch das transformative Zusammenspiel von nicht artikuliertem (implizitem) und explizitem Wissen. Implizites Wissen (engl.: tacit knowledge) ist persönliches Wissen, welches nur schwer zu formalisieren ist. Explizites Wissen ist formelles Wissen, das leicht zwischen Individuen und Gruppen ausgetauscht werden kann. Zusammen mit den Beobachtungen von Organisationstheoretikern [MO76, AS78, DW79, Hub91, KL98] impliziert das Modell einen Prozeß zum Aufbau und Nutzung eines Unternehmensgedächtnisses für das Verbesserungsmanagement Modi der Wissenstransformation Externalisierung Implizit Explizit Sozialisierung Kombination Implizit Explizit Internalisierung Abbildung 3.1: Modi der Wissensumwandlung (adaptiert aus [NT95]) Es existieren vier Modi der Wissenstransformation: Sozialisierung, Externalisierung, Kombination und Internalisierung. 1 1 Zur Erläuterung der Transformationen gebe ich ein Beispiel aus der Geschichte der Mathematik, die Entwicklung der Algebra. Das erste Buch zur Algebra war eine lateinische Übersetzung des arabischen Autors Al-Kohwatizmi mit dem Titel Algebra aus dem Jahre 825. Da der Buchdruck in Europa zu diesem Zeitpunkt noch nicht erfunden und die Darstellung der mathematischen Gesetzmäßigkeiten nicht kanonisiert war, gab es eine sechshundert Jahre lange Phase, in der Algebra wie eine Geheimwissenschaft vom Meister auf den Schüler übertragen wurde (Sozialisierung). Erst im Jahre 1591 schrieb Francois Vieta das erste Werk über Algebra (Artem analyticum isagoge), welches eine symbolische Notation verwendete. Er schlug vor, frühe Buchstaben aus dem Alphabet für unbestimmte Konstanten und späte Buchstaben aus dem Alphabet für unbestimmte Variablen zu verwenden. Die Stärke dieser Konvention wird deutlich, wenn wir überlegen, daß wir heute angesichts der Formel ax + b = 0 nicht fragen, nach welchem Buchstaben wir auflösen sollen (Externalisierung). Im folgenden Jahrhundert wurde die Verwendung von Symbolen in

50 32 Nachhaltigkeit und Vernetzung Sozialisierung (implizit zu implizit) beschreibt den Prozeß des Wissenserwerbs von nicht artikuliertem Wissen, wie z.b Schüler es von Meistern durch Beobachtung, Imitation und Praxis lernen. In Abschnitt 3.4 wird das Eskalationsprinzip als Vernetzungsstrategie des Verbesserungsmanagements vorgestellt. Sozialisierung wird dort mit der Externalisierung zur Bildung virtueller Verbesserungsteams verbunden. Externalisierung (implizit zu explizit) beschreibt die Umwandlung von implizitem zu explizitem Wissen. Die Externalisierung im Verbesserungsmanagement verläuft auf der Grundlage kooperativ erstellter Modelle mittels der Erfassung und Analyse von Fehlerwissen. Die Transformation von explizitem in neues explizites Wissen heißt bei Nonaka und Takeuchi Kombination (explizit zu explizit). Auf Grundlage externalisierten Fehlerwissens lassen sich verschiedene Verfahren der Analyse von Fehlerwissen anwenden. Der Kreis wird geschlossen durch die Internalisierung (explizit zu implizit), die explizites Wissen wieder in die tägliche, implizite Arbeitspraxis zurückbringt. Lehner [Leh00] schreibt dazu: Wettbewerbsvorteile auf der Basis von explizitem Wissen sind meist kurzfristiger Natur, da sie relativ leicht nachgeahmt oder kopiert werden können. Langfristige Vorteile, die schwer zu imitieren sind, entstehen hingegen durch die Verankerung und Aktivierung von Wissen in den Unternehmensprozessen. 2 Weggemann [Weg99, S. 51] definiert - Weick folgend: Lernen ist das Durchlaufen eines Prozesses, durch den - implizit oder explizit - das Wissen bereichert wird. E r führt weiter aus, daß ein Lernprozeß das gleiche ist wie ein Wissenserzeugungs- oder Wissensproduktionsprozeß. Weiter schreibt er: Folgerichtig kann Lernen beschrieben werden als Einsetzen von verfügbarem Wissen, um das Wissen besser für die Ausführung einer Reihe von Aufgaben, die sich mit der Zeit verändern, anzupassen. Lernen von Unternehmen wird nach Nonaka und Takeuchi [NT95] durch fortlaufende Verbesserungen an Produkten und Prozessen realisiert, die notwendigerweise alle vier Modi der Wissenstransformation durchlaufen. Dieses Lernen wird von diesen Autoren durch kulturabhängige Phasen-Modelle der Wissensschaffung beschrieben, die in Abschnitt 3.2 vorgestellt werden. Die Wissenschaffung beruht wiederum auf fünf notwendigen Voraussetzungen (Intention, Autonomie, Fluktuation/kreatives Chaos, Redundanz und notwendige Vielfalt). Dadurch wird eine Spirale der Wissensschaffung erzeugt, die epistemologisch explizites Wissen insgesamt vermehrt, dabei aber ontologisch zwischen individueller und (inter-)organisatorischer Ebene zyklisch pendelt. anderen Bereichen der Mathematik erfolgreich benutzt, so von Descartes ( ) in der Geometrie und von Leibniz ( ) in der Differentialrechnung (Kombination). Heutzutage ist Algebra Schulstoff, der in den weiterführenden Schulen unterrichtet wird (Internalisierung). 2 Hier wird unter explizitem Wissen m.e. öffentlich zugängliches Wissen verstanden.

51 3.1 Dynamische Wissensumwandlung Fehlerwissen Ein autonomer, sich selbst am Leben erhaltender Prozeß der Wissensgenerierung, wie ihn Nonaka und Takeuchi konzipieren und wie er von anderen Autoren als wesentliches Merkmal (vgl. [Wie96]) für das Lernen von Organisationen gekennzeichnet wird, kann für das Verbesserungsmanagement nicht genügen. Es bleibt die Frage, wie Fehlerwissen innerhalb des Verbesserungsmanagements erzeugt und genutzt wird. Der Fehler und das Fehlermachen sind die Grundvoraussetzung für den Erwerb von Fehlerwissen [Ose94]. Wie schon in der Einführung erwähnt, ist Fehlerwissen (negatives Wissen) das Wissen um das, wie etwas nicht ist oder falsch ist (deklaratives Fehlerwissen), oder was man nicht tun soll (prozedurales Fehlerwissen). Die Bedeutung des Fehlerwissens liegt in der Schärfung des positiven Wissens. Da das Fehlerereignis die wichtigste Wissensquelle im Verbesserungsmanagement ist, muß ein Wissenstransformationsansatz vom Fehlerereignis ausgehen. Wie Fehlerereignisse in einen allgemeinen Wissenstransformationsansatz eingefügt werden können, wird durch einen Ansatz des Organisationalen Lernens (vgl. Abschnitt 3.2) vollzogen. Die Wissensgenerierung startet unabhängig von der Kultur mit der Beobachtung und Interpretation von Fehlerereignissen (vgl. Abbildung 3.2). Da emotionale Aspekte eine wesentliche Rolle Externalisierung Implizit Explizit Sozialisierung Kombination Kunde Fehlererkennung Implizit Internalisierung Explizit Abbildung 3.2: Fehlerereignisse als Wissensquelle beim Fehlererleben spielen, kann die Fehlerhaftigkeit eines Produktes von verschiedenen Personen völlig verschieden beurteilt werden. Für einen Kunden, dessen Produkt funktionsunfähig ist, kann dies extreme psychische Auswirkungen haben. Für einen Mitarbeiter im Call-Center, der dies schon mehrfach an einem Tag gehört hat, sind die persönlichen Auswirkungen durch die Gewöhnung gering einzuschätzen. Von der Ebene der Organisation aus kann das Problem aber gerade durch die Vielzahl der eingegangen Reklamationen, bei-

52 34 Nachhaltigkeit und Vernetzung spielsweise im Rahmen einer Frequenz-Relevanz-Analyse, kritisch werden, da sich hier eine systematische Funktionsstörung ihres Produktes abzeichnet, die eine ganze Produktserie oder zumindest ein größeres Los betreffen kann. Zwei Gestaltungsbereiche für die Repräsentation von Fehlerwissen zeichnen sich in dieser Argumentation ab. Zum einen muß der Sachverhalt festgehalten werden, zum anderen müssen Interpretationen aus unterschiedlichen Perspektiven und auf unterschiedlichen Ebenen ermöglicht und dokumentiert werden. Für den Wissensbegriff bedeutet dies, daß das Fehlerwissen verteilbar, also kommunizierbar (i.s. von verstehbar für andere) sein muß. Deshalb muß eine externalisierte Repräsentation des Fehlerwissens geschaffen werden. Daß für alle Betrachter ein gemeinsames Verständnis durch die Bewertung geschafft werden soll (vgl. auch [DW79, SZ95]), kann nun ersetzt werden durch die Schaffung eines perspektiven- bzw. ebenenabhängigen Konsens - das aktuelle Fehlerbild - der durch den Prozeß der Wissenserzeugung auf ein einheitlichen Verständnis zustrebt. Historisch wird diese Entwicklung beispielsweise durch die Einführung von wissens- und teamorientierten präventiven Methoden der Qualitätssicherung (vgl. Abschnitt 2.5) nachvollzogen. Für die Gestaltung von Informationssystemen bedeutet dies, daß Fehlerwissen nicht allein auf der Grundlage nachprüfbarer Wahrheiten oder vorgegebener Interpretationsschemata, sondern auf der Basis gemeinsamer (kooperativer) Interpretationen der Wissensrepräsentation von Fehlerfällen beruhen. 3 Damit zu jedem möglichen Interpretationszeitpunkt der möglichst vollständige Kontext vorliegt, muß eine Vielzahl von Medien eingesetzt werden, um den Kontext für eine erneute Auswertung reichhaltig aufzubereiten. Im Reklamationsmanagement werden z.b. Audiodaten eingesetzt, um die Verärgerung eines Kunden für den späteren Gebrauch realitätsnah zu dokumentieren. Bei der Analyse fehlerhafter Produktionsanlagen können Photos fehlerhafter Produkte oder Videos der Produktion hilfreich sein. Zusammengefaßt gilt, das Fehlererleben, Fehlerfolgenbeseitigung und Fehlerfallbearbeitung oft räumlich und zeitlich getrennt erfolgen, so daß zwischen diesen Geschehnissen eine Speicherung des Fehlerwissens erfolgen muß Typen von Fehlerereignissen Letztendlich ist Fehlerwissen nur ein Mittel zum Zweck der Entscheidungsfindung. Fehlerwissen hilft, Entscheidungsräume zu strukturieren, Zusammenhänge zu verstehen und Alternativen zu bewerten und auszuwählen [Pfe96, S. 4]. Dhar stellt in Anlehnung an March fest [Dha98], daß Unternehmen oft durch die Zurückweisung schlechter Alternativen lernen, weil deren Auswirkungen beobachtbar sind. Dies führt zu einer Korrektur von erkannten Fehlern an Produkten und Prozessen. Dagegen werden verpaßte Chancen oft nicht 3 Ein solches Verständnis unterscheidet sich deutlich von traditionellen Auffassungen von der Gestaltung von Informationssystemen, die auch bei Nonaka und Takeuchi zu finden sind, wenn sie explizites Wissen als objektives Wissen bezeichnen [NT95, S. 60f] (vgl. [Lyy87, KL92, Pet96] für eine vertiefende Betrachtung).

53 3.1 Dynamische Wissensumwandlung 35 Ergebnis Erfolg Fehler Verpasste Wahrer Erfolg Gelegenheiten (Typ II Fehler) Fehler (Typ I Fehler) Wahrer Mißerfolg Ablehnung Annahme Entscheidung Abbildung 3.3: Fehlertypen (adaptiert aus [Dha98]) erkannt, da die Auswirkungen nicht beobachtbar sind. Dies beschränkt sogleich die Fähigkeit des Unternehmens zu lernen (vgl. Abbildung 3.3). Im folgenden werden festgestellte oder vermutete Abweichungen an Produkten und Prozessen, egal ob sie durch Beschwerden, Reklamationen oder andere Verfahren festgestellt werden, als Typ I Fehlerereignis bezeichnet, wobei weiterhin nach Produkten und Prozessen differenziert werden soll. Als Typ II Fehlerereignis soll alles bezeichnet werden, was nicht unternommen wurde, aber potentiell die festgestellte oder vermutete Situation verbessert hätte [Jar98]. Über ein Beispiel für tragische Typ II Fehlerereignisse wurde z.b. im SPIEGEL(SPIEGEL 42/1999 und SPIEGEL4/2000) berichtet. Gleich zwei verpaßte Gelegenheiten sind zu erkennen und führten zu einer schwerwiegenden Eskalation, die dem Unternehmen insgesamt schadete. 50 Unfälle und fünf Tote mit dem Audi TT sind dem Hersteller VW bekannt geworden, die durch die konstruktionsbedingte, sportliche Auslegung des Automobils hervorgerufen wurden. Obwohl das durch Fahrwerksschwächen des TT hervorgerufene kritische Grenzbereichverhalten auch den Testern und der Fachpresse bekannt war, wurden die möglichen Lösungen, ein fester Spoiler und ein ausfahrbarer Heckspoiler, aus Prestige- bzw. Kostengründen nicht gewählt (1. Typ II Fehler). Stattdessen wurde als unsichtbare Billiglösung ein 15 Kilogramm schweres Metallgewicht unter dem Kofferraum installiert. Das konnte aber das Problem nicht vollständig lösen, da es noch schwerer hätte sein müssen. Dies konnte nicht realisiert werden, da beim Autobau das Ziel Gewichtsreduktion eine erheblich höheren Stellenwert bekommen hat. Elektronische Lösungen, die nun serienmäßig eingebaut werden, standen zu dem Zeitpunkt nicht zur Verfügung. Auch die gutmütige Auslegung des Fahrwerks kam nicht in Frage, da der TT ein Sportgerät sein sollte. Der Fehler wurde zu spät erkannt und korrigiert. Zwar wird mittlerweile eine elektronische Fahrwerksstabilisierung (ESP) serienmäßig eingebaut, diese konnte jedoch nach Angaben von Audi nicht nachgerüstet werden (2. Typ II Fehler). Eine mittlerweile auch vorgesehene Umrüstung des Fahrwerks und die Montage eines Spoilers wird Audi nach internen Schätzungen 50 Millionen Mark kosten. Die TT-Fahrer, die ihre Sportwagen tauschen oder

54 36 Nachhaltigkeit und Vernetzung zurückgeben möchten, liegen in einem langwierigen Rechtsstreit mit Audi. Jedes Nachgeben von Audi würde ein Eingeständnis eines Fehlers bedeuten und könnte spektakuläre Schadensersatzansprüche und Umsatzeinbrüche in den USA nach sich ziehen, wo 5000 Audi TT zugelassen sind. Der Vertrauensverlust der Kunden wiegt für Audi schwer und wird durch die Medien weiter verstärkt Implizites und explizites Wissen Ein wichtiger Baustein in Nonakas Konzepten ist laut [Wie96, S. 254] die auf Polanyi [Pol66] zurückgehende Unterscheidung in explizites und implizites Wissen, wobei Information und Wissen nicht gleich gesetzt werden. Information ist nach Nonaka der Fluß von Nachrichten. Und Wissen der daraus entstehende Fluß der in den Wissensträger durch Zustimmung und Überzeugung verankerten Bedeutungen [NT95, S. 58]. Obwohl Nonaka Polanyi zitiert, entsprechen nach Auffassung von Wiegand die Konzeptualisierungen impliziten Wissens einander nicht. Nonaka versteht implizites Wissen als relativ direkt übertragbar, während Polanyi explizit schreibt: We can know more than we can tell [Pol66, S. 4]. Mir scheint auch die Unterscheidung Polanyis zwischen Wissen und Können in Bezug auf implizites Wissen sinnvoll. 4 Ein handlungsorientierter Blickwinkel [Leh00] deutet an, daß z.b. zwischen dem Wissen um die Ausführung einer Handlung und der Handlung selbst ein Unterschied besteht. Für das Verbesserungsmanagement ist die Unterscheidung zwischen implizitem und explizitem Wissen insoweit bedeutsam, daß aufgrund der verteilten Natur von Fehlerwissen ein kommunizierbarer Wissensbegriff benötigt wird. Deshalb sind gerade die kommunizierbaren Aspekte impliziten Wissens der Teil des impliziten Wissens, der schon immer aufgrund seiner Medialität externalisierbar ist. Fehlerwissen setzt sich aus Sachverhalten und Interpretationen dieser Sachverhalte aus unterschiedlichen Perspektiven und auf unterschiedlichen Ebenen zusammen. Die von Scheer und Trumpold eingebrachte Definition von Qualitätsinformation verlangt sowohl von der Vergleichs- als auch von der Bewertungsvorschrift zur Bildung der Qualitätsinformation, daß sie für alle Betrachter ein gemeinsames, reproduzierbares Begriffsverständnis schafft. Aufgrund der Bemerkungen über den Charakter impliziten Wissens kann die Trennung von Sozialisierung und Externalisierung im Sinne Nonakas für das Verbesserungsmanagement nicht aufrecht erhalten werden. Da Fehlerwissen kommuniziert werden muß, ist es dann immer schon externalisiert. Eine neue Unterscheidung ist für das Verbesserungsmanagement deshalb sinnvoll. Sozialisierung wird für das Verbesserungsmanagement als die Erzeugung, Weitergabe und Nutzung von Fehlerwissen in implizit definierten Wissensnetzwerken definiert, während die Externalisierung die gleichzeitige Aufdeckung dieser 4 We have here examples of knowing, both of a more intellectual and more practical kind; both the wissen and können of the Germans, or the knowing what and knowing how of Gilbert Ryle. [Pol66, S.6f]

55 3.2 Lernen im Verbesserungsmanagement 37 impliziten Strukturen und die systematische Erfassung und Nutzung des kommunizierten Wissens bedeutet. 3.2 Lernen im Verbesserungsmanagement Der Wissensgenerierungsprozeß ist abhängig von der kulturellen Herkunft eines Unternehmens. Das Maß, wie weit Wissen von Individuen bzw. Gruppen generiert wird, ist kulturabhängig. Für das Verbesserungsmanagement ist dies bei der Frage, wie japanische Qualitätsphilosophien adaptiert werden, von entscheidender Bedeutung. Hedlund und Nonaka [HN93] haben die ihrer Meinung nach archetypischen Prozesse der Wissensgenerierung in westlichen Industriestaaten (hier aber nur die US-amerikanischer Landeskultur) und Japan gegenübergestellt (vgl. Abb. 3.4 und 3.5). Nach Ansicht der Autoren werden in westlichen Industriestaaten Ideen vor allem von außen an eine Organisation herangetragen, bis zur Entscheidungsreife entwickelt und bei Annahme durch Dekomposition in Aufgaben zerlegt und bearbeitet. Im Gegensatz dazu beginnen japanische Wissensgenerierungsprozesse auf Gruppenebene durch dialogische Reflexion, die in der Einrichtung einer Projektgruppe münden können. Die zentrale Rolle der dialogischen Reflexion wird besonders in der deutschsprachigen Literatur vernachlässigt. 5 Für das Verbesserungsmanagement sind zwei Gesichtspunkte zu beachten. Zum einen wirken sich die durch Übernahme japanischer Qualitätsphilosophien institutionalisierten Teamansätze natürlich auch auf die Methoden der Wissensgenerierung aus. Zum anderen ist der Prozeß der Fehlerbehebung über den Produktlebenszyklus verteilt, z.b. wenn der Kunde einen Fehler in seinem Produkt entdeckt und dieser von einem Servicetechniker repariert wird. Damit wird ein Prozeß dialogischer Reflexion impliziert, da es um die Verbreitung von Fehlerwissen im Produktlebenszyklus geht, die die Voraussetzung von Lernprozessen ist. Eine Theorie, wie die Beeinflussung auf verschiedenen Emergenzebenen tatsächlich vor sich geht, bietet das Organisationale Lernen. Eine offene Definition von Organisationalem Lernen entlehne ich [Wie96, S. 324]: Organisationales Lernen hat stattgefunden, wenn durch zustandsgebundene (Lern)-Prozesse in und/oder von Organisationen Wissen geschaffen wurde, das die Verhaltensmöglichkeiten der Organisation c.p. vergrößert. 5 In der deutschsprachigen Organisationsliteratur häufig vernachlässigt, als Störquelle aufgefaßt oder auf die personale Ebene (Individuum) beschränkt. Der Grund dafür mag die Schwierigkeit darstellen, sie vorherzusagen, formal zu erfassen oder gar zu steuern. Erst im Rahmen der Organisationsentwicklung und des organisatorischen Lernens versucht man, selbtsgestaltende oder selbstrukturierende Prozesse in den Prozeß der substantiellen Gestaltung miteinzubeziehen [Leh00]. Insbesondere Argyris [AS78, AS96] beschäftigt sich mit dem Verhältnis von Individuum und Organisation.

56 38 Nachhaltigkeit und Vernetzung Individuum (2) Gruppierung der Organisation um eine Idee Gruppe Organisation Interorganisationaler Raum Explizites Wissen (1) Individuelle Ideen (3) Aufgabe wird auf Gruppenenebene herunter gebrochen 2. Phase: Beschränkt durch Artikulation (4) Spezifische Verträge mit anderen Organisationen Implizites Wissen (5) Output: Produkte, Personen, Know How Abbildung 3.4: Archetypisches Modell westlicher Wissensgenerierungsprozesse nach Hedlund und Nonaka [HN93] (adaptiert aus [Wie96, S. 258]) Durch die Vielzahl der Forschungsarbeiten in den letzten Jahren ist deshalb zunächst eine Klassifikation der Ansätze in Schulen notwendig. Nach [KT97] lassen sich die organisationstheoretischen Untersuchungen zum Thema lernende Organisation in vier Entwicklungslinien einteilen: Erfahrungsorientierter Ansatz: Nach March und Olsen [MO76] lernen Organisationen aus ihren Erfahrungen. Sie handeln, beobachten und ziehen Konsequenzen für zukünftige Handlungen, wobei der Lernprozeß als Methode von Versuch und Irrtum beschrieben werden kann. Dieser Ansatz ist auch der älteste und folgt zunächst der behavioristischen Tradition der empirischen Psychologie. Interpretationsorientierter Ansatz: Argyris und Schön [AS78] definieren den Lernprozeß von Organisationen als mehr oder weniger radikale Fehlerkorrektur in den Umweltinterpretationen. Während inkrementelles Lernen (Single-loop) die Umweltinterpretationen lediglich verfeinert, werden diese beim fundamentalen Lernen (Double-loop) grundsätzlich in Frage gestellt und ggf. gänzlich neu definiert. Dieser Ansatz vollzieht eine kognitive Wende,

57 3.2 Lernen im Verbesserungsmanagement 39 (1) Artikulierte Ideen aus der Umwelt Individuum Gruppe Organisation Interorganisationaler Raum (3) Intensive Gruppen reflektion und Dialoge (2) Einrichtung einer Projektgruppe (4) Wichtiger Input von Kunden Explizites Wissen (1) Bestimmung der Hauptziele, der Anstrengungs grade, Unternehmensstil, Kultur Implizites Wissen (5) Output: Produkte Abbildung 3.5: Archetypisches Modell japanischer Wissensgenerierungsprozesse nach Hedlund und Nonaka [HN93] (adaptiert aus [Wie96, S. 258]) da er sich nicht mehr auf beobachtbares Verhalten zurückzieht, sondern individualpsychologische Fragestellungen mit einbezieht. Informationsverarbeitender/entscheidungsorientierter Ansatz: Nach Huber [Hub91] findet Lernen in einer Organisation dann statt, wenn durch die Verarbeitung von Information die Spanne der möglichen Handlungsweisen erweitert oder fokussiert wird. Wissensorientierter Ansatz: Dieser Ansatz sieht das Wissen der Organisation als Artefakt, den es aktiv zu managen gilt [DW79]. Noch stärker als interpretationsorientierte und informationsverarbeitende Ansätze betont er die optimierende Transformation der Wissensbestände in Organisationen (Unternehmensgedächtnis) und deren fortlaufendes organisatorisches und informationstechnologisches Management. Als deutscher Vertreter dieser Auffassung ist Pautzke [Pau89] zu nennen. Eine tiefgreifende Untersuchung im deutschsprachigen Raum zum Thema des Lernens von Organisation ist die Arbeit von Wiegand [Wie96], die sich mit einer Vielzahl der in der Literatur verfaßten Ansätze systematisch auseinandersetzt. Dabei werden nicht nur wis-

58 40 Nachhaltigkeit und Vernetzung senschaftliche Ansätze berücksichtigt, sondern auch die sogenannte Managementliteratur, die vor allem im US-amerikanischen Raum eigene Schulen hervorgebracht hat. Die Untersuchungen zeigen nach Wiegand folgende Ergebnisse: Es gibt weder ein einheitliches Konzept noch eine einheitliche Definition des Begriffs Organisationales Lernen. Durchgesetzt hat sich zumindest in der US-amerikanischen Organisationspraxis der Ansatz von Senge [Sen90], der sich aufgrund der strategischen Partnerschaft zu Argyris [AS78, AS96] auch längerfristig halten wird. Als Perspektive und Fazit sieht Wiegand [Wie96, S. 310] 6,daßsichzukünftige konzeptionelle Entwicklungen auf die organisationale Wissensbasis, d.h. das Unternehmensgedächtnis beziehen werden. In der Regel fehlen die Explizierung und Offenlegung der organisationstheoretischen Grundlagen. Deshalb sind Fragen nach Emergenzebenen des Lernens (Individuum, Gruppe, Organisation, Ökologie) oder dem ontologischen oder handlungsorientierten Status von organisationalen Wissen nur schwer bzw. überhaupt nicht zu beantworten. Eine ernstzunehmende empirische Basis der Forschung über Organisationales Lernen existiert nicht. Vor allem fehlen intensive Einzelfallstudien, qualitative Befragungen von Topmanagern und sowohl qualitative als auch quantitative Untersuchungen des Lernen und der Informationsverarbeitung von Gruppen und Subsystemen der Organisationen. Oser [Ose94] hat in seinen Untersuchungen an Schulkindern Erfahrungen gemacht, die den Einfluß von Fehlerwissen auf das Lernen aus Fehlern deutlich machen: Das Lernen aus Fehlern ist inhaltlich facettenreich, z.b. bedeutet es Erfahren von Grenzen, Gewinn von Normenkenntnis, negativem Wissen, personalem Wissen, die Erfahrung von Fehler-machen-und-trotzdem-akzeptiert-Sein, Fehler machen und trotzdem das Selbstvertrauen nicht verlieren. Kleinere Fehler bewirken in erster Linie eine Rückbesinnung auf die Norm und festigen das negative Wissen. Die Wirkung des Lernprozesses muß sich nicht notwendigerweise in einer Einstellungs- und Verhaltensmodifikation manifestieren. Große Fehler können den Charakter von kritischen Lebensereignissen haben und bewirken häufiger nicht nur Lernprozesse im Sinne der Wissensfestigung oder des Wissenszuwachses, sondern können nach tiefgreifenden Einsichten auch Einstellungsund Verhaltensmodifikationen bewirken. Emotionen sind ein wesentliches Element des Fehlererlebens. Beim Lernen aus Fehlern werden komplexe Emotionen wie Schuld, Scham und Reue wirksam. Dinge, die man nicht getan hat (Typ II Fehler), wirken oft besonders stark und lange nach. Sie werden oft als besonders große Fehler bezeichnet. Für das Verbesserungsmanagement übernehme ich den Ansatz von Argyris und Schön mit 6 Es ist zu erwarten, daß die zukünftige konzeptionelle Entwicklung Organisationalen Lernen in der Regel unter Bezugnahme auf die - wie auch immer konzipierte - organisationale Wissensbasis erfolgen wird. [Wie96, S. 310]

59 3.2 Lernen im Verbesserungsmanagement 41 einem starken Fokus auf das Management der organisationalen Wissensbasis. Nach Argyris und Schön [AS78] wird Organisationales Lernen als ebenfalls selbtstreferentieller Prozeß verstanden [Leh00], und es existieren drei Typen des Organisationalen Lernens: Single-loop learning (SLL): Diese Form des Organisationalen Lernens wird dann ausgeführt, wenn Fehler entdeckt und korrigiert werden, das Unternehmen aber ihre strategischen Prozesse (vgl. [Pet96]) nicht ändert. Double-loop learning (DLL): Wenn zusätzlich zur Fehlerentdeckung und -korrektur die existierenden Normen, Prozeduren, Policies und Ziele geändert werden, dann wird dies von Argyris und Schön mit DLL bezeichnet. DLL umfaßt die Veränderungen der organisatorischen Wissensbasis und der unternehmensspezifischen Kompetenzen und Routinen. Deutero-learning (DL): Deutero-learning tritt auf, wenn ein Unternehmen in der Lage ist, die ersten beiden Formen des Organisationalen Lernens zu beherrschen. DL bezogen auf SLL führen laut Argyris und Schön zu Lernkurveneffekten, dagegen bleibt der Lernmodus DL bezogen auf DLL offen. 7 Allerdings führt Wiegand [Wie96, S. 213f] aus, daß sich die Konzepte des SLL und des DLL im Grunde nur durch die weitere Überprüfung der zugrunde liegenden Handlungstheorie unterscheiden und somit ein durch Tiefe geschiedenes Kontinuum organisationalen Lernens darstellen. Verbesserungsmanagement kann somit als SLL und DLL auftreten. Deutlich tritt die Rolle von Fehlerereignissen bei der Art des Lernens in Erscheinung. Nach Oser [Ose94] vertieft und erweitert gerade die Schwere des Fehlergeschehens die Lernprozesse. Die Lernprozesse vollziehen sich auf vier Ebenen, wie Lehner [Leh00] ausführt. 1. Detection (Problemfindung) 2. Invention (Lösungsvorschlag erarbeiten) 3. Production (Praktische Umsetzung des Lösungsvorschlags) 4. Generalization (Verallgemeinerung und Speicherung der Lösung nach erfolgreicher Umsetzung) Übertragen auf die Situation im Verbesserungsmanagement heißt dies: nach dem Auftreten des Fehlerereignisses wird der Fehlerfall erfaßt und analysiert, wodurch möglicherweise eine Korrekturmaßnahme erarbeitet wird, die dann ausgeführt wird. Der Fehlerfall wird dann einem Fehler zugeordnet und in der organisationalen Wissensbasis abgespeichert. Dabei werden im Rahmen des Eskalationsmodells notwendigerweise alle Transformationsmodi des Fehlerwissens durchlaufen. Ein der industriellen Anwendung entnommenes Beispiel verdeutlicht das Lernen im vernetzten Verbesserungsmanagement. Am Helpdesk wird eine Kundenbeschwerde über ein Industriegetriebe aufgenommen. Im konkre- 7 Weggemann [Weg99, S. 63] beschreibt die Ziele von Deutero-Lernen als effektive und effizientere Erkennung und Korrektur von Fehlern sowie als Einsatz von erfolgreichen Reflexionsprozessen.

60 42 Nachhaltigkeit und Vernetzung ten Fehlerbild verliert das Getriebe Öl. Aus den bisherigen Erfahrungen kann der Helpdesk keinen direkten Ratschlag zur Behebung des Problems geben. Daher wird ein Reparaturauftrag an einen Monteur vergeben. Dieser fährt zum Kunden, um den Fehlerfall vor Ort zu beheben. Während der Reparatur entdeckt er, daß die Dichtungsringe des Getriebes an der Antriebswelle nicht korrekt montiert wurden (Problemfindung). Er setzt neue Dichtringe ein (Lösungsvorschlag erarbeiten, Praktische Umsetzung des Lösungsvorschlags). Um das Auftreten dieses Fehlerfalls in Zukunft zu verhindern, wird die weitere Behandlung dieses Fehlerbildes an die Abteilungen im Fertigungsbereich (hier Montage) weitergegeben. Die verantwortliche Abteilung versucht, die tieferen Ursachen des Fehlerbildes herauszufinden und Abstellmaßnahmen aufgrund der vorgenommenen Diagnosen zu definieren. Der Erfolg der Maßnahmen muß dokumentiert und im Produktlebenszyklus weitergeleitet werden. Nach verschiedenen Annahmen und Versuchen, den Fehlerfall an seiner Quelle zu beseitigen, wird schließlich die grundlegende Ursache ermittelt. Ein Fehlerereignis im Montagehandbuch für das Getriebe wurde von der Montageplanung an die Montage weitergeleitet. Die Qualitätskontrolle war nicht in der Lage, das Fehlerbild zu diagnostizieren, weil die Kontrollroutinen nicht effektiv angewendet wurden (Problemfindung). Das Montagehandbuch wird überarbeitet (Lösungsvorschlag erarbeiten) und die entsprechenden Seiten gegen die alten in allen vorhandenen Kopien ausgetauscht (Praktische Umsetzung des Lösungsvorschlags). Die Kontrollroutinen für die Abnahme des Montagehandbuchs werden in der Produktplanung verbessert. Der Helpdesk wird von der Problemfindung unterrichtet. Er kann nun Kunden mit entsprechenden Getrieben benachrichtigen oder direkt Aufträge an Monteure vergeben (Verallgemeinerung und Speicherung der Lösung nach erfolgreicher Umsetzung). Das Beispiel zeigt sowohl SLL als auch DLL im Verbesserungsmanagement. Auf der einen Seite kann der Helpdesk nun (möglichst proaktiv) schnelle Reparaturmaßnahmen initiieren, was künftige Bearbeitungen des Fehlers beschleunigt. Auf der anderen Seite kann die Produktplanung in Zusammenarbeit mit dem Qualitätsmanagement in zukünftigen Fertigungsläufen und Produktgenerationen das Problem an der Quelle abstellen. DL tritt auf, wenn das Unternehmen die Fehlerbearbeitung effektiv und effizienter durchführen kann. Die operative Umsetzung dieser Lernprozesse für das Verbesserungsmanagement werden in Abschnitt 3.4 für die Gestaltung von operativen kurzfristigen Mikro- und Makroprozessen für die Strukturierung von Eskalationen im vernetzten Verbesserungsmanagement vorgestellt. Zunächst werden aber nun die Prozesse zur nachhaltigen, d.h. langfristigen Organisation des Fehlerwissens in einer expliziten Wissenbasis eingeführt. 3.3 Nachhaltigkeit: Ein rechnergestütztes Gedächtnis für das Verbesserungsmanagement Team- und Wissensorientierung haben im Verbesserungsmanagement systematische, zielgerichtete und transparente Vorgehensweisen ermöglicht. Kunden- und Prozeßorientierung im Verbesserungsmanagement unterstützen diese Entwicklungen durch Fokussierung und Res-

61 3.3 Nachhaltigkeit 43 sourcenbündelung. Daß dennoch Fehlerwissen nicht im ausreichenden Maße genutzt werden kann, deshalb auch Fehlerursachen nicht abschließend behoben und die durch die Fehlerfallbearbeitung aufgebauten Potentiale nicht systematisch erschlossen werden, liegt auch an der mangelnden Einbettung des Verbesserungsmanagements in die alltägliche Arbeitspraxis. Die Einbettung des Verbesserungsmanagements in die alltägliche Arbeitspraxis und die Prozesse eines Unternehmens unter den Randbedingungen des stetigen, sich rasant beschleunigenden Wandels bleibt somit zentrales Anliegen des Verbesserungsmanagements. Damit sollen erstens Mitarbeiter bei der Durchführung ihrer Aufgaben unterstützt werden, zweitens die Zusammenarbeit gefördert werden und drittens die Lernkapazität des Unternehmens erhöht werden. Daher ist der erste Schritt zur Gestaltung eines nachhaltigen Verbesserungsmanagements die Schaffung einer expliziten Wissensbasis zur Bewahrung des Fehlerwissens. Die Schaffung einer expliziten Wissensbasis soll die Akzeptanz und die Effizienz in der Anwendung von Methoden des Verbesserungsmanagements erhöhen. Die reine Bewahrung von Fehlerwissen stellt noch keinen Vorteil für das Unternehmen dar. Erst die Möglichkeit, Fehlerwissen innerhalb und außerhalb des Unternehmens zu teilen, birgt einen unmittelbaren Wert. Deshalb muß die Wissensbasis Teil eines Informationssystems sein, das für die Bereitstellung des Fehlerwissens an den notwendigen Stellen im Produktlebenszyklus sorgt. Darüber hinaus muß das Informationssystem die notwendige Kooperation zur Nutzung des Fehlerwissens und das Lernen aus Fehlern in einer sich ständig ändernden Welt unterstützen Kooperative Informationssysteme im VVM Kooperation und Veränderung werden als Leitbegriffe im Forschungsrahmenwerk der kooperativen Informationssysteme eingeführt [DMDJ + 97, DMDJ + 98].NochinderTradition der Wirtschaftsinformatik definiert Hansen ein Informationssystem [Han96, S. 67]: Ein Informationssystem (abgekürzt: IS; engl.: information system) besteht aus Menschen und Maschinen, die Information erzeugen und/oder benutzen und durch Kommunikationsbeziehungen miteinander verbunden sind. Weiter definiert er: Ein betriebliches Informationssystem dient zur Abbildung der Leistungsprozesse und Austauschbeziehungen im Betrieb sowie zwischen dem Betrieb und seiner Umwelt. Eine sowohl soziologische als auch technologische Umorientierung [Stu92] nimmt nicht mehr nur die Prozesse in den Blick, sondern auch die Praxis der Arbeit. Alter [Alt92] faßt dies zusammen und definiert ein Informationssystem als eine combination of work practices, information, people, and information and communication technologies organized to accomplish goals in an organization. Im Rahmen ihrer Theorie bezeichnen DeMichelis et al. [DMDJ + 97, S. 317] ein Informationssystem als kooperativ, if it shares goals with other agents in its environment, such as other information systems, human agents and the organization itself, and contributes positively towards the fulfillment of these common goals. Die Autoren betonen dabei, daß Kooperation in betrieblichen Informationssystemen und

62 44 Nachhaltigkeit und Vernetzung Geschäftsprozessen weitaus komplexer ist als die Teilhabe an Informationen und Interoperabilität der Systeme. Kooperation stellt keine neutrale Kategorie dar, da durch sie betriebliche Prozesse abgearbeitet und verändert werden. Zudem werden in diesem Prozeß Informationen, Regeln und Ziele erzeugt und verändert. Als Hauptaufgabe wird nun nicht der Bau von Informationssystemen angestrebt, die die Ziele mit ihrer Umgebung zu einem Zeitpunkt teilen, sondern Informationssysteme, die kontinuierlich diese Ziele teilen, so wie die Ziele in der Umwelt sich verändern [DMDJ + 97, S. 318]. In Abbildung 3.6 sind die drei Facetten kooperativer Informationssysteme: Lokale Arbeitspraxis, Organisation und Informationstechnologie und ihre Beziehungen zueinander abgebildet. Jeder Facette kann eine Perspektive zugeordnet werden, die den Fokus der Betrachtung verdeutlicht. Im Bereich der Gruppenarbeit spielen praktische Aspekte die Hauptrolle, die formale Organisation wird durch das Management abgedeckt, während auf der Systemseite operationale Gesichtspunkte die Hauptrolle spielen. Den Beziehungen zwischen den Facetten kann weiterhin eine Forschungsrichtung zugeordnet werden, die die primären Erkenntnis- und Gestaltungsziele ausdrücken. Die Pfeile zeigen die Art der Einflußnahme einer Facette auf eine andere. Gruppenarbeit/ Individuen Organisationstheorie Steuerung Nachvollziehbarkeit Organisation/ Geschäftsprozesse technologiegestütztes Arbeiten Spezifikation Archivierung Modellfortschreibung / CSCW (Komponentenorienterte) Informationstechnik Informationssysteme Wirtschaftsinformatik Abbildung 3.6: Kooperative Informationssysteme (adaptiert aus [DMDJ + 97]) Der Organisationsaspekt befaßt sich mit den globalen Belangen einer Organisation, die in Geschäftsprozessen beschrieben werden können. Dies geschieht ungeachtet dessen, durch wen (Aspekt der Zusammenarbeit) oder mit welcher Technologie (Systemaspekt) dieses durchgeführt wird. Veränderungen in diesem Bereich haben aber normalerweise Auswirkungen auf die Gestaltung der Arbeitspraxis und stellen Anforderungen an die unterstützende Technologie dar. Das Spannungsverhältnis des Einzelnen bzw. der Gruppe und der Organisation ist Forschungsgegenstand der Organisationstheorie. Entsprechend der Vielzahl der Organisationsmöglichkeiten und der Betrachtungsebene gibt es eine Unzahl von Mikro-,

63 3.3 Nachhaltigkeit 45 Makro- und Mesotheorien [Wie96] über die gegenseitige Beeinflussung von Praxis und formaler Organisation. Grundsätzlich ist davon auszugehen, daß die formale Organisation das Verhalten der Gruppen und Individuen innerhalb der Organisation steuert und gleichzeitig Änderungen innerhalb der Praxis nachvollzieht. Die Koordination von Aktivitäten, die Entwicklung von Arbeitsweisen und das Lernen gehört zum Gebiet der Arbeitspraxis. Die verschiedenen Arbeitsweisen (im Verbesserungsmanagement speziell teamorientierte Arbeitsweisen wie FMEA und QFD) werden bereits durch Werkzeuge aus dem Groupware-Bereich unterstützt und beeinflußt (technologiegestütztes Arbeiten). Jedoch verlangt die Zusammenarbeit in Gruppen ein hohes Maß an Flexibilität auf Systemseite. Weiterhin verlangt die offene und variable Art der Zusammenarbeit eine stete Spannung mit der festen und formalen Art der Struktur einer Organisation. Gruppen bilden sich aus menschlichen und zunehmend künstlichen Agenten [DMDJ + 97]. Zur Systemseite gehören die verschiedenen Arten DV-basierter Systeme, wie z.b. Groupware, Datenbanken und Workflow-Management-Systeme. Durch Systemintegration wurden Probleme des Austauschs von Daten und Funktionalitäten überwunden. Dennoch tauchen einerseits neue Probleme der Inflexibilität beim Einsatz in der Gruppenarbeit auf, und andererseits müssen sich Organisationen mit den hohen Durchlaufzeiten und Kosten bei der Entwicklung auseinandersetzen. In [DMDJ + 97] werden deshalb flexible komponentenund agentenbasierte Architekturen vorgeschlagen, die mit den sich beschleunigenden Entwicklungen wesentlich besser zurechtkommen sollen Ansätze zur kooperativen Informationssystementwicklung Auch IS-Entwicklungstheorien reflektieren den kontinuierlichen, sich beschleunigenden Wandel in der Prozeßgestaltung und Systementwicklung, berücksichtigen aber den dadurch ausgelösten Wandel der Arbeitspraxis kaum. Deshalb werden nur Organisationsentwicklung und Informationstechnologie als sich gegenseitig bedingend gedacht. Nach der wirtschaftsinformatischen These der structuration theory [OR91] sind Systemeinsatz und Systementwicklung untrennbar verzahnt. So wird die Gestaltung von Geschäftsprozessen zur Spezifikation von Informationssystemen genutzt. Der Rückfluß an Informationen aus den Informationssystemen dient zum einen der Archivierung von ausgeführten Workflows zur Dokumentation von Geschäftsvorfällen, zum anderen kann er genutzt werden, um Geschäftsprozeß- bzw. Workflow-Modelle fortzuschreiben [Pet96, WWT98]. Vossen und Becker [VB96, S. 18f] folgend, soll ein Prozeß als inhaltlich abgeschlossene zeitliche und sachlogische Abfolge der Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind definiert werden. Ein Geschäftsprozeß soll ein hier nicht näher bestimmtes Element der Menge der Prozesse in einem Unternehmen sein. Die Abbildung von Geschäftsprozessen in Informationssysteme erfolgt mittels Geschäftsprozeß- Modellen, die über Workflow-Modelle in Informationssystemen operationalisiert werden können [Hei94, Amb95, Jab95, Kir95]. Die Geschäftsprozeß-Modellierung wird von Hammer und Champy [HC93] als der Kern von Unternehmensgestaltung (engl.: Business En-

64 46 Nachhaltigkeit und Vernetzung Unternehmensgestaltung (z.b. Geschäftsprozeßmodellierung) kontinuierliche Veränderung (z.b. Arbeitsablauforganisation) Organisationsentwicklung Informationssystementwicklung (z.b. Workflow-Management) Abbildung 3.7: Globales Vorgehensmodell für die Gestaltung informationssystem-gestützter Organisationsstrukturen (adaptiert aus[jab97, S. 8]) gineering) angesehen. Geschäftsprozesse stehen daher bei der Betrachtung eines Unternehmens im Vordergrund. Sie zeichnen sich dadurch aus, daß sie einen wesentlichen Teil zum Geschäftserfolg beitragen. Im allgemeinen sind Geschäftsprozesse nicht so detailliert festgelegt, daß sie in Teilbereichen oder ganz durch ein Workflow-Management-System (WFMS) unterstützt werden können. Ein WFMS dient als flexibles Ausführungssystem für Geschäftsvorgänge, die dafür in Workflows transformiert werden müssen [MB91]. Daher erfolgt zunächst in der globalen Phase Organisationsentwicklung eine weitergehende Modellierung der Geschäftsprozeßspezifikation, sofern dies möglich ist. Diese wird dann zur Workflow-Modellierung herangezogen [Jab97] (vgl. Abb. 3.7). Abbildung 3.6 macht deutlich, daß sich CSCW (engl.: Computer Supported Cooperative Support) und Wirtschaftsinformatik relativ unabhängig voneinander entwickelt haben. 8 Dennoch muß die Weiterentwicklung die Richtungen zusammenführen. Zur Weiterentwicklung des Gebietes CSCW tragen nach [HS94] die Disziplinen Informatik und Wirtschaftsinformatik u.a. auch die Arbeitswissenschaften und die Psychologie bei. Es wird zwischen drei eng zusammenhängenden Forschungsbereichen unterschieden (vgl. [Krc92]): 1. Entwicklung eines Verständnisses der Kooperation und Koordination. 2. Entwicklung von Konzepten und Werkzeugen zur Unterstützung von Kooperation, die unter dem Titel Groupware zusammengefaßt werden können. In der Praxis wird Groupware oft auf Messaging-Funktionen, d.h. , Diskussionsforen, Sitzungsunterstützungssysteme usw. reduziert [BVO99]. 3. Bewertung dieser Konzepte und Werkzeuge. Deshalb sind häufig genannte technologische Ansätze zur Gestaltung von Informationssystemen im Wissensmanagement zwar wichtige Bausteine der kooperativen Informationssy- 8 Die prominenten Konferenzen beider Richtungen werden weitestgehend von disjunkten Personenkreisen besucht.

65 3.3 Nachhaltigkeit 47 stementwicklung, können aber eine facettenübergreifende Betrachtung nicht ersetzen, denn die Nachhaltigkeit der technologischen Lösungen ist ständig durch den Änderungsdruck bedroht Bedrohungen der Nachhaltigkeit Warum muß ein Gedächtnis für das Verbesserungsmanagement selbst wieder ein kooperatives Informationssystem sein? Was kann passieren, wenn auf Änderungen in der Umwelt oder im Unternehmen nicht reagiert wird? Was sind die Auswirkungen auf ein Unternehmensgedächtnis, dessen Funktionen nicht durch ein kooperatives Informationssystem in Teilen unterstützt wird? Drei mögliche Störungsformen können folgendermaßen für jeden der Teilbereiche kooperativer Informationssysteme gekennzeichnet werden: Organisation: Das Business Reengineering [HC93] zerstört gewachsene Strukturen informeller Netzwerke. Rapides Wachstum, sich ändernde Organisationsstrukturen und Ausweitungen sowie Individualisierung der Produkt- und Dienstleistungspaletten ergeben die Notwendigkeit, Prozesse den neuen Gegebenheiten anzupassen. Auch das Verbesserungsmanagement ist aufgrund der organisatorischen Änderungen selbst wieder Änderungen unterworfen. Gerade durch die ISO 9000ff. ausgelöste Änderungen an Geschäftsprozessen haben die Strukturen vieler Unternehmen grundlegend verändert und gewachsene Strukturen oft übereilt aus dem Gleichgewicht gebracht oder gar zerstört [MS99, Sim99]. Informationssysteme: Änderungen in der DV-Infrastruktur führen zu Systemchaos. Auch in den empirischen Ergebnissen (vgl. Kapitel 4) läßt sich zeigen, daß die fortlaufende Dezentralisierung von Dienstleistungen und die Fragilität realisierter Schnittstellen zu erheblichen Mehrbelastungen führen, die in keinem Verhältnis zur Leistungserstellung stehen. Arbeitspraxis: Gerade weil das VVM eine unternehmensweite Aufgabe ist, können Personalfluktuationen und die Einführung oder Entwicklung von Methoden des Verbesserungsmanagements Einfluß auf die Nutzbarkeit personengebundenen Wissens haben. Nicht zuletzt durch die Anstrengungen im Business Reengineering sind im mittleren Management viele Stellen eingespart worden. Gleichzeitig sammelte sich in dieser Ebene viel Wissen über Projekte, Kunden und Produkte [AD99]. 9 9 Carley [Car92] beschreibt in einer Studie auf der Grundlage von Simulationsergebnissen, daß in einem Unternehmen, in welchem die einzige Speichermöglichkeit für organisatorisches Wissen die Angestellten selbst sind, Personalwechsel zu Informationsverlusten führt. Deshalb hält sie es für möglich, durch Verwendung von externalisierten Speichermöglichkeiten die (negativen) Auswirkungen von Personalwechseln auf die Leistungsfähigkeit eines Unternehmens zu mindern. Allerdings bleibt anzumerken, daß Personalfluktuation auf unterschiedliche Organisationsformen unterschiedliche Auswirkungen haben. Carley schreibt, daß Bürokratien wesentlich resistenter gegen die Auswirkungen der Fluktuation sind.

66 48 Nachhaltigkeit und Vernetzung Der Theorie kooperativer Informationssysteme folgend hat jede Störung in einem der Teilbereiche sofort Auswirkungen auf die jeweils anderen Bereiche. Der wichtigste Unterschied von kooperativen Informationssystemen zu anderen Systemen ist das Ziel, die Kooperation der drei Bereiche zu ermöglichen und trotz ständiger Störungen oder Veränderungen fortzusetzen. Das Handhaben der Veränderung ist damit integraler Bestandteil kooperativer Informationssysteme und das Ziel des Änderungsmanagements [JJPP97, DMDJ + 98] 10. Das Reverse Engineering und die Reimplementation, als Techniken des Änderungsmanagements, werden deutlich erleichtert, wenn Wissen, das in früheren Zyklen gewonnen wurde, genutzt werden kann. Dies motiviert die zentrale Rolle des Unternehmensgedächtnisses im Verbesserungsmanagement. Für die Gestaltung der wesentlichen Prozesse bilden die Leitkategorien Agent, Werkzeug und Prozeß, im Theorierahmen der kooperativen Informationssystem herausgebildet, die Grundlage der Abstraktion. Basis für die Einbeziehung von Techniken des Änderungsmanagements in kooperativen Informationssysteme sind Introspektion und Reflexion. Änderungsprozesse in allen drei Facetten müssen explizit definiert sein, damit sie und ihre Auswirkungen auf die Facetten insgesamt nachvollziehbar sind. Deshalb ist es notwendig, die Wissensbasis so zu gestalten, daß sie sowohl die notwendigen Modelle und Informationen zum Betrieb des Informationssystems bereitstellt, als auch Mittel, um die Änderungen nachvollziehbar zu gestalten. Es besteht die Gefahr, daß dies in einen stetigen Wettlauf der Modellierer mit der Realität führt, wenn diese Änderungsprozesse manuell definiert werden müßten. Dieser Gefahr muß durch teilweise Automatisierung der Änderungsprozesse begegnet werden. Nicht nur die von den Modellen und Informationen beschriebene Wirklichkeit ist Gegenstand der Änderung, auch das kooperative Informationssystem selbst ist Gegenstand der Änderung. Dieser Vorgang führt zu einem Regreß, der nur dadurch aufgehalten werden kann, wenn die Modelle des kooperativen Informationssystems Möglichkeiten der Reflexion beinhalten, d.h. das kooperative Informationssystem muß selbstbeschreibend sein. Abbildung 3.8 stellt das Gedächtnis des Verbesserungsmanagements als kooperatives Informationssystem dar. Solcherart gestaltete Systeme können als Vision unternehmensweiter Netzwerke [LMK98] verstanden werden. Ackerman und Halverson [AH99, AH00] argumentieren auf Grundlage der verteilten Kognitionsforschung, daß Unternehmensgedächtnisse gleichzeitig verteilte Prozesse und Objekte sind. Unternehmensgedächtnisse komplex verteilt, manchmal überlappend und verwoben sind. Unternehmensgedächtnisse keine reinen Repositories oder Artefakte sind. Sie sind Artefakte, die ihren Zustand behalten und gleichzeitig in vielen organisationalen und individuellen Prozessen eingebettet sind. De- und Rekontextualisierung wichtige Prozesse sind, um Gedächtnisobjekte in Gedächtnisprozesse zu verwandeln. Ein Gedächtnis zwischen Gruppen wird zum Grenz- 10 O Leary und Selfridge berichten, daß ungefähr die Hälfte aller amerikanischen Fortune 500 Unternehmen bedeutende Reengineering Abteilungen mit bis zu 150 Mitarbeitern und Vorstandsvertretungen besitzen [OS98].

67 3.3 Nachhaltigkeit 49 Gruppenarbeit/ Individuen UGS Steuerung Gruppenarbeit/ Organisation/ Individuen Geschäftsprozesse Nachvollziehbarkeit Organisation/ Geschäftsprozesse technologiegestütztes Arbeiten Spezifikation Archivierung Modellfortschreibung / (Komponentenorienterte) Informationstechnik Informationssysteme (Komponentenorienterte) Informationstechnik Informationssysteme Abbildung 3.8: Gedächtnis des Verbesserungsmanagements als kooperatives Informationssystem objekt. Die Konsequenzen des späteren Gebrauchs des Gedächtnisses nennen sie Trajektorien. Für kleine und mittelgroße Unternehmen spielt aus praktisch-betriebswirtschaftlichen Erwägungen in dieser Diskussion der Begriff der Nachhaltigkeit (engl.: sustainability) eine große Rolle. 11 Nach Huber [Hub95] gibt es aufgrund der endlichen Ressourcen der Erde kein nachhaltiges Wachstum, sondern nur eine nachhaltige Entwicklung, die natürlich auf einer qualitativen Transformation beruht, aus den beschränkten Ressourcen mehr herauszuholen. Huber führt als Strategie der Nachhaltigkeit die Begriffe Suffizienz, Effizienz und Konsistenz ins Feld. Suffizienz stellt die Frage nach dem optimalen Produktionsund Konsumniveau. Effizienz betrifft das Verhältnis von Input und Output durch bessere Ausnutzung der Ressourcenproduktivität. Konsistenz heißt Vereinbarkeit, Verträglichkeit, Stimmigkeit. Diese Strategien aus der umweltverträglichen Produktion lassen sich auch für das Verbesserungsmanagement fruchtbar machen. Eine integrative Betrachtung des VVM muß zum einen die wechselseitige Beeinflussung von Organisation, Arbeitspraxis und Informationstechnologie, zum anderen aber auch die Ressourcen von konkreten Unternehmen zur Gestaltung des VVM berücksichtigen. Trotz des durchaus vorhandenen Problembewußtseins sind die Ressourcen gerade von Unternehmen kleiner und mittlerer Größe fast völlig durch das Tagesgeschäft gebunden, und größere 11 Nachhaltigkeit hat mehrere mögliche Bedeutungen. Zum einen ist es die Bedeutung des Adjektivs nachhaltig 12 : dauernd, langfristig angelegt, z.b. in nachhaltiger Wirkung, etwasmitnachhaltiger Wirkung tun, also etwas dauerhaft (aber dann auch ohne großen Nacharbeitsaufwand) bewirken. Diese Bedeutung ist die primäre für das Verbesserungsmanagement. Nachhaltigkeit existiert aber auch als eigenständiger Begriff in der Ökologie. Dort heißt Nachhaltigkeit, etwas besonders ressourcenschonend zu tun. Auch diese Bedeutung schwingt in den Überlegungen zum nachhaltigen vernetzten Verbesserungsmanagement mit. Fehler, die man nicht mehr macht, sind natürlicherweise ressourcenschonend.

68 50 Nachhaltigkeit und Vernetzung Einführungsprojekte sind nur schwer oder gar nicht realisierbar. Eine Methodik für VVM sollte deshalb in kleinen, überschaubaren Schritten voranschreiten, bestehende Strukturen, Kulturen und Lösungen einbetten, das betroffene Personal in den Verbesserungsprozeß einbeziehen und das Ziel der Nachhaltigkeit im Auge behalten, d.h. die Dauerhaftigkeit sowie die Suffizienz, Effizienz und Konsistenz der eingeleiteten Verbesserungen untersuchen. Das Verbesserungsmanagement, als Mittel einer evolutionären Strategie zur kooperativen Gestaltung des organisatorischen, personellen und informationstechnologischen Wandels gedacht, soll somit den Bedürfnissen von kleinen und mittelgroßen Unternehmen in besonderer Weise entgegenkommen. Als Fazit der bisherigen Anmerkungen läßt sich festhalten, daß je näher sich der Untersuchungsgegenstand Verbesserungsmanagement der Praxis annähert, desto wichtiger wird es, sich über die Mechanismen der Verankerung von Fehlerwissen in den Prozessen des Verbesserungsmanagements Klarheit zu verschaffen. Insbesondere muß man sich davor hüten, im Verbesserungsmanagement eine Schattenwirtschaft des Wissensmanagements aufzubauen [Nor98, S. 219], die gar nicht oder nur unzureichend mit den leistungserstellenden Prozessen des Unternehmens verknüpft ist. Fehlerwissen, das erzeugt, aber nicht genutzt werden kann, ist nichts weiter als eine Kostenbelastung für das Unternehmen 13. Die Dynamik, mit der Fehlerwissen in Verbesserungsprozessen erzeugt, gesammelt, gespeichert, verteilt und genutzt wird, hängt von der Gestaltung von Arbeitsabläufen und Informationsflüssen im Verbesserungsmanagement ab Kopplung operativer Prozesse mit dem Gedächtnis Den Einfluß von informationssystem-gestützten Wissensaustauschprozessen auf operative Prozesse konnte von Peters und Jarke aufgrund von Simulations- und Fallstudien nachgewiesen werden [Pet96, PJ96]. Die Gestaltung von Informations- und Arbeitsflüssen im Verbesserungsmanagement muß die zeitlichen, örtlichen und konzeptuellen Barrieren beachten. Informationsflüsse laufen über Abteilungs- und Arbeitsplatzgrenzen zunächst entlang der Arbeitsflüsse. Der Einsatz kooperativer Informationssysteme für das Verbesserungsmanagement hängt im entscheidenen Maße vom Verständnis der Informationsflüsse in einem Unternehmen ab. Peters [Pet96] hat in seiner Dissertation exemplarisch am Beispiel des Qualitätsmanagements drei verschiedene Kategorien von Informationsflüssen in Unternehmen festgestellt. Informationsflüsse, die sich auf konkrete, kurzfristige Aufgabenstellungen beziehen. Informationsflüsse, die sich mittelfristig auf das Unternehmensgedächtnis beziehen. 13 Bach et al. [BVO99, S. 2] schreiben in ihrer Einführung zum Thema Wissensmanagent: Nicht die Kumulation von Wissen, sondern die Verwendung von Wissen in den Prozessen bestimmt den Nutzen.

69 3.3 Nachhaltigkeit 51 Informationsflüsse, die sich auf die langfristige Strategie eines Unternehmens beziehen. Ausgegangen ist er von Beobachtungen von Modellierungsteams für Qualitätsmanagementmethoden, daß verschiedene Qualitäten von Informationsflüssen nicht in einem Informationsflußkonzept untergebracht werden konnten, da die Teams das Gefühl hatten, sie hinsichtlich ihrer Repräsentation, ihrer Präsentation und ihrer Kommunikationskanäle unterschiedlich behandeln zu müssen. Peters führte dies auf zwei Grundprobleme zurück: Unsicherheit in der Spezifikation Die Modellierer wußten, daß der Austausch von spezifischen Informationstypen für die Implementierung von Regelkreisen notwendig war, konnten aber nicht den Inhalt dieser Information beschreiben. Unsicherheiten in der Repräsentation Der Inhalt einer Information war bekannt, konnte aber nicht mit Konzepten des vorgeschlagenen Modells formuliert werden. Die enge Verbindung von Spezifikation und Repräsentation (vgl. [Poh96]) führte in der Analyse der Rahmenwerke von Hammer [Ham93] und Daft/Lengel [DL86] zur oben eingeführten Kategorisierung von Informationsflüssen im Qualitätsmanagement, die im folgenden kurz ausgeführt wird. Workflow Information: Die Verbindung zwischen der Organisation, ihrer Aufbau- und Ablaufstruktur, und der Systemseite wird traditionell durch Informationsflüsse bestimmt, die die kurzfristige Durchführung von Aufgaben unterstützen. Workflow Informationen steuern die betrieblichen Geschäftsprozesse und sollten entlang dieser fließen. Spezifiziert werden sie anhand unternehmensweit verstandener Konzepte oder übernommener Standards. Repräsentiert werden sie laut Peters durch standardisierte Ansätze. Da die Informationen in einem Informationssystem gespeichert werden, können sie Teil des expliziten Unternehmensgedächtnisses des Verbesserungsmanagements werden. Unternehmensgedächtnis: Laut Peters wird ein Unternehmensgedächtnis durch die wiederholte Ausführung und Analyse von Geschäftsprozessen gewonnen. Strategien: Strategien sind laut Hammer [Ham93] gemeinsame Kontexte, mit denen Aufgaben organisiert und Informationen interpretiert werden. Strategien ergeben sich normalerweise aus langfristigen Erfahrungen oder Theorien, die aus der Unternehmung stammen oder von außerhalb übernommen werden. Eine Strategie besteht aus einer Menge von Visionen, Verhaltensregeln und Zielen, unter denen das Unternehmen handelt. Die Strategien werden nicht innerhalb von Informationssystemen repräsentiert, aber bei der Modellierung von Geschäftsprozessen implizit oder explizit berücksichtigt. Peters konnte in seiner Arbeit die gegenseitige Beeinflussung der Informationsflüsse auf operationaler und mittelfristiger Ebene durch in Fallstudien validierte Simulationsmodelle nachweisen [PJ96]. In den Simulationsmodellen wurde auch explizit auf die Einflüsse der Arbeitspraxis Bezug genommen, z.b. durch die Modellierung von Ab- und Zugängen im

70 52 Nachhaltigkeit und Vernetzung Personalbestand. In seiner Kategorisierung der Informationsflüsse bleibt dieser Einfluß allerdings unberücksichtigt. Weiterhin bleibt der Einfluß auf strategische Informationsflüsse unklar. Herausgehoben wird dagegen die zentrale Rolle des Unternehmensgedächtnisses. Im nächsten Abschnitt wird nun die verzahnte Ausgestaltung der Informationsflüsse für die Kategorien Workflow Information und Unternehmensgedächtnis erarbeitet Unternehmensgedächtnis Das Organisationale Lernen soll laut Wiegand auf die organisationale Wissensbasis bezogen sein und diese transformieren. Die Nachhaltigkeit des Verbesserungsmanagements aufgrund des Wissenstransformationsansatzes braucht Prozesse, die auf der organisationalen Wissensbasis die einzelnen Modi der Transformation unterstützen. Daher stellt sich die Frage, wie die organisationale Wissensbasis gestaltet werden kann. Im folgenden erläutere ich die wichtigsten theoretischen Konzepte, welche die Gestaltung der Wissensbasis im Verbesserungsmanagement beeinflussen und kennzeichne die für die Transformationsmodi notwendigen Prozesse, die auf einer expliziten Wissensbasis arbeiten. Die Ursprünge des Begriffs Unternehmensgedächtnis 14 (engl.: Organizational Memory) sind in der Soziologie zu finden. Dort wurde von der Durkheim School [Dur93] der Begriff des kollektiven Gedächtnisses Ende des letzten Jahrhunderts entwickelt. Das kollektive Gedächtnis bezieht sich auf die sozialen Prozesse der Artikulation und Kommunikation von Informationen, die zu gemeinsam benutzten Interpretationen von gesellschaftlichen Normen und Bräuchen führen [Kri75]. Die Idee war, gegenwärtige soziale Aktivitäten unter Berücksichtigung der Vergangenheit zu erklären. Krippendorf unterscheidet drei Formen von sozialen Gedächtnissen: Temporale Gedächtnisse Temporale Gedächtnisse existieren durch andauernde Transmission, durch die Information in einem temporalen Code erhalten bleibt. Deswegen existiert eine Bedrohung durch das Unterbrechen der Transmission. Aufzeichnungsorientierte Gedächtnisse Aufzeichnungsorientierte Gedächtnisse entstehen durch die sinnvolle Kombination 14 Die Verwendung dieser anthropomorphierenden Metapher ist eine der Charakteristika der organisationstheoretischen Forschung, die häufig im Zusammenhang mit dem Begriff der Organisationalen Intelligenz [Mat92] und der Metapher von der Organisation als Gehirn genannt werden. March und Simon deuteten Organisationen als informationsverarbeitende Systeme (vgl. z.b. [Sim81]). Diese Metaphern sind nicht trennscharf. Wichtig sind die Beiträge der Metaphern als Leitbild der Organisationsentwicklung und zur Förderung der Interdisziplinarität. Trotz der Problematik bei der Verwendung der Metaphern sollte deren nützlicher Beitrag anerkannt werden, auch weil er nicht völlig eliminiert werden kann (für vertiefende Untersuchungen vgl. [Wie96, S. 65ff] und [Bus98]). Ein neutralerer Begriff wird im folgenden mit der organisatorischen Wissensbasis eingeführt. Allerdings gehen somit alle funktionalen Eigenschaften, die mit Gedächtnissen verbunden werden und zur Strukturierung der Wissensbasis entscheidend beitragen, verloren.

71 3.3 Nachhaltigkeit 53 von mindestens zwei Prozessen. Die Kodierungsprozesse müssen mit den späteren Dekodierungsprozessen in Einklang stehen. Verluste können sowohl in der Kodierungsals auch in der Dekodierungsphase entstehen, wobei die Frage bleibt, ob solche Informationsverluste nicht auch sinnreich sein können. Ackerman und Halverson [AH99] sprechen in diesem Zusammenhang von De- und Rekontextualisierung. Strukturelle Gedächtnisse Strukturelle Gedächtnisse zeichnen sich durch die Aktivierung von Prozeduren durch Trigger aus. Als Gefahren werden das Verschwinden der Organisation, aber primär Überschreiben, Variieren und Abtrieb genannt. Krippendorf nennt strukturelle Gedächtnisse ökonomischer als aufzeichnungsorientierte Gedächtnisse, da der Zugriff über Prozeduren effizienter gestaltet werden kann als der Zugriff auf eine willkürliche Anordnung von Aufzeichnungen [Kri75, S. 26]. Organisationen sind strukturell beschreibbar, z.b. über ihre Materialflüsse oder Geschäftsprozesse [Kri75, S. 27] und reflektieren in einem signifikanten Maße die Interaktion der Organisation mit seiner Umwelt. Der Hauptunterschied zwischen aufzeichnungsorientierten und strukturellen Gedächtnissen ist demnach: Aufzeichnungsorientierte Gedächtnisse enthalten Informationen über Ereignisse der Vergangenheit, während ein strukturelles Gedächtnis Informationen darüber enthält, kollektiv mit Eigenschaften der Umwelt erfolgreich umzugehen. Wiedergewonnen wird die Information der Vergangenheit mittels Auslösung durch zutreffende Bedingungen. 15 Krippendorf verwendet Metaphern des Information Retrieval, um den Zugriff auf die Gedächtnisformen zu bestimmen. Das Unternehmensgedächtnis wurde zunächst in Verbindung mit systemtheoretischen Analysen von Organisationen als Beispiel für ein kollektives Gedächtnis genannt. Es sollte erklären, wie die nicht vergessene Vergangenheit auf das gegenwärtige Verhalten einer Organisation wirkt [CAA57]. Entscheidend für die Forschung ist die inhärente Interdisziplinarität des Konzeptes Unternehmensgedächtnis, denn es ist nicht aus einer Disziplin heraus entstanden, sondern es wurden Beiträge aus der Soziologie, den Wirtschaftswissenschaften, speziell die wissenschaftliche Betriebsführung, der Systemtheorie, den Politikwissenschaften, der Gruppen- und Verhaltenstheorie, der Kommunikationstheorie und der Entscheidungstheorie geliefert [BLSJ98]. Dadurch sind vielschichtige Sichtweisen und Schwerpunkte entstanden, die eine einheitliche Definition des Begriffs erschweren. Deshalb wird im folgenden ein Definitionsraum für den Begriff Unternehmensgedächtnis erzeugt. In Abbildungs 3.9 ist der Definitionsraum für Unternehmensgedächtnisse grafisch dargestellt. Die drei Dimensionen sind mit Verbreitung, Typ und Sichtweise abgebildet. Verbreitung: Der Verbreitungsgrad eines Unternehmensgedächtnisses kann von der individuellen Ebene bis zum Markt reichen. Extreme individualpsychologische Definitionen von Organisationgedächtnis (vgl. [CM63]) würden generell die Existenz von Gedächtnisinhalten über der Ebene von Individuen leugnen. Beispiele für Gruppen- 15 Past information in structural memory is retrieved by triggering it by the right condition. [Kri75, S. 28]

72 54 Nachhaltigkeit und Vernetzung Abbildung 3.9: Einordnungsschema für Unternehmensgedächtnisse gedächtnisse sind die sogenannten transaktiven Gedächtnisse [Mil78], die aus der Vereinigung individueller Gedächtnisse und der Kommunikation zwischen Gruppenmitgliedern entstehen. Auch Nonaka und Hedlund konstatieren zumindest für japanische Wissensgenerierungsprozesse ein transaktives Gedächtnis (vgl. Abschnitt 3.2). Zudem würden alle Artefakte wie Notizen, geschriebene Protokolle, Photographien, finanzielle Aufzeichnung usw. zum Gruppengedächtnis gehören. Obwohl Miller über die damals herrschende Auffassung hinausgeht, daß das Gedächtnis eine sich entwickelnde Eigenschaft innerhalb kleiner Gruppen ist, befaßt er sich nicht mit Gedächtnissen auf der komplexeren organisatorischen Ebene. Pautzke definiert die organisatorische Wissensbasis [Pau89] als Ansammlung des für die Mitarbeiter einer Organisation prinzipiell zugänglichen (horizontales Schichtenmodell) bzw. verfügbaren (vertikales Schichtenmodell) Wissens. Beim horizontalen Schichtenmodell erfolgt die Differenzierung der Sichten hinsichtlich der Wahrscheinlichkeit, mit der das in diesen Schichten enthaltene Wissen bei organisatorischen Entscheidungen verwendet wird [Wie96, S. 235]. Die ersten beiden (inneren) Schichten bestehen aus dem der Organisation aktuell zugänglichen Wissen (eigentliches Organisationsgedächtnis). Die dritte und vierte Schicht (latente organisatorische Wissensbasis) umfassen das der Organisation potentiell zugängliche Wissen innerhalb und außerhalb der Organisation. Zur fünften Schicht gehört das sonstige kosmisches Wissen. Pautzke kritisiert am horizontalen Schichtenmodell, daß nicht geklärt werden kann, warum verfügbares Wissen nicht in Entscheidungen eingeht und geht deshalb davon aus, daß die Wissensschichten in einem hierarchischen (vertikalen) Verhältnis zueinander stehen. Die Tiefenstruktur (Typ) der ersten Schicht (Vorstellungen, Denkstile, Annahmen) bestimmen die Form der Aufnahme von Wissen in den anderen Schichten. Covington weist auf zwei Funktionen der organisatorischen Wissensbasis hin (zitiert nach Lehner [Leh00]):

73 3.3 Nachhaltigkeit Voraussetzung für die Lernfähigkeit von Organisationen (beeinflußt aktuelle Entscheidungen durch Wissen über die Vergangenheit), und 2. Schaffung einer unabhängigen und selbsterhaltenden Identität (quasi eine Art höherer Auftrag oder eine dauerhafte Sendung) Die Auffassung von Smith [Smi82] geht über die die Grenzen der Organisation hinaus. Sowohl die interne Struktur und Dynamik einer Organisation als auch die Darstellung der Umgebung, die für die Lenkung der Organisation prägend ist, gehen in seine Definition des Unternehmensgedächtnisses ein. Gedächtnisse, die außerhalb der Organisationsgrenzen existieren, sind z.b. externe Archive. Typ: Die ersten Definitionen von Unternehmensgedächtnis basieren auf dem individuellen Verhalten der Mitarbeiter einer Organisation [CM63, NW82]. Im Mittelpunkt stehen die routinisierten Aktivitäten als Speicher von organisationalem Wissen. Mit der kognitiven Wende in der Organisationsforschung stützen sich die Definitionen nunmehr auf individuelle Erkenntnisse und Artefakte. Miller [Mil78] unterscheidet zwischen menschlichem (nicht-artikuliertem) Wissen und nicht-menschlichem, explizitem Wissen, also Artefakten. Definitionen, wie sie in [AS78, Hed81, FL85] zu finden sind, heben auf die kognitiven Eigenschaften der Gruppe oder Organisation ab. Sichtweise: In neueren Definitionen läßt sich eine Entwicklung von einer inhaltlichen Betrachtungsweise [WU91] hin zu einer Betrachtungsweise feststellen, die das Unternehmensgedächtnis als Aufbewahrungsort betrachtet [Ack94a, HDK98], wobei die zeitliche Transformation des Unternehmensgedächtnisses durch das Unternehmensgedächtnis eine weitere Sichtweise hinzufügt. Der Zweck eines Unternehmensgedächtnisses wird in den Auswirkungen der Vergangenheit auf gegenwärtige Entscheidungen gesehen. Auch Stein und Zwass folgen dieser Ansicht. Sie definieren [SZ95]: Organizational memory is the means by which knowledge from the past is brought to bear pre- sent activities, thus resulting in higher or lower levels of organizational effectiveness. Sie machen also keinerlei Aussagen darüber, wie das Unternehmensgedächtnis die Effizienz des Unternehmens beeinflußt. Weiterhin unterscheiden sie im Unternehmensgedächtnis zwischen semantischer (genereller) und episodischer (kontext-spezifischer) Information. Das breite Spektrum der Definitionen läßt auch für die Gestaltung einer expliziten organisatorischen Wissensbasis, d.h. eines Unternehmensgedächtnis-Systems, einen großen Spielraum. Allerdings sind die Unterschiede nicht so divergierend wie bei den Auffassungen über die Natur des Unternehmensgedächtnisses, da die Externalisierung gewisse Voraussetzungen an das Unternehmensgedächtnis-System stellt. Dies bedeutet, daß ein Unternehmensgedächtnis-System nicht ausschließlich auf dem Verhalten, Erkenntnissen oder kognitiven Fähigkeiten von Individuen, Gruppen oder Organisationen aufbauen darf, sondern sich vielmehr auf die Informationen und das Wissen der Organisation beziehen muß. Durch die Entwicklung der Organisations-Forschung in den letzten Jahren stieß die Rechnerunterstützung des Unternehmensgedächtnisses bei Praktikern und Akademikern auf re-

74 56 Nachhaltigkeit und Vernetzung ges Interesse. Aus diesem Antrieb heraus wurden einige Unternehmensgedächtnis-Systeme entwickelt und implementiert. Ein allen gemeinsames Strukturierungsmerkmal sind die mnemonischen Funktionen oder Prozesse [SZ95], die im nächsten Abschnitt näher untersucht werden Mnemonische Prozesse auf Unternehmensgedächtnis-Systemen Nach [HDK98, MEMR98, ADK98] lassen sich sich Unternehmensgedächtnis-Systeme grob in produktzentrierte oder in prozeßzentrierte Ansätze, d.h. auf die Prozesse (implizit oder explizit definiert) einer Organisation bezogen, einteilen. Im Rahmenwerk der kooperativen Informationsysteme kann die prozeßzentrierte Sicht CSCW-Systeme oder WFMS als Unternehmensgedächtnis-Systeme betrachten, je nachdem wie stark der Fokus auf die Agenten oder die Prozesse als primäre Wissensquelle gelegt wird. Datenbasierte Sichtweisen stützen dagegen die Wissensbasis auf elektronische Dokumente ab, die Wissen enthalten. Dokumentenverwaltungs-Systeme und (wissensbasierte) Datenbanksysteme werden dann als Unternehmensgedächtnis-Systeme bezeichnet [AD99]. Das VVM muß zum einen die mit dem Fehlerfall assoziierten Dokumente und Prozesse, zum anderen den Kontext der Fehlerfallbearbeitung bewahren, um sowohl die betroffenen Produkte und Prozesse als auch die Verbesserungsprozesse selbst zu verbessern. Die mit dem Fehlerfall assoziierten Dokumente und Prozesse sollten also, wie auch die beteiligten Agenten und Werkzeuge, über den Kontext der Fehlerfallbearbeitung in der Wissensbasis repräsentiert werden [MWH99]. Nun kommt es darauf an, Mittel zu finden, die es erlauben, Repräsentationen dieser Prozesse zu erzeugen, zu warten und zu nutzen. Stein und Zwass [SZ95] definieren das Unternehmensgedächtnis-System als ein System, welches Prozesse anbietet, durch das Wissen aus der Vergangenheit dazu genutzt werden kann, um auf die gegenwärtigen Aktivitäten einzuwirken und den Wirkungsgrad der Organisation zu steigern. 16 Drei wichtige Eigenschaften von Unternehmensgedächtnis- Systemen werden in dieser Definition ausgedrückt. Sie sollen die gegenwärtigen Prozesse der Organisation beeinflussen. Sie sollen effizienzsteigernd wirken und als Mittel der Beeinflussung werden Prozesse genannt. Deshalb definieren Stein und Zwass die funktionalen Anforderungen an ein Unternehmensgedächtnis-System. Diese ermöglichen die Akquisition, Speicherung, Verwaltung, Suche, Wiedergewinnung und Verbreitung von Wissen. Burstein et al. [BLSJ98] definieren deshalb explizit ein Unternehmensgedächtnis-System als Mittel zur Erzeugung und zum Zugriff eines Unternehmensgedächtnisses mit mnemonischen Prozessen der Speicherung und Wiedergewinnung 17. Diese Definition geht insoweit über 16 We define an organizational memory information system (OMIS) as a system that functions provide a means by which knowledge from the past is brought to bear on present activities, thus resulting in increased level of effectiveness for the organisation. [SZ95, S. 11] 17 OMS is considered as means of capturing and giving access to OM, with mnemonic functions of storage and retrieval being support in the organisation. [BLSJ98, S. 3]

75 3.3 Nachhaltigkeit 57 die von Stein und Zwass gegebene Definition hinaus, daß sie das Unternehmensgedächtnis- System auch als System zur Erzeugung eines Unternehmensgedächtnisses situiert und diese somit eine direkte, konstituierende Beziehung zur organisationalen Wissensbasis besitzt. Eine zentrale Rolle spielen dabei die mnemonischen Prozesse, die mit dem Unternehmensgedächtnis verbunden werden können. Referenz Mnemonische Prozesse Stein and Zwass [SZ95] Akquisition, Suche, Wiedergewinnung, Aufbewahrung, Wartung Probst und Romhardt Zieldefinition, Identifikation, Erwerb, Entwicklung, Verteilung, [PRR97] Bewahrung, Nutzung, Bewertung Ramesh [Ram97] Akquisition, Wiedergewinnung, Aufbewahrung, Entwicklung, Wiederverwendung Morrison [Mor97] Akquisition, Suche, Wiedergewinnung, Aufbewahrung Wijnhoven [Wij98] Akquisition, Suche, Wiedergewinnung, Aufbewahrung, Verbreitung Burstein et al. [BLSJ98] Akquisition, Wiedergewinnung, Aufbewahrung, Wartung, Lernen Tabelle 3.1: Mnemonische Prozesse in der Literatur Aus einer Untersuchung relevanter Literaturstellen habe ich einen Satz von mnemonischen Prozessen extrahiert [KS00], die in den aufgeführten Referenzen vielfach genannt wurden (vgl. Tabelle 3.1, fett gekennzeichnet). Diese Prozesse können den einzelnen Phasen der Wissenstransformation zugeordnet werden. Akquisitionssprozesse sind vornehmlich Prozesse der Externalisierung von sozialisierten Wissen im Transformationsmodell, während Wartungsprozesse explizites Wissen neu kombinieren. Prozesse der Wissenssuche und - wiedergewinnung, wie sie in Tabelle 3.2 unter dem Gesichtspunkt der Transformation zusammengefaßt sind, durchlaufen aber alle Modi der Wissenstransformation. Denn auch die Sozialisierung des Wissens kann in der Wissensbasis explizit gemacht werden, z.b. durch die Speicherung von Verweisen auf Wissensträger. Pop-Technologien [O L98a] (Anfrage, Filterung, Geführte Suche) dienen dazu, Such- und Filterkriterien des Benutzers zu externalisieren. Die hypertext-artige Navigation führt zur Kombination von explizitem Wissen. Push-Prozesse, wie das aufgabenspezifische Verteilen von Wissen aufgrund von expliziten Workflow-Modellen, internalisieren Wissen. Die aufgeführten Prozesse schlagen noch keine Realisierungsstrategien vor. Für jeden Prozeß sind deshalb, abhängig von der Struktur der Wissensbasis, verschiedene Möglichkeiten der Realisierung möglich. In Tabelle 3.2 sind die angeführten Prozesse bezüglich ihres Wissensflusses angeordnet. Asking an Expert ist ein Prozeß, der den Wissensfluß von Mitarbeiter zu Mitarbeiter und damit die Sozialisierung von Wissen unterstützt. Die Externalisierung realisiert einen Wissensfluß von Mitarbeitern zur Wissensbasis, während die Internalisierung den Wissensfluß aus der Wissensbasis heraus unterstützt. Innerhalb der Wissensbasis kann die Navigation Wissen vernetzen.

76 58 Nachhaltigkeit und Vernetzung Wissensfluß...zu Mitarbeiter...zu Wissen von Mitarbeiter... Sozialisierung Externalisierung Asking an Expert Anfrage Filterung Geführte Suche von Wissen... Internalisierung Kombination Abonnement Aufgabenspezifisches Pushen Navigation Tabelle 3.2: Prozesse der Wissenssuche und -wiedergewinnung (adaptiert aus [O L98a]) Rollen in mnemonischen Prozessen Durch die mnemonischen Prozesse können die Mitarbeiter oder Softwaresysteme im Verbesserungsmanagement verschiedene Rollen im Umgang mit Fehlerwissen einnehmen. Diese Rollen sind entscheidend für den nachvollziehbaren Aufbau, die Nutzung und die Wartung des Unternehmensgedächtnis-Systems. Führt der Bearbeiter eines Fehlerbildes einen mnemonischen Prozeß auf der Wissensbasis aus, wird ihm automatisch eine Rolle zugewiesen. Wissenserzeuger: Neues Fehlerwissen wird von Bearbeitern von Fehlerbildern erzeugt. Bei der Erfassung und Analyse wird implizites, bspw. von Kunden mündlich mitgeteiltes Fehlerwissen strukturiert externalisiert. Bei der Fehlerfallbearbeitung wird durch das Auftreten eines Fehlerereignisses neues Wissen erzeugt. So sind in der Hauptsache Akquisitionsprozesse mit der Rolle des Wissenserzeugers verbunden. Wissensnutzer: Die Internalisierung von Fehlerwissen wird durch Wissensnutzer durchgeführt; Agenten, die nach Wissen suchen, es wiedergewinnen und in der Erfassung, Analyse und Maßnahmendefinition nutzen. Wissensnutzer führen also hauptsächlich Such- und Wiedergewinnungsprozesse auf dem Unternehmensgedächtnis-System aus. Experte: Experten sind Agenten, die einen Teil des für das Unternehmen relevanten Wissens besitzen (implizit oder explizit), ohne es erzeugt haben zu müssen. Wissensnutzer können sich mit einem Problem an Experten wenden, wenn mnemonische Prozesse definiert sind, die zu einem Gebiet den oder die entsprechenden Experten auffinden. Die Kenntnis von Experten ist entscheidend für die Zusammenstellung von kurz- und langfristigen Verbesserungsteams. Wissensverwalter: Wissensverwalter überwachen die organisatorische Wissensbasis. Wissen kann über die Zeit konfligierend, ungültig oder irrelevant werden. Der Wissensverwalter kann Prozesse, Objekte, Werkzeuge und Agenten für die explizite Wartung auswählen. Wartungsfunktionen wie Veralterung und Archivierung werden von ihm durchgeführt. Auch die Wissensbasis selbst kann automatische Rekonstruktionen durchführen, z.b. die Generierung eines Volltextindexes.

77 3.3 Nachhaltigkeit Fehlerstrukturwissen Das Fehlerwissen wird mittels der mnemonischen Prozesse im Sinne von Nonaka transformiert. Eine wesentliche Aufgabe ist es, über den Fehlerfällen Strukturwissen aufzubauen, um Fehlerfälle zu identifizieren, sie zu klassifizieren und das gesammelte Fehlerwissen bei der Fehlerfallbearbeitung zu nutzen. Ziel diese Abschnitts ist daher die Klärung der Frage, wie Strukturwissen über Fehlerfälle aufgebaut werden kann. Dabei sind folgende Anforderungen aus der Praxis zu beachten, die in einem Workshop des Projekts AdCo [JK99] von Experten des Verbesserungsmanagements in Fertigungsbetrieben geäußert wurden. Die Anwender lehnen monolithische Fehlerkataloge ab. Fehlerkataloge, die nach unternehmensweiten Vorgaben klassifizierte Fehler enthalten, werden für wenig hilfreich gehalten. Dies hat mehrere Gründe: Erstens, Fehlerwissen wird in unterschiedlichen Kontexten benutzt. Die Fehler, die z.b. in der Fertigung betrachtet werden, haben möglicherweise keine Relevanz für den Service-Techniker. Ein unternehmensweiter Fehlerkatalog würde für unterschiedliche Anwendungskontexte irrelevante Informationen enthalten. Zweitens haben monolithische Fehlerkataloge durch ihre Entwicklung oft eine (subjektiv empfundene) redundante Struktur. Die Anwender sind sich unsicher, in welche Kategorie ihr Fehlerfall gehört und klassifizieren letztendlich vollkommen willkürlich, so daß die entstehenden Kataloge nicht mehr nutzbar sind, um aktuelle Fehlerfälle zu bearbeiten. Die Anwender wünschen eine flexible Klassifizierung. Eine flexible Klassifizierung, die auf Abteilungen oder auf Arbeitsplätze abgestimmt ist, erleichtert die Nutzung von Fehlerwissen in unterschiedlichen Kontexten. In der Hotline eines Call-Centers sind Zugriffschnelligkeit und Aussagekräftigkeit der Informationen über Fehler, also verdichtete Fehlerfälle, für die schnelle Maßnahmenfindung ohne große Analyseprozesse erwünscht. Bei der Entwicklung von fehlervermeidenen Produkterstellungsprozessen wird auf einen hohen Abdeckungsgrad potentieller Fehler Wert gelegt, ebenfalls auf die Nachvollziehbarkeit jedes einzelnen Fehlerfalls. Deshalb ist es notwendig, einen speziell auf das Verbesserungsmanagement zugeschnittenen Variantenbegriff zu entwickeln, eine formale Repräsentation in Form eines Modells zu bilden und geeignete Werkzeugunterstützung zur Erstellung von Variantenmodellen und deren Nutzung im Verbesserungsmanagement anzubieten Variantenbegriff Ähnlichkeitsauffassungen unterliegen historischen Wandlungen und werden von den Disziplinen der Wissenschaft unterschiedlich behandelt. Eine begriffsgeschichtliche Abhandlung findet sich in [Len96]. Hier geht es darum, eine für das Verbesserungsmanagement zugeschnittene, verwendungsorientierte Definition des Begriffs Variante einzuführen, der extrem subjektive Auffassungen überwindet und einem kommunizierbaren Wissensbegriff

78 60 Nachhaltigkeit und Vernetzung entgegenkommt. Dazu wird zunächst die Auffassung der kognitiven Psychologie rekapituliert. In der kognitiven Psychologie wird der Begriff der Variante unterschiedlich definiert und verwendet. Alle Definitionen legen aber ein großes Gewicht auf Ähnlichkeiten, die durch kognitive Fähigkeiten erkannt werden können. Maßgeblich ist die Subjektivität der Zuordnung eines Gegenstandes zu einer Kategorie, wodurch der Variantenbegriff dem Alltagsverständnis entgegenkommt [Ede93]. Unterstützt wird diese Betrachtung durch Rosch [Ros78], die für die Bildung von Kategorien kognitive Ökonomie (engl.: cognitive economy) und die wahrgenommenen Weltstrukturen (engl.: perceived world structures) als grundlegende Prinzipien vorschlägt. Beide Prinzipien beruhen primär auf der Auswertung von Sinneseindrücken, die durch andere Einflüsse wie Kultur und Sozialisierung determiniert werden. Für die Wissensrepräsentation im Verbesserungsmanagement ist eine Objektivierung und Verfeinerung des Variantenbegriffs notwendig. Dazu müssen klassische Modelle der Variantenbildung betrachtet werden. Aber auch in der industriellen Fertigungspraxis ist der Begriff der Variante nicht allgemeingültig definiert, oftmals erfolgt die Klassifikation über das Endprodukt, definiert durch die Funktion (z.b. Staubsauger). Im PPS-Bereich eines Unternehmens entstehen wichtige Informationen für die produktbezogene Variantenbildung. Innerhalb von PPS-Systemen werden verschiedenste Arten von Daten gespeichert, die für die Produktionsplanung und -steuerung relevant sind. Dazu gehören Grunddaten wie Fertigungspläne, Stücklisten, Arbeitspläne etc. [Sch88]. Zur Darstellung der Produktstrukturen werden häufig Gozintographen benutzt [Ros80]. 18 Ein solcher Graph besteht aus einer Menge von n-elementen und einer Menge von m-relationen. Abbildung 3.10 zeigt das Beispiel eines Gozintographen für zwei Endprodukte. Zum einen kann der Graph anschaulich darstellen, aus welchen untergeordneten Teilen ein übergeordnetes Teil besteht und zum anderen kann man ablesen, mit welchen Mengen ein untergeordnetes Teil (Beschriftung der Kanten) in ein übergeordnetes Teil eingeht. Die Pro- Abbildung 3.10: Gozintograph für zwei Endprodukte (adaptiert aus [Sch88]) 18 Der Name Gozintograph ist eine Verballhornung aus dem Englischen und stammt aus that part goes into.

79 3.3 Nachhaltigkeit 61 duktinformationen sind im allgemeinen Fall hierarchisch strukturiert, da sie aus dem Konstruktionsprozeß entstehen. Scheer [Sch88] schreibt dazu: Da ein Konstruktionsvorgang im allgemeinen in einer Top-Down-Vorgehensweise durchgeführt wird, sind die Entscheidungsschritte [der konstruktionsbegleitenden Kalkulation] jeweils auf eine Hierarchiestufe innerhalb einer Stücklistenstruktur bezogen. Produktmodell für Konstruktionsprozesse Prinzipmodell Gestaltmodell Anforderungsmodell Funktionsmodell Technologiemodell Planungsmodell Baugruppenmodell Materialmodell Baugruppenmodell Einzelteilmodell Toleranzmodell Einzelteilmodell Geometriemodell Oberflächenmodell Geometriemodell Abbildung 3.11: Produktmodell für Mechanikprodukte (adaptiert aus [RG91]) Im günstigsten Fall sind im PPS-Bereich sogar geeignete Produktmodelle vorhanden, die verschiedene Sichten auf das Produkt erlauben. Im Verbesserungsmanagement spielt die Granularitätsebene der Betrachtung eine größere Rolle als in der Fertigung. Weiterhin sind die klassischen Variantenbegriffe der Fertigung in der Regel rein produktorientiert. Sie umfassen dann Merkmalsmengen, deren Ausprägungen und Produktstrukturen. Dabei wird der Produktlebenszyklus (vgl. Abschnitt 2.2) zumeist völlig außer acht gelassen. Gemäß der dort eingeführten Zweiteilung müssen sich demnach noch Produktionskontexte und Produktnutzungsumstände in die Variantenbildung miteinbeziehen lassen. Man kann somit fünf verschiedene Sichtweisen auf Produkte und Prozesse für die Definition der Variantenhaftigkeit herausbilden, die im folgenden kurz skizziert werden. Merkmalsausprägungen: Die Ausprägungen einzelner Merkmale aus der Merkmalsmenge von Produkten oder Prozessen können herangezogen werden, um zu erkennen, daß es sich um Varianten eines anderen Produktes handelt. Soll eine Variantenbeziehung zwischen zwei Produkten über die Merkmalsausprägungen erkannt werden, dann ist bei den Varianten dieses Produktes die Merkmalsmenge gleich (bzw. beide Produkte besitzen mindestens das zu vergleichende Merkmal). Merkmalsmengen: Verschiedenen Produkten oder Produktionsprozessen läßt sich immer eine Menge von Merkmalen zuordnen, die sie voneinander abgrenzt (Differen-

80 62 Nachhaltigkeit und Vernetzung zierung über die Merkmalsmenge) und somit zur Nicht-Varianten macht. Genauso kann ein Unterschied in der Merkmalsmenge aber auch einen variantenbeschreibenden Charakter haben, nämlich indem eine Variante eines Produktes über ein neues Merkmal verfügt, das die anderen Produkte nicht besitzen. Produktstrukturen: Die Produktstruktur beschreibt das Zusammenspiel bzw. die Anordnung und Auswahl von Baugruppen (oder Prozeßschritten). Produktnutzungsumstände: Die Bedingungen, unter denen ein bestimmtes Produkt eingesetzt wird, können ebenfalls sehr starken Einfluß auf das Fehlerverhalten des Produktes haben. Deshalb können ähnliche Nutzungsumstände Produkte zu Varianten voneinander machen, die bei der Fehlerfallbearbeitung berücksichtigt werden müssen. Produktionskontext: Ein Produkt entsteht zwangsläufig in einem bestimmten Produktionskontext. Aus der Beziehung zwischen Produkt und Produktionskontext lassen sich ebenfalls Möglichkeiten der Variantenbildung ableiten. Wenn sich ein Fehlerfall bereits bei der Produktion ereignet, so ist das oft auf die Produktionanlage zurückzuführen (eventuell durch fehlerhafte Einstellungen oder Fehlbedienungen) Repräsentation von Varianten Die Identifizierung von Varianten verlangt, daß die zugehörigen Daten erstens miteinander verknüpft sind, was durch das Fehlerdatenmodell (vgl. Abschnitt 6.2.7) geleistet wird, und zweitens die Varianten geeignet repräsentiert werden, so daß die Auswertung über den Teilbereichen des Fehlerdatenmodells Produkt, Prozeß, Anlage und Fehlerdaten ermöglicht wird. Dies kann über explizite Zuordnung von Einzeldaten zueinander, mittels impliziter Variantenbildung, mittels klassifikatorischen Ansätzen oder automatisch durch Verfahren der Ähnlichkeitsanalyse geschehen. Explizite Variantenbildung (Attributierung): Eine explizite Zuordnung von Variantenwissen ist durch Attributierung der Daten im Modell, z.b. durch Variante von, immer möglich. Allerdings steigt dadurch der Aufwand für die Pflege der Datenbasis, da beim Eintragen neuer Daten alle möglichen Variantenbildungen neu betrachtet werden. Daher eignet sich dieser Ansatz nur, wenn der Variantenbegriff nicht ausreichend formalisiert werden kann, Variantenwissen aber unbedingt erforderlich ist. Implizite Variantenbildung (Klassifikation): Bei der impliziten Variantenbildung ist der Eingabeaufwand deutlich geringer. Hier muß der Eingebende nicht die Beiziehung eines jeden Objektes zu allen anderen festlegen. Er ordnet lediglich das Objekt einer Klasse von Objekten zu, die untereinander Varianten sind. Sind die einzelnen Klassen noch dazu hierarchisch geordnet, so sind sowohl klassenübergreifende Variantenbeziehungen als auch mehrere unabhängige Hierarchien möglich. Allerdings muß der Eingebende zur Eingabezeit die Hierarchien kennen, damit eine korrekte Zuordnung

81 3.3 Nachhaltigkeit 63 möglich wird. Auch für die spätere Auswertung ist die Kenntnis der tatsächlichen Hierarchien von Nutzen. Automatische Variantenbildung (Ähnlichkeitsanalyse): Völlig ohne Aufwand bei der Eingabe ist die automatische Variantenbildung, da auf einen expliziten Variantenbegriff in der Repräsentation verzichtet wird. Der Benutzer muß auf bestehende Objektbeziehungen oder Klassenzugehörigkeiten keine Rücksichten nehmen. Allerdings muß der Datenbestand in seinen Ähnlichkeitsbeziehungen sehr gut formalisierbar sein oder sehr viel Aufwand in der Ähnlichkeitsanalyse betrieben werden, wenn zum Eingabezeitpunkt kein Wert auf die Bildung von Variantenwissen gelegt wurde. Zur Anwendung kommen Verfahren, die auf der Bildung von semantischen Distanzen oder Verfahren aus der Informationsgewinnung wie statistische Clusteranalyse [Dha98], Klassifikation mit neuronalen Netzen oder Volltextsuche mit vordefinierten Ontologien [BMMaHW97, O L98b, GK99]. Am sinnvollsten erscheinen letztendlich Klassifizierungstechniken zur Repräsentation von Varianten bezüglich der Klassifikationsdimensionen Produkt, Prozeß oder Produktlebenszyklus, Anlage und Fehlerkontext. Diese Entscheidung liefert einen akzeptablen Kompromiß zwischen dem Aufwand für die Repräsentation bzw. Transparenz des verwendeten Variantenbegriffs und der Nutzbarkeit in der betrieblichen Praxis. Zwar müssen die Klassenbäume im Designprozeß aufgebaut und anschließend gewartet werden, doch ist der Aufwand für den einzelnen Benutzer deutlich niedriger als bei der expliziten Attributierung. Dort muß beim Einfügen einer neuen Variante stets der gesamte Suchraum nach möglichen Varianten abgesucht werden. Dazu werden wiederum mnemonische Prozesse definiert, so daß sowohl der Aufbau als auch die Nutzung der Hierarchien nachvollziehbar bleiben. Im Vergleich zur Ähnlichkeitsanalyse ist zwar der Aufwand der Variantenverwaltung höher, aber auch die Transparenz der verwendeten Variantenstruktur besser. Auch hat die Klassifizierung den Vorteil, daß sie zum einen an die Belange des Unternehmens angepaßt werden kann, zum anderen können Benutzer(-gruppen) transparente Klassifizierungsstrategien entwickeln, die ihren eigenen Arbeitskontext, z.b. Call-Center oder Produktentwicklung, wiederspiegeln. Schließlich lassen sich die Klassifizierungstrategien in natürlicher Weise auf die bisher verwendeten Modellierungskonzepte abbilden. Als Fazit der Überlegungen in diesem Abschnitt läßt sich festhalten, daß die Schaffung einer expliziten Fehlerwissensbasis die Nachhaltigkeit des Verbesserungsmanagements erhöht. eine kooperative Informationssystem-Entwicklung Bedrohungen der Nachhaltigkeit entgegnet. die Fehlerwissenbasis mittels mnemonischen Prozessen mit operativen Prozessen gekoppelt wird. die rollenbasierte Durchführung von mnemonischen Prozessen die nachvollziehbare Erzeugung, Nutzung und Wartung des Fehlerwissensbasis erlaubt. die Nutzbarkeit der Fehlerwissensbasis vom variantenorientierten Aufbau von Fehlerstrukturwissen abhängig ist.

82 64 Nachhaltigkeit und Vernetzung Im nächsten Abschnitt werden solcherart gekoppelte operative Prozesse zur Vernetzung virtueller Verbesserungsteams ausgestaltet. 3.4 Vernetzung: Das Eskalationsprinzip des Verbesserungsmanagements Um ein allgemeines Erklärungsmodell wie das der dynamischen Wissensumwandlung (vgl. 3.1) auf eine konkrete Aufgabenstellung wie das vernetzte Verbesserungsmanagement anwenden zu können, ist zunächst eine grundlegende Modellvorstellung der verteilten kooperativen Abläufe im Verbesserungsmanagement notwendig, die folgende Eigenschaften besitzt: Die Modellvorstellung sollte genügend abstrakt sein. Jedes Unternehmen hat aufgrund seiner Marktposition und seiner Struktur verschiedene Ausgangssituationen für das Verbesserungsmanagement. Sie sollte die grundlegend verteilte Natur des Verbesserungsmanagements respektieren. Sie sollte die Wissenstransformation präzise abbilden. Die Literatur zum Beschwerde- und Reklamationsmanagement (vgl. [Hei98, SS98, Wal99], die von Beobachtungen des Kundendienstes eines Unternehmens gedeckt [Pfe97, S. 83ff] werden, postulieren Eskalationen als Bearbeitungsprinzip von Fehlerfällen. Aufgrund dieser Analysen und Literaturrecherchen haben wir im Projekt FOQUS (vgl. Abschnitt 5.2.2) ein Eskalationsprinzip zur idealtypischen organisatorischen Beschreibung von abteilungsund arbeitsplatzübergreifenden Verbesserungsprozessen gewählt und ein Eskalationsmodell erarbeitet. Es wird zwischen arbeitsplatz- oder gruppenübergreifenden Makroprozessen und arbeitsplatz- oder gruppenlokalen Mikroprozessen unterschieden. Eskalationen beschreiben Geschäftsprozesse zur Bearbeitung von Fehlerfällen und den Austausch von Wissen zwischen Bearbeitungsbereichen. Bearbeitungsbereiche, auch Kompetenz- oder Eskalationsstufen genannt, beschreiben (Team-)Arbeitsplätze im verteilten Produktlebenszyklus, z.b. die Hotline im Call-Center, die Reparaturabteilung und die Montagestrecke. Diese Arbeitsplätze führen Mikroprozesse durch, die zum Makroprozeß beitragen. Im folgenden werden die Grundideen des Eskalationsmodells in der Gestaltung von service-orientierten Workflows verfeinert. Eskalationsstrategien innerhalb dieser Workflows und die Rollenverteilung bei der koordinierten Bearbeitung von Fehlerfällen bilden weitere Schwerpunkte. Der Transfer von Fehlerwissen während der Transformation innerhalb des Eskalationsmodells erfolgt in dreifacher Weise [Wie96, S. 259]: Das Fehlerwissen wird horizontal zwischen Personen und Bereichen verteilt. Das Fehlerwissen wird vertikal zwischen Kompetenzstufen transferiert. Das Fehlerwissen wird prozeßübergreifend transferiert.

83 3.4 Vernetzung 65 Eskalationsbereich z.b. FMEA Teamsitzung Eskalationsbereich Fehlerbild eskalieren Korrigieren z.b. Serviceingenieur Erfassen Eskalationsbereich Fehlerbild eskalieren Korrigieren Analysieren z.b. Call Center Erfassen Fehlerbild eskalieren Korrigieren Analysieren Feedback Erfassen Analysieren Feedback Kunde Feedback Abbildung 3.12: Eskalationsmodell (adaptiert aus [KPJ00]) Die Transformation startet mit der Sozialisierung persönlichen, nicht artikulierten Wissens. Falls eine Verbesserung in verschiedenen Abteilungen bearbeitet werden muß, um das Problem zu erfassen, zu analysieren und zu lösen, können zwei Problembereiche erfaßt werden. Zum einen kann eine Zuordnung von Verantwortlichkeiten fehlen, was zu Verzögerungen in der Bearbeitung einer Verbesserung und zur Reduktion der Effektivität der Problembehebung führen kann. Zum anderen können Verantwortlichkeiten implizit oder explizit mehrfach zugeordnet sein. Dies kann zu wechselseitigen Behinderungen führen, aber auch gewollt sein, um durch Parallelisierung und Redundanz zu einer effizienteren Bearbeitung des Problems zu kommen [NT95] Beschreibungselemente des Eskalationsmodells Eskalationen bilden die Grundlage für die Beschreibung von Vorgängen im Verbesserungsmanagement. Die Beschreibungselemente des Eskalationsmodells (Abb. 3.12) sehen wie folgt aus: 1. Der Kunde als mittelbarer und unmittelbarer Betroffener löst die Fehlerfallbearbeitung durch Kontaktaufnahme mit einer ihm bekannten Ansprechstelle aus. Der Kunde kann extern sein oder auch ein beliebiger Mitarbeiter innerhalb eines Unternehmens. In der Abbildung wurde als typische Ansprechstelle das Call-Center eines

84 66 Nachhaltigkeit und Vernetzung Unternehmens gewählt. 2. Mikroprozesse beschreiben einen Bearbeitungsbereich des Fehlerfalls. Mikroprozesse durchlaufen die Wissenstransformation in drei Phasen, die strukturell für jeden Bearbeitungsbereich gleich sind, sich aber in ihrer Ausprägung je nach Aufgabe, Arbeitsplatz und Qualifikation bzw. Kompetenz des Bearbeiters unterscheiden. Jeder Mikroprozeß schafft ein neues Fehlerbild. (a) Der Fehlererfassungsschritt Erfassen ist der mnemonische Prozeß der Informationssammlung und -dokumentation von verfügbaren Fehlerdaten. Auf der einen Seite können diese Daten für die Interpretation von automatisierbaren Diagnoseprozessen maschinenlesbar aufbereitet sein, auf der anderen Seite können Daten dazu dienen, Bearbeiter in späteren Phasen der Eskalation zu unterstützen, die mit dem Fehlerbild arbeiten müssen, ohne die Fakten realiter zu kennen. Deshalb ist für diese Fälle der Einsatz von reichhaltigen Medien sinnvoll, die das notwendige Kontextwissen beschreiben, um Unsicherheit und Mehrdeutigkeit zu reduzieren [DL86]. (b) Der Fehleranalyseschritt Analysieren ist der Prozeß der Interpretation der verfügbaren Informationen, um mögliche Ursachen eines Fehlerbildes zu ermitteln und anwendbare Maßnahmen zu definieren. Dieser Schritt kann sowohl durch menschliche Bearbeiter als auch durch computerisierte Werkzeuge unterstützt werden. Falls keine lokale Lösung des Problems möglich ist, oder der Bearbeiter weiterreichende Ursachen des Fehlerbildes annimmt, wird das Fehlerbild eskaliert. Zum Analyseprozeß gehören die Akquisition notwendigen weiteren Wissens, die Suche- und Wiedergewinnung von vorhandenem Wissen und die Wartung der Wissensbasis, beispielsweise durch Klassifikation von Fehlerfällen. (c) Der Fehlerkorrekturschritt Am Ende der Analysephase sollten der potentielle Fehler, ebenso eventuelle Fehlerfolgen, Fehlerbedeutung und Fehlerursachen bestimmt sein. Weitherhin sollten Maßnahmen zur Korrektur festgelegt sein, eventuell mit Prüfmaßnahmen. Korrektur ist der Prozeß der Durchführung und Verfolgung von Verbesserungsmaßnahmen für die Fehlerbehebung. Der Erfolg oder Mißerfolg solcher Maßnahmen wird an alle in der Eskalation beteiligten Mitarbeiter weitergeleitet. 3. In den Makroprozessen ist jeder Bearbeitungsbereich eine Eskalationsstufe. Bei der Eskalation wird mit dem Fehlerbild auch die Verantwortung und Berechtigung zu einer Bearbeitung weitergegeben, d.h. das Fehlerbild eskaliert. Die Bedingungen der Weitergabe werden vom gegenwärtigen und zukünftigen Bearbeiter ausgehandelt. Wichtig für die Kundenbindung und die Fortsetzung der Kooperation ist die ständige Versorgung mit Rückmeldungen während der Fehlerfallbearbeitung, damit jedes Mitglied des Verbesserungsteams einen annähernd gleichen Wissensstand hat. Insbesondere ist dies für die Kundenschnittstelle wichtig, um dort Rückfragen bezüglich

85 3.4 Vernetzung 67 des Standes der Fehlerfallbearbeitung, den verläufigen Diagnosen und der eingeleitetenmaßnahmenbeantwortenzukönnen Service-orientierte Workflows Auf die Frage, wie die Aufbau- und Ablaufstruktur von Workflow Informationen zu gestalten ist, versucht das Forschungsgebiet des Workflow-Managements Antworten zu geben. Der Stand der Technik im Workflow-Management wird für den deutschsprachigen Bereich vor allem durch [VB96, OV96, JBS97] beschrieben. Insbesondere wurden in der letzten Zeit Fragen der Adaptivität, z.b. [Kir95, Vv96, Amb96, VWW96, GJHLR97, Sie97, Wes97, SD97], und der Skalierbarkeit, z.b. [AKA + 94, KAGM95, Jab97, BD97] behandelt. Nur wenige Ansätze, z.b. [SZ95, WWT97, WWT98], sehen WFMS als Ansätze des Verbesserungsmanagements. Nach der Definition von Halter [Hal96], die sich eng an [RS95] anlehnt, 19 wird unter einem Workflow aus dieser Perspektive folgendes verstanden werden: Ein Workflow verbindet die einzelnen Aufgaben (Aktivitäten) eines Prozesses zu einem Ablauf und definiert, wer (welche Rolle) welche Aufgabe mit welchem Mittel und welchen Informationen durchführt. Eine Aufgabe kann selber in einzelne Arbeitsschritte aufgeteilt werden, welche manuell oder mit Hilfe von Anwendungen abgearbeitet werden. Solcherart definierte Workflows bezeichnen also im allgemeinen arbeitsteilige Prozesse, die von Personen als Aufgabenträger durchgeführt werden. Sie beziehen sich auf Teile von Geschäftsprozessen oder andere Vorgänge in einer Organisation. Workflows lassen sich untergliedern in Subworkflows. Sie haben einen definierten Anfang und ein definiertes Ende, der eigentliche Ablauf ist ebenfalls festgelegt. Die Koordination und Steuerung von Workflows wird von einem WFMS automatisiert. Implementierte und eingeführte Lösungen zur Steuerung von Workflows unter Verwendung eines WFMS werden Workflow-Management- Anwendungen (WFMA) genannt [Jab97]. Workflow-Management steht für das Organisieren, Planen, Entscheiden, Kontrollieren, Steuern und Führen in Zusammenhang mit Workflows. Inwieweit diese Handlungen von WFMS und WFMA umgesetzt werden, ist durch deren Entwicklungsstand bestimmt [Jab97]. Die Definition eines WFMS durch die Workflow Management Coalition (WFMC) [WFM99] lautet : A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. Daraus lassen sich folgende Basisannahmen im Workflow- Management entnehmen: 19 Dort werden Workflows definiert als Aktivitäten, welche die koordinierte Ausführung von Aufgaben (Tasks) durch unterschiedliche Verarbeitungseinheiten umfassen (Übersetzung durch [VB96]).

86 68 Nachhaltigkeit und Vernetzung 1. Der zu unterstützende Workflow ist relativ stabil und einfach zu warten. WFMS arbeiten sehr gut, falls der Geschäftsprozeß gut dokumentiert ist und elektronisch unterstützt werden kann. 2. Es existiert ein detailliertes und konsistentes Geschäftsprozeßmodell, das von allen Beschäftigten im Unternehmen gut verstanden wird. Manche WFMS benutzen Referenzmodelle für spezielle Anwendungsdomänen, die dann für Unternehmenszwecke angepaßt werden können. Workflows können eine verschachtelte Struktur aufweisen: sie entsprechen sowohl Prozessen, Prozeßelementen als auch Prozeßschritten. 3. Die Benutzer der Systeme haben vergleichbare Fähigkeiten. WFMS bieten zumeist Benutzern die gleiche Art der Unterstützung durch Werkzeuge, unabhängig von der Aufgabe, die sie zu erfüllen haben. 4. WFMS arbeiten mit existierenden Werkzeugen und Lösungen der Anwendungsdomäne zusammen. Im Verbesserungsmanagement sind die Annahmen allerdings problematisch. Diese Vorgehensweise bei der Entwicklung von WFMS läßt die Arbeitspraxis, sofern sie nicht in der Ablauforganisation geplant ist, ungenügend berücksichtigt. Solcherart definierte WFMS, nur für Übertragung von Geschäftsprozessen auf Aufgabenträger gedacht, sind nach Schäl [Sch96a, S. 7] trotz ihrer Reflexion des ständigen Wandels in den Prozessen nur Ausdruck einer tayloristischen Auffassung von Arbeitsgestaltung, die zu Dequalifizierung des Personals, zu zentralisierenden Kontrollfunktionen und zu einer Bürokratisierung der Organisation führten. Damit wird zum einen der Umgang des Kunden mit einem solchen Unternehmen schwierig, da laut Schäl z.b. die Schnittstelle des Unternehmens zum Kunden häufiger wechselt. Da zum Gesamteindruck eines Produktes auch die Service-Qualität eines Unternehmens gehört (vgl. Abschnitt 2.1), kann dadurch die Kundenzufriedenheit erheblich beeinträchtigt werden. Zum anderen haben solche Systeme natürlichweise Schwierigkeiten durch die notwendige Wissens- und Teamorientierung und die damit verbundene Flexibilisierung der Arbeit im Verbesserungsmanagement. In Bezug zu obiger Aufzählung läßt sich für das Verbesserungsmanagement deshalb festhalten: 1. Verbesserungsmanagement-Prozesse sind nicht stabil, sondern können und sollen häufig wechseln. Experimente mit WFMS zeigen, daß sie schwierig an Prozeßänderungen zu adaptieren sind und Benutzer deshalb Trampelpfade [Ham90] abseits der Systeme etablieren. 2. Ab einem gewissen Detaillierungsgrad sind Verbesserungsmanagement-Prozesse nicht gut definiert und der Prozeßbesitz geht an die im Verbesserungsmanagement-Prozeß beteiligten Abteilungen über. Deshalb sind monolithische und komplexe Geschäftsprozeßmodelle, die auch noch von allen Beteiligten verstanden werden müssen, im Verbesserungsmanagement ohne Sinn. WFMS, die diese benutzen, reflektieren nicht den föderativen Organisationskontext des Verbesserungsmanagements. 3. Verbesserungsmanagement-Prozesse werden oftmals ad hoc behandelt und verteilen

87 3.4 Vernetzung 69 sich über mehrere Unternehmensfunktionen. Dort sitzen Beteiligte mit unterschiedlichen Wissenshintergründen, Erfahrungen und Arbeitsplatzbeschreibungen. Diese Profile müssen durch Integration einer personalspezifischen Unterstützungskomponente in das WFMS eingebaut werden. 4. In heterogenen Systemen gibt es nur selten Integration, weil die Lösungen sehr unterschiedlicher Herkunft sind. Deshalb verlassen sich WFMS auf simple Arbeitsunterstützungsmechanismen wie Aufgabenlisten, und Pert-Charts. Das vernetzte Verbesserungsmanagement aber verlangt eine spezifische Unterstützung von Mikroprozessen an den Arbeitsplätzen, die von der Eskalationsstufe abhängt. Neben der notwendigen Einbeziehung der Arbeitspraxis und der Kunden muß der von außen an ein Unternehmen herangetragene Änderungsdruck berücksichtigt werden. Schäl [Sch96a, S. 8] führt folgende äußere Umstände, die zur Kunden- und Prozeßorientierung in der Organisationsgestaltung führen können: Produkte entstehen in höherer Variantenzahl oder kundenspezifischen Versionen (vgl. Tabelle 2.1). Unternehmen werden internationaler (vgl. Tabelle 4.1). Offene und gemeinsame Märkte erhöhen den Druck auf die Kosten und Durchlaufzeiten. Die Umgestaltung von bürokratisch-funktionalen zu vernetzten Teams in Prozeßorganisationen ist nach Schäl die einzige Möglichkeit, um Unternehmen flexibel auf neue und sich kontinuierlich verändernde Umwelten reagieren zu lassen. In Abbildung 3.13 sind die alten funktionalen Einheiten in vernetzte Teams umgewandelt, zwischen denen die Geschäftsprozesse (möglicherweise mit den alten Funktionen) in Form von Eskalationen gestaltet werden müssen. Als wichtiges Prinzip der Kundenorientierung ist die eindeutige Kundenschnittstelle zwischen Unternehmen und Kunden eingetragen (engl.: Onefacetothecustomer ). Eine kundenorientierte Definition von Workflows, die zum einen Geschäftsprozesse Funktionale Einheit Business Team (Kompetenzstufe) Prozeß organisation Händler (Service und Wartung) Workflow (Eskalation) Kunde Call Center Stammwerk Abbildung 3.13: Verteilte Prozeßorganisation (adaptiert aus [Sch96a])

88 70 Nachhaltigkeit und Vernetzung und Workflows identifiziert und zum anderen eng an den Zielen des Verbesserungsmanagements ausgelegt ist, wird von Schäl vorgeschlagen [Sch96a, S. 12f]: A workflow is a unit of work generating products or services which are related to, or result in, customer satisfaction. Every workflow has a main customer, who is served by a supplier, or a cooperative network as being a chain of customers and suppliers, working towards the satisfaction of the main customer. Diese Definition vereinigt also Prozeß- und Kundenorientierung durch die Einrichtung kooperativer Netzwerke aus Kunden-Lieferantenketten. Schaut man nun innerhalb des Qualitätsmanagements in diese Netzwerke hinein, so erkennt man, daß auch dort tayloristische Vorstellung mittlerweile durch methodische und partizipative Entwicklungen sinnvoll ergänzt oder ersetzt wurden. Denn die, heute zum großen Teil informationssystem-gestützten methodischen Entwicklungen offenbaren die Team- und Wissensorientierung im Qualitätsmanagement. Gerade bei der Analyse von Geschäftsprozessen zwischen Kunden und Unternehmen ist der Vorteil service-orientierter Workflows deutlich. Abbildung 3.14 zeigt einen Ausschnitt aus der Modellierung des Vorgangs Lenkung fehlerhafter Produkte aus der Fallstudie in Abschnitt 2.7. Deutlich sind die nicht geschlossenen Zyklen zu erkennen. Kunden können völlig unterschiedliche Wege wählen, Beschwerden, Reklamationen und Reparaturaufträge einschließlich der betroffenen Produkte in das Unternehmen zu bringen. Das reparierte Produkt, die zugehörige Rechnung, der ablehnende Bescheid usw. kommen wiederum von anderen Stellen. Zwischendurch können weitere Kontakte zwischen Kunde und Unternehmen an anderen Stellen auftreten. Einzelne Kunden rufen in der Reparaturwerkstatt an, andere sind auf den Vertreter vor Ort angewiesen. Innerhalb des Unternehmens liegen ähnlich gelagerte Probleme bei der Bearbeitung fehlerhafter Produkte vor. In Abschnitt wird ausführlich auf die Modellierung service-orientierter Workflows im vernetzten Verbesserungsmanagement eingegangen. In Abbildung 3.15 ist die Herleitung des Workflow-Modells aus den Rollen, die eine Trisektion der Prozeßdurchführung begründen, und dem kundenorientierten Workflow-Modell von Schäl [Sch96a] dargestellt. Schäl nutzt dazu den auf Grundlage der Sprechakttheorie (engl.: Language-Action Perspective (LAP))[FGHW88] von Medina-Mora et al. [MMWFF92] entwickelten Ansatz. Die Sprechakttheorie geht von drei Annahmen aus. 1. Sprache kann Handlung ausdrücken, d.h. Sätze sind nicht nur deskriptiv, sondern drücken Handlungen aus, z.b. Hiermit mache ich Sie zu meinem Stellvertreter. 2. Sprache wird zur Koordinierung von Aktivitäten benötigt. Koordinierungsmaßnahmen können Absprachen, Anweisungen oder Aussagen umfassen. Kommunikation ist die Basis effektiver Zusammenarbeit. 3. Sprache schafft eine gemeinsame Realität für die Kommunikationspartner. Die Grundlage für ihre Interaktionen ist der Austausch von Sachverhalten, der Aufbau gemeinsamen Wissens und der Erwerb neuen Wissens. Aus der Sprechakttheorie heraus entwickelte Informationssysteme betonen daher die Wich-

89 3.4 Vernetzung 71 SB Meldung des Complaints QAR WE Artikel dekontaminieren MC-FO CH PER Abgleich QAR CH Reklamation SB CH Untersuchung des Complaints SB Kunde Warenanlieferung WE CH Klassifizierung? RS CH Berechtigter Complaint CH Archivierung QAR WV Kostenvoranschlag RS CH Unberechtigter Complaint QAR WV Verschrotten RS WV Reparaturauftrag RS Legende Aktions- Workflow Abbildung 3.14: Darstellung service-orientierter Workflows tigkeit der Kommunikation im Unternehmen. Das kundenorientierte Workflow-Modell zielt auf die Schaffung eines kooperativen Netzwerks aus Kunden-Lieferanten-Ketten. Jeder Workflow hat einen Hauptkunden und einen Lieferanten (vgl. Abschnitt 2.4). Der Workflow beschreibt die pragmatische Kommunikation zwischen Kunden und Lieferanten, die aus vier einzelnen Phasen bestehen, die zu einer geschlossenen Leistungserbringungskette führen sollen [Sch96a, S. 36f]. 1. In der der ersten Phase (Anfragephase) fragt der Kunde eine Dienstleistung oder ein Produkt nach. 2. In der zweiten Phase (Verpflichtungsphase) gibt der Lieferant die Verpflichtung ab, die spezifischen Bedingungen zu erfüllen. Die Bedingungen können Gegenstand von Verhandlungen zwischen Kunden und Lieferanten sein. 3. In der dritten Phase (Durchführungsphase) erfüllt der Lieferant die Bedingungen. Dadurch wird das gewünschte Produkt oder die Dienstleistung ausgeliefert. 4. In der vierten Phase (Auswertungsphase) wird die Kette geschlossen. Dies verlangt die Zustimmung des Kunden, der die erbrachte Leistung auswertet. In jeder der Phasen können Eskalationen (sekundäre Workflows) auftreten, die wiederum als kundenorientierter Workflow (oder vereinfacht als zweiphasiger Diskussionsworkflow [Sch96a, S. 38] modelliert werden. In der Anfragephase können Ergänzungen oder Kor-

90 72 Nachhaltigkeit und Vernetzung Prozeßausführung im Verbesserungsmanagement Ausschnitt des Workflowmodells nach Medina Mora et al. Workflowmodell des vernetzten Verbesserungsmanagements Abbildung 3.15: Workflow-Modell des vernetzten Verbesserungsmanagements rekturen bei gewünschtem Produkt oder verlangter Dienstleistung gemacht werden. In der Verpflichtungsphase können komplexe Verhandlungen der Verpflichtung vorausgehen. In der Durchführungsphase können Delegationen oder redundante Eskalationen erfolgen und in der Auswertungsphase kann die Bestätigung der Leistung Gegenstand eines komplexen Workflows sein Rollen in Eskalationen Ebenso wie bei mnemonischen Prozessen müssen auch Eskalationen rollenbasiert durchgeführt werden. Dies hat drei Gründe. Erstens muß die Koordination arbeitsteiliger Aktivitäten gewährleistet werden. 20 Zweitens muß die Zuführung von Informationen in der Eskalation rollenspezifisch sein, damit diese u.a. im Kontext der Rolle internalisiert werden 20 Die Zuordnung von Akteuren zu Workflows ist die Voraussetzung zur Koordination [Jab95]. Zur dynamischen Akteurzuordnung werden Rollenkonzepte herangezogen, durch das häufiges Nachbearbeiten von Workflow-Spezifikationen vermieden wird. Eine Rolle wird durch eine Menge von Fähigkeiten bzw. Kompetenzen beschrieben.

91 3.4 Vernetzung 73 kann. Drittens müssen die Arbeitsschritte zur späteren Analyse nachvollziehbar einer Rolle zugeordnet werden, wodurch gespeicherte Informationen rekontextualisiert werden können. Jedes Rollenmodell ist unternehmens- oder anwendungsspezifisch zu bestimmen. Rollenmodelle können aus einer eingehenden Analyse oder direkt aus einer explizit beschriebenen Aufbauorganisation eines Unternehmens gewonnen werden. Ein generisches Rollenmodell des Verbesserungsmanagements ist durch Metarollen beschrieben, die die Verantwortlichkeiten während der Eskalation definieren und aus denen sich Funktionen der Vorgangsbearbeitungen und Berechtigungen ableiten. Die Beteiligten eines Verbesserungsprozesses können durch genau drei Metarollen beschrieben werden (vgl. [KPJ98], [SS98, S. 160ff]). Diese übernehmen in den Eskalationstrategien genau definierte Rollen. Koordinator (engl.: Complaint Owner): Für das Verbesserungsmanagement ist der Hauptkunde der Koordinator, der entweder das Fehlerereignis entdeckt oder gemeldet hat. Dieser Kunde kann somit im gesamten Produktlebenszyklus auftauchen. Der Koordinator ist der Initiator der Eskalation. Dies spiegelt sowohl den Gedanken des Beschwerdemanagements als auch der Prozeß- und Kundenorientierung wider, daß der erste Bearbeiter einer Beschwerde für die Bearbeitung einer Beschwerde verantwortlich und dem Kunden gegenüber als Ansprechpartner erhalten bleibt. Der Koordinator ist damit für einen Fehlerfall verantwortlich. In dieser Phase ist der Koordinator auch gleichzeitig der Durchführer. Erst wenn der Fehlerfall eskaliert werden muß, wechselt die Rolle des Durchführers auf den neuen Lieferanten. Durchführer (engl.: Task Owner): Der Durchführer wechselt von Eskalationsstufe zu Eskalationsstufe (Ausnahme sind lokale Eskalationen, die durch das Weglegen und Wiederaufnehmen eines Fehlerfalls gekennzeichnet sind). Der aktuelle Durchführer übernimmt das Problem vom jeweils letzten Bearbeiter. Prüfer (engl.: Process Owner): Der Prüfer ist die letzte Instanz des Eskalationsvorgangs. Er entscheidet letztendlich, ob die Eskalation abgeschlossen ist oder abgebrochen werden muß. Im Sinne der Prozeßorientierung ist der Prüfer der Besitzer der Ressourcen einer Eskalation und muß deren betriebswirtschaftliche sinnvolle Nutzung sicherstellen. Weiterhin sorgt er für die Erstellung eines Abschlußberichts der Eskalation und verständigt alle Beteiligten über die Beendigung der Eskalation. Das Workflowmodell des vernetzten Verbesserungsmanagements verknüpft die Ausführung service-orientierter Workflows mit den generischen Rollen zur Ausführung von Verbesserungsprozessen. Damit wird eine explizite Prüfinstanz eingeführt, welche die Verwendung der Ressourcen in Verbesserungsprozessen überwacht, damit Eskalationen im Rahmen des Möglichen und Notwendigen bleiben.

92 74 Nachhaltigkeit und Vernetzung Replizierte elektronische Vorgangsmappen Eine wesentliche Anforderung an ein Verbesserungsmanagement-System ist die Sammlung, Aufbewahrung und Nutzung von Fehlerwissen trotz der bestehenden Barrieren. Die Diskussionen zeigten, daß im Verbesserungmanagement Workflows fallbasiert oder ad hoc ablaufen und damit aktivitätsorientierte Workflows auf der Basis detaillierter, konsistenter und definierter Ablaufinformationen nicht auf das Verbesserungsmanagement anwendbar sind. Der Kontext der Fehlerfallbearbeitung muß trotz der Heterogenität, der Verteilung und der Instabilität von Arbeits- und Informationsflüssen über zeitliche, örtliche, technische und konzeptuelle Barrieren erhalten und transportiert werden. Weiterhin sind viele etablierte Techniken der Analyse und Entscheidungsunterstützung im Verbesserungsmanagement, die der Komplexitätsreduktion dienen, dokumentorientiert. Für das Verbesserungsmanagement wird also eine flexible Unterstützung gesucht, die Abläufe im Verbesserungsmanagement unterstützt, Vorgangs- und Inhaltsdaten in Dokumenten bündelt, den Kontext der Bearbeitung erhält und entscheidungsunterstützende Maßnahmen dokumentiert. Zur Unterstützung von Vorgängen sind in nahezu allen Büros papierbasierte Vorgangsmappen zu finden (vgl. [KR91, Kar94]). Sie enthalten beliebige Dokumente, die zur Erledigung einer festgelegten Aufgabe notwendig sind, und werden von einem Bearbeiter zum nächsten transportiert. Es wird zwischen dem Transportmittel Vorgangsmappe und der inhaltlichen Arbeit an den Dokumenten unterschieden. Die Namen der nächsten Bearbeiter werden auf der Mappe vermerkt und ein interner Botendienst sorgt für die Weiterleitung. Vorgangsmappen sind außerordentlich flexibel einsetzbar, jedoch bereiten die schleppende Weiterleitung der Mappen, das Auffinden von Mappen, die sich im Umlauf befinden, der sequentielle Durchlauf aufgrund der physischen Existenz genau einer Mappe, Probleme. Abhilfe soll nach [KR91, Kar94] die Unterstützung durch elektronische Vorgangsmappen (engl.: electronic circulation folder) schaffen. Es ist zunächst einmal erstaunlich, daß ein Arbeitsmittel, welches ein Synonym für bürokratische Arbeitsformen geworden ist, nun als Metapher für die flexible Unterstützung service-orientierter Workflows dienen soll. Dabei sind zwei Sachverhalte zu berücksichtigen. Erstens hat die Elektronifizierung von Vorgangsmappen weitreichende Folgen für die Unterstützbarkeit durch ein Informationssystem. Zweitens kann gerade der Gebrauch vertrauter Metaphern die notwendigen Änderungen erleichtern. Für die Bearbeitung von Fehlerfällen im Verbesserungsmanagement werden die Vorgangsmappen in elektronischer Form repräsentiert und durch ein service-orientiertes WFMS unterstützt. Elektronische Vorgangsmappen abstrahieren in ihrer Realisierung von der Heterogenität der zugrunde liegenden DV-technischen Infrastruktur. Sie bündeln den Problemkontext idealerweise in den in der Vorgangsmappe enthaltenen Dokumenten und sie enthalten zusätzlich Informationen zur weiteren Verteilung von Informationen und Arbeit.

93 3.4 Vernetzung 75 Eine elektronische Vorgangsmappe umfaßt also neben den inhaltlichen Dokumenten zur Bearbeitung einer Aufgabe Informationen über den Bearbeitungsablauf (Workflow durch das Unternehmen, Arbeitsplatzkonfiguration etc.). 21 Dies ist der Kern der Vorgangsmappen- Metapher. Die Zweiteilung der elektronischen Vorgangsmappe ist in Abbildung 3.16 veranschaulicht, neben Ablaufinformationen für den Bearbeitungsweg sind Vorgangsdaten enthalten. Abbildung 3.16: Elektronische Vorgangsmappe Ein Vorgang ist eine spezielle Form von Aktivitäten in Organisationen. 22 Dabei ist die Unterscheidung von Vorgangstypen (Beschreibung von Vorgangsabwicklungen) und ihren Instanzen (konkrete Vorgänge) von Bedeutung. Die Definition von Vorgangstypen besteht aus zwei Teilen, der Ablauf- und der Aktivitätsbeschreibung. In der Ablaufbeschreibung ist die Reihenfolge der Aufgaben festgelegt, mit der ein Vorgang zum gewünschten Ziel geführt werden kann. Zu unterscheiden sind die sequentielle und die parallele Bearbeitung. In Abhängigkeit von Vorgangsvariablen können Verzweigungen angeboten werden. Die Aktivitätsbeschreibung enthält eine Spezifizierung der Aufgaben, die Zuordnung von Bearbeitern in Form von Rollen, Verweise auf benötigte Dokumente, Werkzeuge und Zeitvorgaben. Um Anpassungen bei Bearbeiterwechsel zu vermeiden und die Beschreibungen flexibel einsetzen zu können, ist die Abstraktion von bestimmten Personen notwendig. Hierzu dienen die Konzepte Rolle oder Stelle, die Kompetenzen bzw. Zuständigkeiten zusammenfassen. Verweise auf konkrete Personen sind auf diese Weise bei der Vorgangstypbeschreibung vermeidbar. Die Zuordnung von tatsächlichen Bearbeitern zu den Rollen geschieht im laufenden System. Zur Steuerung, Überwachung und Koordination von Aktivitäten innerhalb von Vorgängen existieren spezielle WFMS [SB95]. Diese komplexen Softwaresysteme sorgen für das automatische Weiterleiten von Vorgängen an dafür vorgesehene Bearbeiter gemäß der fallbasierten Vorgangstypbeschreibung. Über diese reine Steuerungsfunktion hinaus gibt es Managementfunktionalitäten, mit denen z.b. der Bearbeitungszustand und der Aufenthaltsort von Vorgängen festgestellt werden kann. 21 Im weiteren Verlauf werden die Begriffe elektronische Vorgangsmappe und Vorgangsmappe synonym verwendet. 22 Ein Vorgang wird in [SB95] definiert als abgrenzbare, strukturierte Folge von (mindestens zwei) Akti- vitäten mit Informationsaustausch, die von Mitgliedern einer Organisation aus einem bestimmten Grund und mit einem festgelegten Ziel ausgeführt werden.

94 76 Nachhaltigkeit und Vernetzung Die nachfolgend aufgeführten Vorteile der Informationstechnologie beziehen sich auf die elektronische Vorgangsbearbeitung im Gegensatz zur herkömmlichen papierbasierten. Elektronische Vorgangsmappen liefern demnach folgende Vorteile für das vernetzte Verbesserungsmanagement [KPJ98]: Kürzere Bearbeitungszeiten und qualitativ bessere Durchführung von Vorgängen: Durch das elektronische Verschicken von Informationen fallen Transportund Liegezeiten nahezu weg. Dokumente in elektronischer Form lassen sich einfach kopieren, so daß paralleles Arbeiten leichter möglich wird, wodurch die Bearbeitungsdauer ebenfalls gesenkt werden kann [SB95]. Durch das einfache Kopieren von Vorgangsmappen können die in Abschnitt beschriebenen Eskalationsstrategien realisiert werden, z.b. können mehrere Bearbeiter im betriebswirtschaftlich vertretbaren Rahmen parallel an der Lösung einer Aufgabe arbeiten, um so eine Auswahl von Ergebnissen zur Verfügung zu haben, von denen das beste umgesetzt wird. Jeder Bearbeiter wird durch das Wissen, daß andere am gleichen Problem arbeiten, angespornt, was sich positiv auf die Bearbeitungsdauer und Qualität auswirken kann [NT95, S. 80ff]. Die Bearbeitungsqualität kann ebenfalls dadurch verbessert werden, daß alle mit einem Vorgang verbundenen Aktivitäten genau festlegt sind und ihre vollständige Durchführung vom System überwacht werden kann. Kein Herumirren von Information und Vermeidung von Informationsüberfrachtung bei adäquater Nutzung der Sicht: Vorgangsmappen binden durch rollenbasierte Konfigurationskonzepte alle für die Durchführung einer Aufgabe notwendigen Informationen. In einer Mappe werden alle für den zugehörigen Vorgang relevanten Inhalte zusammengefaßt, so daß die Informationsbeschaffung vereinfacht wird. Insbesondere können Verweise auf andere elektronische Dokumente, wie z.b. Internet- Seiten und Online-Handbücher, durch mnemonische Prozesse direkt verfügbar gemacht werden. Durch die Verwendung von Rollenkonzepten lassen sich Informationen auf die jeweiligen Zuständigkeiten und Kompetenzen abstimmen. Informationsüberfrachtung kann auf diese Weise vermieden werden. Weiterhin sind die Rolleninformationen nutzbar, um aufgabenspezifische Unterstützung durch geeignete Software und Hardware zu bieten. Aufgabenspezifische Unterstützung und Möglichkeiten zur Vorgangssuche und -überwachung: Durch Rollenkonzepte kann weiter eine aufgabenspezifische Unterstützung für die Bearbeiter geleistet werden. Entsprechend den mit einer Rolle verbundenen Aufgaben werden benötigte Daten und Hilfsmittel (Werkzeuge) zur Verfügung gestellt. Bei der verteilten Bearbeitung von Vorgängen ist mittels des Informationssystems leicht feststellbar, wo und in welchem Zustand sich einzelne Vorgänge im System befinden. Ein Überblick über die gesamte Vorgangsbearbeitung zu Kontrollzwecken kann so einfach gewonnen werden. Nutzung von Erfahrungswissen: Wissen, das während der Vorgangsbearbeitung gewonnen wurde, läßt sich zum Aufbau eines Unternehmensgedächtnisses mittels mnemonischen Prozessen in verschiedenen Hinsichten nutzen, um in Zukunft darauf zugreifen zu können und dadurch Lerneffekte zu ermöglichen. Erstens kann das ent-

95 3.4 Vernetzung 77 standene Fehlerwissen genutzt werden, zweitens die durch die Eskalation gewonnene Ablauferfahrung. Die in den Vorgangsdaten enthaltenen Fallbeschreibungen werden durch Analyse- und Klassifikationstechniken zu Fehlern gebündelt und können als Erfahrungsgrundlage in die Bearbeitung gleicher oder ähnlicher Fehlerfälle einfließen. Es können enthaltene Ablaufinformationen zur Vorgangsverbesserung mit Hilfe von Nachvollziehbarkeitsinformationen genutzt werden. Über den Bearbeitungsprozeß lassen sich automatisch Daten erfassen, die es im nachhinein möglich machen, einzelne Bearbeitungsschritte und Entscheidungen nachzuvollziehen. Dadurch läßt sich eine Basis für die kontinuierliche Verbesserung der Prozeßdefinitionen (Vorgangstypenbeschreibungen) realisieren [Poh96, Döm99]. Die Kombination beider Hinsichten dient der Optimierung der Fehlerbearbeitung durch Verkürzung von Eskalationsketten, der Optimierung der Erfassungs-, Analyse- und Maßnahmequalität sowie der Verlagerung von Wissen im Produktlebenszyklus. Für die Realisierung eines Verbesserungsmanagementsystems auf Basis elektronischer Vorgangsmappen müssen die aus dem Eskalationsmodell gewonnenen Anwendungsfälle noch den Rollen zugeordnet werden. 23 Dabei werden die Systemfunktionalitäten informal beschrieben. Abbildung 3.17 zeigt die möglichen Anwendungsfälle in UML Notation. System zur Fehlerfallbearbeitung Fehlerfall anlegen Koordinator Prüfer Fehlerfall beobachten Fehlerfall weiterleiten Durchführer Fehlerfall zusammenführen Fehlerfall bearbeiten Fehlerfall abschließen Abbildung 3.17: System zur Fehlerfallbearbeitung - Anwendungsszenarien 23 In der Softwareentwicklung werden Anwendungsfälle (engl.: use cases) dazu verwendet, um informal die Benutzung, die Verantwortlichkeiten und die Dienste in einem objektorientierten Design zu beschreiben (vgl. [JCJO92]). Im Kontext von Informationssystemen werden Szenarien dazu eingesetzt, den sozialen Rahmen und die Umwelt des zu entwickelnden Systems zu beschreiben, mit dem Ziel, Auswirkungen des Systemeinsatzes und die Umsetzung von Benutzeranforderungen bewerten zu können (vgl. [Kyn95]).

96 78 Nachhaltigkeit und Vernetzung Anlegen: Das Anlegen eines Fehlerfalls wird im Sinne der Complaint Ownership nur von der Rolle des Koordinators durchgeführt. Dabei wird im System eine Vorgangsmappe mit einer ersten Version des Fehlerfalls, d.h. das aktuelle Fehlerbild, angelegt und das Fehlerbild soweit wie möglich erfaßt. Im Analyseschritt kann eine Klassifikation des Fehlerfalls durchgeführt werden, die erste Reaktionen ermöglicht. Weiterleiten: In diesem Fall sind mindestens zwei Rollen beteiligt. In der ersten Eskalation leitet der Koordinator die Vorgangsmappe an andere Durchführer weiter, in weiteren Eskalationen leiten Durchführer die Fehlerfälle an andere Durchführer weiter. Der Prüfer leitet nur dann eine Vorgangsmappe weiter, wenn Unstimmigkeiten festgestellt werden. Zur parallelen Bearbeitung können mehrere (auch gleiche) Rollen selektiert werden. Die Zuordnung von Rollen zu Agenten muß durch eine Rollenauflösung realisiert werden, die auch interaktiv Mehrdeutigkeiten eliminiert. Alle Agenten, die eine Mappe erhalten, werden vom System informiert. Bearbeiten: Das Bearbeiten eines Fehlerfalls wird entsprechend den Mikroprozessen des Eskalationsmodells realisiert. Ein Durchführer erhält eine Vorgangsmappe und lädt diese zur Bearbeitung, wodurch eine neue Version erzeugt wird, so daß die einzelnen Makroprozeßschritte nachvollziehbar und paralleles Arbeiten möglich bleiben. Je nach Agenten- und Arbeitsplatzspezifikation wird die Konfiguration der Vorgangsmappe, d.h. die Sicht auf die Daten, die jeweiligen Kompetenzen, die Rechte, die für den Agenten sinnvollen Funktionen und die verfügbaren Werkzeuge am Arbeitsplatz angeboten. Um sich über den bisherigen Bearbeitungsverlauf zu informieren, kann der Durchführer die Historie des Fehlerfalls einsehen. Zusammenführen: Eine Vorgangsmappe, die an mehrere Durchführer weitergeleitet wurde, kann vom Prüfer wieder zusammengeführt werden, da er aufgrund seiner Process Ownership Kompetenzen dazu in der Lage ist, mögliche Konflikte aufzulösen. Zu jeder aktuellen Version eines Fehlerfalls können alle parallelen Versionen gesucht werden; die auftretenden Konflikte werden automatisch ermittelt und angezeigt. Die Auflösung der Konflikte erfolgt interaktiv. Abschließen: Das Abschließen eines Fehlerfalls erfordert die gleichen Kompetenzen wie das Zusammenführen. Vor dem Abschluß ist eine inhaltliche und wirtschaftliche Prüfung notwendig, um inkonsistente und unvollständige Daten zu bearbeiten sowie die wesentlichen Prozeß-Kennzahlen zu bestimmen. Ein abgeschlossener Fehlerfall sollte alle relevanten Informationen enthalten, so daß ein Zusammenführen eventueller paralleler Versionen notwendig wird. Die Endversion wird im Unternehmensgedächtnis-System, als geschlossen markiert, gespeichert. Beobachten: Alle Rollen können laufende Fehlerfallbearbeitungen beobachten. Der Koordinator ist am Bearbeitungsfortschritt und an der Behebung des Fehlers interessiert. Es gibt zwei Beobachtungssichten. Zum einen können alle Vorgangsmappen beobachtet werden. Diese Liste wird laufend aktualisiert, so daß Änderungen für alle bisherigen Durchführer sichtbar sind. Zum anderen können einzelne Versionen einer Vorgangsmappe schreibgeschützt angezeigt werden, z.b. um Ähnlichkeitsbeziehungen festzulegen.

97 3.4 Vernetzung Eskalationsstrategien Neben den für das Verbesserungsmanagement ungeeigneten standardisierten Workflows gibt es noch fallbasierte und Ad-hoc-Workflows, die innerhalb einer kooperativen Vernetzung genutzt werden können, um den Arbeits- und Informationsfluß zwischen Personen zu koordinieren [Sch96a, S. 13]. Im Verbesserungsmanagement werden solche Workflows als Eskalationsstrategien bezeichnet. Eskalationen sind grundsätzlich fallbasiert oder ad hoc. Unbekannte Probleme werden in Ad-Hoc-Eskalationen bearbeitet. Bildet sich durch die gesammelte Erfahrung eine Problemfallklasse heraus, können Eskalationsmuster zu diesem Einzelfall definiert werden, woraus sich fallbasierte Workflows ergeben. Je nach Eskalationsstrategie kann die Struktur des Eskalationsgraphen unterschiedlich komplex werden. Es gibt drei Basisstrategien für Ad-Hoc-Eskalationen. Sequentielle Eskalation, parallele Eskalation und Deeskalation. Sequentielle Eskalation: Der einfachste Fall ist die sequentielle Eskalation. Indiesem Fall degeneriert der Eskalationsgraph zu einer linearen Struktur. Der Problemfall wird bei jeder Eskalation zur nächsten Kompetenzstufe weitergegeben. Parallele Eskalation: Im Falle der parallelen Bearbeitung wird das Problem an mehrere Kompetenzstufen gleichermaßen weitergegeben. Diese Kompetenzstufen können von gleicher oder unterschiedlicher Kompetenz sein. Auch die Intention kann unterschiedlich sein. Erstens kann versucht werden, das Problem in der Analysephase in mehrere Teilprobleme zu zerlegen und die Teilprobleme parallel lösen zu lassen. Diese Maßnahme soll Delegation genannt werden. Zweites kann das Problem an mehrere Kompetenzstufen vergeben werden, um durch Redundanz eine schnellere oder auch qualitativ hochwertige Lösung des Problems durch eine Verbesserung zu erreichen. Dieser Vorgang soll redundante Eskalation genannt werden. Drittens kann die Eskalation natürlich auch als Druckmittel verwendet werden. Durch gleichzeitige Eskalation an Bearbeiter und Entscheidungsträger kann Druck auf die Bearbeiter ausgeübt werden, das Problem schneller zu lösen. Deeskalation: Eine weitere Möglichkeit besteht in der Deeskalation. Dies ist das Weiterleiten (Zurücksenden) an einen vorherigen Bearbeiter. Dies kann notwendig werden, wenn das Problem vom vorherigen Bearbeiter falsch eingeschätzt wurde oder sich Komplikationen ergeben, die vorher nicht absehbar waren. Ziele der Eskalationsstrategien sind je nach Fall Einsparungen in der Zeit der Bearbeitung und der Anzahl der Bearbeitungsschritte (vgl. Abschnitt 4.3). In der Tradition des Beschwerdemanagements sind mit dem Eskalationsmodell sehr klar definierte Ziele verbunden, die überwiegend von Stauss und Seidel genannt wurden (vgl. [SS98] und [Kat98]). Im folgenden werden wesentliche Kennzahlen des Verbesserungsmanagements aufgelistet: Abgeschlossene Verbesserungsmaßnahmen: Das Verhältnis von entdeckten Fehlerereignissen zu abgeschlossenen Verbesserungsmaßnahmen gibt den Erfolgsgrad des Verbesserungsmanagements wieder. Aber auch in abgeschlossenen Eskalationen sind

98 80 Nachhaltigkeit und Vernetzung noch Verbesserungspotentiale vorhanden. Eskalationen sind ergebnisoffen. Am Beginn einer Eskalation ist somit selten erkennbar, ob ein Typ I Fehlerereignis professionell bearbeitet wird oder eine Reihe von Typ II Fehlerereignissen eine langwierige und in vielen Beziehungen teure Bearbeitung nach sich ziehen (vgl.abschnitt 3.1.3). Ein Problem kann grundsätzlich durch eine Verbesserungsmaßnahme gelöst werden, die sowohl den Kunden befriedigt als auch Produkt- und/oder Prozeßverbesserungen mit sich bringt. Eine Eskalation kann in einer temporären Lösung des Problems durch einen Work-Around enden. Je nach Einzelfall kann danach entschieden werden, das Problem weiter zu verfolgen oder es nicht mehr weiter zu verfolgen. Eskalationen können aber auch aus betriebswirtschaftlichen Gründen abgebrochen werden, z.b. wenn die Analyse und Reparatur eines Produktes teurer kommen würde als der Ersatz des Produktes, auch wenn das Problem des Produktes nicht in Erfahrung zu bringen ist. Maßnahmen, die aus ökonomischen oder fachlichen Gründen nicht gewählt oder beendet wurden, können gespeichert und in folgende Analysen einbezogen werden, falls sich Maßnahmen nachträglich als nicht ausreichend oder gar falsch herausstellen sollten. Schnelligkeit und Termintreue: Die Schnelligkeit in der Reaktion zwischen Eskalationsstufen, aber auch in der Gesamteskalation gibt Auskunft über die Reaktionsgeschwindigkeit des Verbesserungsmanagements und hat direkten Einfluß auf die Kundenzufriedenheit, da nicht der Eindruck entstehen darf, ein Kunde wurde vergessen. Versprochene Termine müssen eingehalten werden. Dabei muß eine Auskunftsfähigkeit über den Stand der eingeleiteten Verbesserungen erreicht werden. Geringe Tiefe der Eskalationen: Ziel der Optimierung ist die Verringerung der Anzahl der Eskalationen. Der längste Pfad im Eskalationsgraphen bezeichnet die maximale Eskalationszahl, wobei dies nicht unbedingt ein erfolgreicher Pfad sein muß. Eskalationen, egal ob aus einem Mangel an Fach- oder Entscheidungskompetenz, verlängern den Bearbeitungszeitraum. Deshalb ist eine hohe Rate von abgeschlossenen Maßnahmen in der ersten Eskalation ein Optimierungskriterium. Sie zeigt an, wie gut das Wissen aus vergangenen Fehlerfällen genutzt werden kann. Auch für den Kunden ist dieses Ergebnis optimal. Sie werden sich fair und kompetent unterstützt fühlen und versuchen nicht, Fehlerereignisse bis zur Geschäftsführung zu eskalieren. Geringe Breite der Eskalationen Dieses Maß gibt größte gleichzeitige Beteiligung von Abteilungen im Graphen wieder. Dadurch läßt sich die Breitenwirkung, mitunter die Redundanz oder auch die Suche nach Alternativen, angeben. Ziel im Verbesserungsmanagement ist es, unter Beibehaltung der Ziele einen geringen Aufwand bei der Bearbeitung zu erreichen. Die Ressourcenverbräuche müssen deshalb erfaßt und den Produkten zugeordnet werden. Die Verschmelzung zweier Ideen, die Bildung fallbasierter kooperativer Netzwerke im Verbesserungsmanagement und ein prozeß- und kundenorientiertes Rollenmodell, stärkt auf der organisatorischen Ebene die Verantwortung der Beteiligten bei der Prozeßdurchführung. Auf der technischen Ebene dienen Rollenkonzepte der Koordination der Agenten in ihren

99 3.5 Gesamtansatz des nachhaltigen vernetzten Verbesserungsmanagements 81 Rollen während der Eskalation durch die Berechtigung, Funktionen mit zielgerichteten Informationen nachvollziehbar auszuführen. Die Erzeugung, die Bewahrung, den Austausch und die Nutzung von Fehlerwissen wird durch mnemonische Prozesse geleitet, in denen die Prozeßbeteiligten gleichzeitig entsprechende Rollen als Wissensagenten annehmen. Diese mnemonischen Prozesse müssen für die Beteiligten während der Eskalation weitestgehend transparent ausgeführt werden, damit sie nicht von der eigentlichen Aufgabe der Fehlerfallbearbeitung abgelenkt werden. 3.5 Gesamtansatz des nachhaltigen vernetzten Verbesserungsmanagements Nachhaltigkeit und Vernetzung bei der Erzeugung, Bewahrung und Nutzung von Fehlerwissen im Produktlebenszyklus sind die primären Ziele im Verbesserungsmanagement. Die Verknüpfung zwischen dem Produktlebenszyklus eines Produktes und dem Verbesserungsmanagement wird durch die Einrichtung von personen-/abteilungsübergreifenden, kompetenzübergreifenden und prozeßübergreifenden Wissenstransferprozessen geleistet. Ausgehend von der Idee, kurzfristige Abläufe und langfristigen Wissensaufbau zu verbinden [Pet96, S. 55f] 24,müssen die verschiedenen Rollenkonzepte, das zugrundeliegende variantenbehaftete Produkt- und Prozeßwissen und die konkrete Fehlersituation berücksichtigt werden. Die Verschmelzung von Vorgangsbearbeitungssystemen und Unternehmensgedächtnis- Systemen bieten eine Reihe von Vorteilen. Vorgangsbearbeitungssysteme unterstützen die direkte, verzögerungsarme Fallbearbeitung von Fehlerereignissen die systematische Identifizierung von Problemlösungskompetenzen in Bearbeitungsbereichen und die strukturierte Unterstützung während der Fehlerfallbearbeitung. Unternehmensgedächtnis-Systeme unterstützen die Diagnose- und Lernkapazitäten bei der Fehlerfallbearbeitung und die erfahrungsbasierte Verbesserung von Eskalationen. Ein Überblick über den Gesamtansatz des nachhaltigen vernetzten Verbesserungsmanagements ist in Abbildung 3.18 in Form einer Systemarchitektur dargestellt. Einzelnen Teilen der Systemarchitektur werden die einzelnen Phasen des Wissenstransformationsansatzes von Nonaka und Takeuchi zugeordnet. Dies verdeutlicht den Fokus der einzelnen Serverund Klientenkomponenten. 24 Diese Idee ist mit dem Konzept der Qualitätsregelkreise auf verschiedenen Detailstufen verbunden [Pfe93]

100 Kunde Fehlerbild eskalieren Feedback Erfassen z.b. Call Center Korrigieren Fehlerbild eskalieren Feedback Erfassen z.b. Serviceingenieur Analysieren Korrigieren Fehlerbild eskalieren Feedback Erfassen Analysieren Korrigieren enthält führt_aus führt_aus benutzt benutzt unterstützt erzeugt nutzt unterstützt erzeugt nutzt sucht stellt_dar G ehäuse Staubsauger Deckel Boden Antrieb Wele M otor Strom versorgung Rotor Meta-Meta-Ebene Meta-Ebene enthält Motoren G ehäuse Bohrm aschine Antrieb Körper Bohrkopf Wele Trafos M otor Strom versorgung W icklung G ehäuse Haartrockner Träger Auslaß Antrieb Wele M otor Strom versorgun Rotor 82 Nachhaltigkeit und Vernetzung Kombination: Aufbau von variantenorientiertem Fehlerstrukturwissen Eskalationsbereich Eskalationsbereich Eskalationsbereich z.b. FMEATeamsitzung Agent Wissensagent Prozess Hilfsmittel Fehler- struktur- wissen Mappenmanager Unternehmensgedächtnis- Repository Externalisierung: Nachhaltige, prozeßorientierte Fehlerfallspeicherung Objekt UGS- Repository Wissenserzeuger Mmenonischer- Wissensverbraucher UGS-Objekt Prozeß Wissensträger Gemeinsames Wissensadministrator Akquisition Suche Wiedergewinnung Monitoring Replizierte Elektronische Vorgangsmappen Metamodell Mnemonische Prozesse unterstützen On-the-Fly Model Engineering Nutzung von Variantenwissen Kunde Feedback Fehlerbild eskalieren Erfassen Kunde Eskalationsbereich z.b. Call Center Korrigieren Fehlerbild eskalieren Eskalationsmanager Feedback Erfassen Anfragemanager Eskalationsbereich z.b. Serviceingenieur Analysieren Korrigieren Eskalationsbereich z.b. Call Center Fehlerbild eskalieren Erfassen Feedback Fehlerbild eskalieren Feedback Erfassen Eskalationsbereich z.b. FMEA Teamsitzung Einbindung heterogener Informationsquellen Analysieren Korrigieren Konfiguration und Versionierung Elektronischer Vorgangsmappen Korrigieren Steuerung des Mappenflusses durch die Eskalation Eskalationsbereich z.b. Serviceingenieur Fehlerbild eskalieren Analysieren Erfassen Feedback Internalisierung: Eskalationsspezifische Fehlerfallbearbeitung Korrigieren Eskalationsbereich z.b. FMEA Teamsitzung Fehlerbild eskalieren Analysieren Erfassen Korrigieren Feedback Analysieren Sozialisierung: Bildung virtueller Verbesserungsteams Abbildung 3.18: Rahmenwerk des nachhaltigen vernetzten Verbesserungsmanagements im Überblick Sozialisierung und Externalisierung Als Reaktion auf das Vorliegen eines Fehlerfalls soll die Vernetzung schnelle Gegenmaßnahmen durch die Analyse des Fehlerbildes ermöglichen. Dazu ist es notwendig, das Fehlerwissen durch kurzfristige Vernetzungstrategien der virtuellen Teambildung entsprechend der Aufgabenstellung zu den richtigen Personen zu transportieren, um das vorliegende Problem zu identifizieren, einen oder mehrere Lösungsvorschläge zu erarbeiten und diese Lösungsvorschläge praktisch umzusetzen. Zur Erzeugung der schnellen Gegenmaßnahme muß das Fehlerwissen der Vergangenheit in diesen kurzfristigen Vernetzungen nutzbar sein. Um nicht nur ad hoc zu reagieren, muß das in diesen kurzfristigen Prozessen gesammelte Fehlerwissen sowohl reaktiv als auch proaktiv genutzt werden können. Das bedeutet, daß zur effizienten Nutzung das erzeugte Fehlerwissen entlang des Produktlebenszyklus gesammelt und so organisiert werden muß, daß reaktive Verbesserungen (SLL) als Maßnahme zur Lösung von Fehlerfällen in gegenwärtigen Produkt- und Prozeßgenerationen und proaktive Verbesserungen (DLL) als Maßnahme zur Abstellung von Fehlern in künftigen Produkt- und Prozeßgenerationen generiert werden können. Das reaktive Verbesserungsmanagement ist also vordringlich mit der Aufgabe befaßt, Fehlerwissen

101 3.5 Gesamtansatz des nachhaltigen vernetzten Verbesserungsmanagements 83 horizontal, vertikal und prozeßübergreifend aus den produktionsnahen in kundennahe Phasen des Produktlebenszyklus zu transferieren, um die Schnelligkeit von Maßnahmen zu optimieren. Dazu ist es notwendig, daß ein Feedback über den aktuellen Bearbeitungsstand des Fehlerfalls gegeben ist, so daß der Koordinator und gegebenenfalls der Prüfer beschleunigend oder deeskalierend in das Geschehen eingreifen können. Das proaktive Verbesserungsmanagement verknüpft, aufbauend auf dem reaktiven Verbesserungsmanagement, die Erfahrungen aus produktionsnahen und kundennahen Bereichen mit produkt- oder prozeßplanenden Bereichen, um in künftigen Produkt- und Prozeßgenerationen proaktive Maßnahmen zur Fehlervermeidung zu treffen. Dabei sind die in den kurzfristigen Fehlerfallbearbeitungen gesammelten Erfahrungen in zwei Weisen von Nutzen. Erstens bilden die Verallgemeinerungen erfolgreicher Lösungsvorschläge die Basis für Verbesserungen und Innovationen, zweitens unterstützen sie die Bildung von langfristigen Verbesserungsteams. Die gegenseitige Kenntnis von Kompetenzen hilft bei der Auswahl von Personen aus dem gesamten Unternehmen. Dabei wird die Auswahl durch Generierung von Wissensprofilen durch das Repository unterstützt. Obwohl der Lösungshorizont reaktiver und proaktiver Verbesserungen unterschiedlich ist, ermöglicht erst die Verzahnung beider Ansätze die effiziente Nutzung des Fehlerwissens. Innovationspotentiale liegen damit nicht nur in den Forschungs- und Konstruktionsabteilungen, sondern können aus dem reaktiven und proaktiven Verbesserungsmanagement durch die systematische Aufbereitung und Ausnutzung von Fehlerwissen gewonnen werden. Das Fehlerwissen wird fallbasiert in elektronischen Vorgangsmappen dezentral externalisiert. Die Versionierung von Fehlermappen ermöglicht eine zusammenhängende prozeßorientierte Speicherung. Jeder Version einer Fehlermappe entspricht eine Eskalationsstufe mit ihrem gesamten Kontext. Obwohl also die Generierung von Fehlerwissen dezentral abläuft, wird im Server eine Fallhistorie der Fehlerfallbearbeitung samt dem organisatorischen, technologischen und personellen Kontext abgespeichert. Kombination Für die reine Speicherung und den Zugriff auf elektronische Fehlermappen reichen herkömmliche Datenbanktechnologien aus. Für die ebenfalls dezentrale Fehlerfallbearbeitung muß der Kontext der Fehlerbearbeitung laufend mit dem sich ändernden variantenbehafteten Produkt- und Prozeßwissen eines Unternehmens verknüpft werden. Dabei sind folgende Gesichtspunkte zu beachten, die vorher schon in Fallstudien diskutiert wurden: Fehlerwissen unterliegt der Interpretation: Auch wenn der Sachverhalt eines Produktfehlers und/oder einer Funktionsstörung vorliegen, kann die Interpretation auf unterschiedlichen Ebenen und aus unterschiedlichen Perspektiven verschieden sein. Ob eine Reklamation berechtigt ist oder nicht, ob Kulanz gewährt wird oder nicht, sind Entscheidungen, die Kompetenzen einzelner Mitarbeiter überschreiten und möglicherweise Neubewertungen des vorliegenden Sachverhalts auslösen. Innerhalb der Neubewertung muß der Informationskontext erhalten bleiben, so daß trotz zeitlicher und räumlicher Entfernung vom Fehlergeschehen noch eine angemessene Interpretation des Fehlergeschehens möglich ist.

102 84 Nachhaltigkeit und Vernetzung Fehler müssen klassifiziert werden: Trotz der Erfassung von Fehlern ist die Nutzung des gesammelten Fehlerwissens durch mangelnde Einordnung der Fehler erschwert. Zum Aufbau von nutzbarem Fehlerwissen ist die Strukturierung des Wissens entsprechend den Nutzungszielen notwendig. Diese Nutzungsziele sind die Verbesserung der eigentlichen reaktiven Prozesse und die Verbesserung der Produkt- und Prozeßentwicklung. Deshalb muß über diesen Fehlerfällen Fehlerstrukturwissen aufgebaut werden. Dies verlangt den Einsatz von Repository-Technologien, die es erlauben, unter sich ändernden Bedingungen, dieses Wissen nutzbar zu erhalten. Dabei unterstützen mnemonische Prozesse die Erzeugung, Wartung und Nutzung einer strukturierten, variantenorientierten Fehlerwissensbasis. Die uniforme und nachvollziehbare Verwendung von mnemonischen Prozessen auf den Wissensrepräsentationen wird durch ein Metamodell gewährleistet. Die Metamodellierung erlaubt die Introspektion der durch die Fehlerfallbearbeitung gewonnenen Modelle (engl.: On-the-fly model engineering) sowie weitergehenden Analysen sowohl von Modellen als auch Basisdaten. Veränderungen bestimmen Unternehmen, auch das Verbesserungsmanagement ist diesen ständigen Veränderungen unterworfen. Das nachhaltige Verbesserungsmanagement zielt mittels der mnemonischen Prozesse auf die systematische Reflexion von organisatorisch und technologisch determinierten Veränderungen und Innovationspotentialen in den durch reaktives und präventives Verbesserungsmanagement geschaffenen Wissensbasen 25. Internalisierung Ausgehend von diesem Unternehmensgedächtnis-Repository kann nun das gesammelte Fehlerwissen in der eskalationsspezifischen Fehlerfallbearbeitung genutzt werden. Obwohl Fehler erfaßt und auch bearbeitet werden, fließt das Wissen gar nicht, unspezifisch oder nicht an die zuständigen Stellen. Dadurch werden entweder Mehrfachbearbeitungen ausgelöst oder das Problem wird nicht weiter verfolgt. Zur operativen Gestaltung von Verbesserungsprozessen sind drei serverseitige Komponenten zur rollenbasierten, arbeitsplatzspezfischen Unterstützung der Fehlerfallbearbeitung auf der Seite der Klienten vorgesehen. Der Anfragemanager bindet zur Fehlerbearbeitung notwendige Informationsquellen ein. Diese Quellen können unternehmensintern oder -extern sein und die Strukturen der Information können heterogen organisiert sein. Entscheidend ist die Modellierung der Informationsquellen im Unternehmensgedächtnis-Repository. Die Informationsquellen müssen für den Anwender weitestgehend transparent und aufgabenspezifisch in die elektronische Fehlermappe eingebunden werden, z.b. als HTML-Seite. Der Mappenmanager verwaltet serverseitig die rollen- und arbeitsplatzspezifische Konfiguration und Versionierung der elektronischen Fehlermappen. Er sorgt für die Konsistenz der Vorgangsmappen während der Eskalation. Der Eskalationsmanager steuert den Mappenfluß durch die Eskalation. Dabei nutzt 25 Die Diskussion des KAIZEN-Konzepts zeigt, daß die Leistungsverbesserung durch eine Kombination von Innovationen und ständiger Verbesserung effizient wird. [Kla93, S. 27]

103 3.6 Zusammenfassung 85 er Vorgaben aus der Fehlermappe oder steuert ad hoc Verhandlungen zwischen den Eskalationsstufen. 3.6 Zusammenfassung Ziel dieses Kapitels war es, aus einer organisationstheoretisch motivierten Untersuchung des Lernens von Unternehmen aus Fehlerwissen heraus, einen informatisch motivierten Lösungsansatz abzuleiten. Dabei wurde das Rahmenwerk der kooperativen Informationssysteme angewendet, das auf der Grundlage der Leitbegriffe Kooperation und Veränderung die gegenseitige Beeinflussung von Arbeitspraxis, formaler Organisation und Informationstechnologie in Bezug auf die Stabilisierung des Wandels erklärt. Dazu ist es im Verbesserungsmanagement notwendig, die beteiligten Personen unter nachhaltiger Einbindung von Organisationseinheiten, Prozessen, Hilfsmitteln und Wissenbasen zu vernetzen. Als Kernelemente wurden ein Unternehmensgedächtnis auf der Grundlage von Wissenstransformationen zur langfristigen Konservierung von Wissen und das Eskalationsprinzip zur operativen Gestaltung des Verbesserungsmanagements identifiziert. Die Kombination beider Ansätze ermöglicht das Lernen im Verbesserungsmanagement auf der Grundlage des Wissenstransformationsansatzes von Nonaka und Takeuchi. Für den Entwurf und die Implementierung eines Verbesserungsmanagementsystems, das einen Austausch zwischen operativen und unternehmensgedächtnis-bezogenen Arbeits- und Informationsflüssen realisiert, sind sowohl der Stand der Technik auf der Nachfrageseite als auch auf der Angebotsseite zu klären. Die Praxis des rechnergestützten Verbesserungsmanagements gibt vor, welche informationstechnologischen Realisierungsoptionen überhaupt mit den vorhandenen Ansätzen und Möglichkeiten konform sind. Die Realisierungsoptionen der Anbieter, seien es Unternehmen oder Forschungsinstitute, geben den Rahmen vor, in der praxisnahe Verbesserungsmanagementsysteme realisiert werden können und wo die aus dem Theorierahmen stammenden Herausforderungen in der Forschung verortet werden können.

104 Kapitel 4 Rechnergestütztes Verbesserungsmanagement in der Praxis Das Schlimmste ist nicht: Fehler haben, nicht einmal sie nicht bekämpfen, ist schlimm. Schlimm ist, sie zu verstecken. Bertolt Brecht Eine bestimmende Motivation dieser Arbeit ist die Nachfrage der Praxis nach anwendbaren DV-Lösungen für das Verbesserungsmanagement. Um dieser Aufgabe gerecht zu werden, ist es zunächst wichtig, den Stand des DV-gestützten Verbesserungsmanagements 1 in der Praxis auf breiter Basis zu ermitteln. Der Stand der Praxis, der dieses Kapitel einleitet, wurde durch eine zweistufige Fragebogenerhebung ermittelt und ausgewertet. In diesem Kapitel bildet die Nachfrage kleiner und mittelständischer Unternehmen der Fertigungsindustrie den Kern der Untersuchung. Neben der Bedeutung (vgl. Abschnitt 4.2) und der Ist-Situation (vgl. Abschnitt 4.3) des Verbesserungsmanagements für die Praxis, sollte die Befragung eine Detailanalyse (vgl. Abschnitt 4.4) der DV-Organisation im Verbesserungsmanagement in kleinen und mittelständischen Unternehmen ermöglichen. Dazu wurden vier Schwerpunkte adressiert: Die Nutzung der DV-Infrastruktur zur Unterstützung des Verbesserungsmanagements. Die Nutzung von Software für die Aufgaben des Verbesserungsmanagements. Die Organisation und Nutzung von Fehlerdaten. Die Organisation von rechnergestützten Informations- und Arbeitsflüssen. 1 Die Begriffe Fehlermanagement und Verbesserungsmanagement werden in diesem Kapitel synonym verwendet.

105 4.1 Aufbau und Durchführung der Befragung 87 Die Detailanalyse ergab, daß die DV-Organisation und die Nutzung von Software für die Organisation des Fehlerwissens und die Gestaltung rechnergestützter Informations- und Arbeitsflüsse noch große Verbesserungspotentiale bereithält. 4.1Aufbau und Durchführung der Befragung Um den Stand des Verbesserungsmanagements zu erfragen, wurde im Januar 1996 zunächst ein kurzer Fragebogen an 1525 kleine und mittelständische Unternehmen, hauptsächlich aus dem Stahl- und Metallbau, dem Maschinenbau und der Kunststoffindustrie geschickt. Die in Tabelle 4.1 aufgeschlüsselten Verkaufsregionen der Unternehmen zeigen, daß fast 80 % der Unternehmen weltweit verkaufen, bei einer geringen Enthaltung. Der Markt ist auch für kleine und mittelständische Unternehmen ein globaler. Angaben in % Ja Nein Keine Angabe Regional Überregional Europaweit Weltweit Tabelle 4.1: Verkaufsregionen von 349 befragten Unternehmen Dieser Fragebogen wurde gestaltet, um die Bedeutung, Ist-Situation und Soll-Situation des Verbesserungsmanagements in Deutschland zu ermitteln sowie Unternehmensdaten und Vorschläge aufzunehmen [FWKP96, Pfe97]. Ein zweiter Fragebogen wurde an die 349 Unternehmen (Quote: 23 %) verschickt, die den ersten Fragebogen beantwortet und Interesse an einem zweiten, detaillierten Fragebogen bekundet hatten. Von diesen Fragebögen wurden 60 (Quote: 17 %) zurückgeschickt und 48 ausgewertet. Obwohl die absoluten Zahlen einer Umfrage immer mit etwas Vorsicht zu genießen sind, spiegeln allein die Größenordnungen der Antworten die Bedeutung, die problematische Ist-Situation und die Anforderungen an ein zukünftiges Verbesserungsmanagement wieder. Der detaillierte zweite Fragebogen war in drei Teile gegliedert. 2 Im dritten Teil, der vom 2 Die einzelnen Teile wurden jeweils von einem der im Projekt FOQUS beteiligten wissenschaftlichen Institute gestaltet. Der erste Teil des Fragebogens erfragte den Stand des Verbesserungsmanagements in produktionsnahen Bereichen (im Projekt internes Fehlermanagement genannt) und wurde vom Lehrstuhl für Fertigungsmeßtechnik und Qualitätsmanagement am Werkzeugmaschinenlabor (WZL) der RWTH Aachen betreut. Der zweite Teil des Fragebogens konzentriert sich auf die Gestaltung des Reklamationsmanagements (im Projekt externes Fehlermanagement genannt) und wurde vom Lehrstuhl für Fertigungtechnik und Betriebsorganisation (FBK) am Centrum für Produktionstechnik (CCK) der Universität Kaiserslautern erstellt. In beiden Teilen werden inhaltliche und organisatorische Aspekte erfragt, die für die Gestaltung des Verbesserungsmanagements wesentlich sind.

106 88 Rechnergestütztes Verbesserungsmanagement in der Praxis Verfasser dieser Arbeit am Lehrstuhl für Informatik V der RWTH Aachen erstellt und betreut wurde, wird explizit nach der DV-Organisation und den Informations- und Arbeitsflüssen im Verbesserungsmanagement gefragt. Die Darstellung und Analyse der Ergebnisse dieses Teils bilden einen Schwerpunkt dieses Kapitels. 4.2 Bedeutung des Fehlermanagements Die Bedeutung des Fehlermanagements wird durchweg als hoch angesehen. Obwohl das Fehlermanagement als Ansatz zur Vermeidung von Kundenverlusten und zur Reduktion von Nacharbeits- und Garantiekosten erkannt wird, muß der Aufwand für die Nutzung des Fehlermanagements aber für 68 % der befragten Firmen deutlich reduziert werden. Fast 80 % der befragten Unternehmen stuften das Fehlermanagement als sehr wichtig ein, weitere 19 % zumindest als wichtig. Damitschätzt nur 1 % der befragten Unternehmen das Fehlermanagement als nicht so wichtige unternehmerische Aufgabe ein. Desweiteren läßt sich die Bedeutung des Fehlermanagements aus den relativ hohen Rücklaufquoten der Fragebögen erschließen. In der Produktion sind durchschnittlich 60 % der Fehler Wiederholfehler und binden dadurch ca. 10 % der Maschinen- und Personalressourcen. Insbesondere soll das Fehlermanagement einen Beitrag zur Kostensenkung leisten. Für 76 % der Unternehmen ist die Reduktion der als zu hoch eingeschätzten Nacharbeitskosten eine wichtige Motivation, aber auch die Garantiekosten sind für die Hälfte der Unternehmen ein wichtiger, zu reduzierender Kostenfaktor. Fast 60 % der Unternehmen betrachten Fehler als eine Ursache für den Verlust von Kunden. Dies korreliert mit einer Untersuchung von Desatnik [Des89], wonach 90 % der Kunden, die mit der Qualität eines Produktes unzufrieden sind, dies fortan meiden werden. Der erste Fragebogen verdeutlichte die Potentiale, die ein nachhaltiges Verbesserungsmanagement besitzt. 4.3 Ist-Situation des Fehlermanagements Der erste Fragebogen ergab nach der Auswertung von Antworten und Kreuzvergleichen folgendes Meinungsbild in kleinen und mittelständischen Unternehmen der Fertigungsindustrie: Keine Fehlererfassung trotz hoher Nacharbeitskosten. Nur 20 % der Unternehmen, die ihre Nacharbeitskosten als zu hoch einschätzen, führen eine systematische Fehlererfassung zur Vorbereitung der Ursachenanalyse durch. Keine Fehlerursachenanalyse trotz Fehlererfassung. Unternehmen, die angaben, Reklamationsdaten von Kunden systematisch zu erfas-

107 4.3 Ist-Situation des Fehlermanagements 89 sen, führten zu fast 75 % keine Ursachenanalyse durch, womit die Datenerfassung ins Leere läuft. Fehlermanagement sollte mehr sein als standardisierte Formulare zur Fehlererfassung. Nur 22 von 108 Unternehmen (20 %) haben Vertrauen in die vollständige und korrekte Wiedergabe des Fehlergeschehens durch die Erfassung mittels standardisierter Formulare. Gerade die Qualität der Erfassung ist nach Ansicht vieler Unternehmen verbesserungswürdig. Der Qualitätsregelkreis wird nicht geschlossen. Wiederum sind fast 70 % der Unternehmen, die Reklamationsdaten systematisch erfassen, nicht in der Lage, diese Informationen aus der Produktnutzungsphase in die Fertigung oder noch frühere Phase rückzukoppeln. Fehlende Rückführung von Fehlerdaten zur Produktentwicklung. Trotz der nicht verschwindend geringen Quote von 17 % der Unternehmen, die das Fehlerwissen als wesentliche Grundlage der Produktentwicklung betrachten, verdeutlicht die Auswertung den provisorischen Charakter des Fehlermanagements in vielen Unternehmen. Die systematische Analyse des Fehlerwissens führt gerade bei kleinen und mittelständischen Unternehmen kaum statt. Viele Gründe sind hierfür ausschlaggebend, von denen hier nur zwei adressiert werden. Erstens führt der hohe Marktdruck zu knappen Ressourcen, die vorwiegend an das Tagesgeschäft gekoppelt sind. Experten werden dennoch zur Lösung von relativ einfachen Routineproblemen herangezogen. Tiefergehende Analysen werden dadurch erschwert. Fehlerursachen werden so oft nicht behoben, sondern umgangen, Änderungen selten dokumentiert und Verbesserungen erst gar nicht angedacht, wodurch die Nachhaltigkeit der Ursachenbekämpfung gefährdet wird. Zweitens führen die Suche nach neuen Marktchancen und die starke Kundenbindung zu einer Fertigung mit einer hohen Anzahl von Varianten in Klein- oder Einzelfertigung, anstatt in Großserien zu fertigen und eine relativ begrenzte Produktpalette zu pflegen, wodurch die Anwendung klassischer Methoden der Statistik, z.b. SPC, erschwert wird. Die hohe Bedeutung, die dem Fehlermanagement zugewiesen wird, zeigt deutliche Diskrepanzen hinsichtlich der Kopplung mit der fortlaufenden Produkt- und Prozeßverbesserung. Überall in den Wertschöpfungsketten ist Wissen verteilt. Wissen und Ideen existieren in den Köpfen der Mitarbeiter, in den Kompetenzen, in den Prozessen, in den Produkten. Repräsentationen von Wissen stecken in den Dokumenten und Datenbanken der Unternehmen. Zusätzlich zu der Verteiltheit des Wissens, erschweren die unterschiedlichen Formen, Spezifikationen, Repräsentationen und Präsentationen von Wissen eine systematische Nutzung. Zukünftige Produktgenerationen hängen von den Erfahrungen, dem Wissen und den Ideen des Unternehmens ab. Die Potentiale des reaktiv-proaktiven Verbesserungsmanagements, die Chancen, die sich aus der Lösung von Problemen, der Behebung von Fehlerursachen, der systematischen Nutzung von Fehlerwissen und der Gestaltung von neuartigen Kundenschnittstellen (engl.: Customer Relationship Management oder ElectronicCustomer Care [MO98]) ergeben, werden nicht im ausreichendem Maße zur Grundlage

108 90 Rechnergestütztes Verbesserungsmanagement in der Praxis für Kundenorientierung und Innovation im Unternehmen herangezogen. Gerade diese Kompetenzen werden für innovative Produkte und die Gestaltung unternehmensübergreifender Wertschöpfungsketten benötigt [ZHB99]. Am Schluß des Fragebogens formulierten die bedirekte Umsetzung der Fehleranalyse in vorbeugende Maßnahmen (Automobilbau) bezahlbar, auch für kleine Unternehmen (Metallbau) schnell, wirksam, rechnergestützt (Gießerei) Produkt- und Prozeßplanung soll auf Fehlermanagementdaten zürückgreifen können (Maschinenbau)... transparenter, eindeutiger, konsequenter und von jedem Mitarbeiter praktiziert (Textilindustrie) Umsatz, Cash-flow sind nur momentane Ergebnisse, Fehler sind Meinungsbilder für die Zukunft (Textilindustrie)... muß die kontinuierliche Verbesserung in kleine Schritten unterstützen (Dienstleistung)... nicht nur in der Produktion sondern unternehmensweiter Einsatz (Medizintechnik) Abbildung 4.1: Anregungen für ein Verbesserungsmanagement der Zukunft (adaptiert aus [Pfe97]) fragten Unternehmen Anregungen für die Gestaltung eines Verbesserungsmanagementsystems (vgl. [Pfe97, S. 15].) In Abbildung 4.1 sind einige der Anregungen zusammengefaßt. Im nächsten Abschnitt werden durch eine Detailanalyse der DV-Organisation des Verbesserungsmanagements Gründe für die bisherige mangelnde Umsetzung der Anregungen in die Praxis gegeben. 4.4 Detailanalyse der DV-Organisation In den detaillierten Fragebögen wurde nach dem internen Fehlermanagement, dem externen Fehlermanagement und der DV-Organisation des Fehlermanagements gefragt. Die Datenbasis für die Auswertung ist bei dieser Umfrage geringer als beim ersten Fragebogen, dafür zielen die Fragen nicht auf die Ermittlung eines Meinungsbildes, sondern erfragen konkrete Daten, z.b. über die DV-Organisation des Fehlermanagements in den Unternehmen. Zu beachten ist dabei, daß für den detaillierten Fragebogen die Abteilungsleiter des Qualitätsmanagements gezielt als Erheber der Daten angesprochen wurden, die Aussagen sich aber, soweit vorhanden, auf das Qualitätsmanagement als Unternehmensfunktion oder -einheit und die Kooperation mit anderen am Produktlebenszyklus beteiligten Unternehmenseinheit beziehen. Es wird also weitestgehend die Sicht der Leiter von Qualitätsmanagements-

109 4.4 Detailanalyse der DV-Organisation 91 Abteilungen bezogen auf höhere Emergenzebenen analysiert. Die verwendeten Systeme sind in den personellen und organisatorischen Kontext der Unternehmen eingebunden. Deshalb wird für die Darstellung der Umfrageergebnisse eine Systematik vorgeschlagen, die den Facetten der Theorie kooperativer Informationssysteme und deren Beziehungen untereinander folgt. Dabei wird den folgenden Leitfragen nachgegangen. 1. Wie groß ist der Grad der DV-technischen und organisatorischen Vernetzung? Da sich das Fehlermanagement über den gesamten Produktlebenszyklus erstreckt, ist die Vernetzung der organisatorischen Einheiten im Fehlermanagement von entscheidender Bedeutung. In diesem Komplex wird die Organisation des Fehlermanagements bezogen auf die DV-Organistion (Systemseite) untersucht. Dazu gehört sowohl die organisatorische und DV-technische Vernetzung der Unternehmen als auch die Beziehungen zwischen den Vernetzungsformen. Folgende Fragestellungen sind dabei primär: Wie sind die Beziehungen zwischen den einzelnen Unternehmenseinheiten, aber auch zum Kunden organisiert? Fördert die DV-Vernetzung die organisatorische Vernetzung, ist sie neutral oder hinderlich? Ist die organisatorische Vernetzung Voraussetzung für eine sinnvolle Vernetzung von EDV-Systemen? 2. Welche Art der Software wird im Fehlermanagement genutzt? Auf der Systemseite wurden die Informationssysteme ermittelt, die im Fehlermanagement von Bedeutung sind. Zentrale Fragen dabei waren: Wird in den Unternehmen Standardsoftware eingesetzt oder Eigen- bzw. Spezialentwicklungen bevorzugt? Wird mit offenen Standards gearbeitet? Wie sehen bereits realisierte Insellösungen aus? Welche Trends lassen sich erkennen? 3. Wie werden die erfaßten Fehlerdaten organisiert und genutzt? Im ersten Fragebogen wurde die Problematik der Beziehung von erfaßten und tatsächlich genutzten Daten deutlich. Wo sind die wesentlichen Informationsquellen? Werden Daten genügend aufbereitet? Geben sie das Fehlergeschehen korrekt und vollständig wieder? Sind die Daten zugreifbar? 4. Wie sehen die rechnergestützten Informations- und Arbeitsflüsse aus? Die Gestaltung von rechnergestützten Informationsflüssen hat erheblichen Einfluß auf die Qualität und Effizienz von Verbesserungsprozessen. Diese Fragestellungen beziehen sich einerseits auf die konkreten Ausprägungen der Flüsse auf Mitarbeiterund Gruppenebene, andererseits auf die geplanten formalen Informationsflüsse der Organisation, die in den Systemen abgebildet werden sollen. Zentrale Fragestellungen in diesem Zusammenhang sind: Wie wirken sich Vernetzung und Softwarenutzung auf die Informations- und Arbeitsflüsse aus? Stimmen Planung und Ausprägung der Flüsse überein? Werden Fortentwicklungen der rechnergestützten Informations- und Arbeitflußunterstützungen in der Praxis aufgenommen?

110 92 Rechnergestütztes Verbesserungsmanagement in der Praxis 4.4.1Grad der DV-technischen und organisatorischen Vernetzung Die technischen und personellen Voraussetzungen für ein durchgängiges Fehlermanagement sind in vielen Unternehmen vorhanden. Häufig sind die QM-Abteilungen, die in 82 % der befragten Unternehmen für die Einführung und Betreuung von Fehlermanagement- Systemen verantwortlich sind, DV-technisch vernetzt und mit moderner Hardware ausgestattet. 72 % unterhalten ein lokales Rechnernetz. 88 % wollen in Zukunft ihre DV- Aktivitäten verstärken. Immerhin 46 % sind mit Service- oder sonstigen dezentralen Standorten vernetzt. Zur Zeit werden 64 % der QM-Abteilungen noch von einer zentralen DV- Abteilung unterstützt, was zu einer gemischt zentralen/dezentralen Datenhaltung (54 %) geführt hat. Der Trend geht aber eindeutig zu mehr DV-Autonomie der Abteilungen. Weiterhin gaben 84 % der Unternehmen an, daß die im Fehlermanagement beteiligten Mitarbeiter prinzipielle Kenntnisse im Umgang mit Computern und Software besitzen. Die organisatorische Vernetzung nutzt die informationstechnologischen Möglichkeiten bei weitem nicht aus. Im Vordergrund steht der Wunsch nach stärkerer Nutzung der DV- Infrastruktur zum Informationsaustausch, z.b. zur Einbindung der Fertigungsebene. 72 % der QM-Abteilungen tauschen Daten mit anderen Unternehmensfunktionen aus. Sie stellen schwerpunktmäßig ihre Daten den Unternehmensfunktionen Ein- und Verkauf, Arbeitsvorbereitung, Produktionsmanagement, Fertigung und Entwicklung zur Verfügung. Weniger häufig ist die Bereitstellung von Daten für das Produktmanagement und die Geschäftsführung. Umgekehrt bekommen die QM-Abteilungen schwerpunktmäßig ihre Daten vom Ein- und Verkauf, der Produktion bzw. Fertigung, der PPS und der Entwicklung bzw. Konstruktion. Folgerichtig wünschen sich die befragten Abteilungen gerade mit den Funktionen der Produktion, des Ein- und Verkaufs und der Geschäftsführung eine engere DV-technische Zusammenarbeit. Zusammen mit der Abnahme zentraler EDV-Funktionen entstehen dadurch immer mehr bilaterale Schnittstellen zwischen Abteilungen. Bei der Erhebung wurde im Mittel ein Aufwand von 4 Stunden pro Woche für die Verwaltung dieser Schnittstellen angegeben, wobei allerdings 21 % der Abteilungen angaben, überhaupt keine Zeit in die Verwaltung der Schnittstellen zu stecken und weitere 44 % dazu keine Angaben machten. Abbildung 4.2 faßt die Aussagen grafisch zusammen. Ein möglicher Grund für die mangelnde Kohäsion von organisatorischer und informationstechnologischer Vernetzung kann die weiterhin zentralistische Gestaltung von Qualitätsund Fehlermanagement sein, wobei daran gedacht werden sollte, daß in der Befragung die QM-Abteilungen angesprochen wurden. Die Hälfte der Unternehmen ist der Überzeugung, daß das Fehlermanagement zentral gestaltet werden sollte, weitere 22 % sprechen sich für eine standortzentrale Gestaltung aus. Nur 24 % sind für eine abteilungs- oder produktbezogene Gestaltung des Fehlermanagements. Im Mittel investieren die QM-Abteilungen 14 Stunden pro Woche in die gesamte DV- Organisation, wobei durchschnittlich 6 Stunden auf die Verwaltung der Hardware (inklusive DV-Vernetzung) und 6 Stunden auf die Verwaltung der Software entfallen. Die restliche

111 4.4 Detailanalyse der DV-Organisation 93 Zeit verteilt sich auf Informationsbeschaffung und sonstige organisatorische Tätigkeiten. Obwohl im folgenden stark auf Software und ihre Nutzung im Fehlermanagement fokussiert wird, macht die Gewichtung des Administrationsaufwandes deutlich, daß auch die Verwaltung der Hardware in den QM-Abteilungen aufwendig ist. Das hängt einerseits mit der engen Verzahnung der DV-Hardware mit den Produktionsmaschinen, andererseits aber an der Gebundenheit der Software an bestimmte Hardware, die schnell zu heterogenen Hardwarebeständen führt. Der relativ hohe Gesamtaufwand reiner DV-Administration am gesamten Qualitätsmanagement hängt einerseits mit der zunehmenden Dezentralisierung der DV-Funktionen, andererseits an der gestiegenden Bedeutung und der damit verbundenen Intensivierung der Rechnerunterstützung im Qualitätsmanagement, drückt aber auch das Problem aus, daß inhaltliche Arbeiten zu kurz kommen Netzwerk Unterstützung durch Zentrale DV Datenhaltung gemischt Austausch mit Unternehmen sfunktionen Ja Nein K.A. Abbildung 4.2: DV-Organisation im Fehlermanagement Informationsflüsse im Fehlermanagement Wie erwähnt, sind in 82 % der Unternehmen die QM-Abteilungen für das Fehlermanagement verantwortlich, wobei mit der Durchführung in der Hauptsache qualifiziertes technisches Personal betraut ist. 87 % der Unternehmen waren zum Zeitpunkt der Erhebung ISO DIN EN 9001 zertifiziert bzw. gaben an, dies in naher Zukunft tun zu wollen. Dagegen konnten 40 % der Unternehmen keine Angabe zu ihren Fehlerkosten machen. Tatsächlich hat auch das American Productivity & Quality Center (APQC) ermittelt, daß nur 40 % ihrer Partnerunternehmen Reklamationskosten kalkulieren können [APQ98].

112 94 Rechnergestütztes Verbesserungsmanagement in der Praxis Informationsflüsse begleiten den Produktlebenszyklus von der Entwicklung bis zur Entsorgung. Teilweise werden Informationsflüsse zwischen Produktionssystemen realisiert, teilweise existieren aufgaben- oder produktbezogene Informationsflüsse zwischen Personen bzw. Unternehmensfunktionen. In aufgabenbezogenen Informationsflüssen zwischen Personen dominieren klassische Medien wie Teamsitzungen (88 %), persönliche Gespräche (90 %), Telefon (90 %) und Hauspost (83 %). Immerhin 52 % der Befragten setzen auch das Computernetzwerk zur Realisierung zielgerichteter Informationsflüssen ein. Der Aufwand zum zielgerichteten Austausch von Informationen wird für beide Arten von Informationsflüssen im allgemeinen als zu hoch eingeschätzt. Im aufgabenbezogenen Bereich wollen 31 % der Befragten in Zukunft weniger als 10 % ihrer Arbeitszeit zur Beschaffung von Informationen investieren, während dies heute nur 12 % der Befragten gelingt. Beklagt wird die Vielzahl der Informationen, der mangelnde Bezug zur konkreten Aufgabe, die unübersichtliche Präsentation und die mangelnde elektronische Verfügbarkeit. Um den zielgerichteten, aufgabenbezogenen Austausch zu unterstützen, wollen 31 % (20 % heute) zukünftig in den Abteilungen selbst Datenbanktechnologie einsetzen und 68 % (50 % heute) wollen Datenbanken zur Dokumentation von Ergebnissen und zur effektiveren Gestaltung des Berichtswesen nutzen. Deshalb wird die Kopplung von Datenbanksystemen zum formalen Informationsaustausch zwischen Produktionssystemen in Zukunft eine wichtige Rolle spielen. Die Hälfte (52 %) der befragten Abteilungen tauschen Produktionsdaten mittels Datenbanktechnologie aus, vor allem über zentrale Datenbanken. Diese Form der Nutzung wird in Zukunft noch intensiviert werden (77 %), wobei die stärkere Nutzung von abteilungseigenen Datenbanksystemen und die gemischt zentrale/dezentrale Datenhaltung zu berücksichtigen sind. In Abbildung 4.3 sind vor allem datenbank-bezogene Aussagen noch einmal grafisch zusammengefaßt. Vor allem zum Zusammenwachsen der Kommunikationskanäle für Produktionssysteme und aufgabenbezogene Informationsflüsse werden Synergieeffekte im Bereich der Dokumentation, der Analyse und des Berichtswesens erwartet. Einsparmöglichkeiten werden durch einheitliche Dokumentenverwaltung, wegfallende Bearbeitungsschritte und bessere Fokussierung der Informationen erwartet Arbeitsflüsse im Fehlermanagement Da eine fehlerfreie Produktion als nicht erreichbares Ideal verstanden werden muß, ist insbesondere die Service-Qualität von besonderer Bedeutung. Als Maßstab gilt hier zuerst die Schnelligkeit der Reklamationsbearbeitung. Die durchschnittliche Bearbeitungsdauer einer Reklamation wurde mit durchschnittlich 9 bis 10 Tagen ermittelt (80 % der befragten Unternehmen) und involviert durchschnittlich 3 (im Extremfall 10) Abteilungen. Das APQC hat in einer eigenen Studie ermittelt, daß 60 % der Reklamationen eine Bearbeitungszeit vonmehrals3tagenbenötigen [APQ98].

113 4.4 Detailanalyse der DV-Organisation DB- Benutzung Zeitaufwand DB- Austausch DB- Dokumentation Heute Zukünftig Abbildung 4.3: Informationsaustausch im Fehlermanagement Bei der Untersuchung der Arbeitsflüsse im Fehlermanagement gaben 90 % der Befragten an, vorgeschriebene Abläufe zu besitzen. 83 % benutzen Formulare, um ihre Arbeitsabläufe zu unterstützen, aber nur 10 % (23 % zukünftig) nutzen WFMS. Oft sind diese Lösungen unternehmensintern erstellt worden. Die Hälfte der QM-Abteilungen nutzen für das Qualitätsmanagement spezifische Lösungen (z.b. Prüfmittelmanagement, elektronische Anbindung von Prüfmitteln, Prüfplanung) zur Unterstützung ihre Arbeitsabläufe, aber nur 6 % nutzen kommerzielle WFMS. 17 % der Befragten gaben an, kommerzielle WFMS anzuschaffen, um ihre Abläufe nach einer Erprobungsphase zu unterstützen. Abbildung 4.4 faßt noch einmal die obigen Aussagen grafisch zusammen. Vom Einsatz von Workflow-Lösungen erwarten sich viele eine bessere Unterstützung und damit verbundene Produktivitätssteigerungen (69 %), obwohl praktische Erfahrungen erst in geringer Zahl vorliegen (vgl. [OV96]). Deshalb wurde vielfach der Wunsch geäußert, erst einmal Praxiserfahrungen zu sammeln. Ohne diese Praxiserfahrungen wurden vor allem Wünsche nach einer systematischen Nutzung des gesammelten Wissens, dem Monitoring von Arbeitsabläufen und der schnellen Rückmeldung von erledigten Arbeitsschritten geäußert.

114 96 Rechnergestütztes Verbesserungsmanagement in der Praxis WFMS Arbeitsabläufe Standard- WFMS QMspezifisch Heute Zukünftig Abbildung 4.4: Arbeitsflüsse im Fehlermanagement Datenhaltung im Fehlermanagement Das Vertrauen in gesammelte Daten zum Fehlergeschehen in den Unternehmen ist nicht klar definiert. Bei der Frage, ob die erfaßten Daten das reale Fehlergeschehen auch vollständig und korrekt wiedergeben, ordnen sich 83 % der befragten Firmen eher unschlüssig ein, d.h. sie nutzen die Daten nicht in Entscheidungsprozessen. Fehlersammelkarten werden in den meisten Unternehmen eher vereinzelt als durchgängig genutzt. Dagegen sind standardisierte Formulare zur wichtigsten Fehlererfassungsmethode geworden. 70 % der Unternehmen setzen standardisierte Formulare ein, aber nur 46 % verwenden diese durchgängig im gesamten Unternehmen. In 17 % der Unternehmen wird die Erfassung von Fehlerdaten durchgängig mittels EDV organisiert und 25 % der Unternehmen verfügen ansatzweise über EDV-Unterstützung. In 57 % der Unternehmen werden Schlüssel zur Identifikation der Fehler eingesetzt, 65 % identifizieren Fehler (auch zusätzlich) mittels Freitexten. Nur 28 % der Unternehmen organisieren ihre Fehler in Katalogen. Die Erfassung und Auswertung von Fehlerdaten im internen Fehlermanagement erfolgt hauptsächlich durch Mitarbeiter der QM-Abteilungen. In 84 % der Unternehmen werden Fehlerdaten durch QM-Mitarbeiter erfaßt, immerhin in 60 % der Firmen erfassen auch Fertigungsmitarbeiter Fehlerdaten, während in nur 6 % der Firmen diese auch Fehlerdaten

115 4.4 Detailanalyse der DV-Organisation 97 auswerten, während in 86 % QM-Mitarbeiter für die Auswertung verantwortlich sind. Im externen Fehlermanagement sind in 47 % der Unternehmen die QM-Abteilungen für die Bearbeitung von Reklamationen verantwortlich, auch für die Definition und Ausführung von Sofortmaßnahmen vor Ort. Bei fast 50 % der Unternehmen werden die erfaßten Fehlerdaten überwiegend zur Berichterstellung für die Leitungsfunktionen genutzt. Dagegen werden bei 47 % die Daten überhaupt nicht bzw. bei 37 % nur eingeschränkt als wichtige Basis bei der Entwicklung neuer Produkte in die Produktentwicklung zurückgespielt. Die Gestaltung von Berichten erfolgt vorwiegend durch einfache Grafiken (80 %) oder ausführliche Textdarstellungen (55 %). In 29 % der Unternehmen werden Berichte elektronisch erstellt und weitergeleitet Softwarenutzung im Fehlermanagement Im allgemeinen werden zur Durchführung des Fehlermanagements Helpdesk-Systeme in der Endkundenbetreuung und Computer-Aided Quality Control (CAQ) Systeme für produktionsnahe Aufgaben eingesetzt. Dabei fokussieren kleine und mittelständische Unternehmen noch auf die Nutzung produktionsnaher Fehlermanagement-Systeme, während die kundenorientierten Frontoffice-Systeme kaum genutzt werden. In 31 % der QM-Abteilungen werden CAQ-Systeme genutzt, weitere 42 % wollen dies zukünftig tun, während erst 21 % dieser Systeme Fehlermanagement-Komponenten (z.b. Fehlerfallbasis, Fehler- oder Reklamationserfassung, Fehleranalyse) besitzen, wollen 65 % solche Komponenten anschaffen. Als Realisierungsplattform wurde häufig SAP und seine Module genannt. SAP soll sowohl Eigenlösungen und Fremdsysteme ersetzen als auch erstmals eingesetzt werden. Als Systemplattform für QM-Anwendungen wurden Windows 95 bzw. NT (65 %) favorisiert, die wohl die bis dahin dominierende Plattform Windows 3.1 ablösen. Als Hauptvorteil der Software-Nutzung wurde Schnelligkeit des Zugriffs und die Auswertbarkeit am häufigsten genannt. In Abbildung 4.5 sind wesentliche Kennzahlen zur Entwicklung der Softwarenutzung im Fehlermanagement zusammengefaßt. Fast alle Abteilungen setzen Standard-Büroapplikationen wie Tabellenkalkulationen (85 %) und Textverabeitungssoftware (90 %) ein. Auch Standard-Datenbanksysteme sind mit 60 % weit verbreitet. Bei Fragen nach gewünschten Software-Anwendungen, Vorteilen / Problemen von Software, Schnittstellen zwischen Fehlermanagement-Systemen (FMEA, CAQ, Helpdesk) und Schnittstellen zu anderen Unternehmenssystemen (CAD, CAM, CAP, PPS, Kostenrechnung) wurden überproportional keine Angaben gemacht. Gründe dafür können, neben den oben genannten, mangelnde Marktübersicht und mangelnde Informationen über die Möglichkeiten der Schnittstellengestaltung in den QM-Abteilungen sein. Nur 12 % der Befragten setzen Datenbanken zur Gestaltung von Schnittstellen ein, aber schon 31 % wollen dies zukünftig tun, während heute noch die Weitergabe von Daten über Austausch von Dateien (23 %) oder durch erneute Eingabe (15 %) realisiert werden. Die Unzufriedenheit mit der jetzigen Software äußert sich in den genannten Anforderungen an zukünftige Software für das Verbesserungsmanagement. Die QM-Abteilungen setzen

116 98 Rechnergestütztes Verbesserungsmanagement in der Praxis CAQ- System CAQ mit FM Einsatz angepaßter Fremd-SW DB- Schnittstellen- Management Heute Zukünftig Abbildung 4.5: Softwarenutzung im Fehlermanagement auf modulare Lösungen mit Schnittstellen, die auf offengelegter Datenbanktechnologie realisiert wurden. Eigenentwicklungen (56 % heute, 37 % zukünftig) sollen zukünftig mehr Fremd-Software (25 % heute, 37 % zukünftig) Platz machen, die auf die Bedürfnisse des Unternehmens angepaßt werden kann. Entscheidungen, neue Software im Unternehmen einzusetzen, werden vor allem von bedarfsorientierten Kosten-Nutzen Aspekten (41 %) beeinflußt, wobei insbesondere die Integrierbarkeit in das existierende System, langfristiger Support und Qualität noch vor Funktionalität und Schulungsaufwand stehen. Dabei wurden Integrierbarkeit der Software und Schulungsaufwand als Hauptprobleme am häufigsten genannt. 4.5 Defizite in der DV-Organisation des Verbesserungsmanagements Informations- und Arbeitsflüsse im Verbesserungsmanagement zeichnen sich dadurch aus, daß sie über Unternehmens- und Abteilungsgrenzen hinweg funktionieren müssen, einen hohen Koordinationsaufwand hinsichtlich der zu treffenden Maßnahmen beinhalten und eines Austauschs komplex gestalteten Fehlerwissens bedürfen. Als Fazit der Untersuchung läßt sich festhalten: Der derzeitige Einsatz von DV-Technik behindert oft mehr

117 4.5 Defizite in der DV-Organisation des Verbesserungsmanagements 99 als daß er fördert. Trotz allgemein hohem technischen Stand der DV-Infrastruktur leidet die Effizienz des Einsatzes an mangelnder Beachtung von Schnittstellen zwischen einzelnen Abteilungen innerhalb eines Unternehmens sowie zwischen Kunden und Unternehmen. Die Befragten in den QM-Abteilungen geben an, unter einer Flut von aufgabenfremden, meist papierbasierten Informationen unterzugehen. Informationen, die eigene Aufgaben betreffen, werden über klassische Kommunikationskanäle wie Teamsitzungen, Telefon und Hauspost übermittelt. Ebenso wird die Nutzbarkeit der vorhandenen Information als sehr schlecht angesehen. Uneinheitliche, schlecht strukturierte und meist nicht elektronisch gespeicherte Dokumente beherrschen das Bild. Technologische Barrieren werden vor allem durch den Einsatz von Insellösungen und die isolierende, änderungsresistente Datenhaltung aufgebaut, die nur unzureichend untereinander verbunden sind. Dies führt zu einem deutlich als zu aufwendig eingeschätzten Informationsaustausch und zu mangelnder Unterstützbarkeit durchgängiger Fehlerfallbearbeitung. Die effiziente Fehlerfallbearbeitung hängt von der Nutzung von Fehlerwissen ab. Fehlerwissen entsteht im allgemeinen an Orten und zu Zeitpunkten im verteilten Produktlebenszyklus, wo es nicht genutzt wird. Der Austausch von Fehlerwissen ist auf einfache Repräsentationen beschränkt und wird nicht ausreichend informationstechnologisch unterstützt. Die Kernprozesse der Leistungserstellung in Fertigungsbetrieben werden durch Qualitätsforderungen an Produkte und Produkterstellungsprozesse bestimmt. Trotzdem ist die Rückführung von Verbesserungswissen aus der Organisation des Verbesserungsmanagements in die Kernprozesse im allgemeinen unzureichend. Das VVM muß sich mit den realen Bedingungen kleiner und mittelständischer Unternehmen auseinandersetzen. Dabei fallen insbesondere drei Faktoren ins Gewicht (vgl. auch [KPJ00]): Heterogenität sowohl der verwendeten Hardware und Software als auch der Wissensquellen. Obwohl betriebswirtschaftliche Standardsoftware den Markt durchdringt, scheuen gerade kleine und mittelständische Unternehmen die Einführung, da sie befürchten, durch zu starre Prozesse und Informationsflüsse die Innovationskraft zu verlieren, die gerade ihr wirtschaftliches Überleben garantiert (vgl. [MS99]). Verteilung der organisatorischen Einheiten und damit auch der Informationen. Der gesamte Produktlebenszyklus (vgl. Abschnitt 2.2) wird durch verstärkte Kundenorientierung und die ganzheitliche Betrachtung von unternehmensübergreifenden Wertschöpfungsketten zur Quelle von wettbewerbsrelevantem Wissen. Daraus resultierende organisatorische Maßnahmen wie Globalisierung, Virtualisierung, Outsourcing und Lean Management, aber auch informationstechnologische Entwicklung wie das Verschmelzen von Kommunikations- und Informationstechnologien, z.b. in Call- Centers [Buc99], belegen die neuen Herausforderungen. Instabilität der Informations- und Arbeitsflüsse. Die zunehmende Beschleunigung und Diversifizierung der Produktentwicklung führt konsequenterweise zu organisatorischen und damit auch informatischen Weiterentwicklungen, damit ändern sich die Prozesse und Informationsflüsse im Unternehmen unter dem Einfluß von Prozeßentwicklung, Personalfluktuation und DV-Technik in immer schnelleren Zyklen. Das

118 100 Rechnergestütztes Verbesserungsmanagement in der Praxis Concurrent Engineering verlangt im Gegensatz zu früher üblichen sequentiellen Vorgehensweisen die gleichzeitige und umfassende Betrachtung verschiedenster Informationsquellen und Prozesse zum frühest möglichen Zeitpunkt [AD99]. Problem Ursache Mögliche Maßnahme Informationsflüsse Informationsaustausch Formate Software Datenhaltung Kommunikations- und Koordinationsunterstützung Mitarbeiter ersticken in nicht aufgabenspezifischer Papierflut Informationslücken führen zu hohen Suchkosten Manuelle Transformationsschritte bei Informationsaustausch Schlecht strukturierte Berichte Papierbasierte Berichte Medienbrüche Proprietäre, änderungsresistente Software-Inseln Ineffiziente, änderungsresistente, verteilte und heterogene Datenquellen Bilaterale Schnittstellen nicht definiert Arbeit wird nicht oder mehrfach erledigt Unterstützung von aufgabenorientierten Informationsflüssen durch elektronischer Vorgangs - mappen Unterstützung der Informationsflüsse durch Datenbankmanagementsysteme Unterstützung durch Repository Virtuelle Teambildung mittels des Eskalationsprinzips Tabelle 4.2: Herausforderungen in der DV-Unterstützung des VVM Was sind die Ansatzpunkte möglicher Verbesserungsmaßnahmen in der Praxis, die sich aus den in Tabelle 4.2 aufgeführten Problemen und deren Ursachen ergeben? Die Unterstützung aufgabenorientierter Informationsflüsse durch elektronische Vorgangsmappen zielt auf die Behebung von Informationslücken bei der Fehlerfallbearbeitung bei gleichzeitiger Beachtung der Angemessenheit der Informationsversorgung durch rollenbasierte Konfiguration der Vorgangsmappen. Die Informationsflüsse müssen durch Datenbanktechnologien unterstützt werden, um Medienbrüche zu erkennen und die damit verbundenen Transformationsschritte zu unterstützen. Weiterhin kann die Qualität und Schnelligkeit der Berichterstattung durch die Verwendung eines Datenbanksystems gesteigert werden. Die Auswertung ergab, daß die Anwender relationale Datenbankmanagementsysteme (RDBMS) wegen ihrer Verbreitung und ihrer standardisierten Verwendung bevorzugen. Die Anwender wollen bisherige Lösungsinseln und Datenhaltungspraxen weiterhin

119 4.6 Zusammenfassung 101 unterstützen bzw. einen evolutionären Wandel unterstützen. Der Einsatz von Repository-Technologien erleichtert die Weiterverwendung von Software und Daten durch Bereitstellung geeigneter Abstraktions- und Integrationsmethoden. Die virtuelle Teambildung in Eskalationen zielt auf die effektive und effiziente Fehlerfallbearbeitung. Arbeit wird zielgerichtet an die betroffenen Teams oder Agenten weitergeleitet. Die notwendigen Kommunikationsprozesse bilden die Grundlage für die Definition bilateraler Informationsbedürfnisse. 4.6 Zusammenfassung Ziel dieses Kapitel war die Darstellung, Analyse und Bewertung einer Umfrage zum Thema Fehlermanagement. Diese umfaßten einen zweistufigen Erhebungsprozeß mittels Fragebogen, der den Stand der Praxis sowie Anforderungen an ein zukünftiges Verbesserungsmanagement in der kleinen und mittelständischen Industrie ermittelt. Das Hauptergebnis ist, daß sowohl organisatorische, personelle als auch technologische Defizite die Implementierung eines nachhaltigen vernetzten Verbesserungsmanagements auf breiter Front behindern. Verbesserungsmaßnahmen, die in Kapitel 3 als Ergebnis theoretischer Vorarbeiten definiert wurden, sind auf Grundlage der Analyseergebnisse diskutiert und hinsichtlich ihrer Praxisrelevanz bewertet worden. Die definierten Verbesserungsmaßnahmen sind grundsätzlich auf die analysierten Probleme anwendbar. Allerdings ergibt sich für die Realisierung, daß Informationssysteme für das Verbesserungsmanagement mit industriell verbreiteten und akzeptierten Basistechnologien realisiert werden sollten. Dazu gehören beispielsweise relationale Datenbankmanagementsysteme. Welche Realisierungsoptionen dem nachhaltigen vernetztem Verbesserungsmanagement zur Verfügung stehen, wird das nächste Kapitel klären.

120 Kapitel 5 Informationssysteme im Verbesserungsmanagement Dieses Kapitel hat drei wesentliche Ziele. Errors are not in the art but the artificers. Sir Isaac Newton 1. Die Erkundung von Realisierungsoptionen für das nachhaltige vernetzte Verbesserungsmanagement. Die Vielzahl der informationstechnologischen Realisierungsmöglichkeiten von Verbesserungsmanagementsystemen erzwingt eine erschöpfende Untersuchung von marktrelevanten Systemen. Diese Arbeit konzentriert sich auf Helpdesk-Systeme, die insbesondere das Reklamations- und Servicemanagement unterstützen und mit zunehmender Kundenorientierung an Marktrelevanz gewinnen. Weiterhin unterstützen Helpdesk- Systeme wesentliche theoretische Konzepte, die in Kapitel 3 erarbeitet wurden. Die Studie in Abschnitt 5.1 stellt einen Katalog von Funktionen des nachhaltigen vernetzten Verbesserungsmanagements auf. Kein reales System bildet alle Funktionen ab. Die Realisierungen einzelner Funktionen sind in recht unterschiedlicher Qualität ausgeführt. Ziele des Katalogs sind erstens die Unterscheidung von wesentlichen und weniger wesentlichen Realisierungsoptionen des nachhaltigen vernetzten Verbesserungsmanagements durch die Bildung von Ebenen und die Einordnung von Funktionen in Nachbarschaften auf gleicher Ebene, zweitens die Bewertbarkeit von Helpdesk- Systemen, drittens die Beurteilung der Güte einer Helpdesk-Implementierung im Unternehmen. 2. Die Untersuchung und Bewertung von Erfahrungen bei der Realisierung von Repositories für das nachhaltige vernetzte Verbesserungsmanagement. Die Gestaltung und Nutzung von Repositories für das Qualitäts- bzw. Verbesserungsmanagement hat eine Tradition, die wesentlich durch die Projekte WibQuS

121 5.1 Workflow-gestützte Helpdesk-Systeme 103 und FOQUS getragen wird. Die Erfahrungen, die in diesen Projekten in der Nutzung von Repository-Technologien und Methoden zur Modellerstellung gewonnen wurden, sind wichtige Vorarbeiten für die Gestaltung eines Repositories für das nachhaltige vernetzte Verbesserungsmanagement. 3. Die fokussierte Untersuchung von forschungsrelevanter Literatur. Aus den theoretischen Konzepten des 3. Kapitels lassen sich unmittelbar Anforderungen für die Gestaltung von Verbesserungsmanagementsystemen ableiten. Diese Anforderungen werden getrennt für die Realisierung von Unternehmensgedächtnis- Repositories zur nachhaltigen Bewahrung von Wissen (vgl. Abschnitt 5.3) und Vorgangssteuerungssystemen (vgl. Abschnitt 5.4) ermittelt. Die untersuchte Literatur bzw. die dort beschriebenen Systeme werden fokussiert mittels der Anforderungen hinsichtlich ihrer Eignung für das nachhaltige vernetzte Verbesserungsmanagement bewertet. Die geringe Schnittmenge von Systemen, allesamt Forschungsprototypen, die sowohl die langfristige Wissensorganisation als auch die Gestaltung und Ausführung operativer Prozesse unterstützen, zeigt, daß die Synthese dieser Ansätze Forschungsrelevanz besitzt. 5.1Workflow-gestützte Helpdesk-Systeme Die empirischen Untersuchungen verdeutlichen, daß die Nutzung von Informationstechnologie im Verbesserungsmanagement gerade zu Problemen führt, die in Tabelle 4.2 zusammengefaßt wurden. Mit den informationstechnologischen Entwicklungen im Verbesserungsmanagement werden zumeist die sogenannten CAx-Technologien verbunden. Jedoch ist gerade die Praxis des Verbesserungsmanagements im kundennahen Bereich weit voran geschritten. In Call-Centers wachsen Informations- und Kommunikationstechnologien nahtlos zusammen [Gra99, Buc99]. Im kundennahen Bereich des Verbesserungsmanagements, dem Beschwerdemanagement, werden Helpdesks eingesetzt. Helpdesk ist ein generischer Name für eine Reihe von Funktionen, die oft der Endkundenunterstützung (engl.: Frontoffice) zugeordnet werden. Marcella und Middleton definieren den Helpdesk als an accessible service point which will provide on-demand advice, information or action to aid the user in carrying out an IT-related task [MM96]. Dies deutet an, daß der Begriff historisch aus der direkten Unterstützung von Kunden der Hardware- und Software-Branche entstammt. Helpdesks können interne oder externe Kunden besitzen. 1 Wald [Wal99] betont den Wandel des Begriffs über die Zeit. Während früher den Fachabteilungen die sie betreffenden Probleme direkt weitergeleitet wurden, gibt es heute oft eigenständige Service- oder Supportabteilungen, die den Helpdesk mit dem nötigen Fachabteilungswissen betreiben. Auch [MM96] betont die zentralisierte Rolle des Helpdesks, den exklusiven Personalbestand und die entsprechende Qualifikation der Mitarbeiter. Auch Hersteller von Nicht-DV-Produkten 1 Interne DV-Abteilungen sind oft eigenständige Dienstleister innerhalb eines Unternehmens mit eigener Supportabteilung.

122 104 Informationssysteme im Verbesserungsmanagement und Dienstleister können Helpdesks betreiben und tun dies in zunehmenden Maße [MM96]. Helpdesk-Systeme (HDS) sind eine Klasse von Informationssystemen, die Funktionen des Helpdesks DV-technisch unterstützen, dazu gehören beispielsweise die automatische Rufweiterleitung im Call-Center, die Pflege einer Helpdeskdatenbank und die Abarbeitung von Eskalationen. Die Vielzahl der möglichen Funktionen, die ein Helpdesk-System unterstützen kann, verlangt eine systematische Herangehensweise zur Erschließung der Potentiale von Helpdesk-Systemen für das nachhaltige vernetzte Verbesserungsmanagement. Daher habe ich einen ebenenorientierten Katalog für HDS konzipiert, der im Rahmen einer Diplomarbeit [Kat98] mit der Untersuchung kommerzieller HDS verfeinert wurde. Grob lassen sich Helpdesk-Systeme in zwei Kategorien einteilen. Konfigurierbare Helpdesk-Systeme: Diese Systeme können auf die Anforderungen von Unternehmen angepaßt werden, wobei die Anpaßbarkeit von einfachen Erweiterungen der zugrundeliegenden Datenbanken und Masken für kundenspezifische Einträgen (z.b. SupportMagic) bis hin zu einer vollständig individuellen Definition der Geschäftsprozesse und Einbeziehung systemfremder Werkzeuge (z.b. Applix, Clientele) reicht. Derartige Systeme werden in der Regel von den Anbietern oder Beratungsunternehmen (z.b. Remedy/Dr. Materna) im Unternehmen eingeführt. Fixe Helpdesk-Systeme: Diese Systeme besitzen einen festen Satz von Werkzeugen und Masken, so daß sie schnell und ohne zusätzliche Beratungskosten eingesetzt werden können. Durch die Einführung eines Ebenenmodells ist es möglich, essentielle informationstechnische Optionen in die Ebenen einzuordnen und bezüglich ihrer Eignung zu beurteilen. Im folgenden werden informatische Funktionen als Werkzeuge eines HDS bezeichnet. Werkzeuge einer Ebene können auf die Werkzeuge in ihrer Ebene und auf die in der darunter liegenden Ebene zugreifen. Die Bedeutung eines Werkzeuges hängt nicht von seiner Lage in den Ebenen ab, sondern vom jeweiligen Unternehmen. Weil sich die Gestaltungsmöglichkeiten und die Gestaltungsanforderungen von Unternehmen zu Unternehmen, von Abteilung zu Abteilung, von Arbeitsplatz zu Arbeitsplatz unterscheiden, kann das Ebenenmodell genutzt werden, eine Architektur aus konfigurierbaren Komponenten der verschiedenen Ebenen auf die speziellen Anforderungen abzustimmen. Deshalb werden im weiteren Verlauf ein Katalog der Werkzeuge erstellt und eine Vorgehensweise beschrieben, um für das eigene Unternehmen ein HDS auszuwählen. Das hier vorgestellte Ebenenmodell beruht auf einem Vergleich des in Abschnitt 3.5 vorgestellten Gesamtansatzes des VVM mit den Architektur-Modellen der untersuchten HDS. Das Modell (vgl. Abb. 5.1) besitzt 5 Ebenen und einen Erweiterungskatalog. Der Erweiterungskatalog adressiert, die in Kapitel 4 geäußerten Wünsche nach offenen Funktions- und Datenschnittstellen und die Einbeziehung weiterer Informationssysteme, die Relevanz für das Verbesserungsmanagement besitzen. Für die Realisierung eines Verbesserungsmanagementsystems liegt bereits auf der Ebene 2 (Minimales Helpdesk-System) ein vollständiger Systemkern vor, mit dem alle operativen Aufgaben des Verbesserungsmanagements entsprechend den organisatorischen Vorgaben gelenkt werden können. Die dritte Entscheidung war, die Werkzeuge den einzelnen

123 5.1 Workflow-gestützte Helpdesk-Systeme 105 Ebenendarstellung der Werkzeuge Ebene: Gruppe: 0 Workflowkern Minimaler Helpdesk Vollständige Information Erweiterter Workflow Externer Zugriff Erweiterungen Abbildung 5.1: Modell eines Helpdesk-Systems Modulen des Gesamtansatzes zuzuordnen. In den folgenden Tabellen sind die aufgeführten Werkzeuge den Modulen des Gesamtansatzes zugeordnet, um den Ort der Realisierung der Werkzeuge zu verdeutlichen. Dabei werden Werkzeuge einem Server (Repository), Klienten (Arbeitsplätze) oder den operativen Komponenten Anfrage- und Eskalationsmanager zugeordnet. Keines der untersuchten Systeme hat einen ausgeprägten Vorgangsmappenansatz, so daß dieser Komponente keine Werkzeuge zugeordnet werden konnten. Workflow-Kern Der Workflow-Kern enthält die drei essentiellen Werkzeuge eines HDS: eine strukturierte Fehlerfalldatenbank, einen flexiblen Eskalationsmanager und eine Schnittstelle zu den Arbeitsplätzen der Support-Mitarbeiter. Ebene Werkzeug-Nr. Werkzeug Zuordnung Workflow-Kern 1 Workflowtechniken Eskalationsmanager 0 2 Fehlerdatenmodell Repository 3 Kommunikationsschnittstellen Repository & Anfragemanager Tabelle 5.1: Ebene 0 - Workflow-Kern Durch Workflow-Techniken werden die zur Reklamationsbearbeitung notwendigen Informationen und Zuständigkeiten weitergegeben. Die Arbeit eines Workflow-Ausführungsmechanismus darf nicht fest definiert werden. Sie muß durch Regeln beschrieben werden können, um Abläufe im Sinne der kontinuierlichen Prozeßverbesserungen anpassen zu können. Im Sprachgebrauch der HDS werden solche Workflow-Techniken oftmals durch Trouble-Ticket-Systeme [Wal99, S. 65] realisiert. Das HDS muß ein flexibles Fehlerdatenmodell abbilden können. Es muß offen für Erweiterungen sein und mit der Workflow-Maschine verbunden werden. Das Daten-

124 106 Informationssysteme im Verbesserungsmanagement modell nimmt alle Informationen eines Fehlerbildes zur Fehlerfallbearbeitung auf. Die Daten zu einem einzelnen Fall müssen isoliert bearbeitet werden können und bilden so eine logische Vorgangsmappe, die auch Eskalationen und Bearbeitungsstände umfassen. Das Datenmodell dokumentiert damit den Fehlerfall und dient als Basis für Analyse-Werkzeuge (Werkzeug 5 ). Die Anpassungsfähigkeit des Datenmodells muß durch spezielle Administrationswerkzeuge unterstützt werden, so daß Masken und Tabellen eines HDS individuell angepaßt werden können. An den Anwenderarbeitsplätzen müssen Anfragen an das System gestellt und neue Informationen aufgenommen werden. Bei dieser Kommunikation ist der Server passiv, da jede Interaktion von den Benutzern ausgeht. Minimaler Helpdesk Im minimalen Helpdesk hat zumindest ein Benutzer ein vollständiges System zur Erfassung und Analyse von Fehlerbildern zur Verfügung und kann aufgrund der darunterliegenden Ebene Workflow-Kern mit dem System kommunizieren. Ebene Werkzeug-Nr. Werkzeug Zuordnung Minimaler Helpdesk 4 Fehlererfassung Arbeitsplatz 1 5 Fehleridentifikation Anfragemanager 6 Lernfähigkeit Repository Tabelle 5.2: Ebene 1 - Minimaler Helpdesk Die Fehlererfassung dient der vollständigen Eingabe aller zu einem Fehlerbild gehörenden Informationen. Erfassungen sollten zumindest textuell erfolgen [Bar92]. Der Fehlererfassung kommt gerade bei HDS eine hohe Bedeutung zu, da eine schnelle, bequeme und übersichtliche Eingabemöglichkeit die Akzeptanz des Systems beim Anwender, z.b. Call-Center Mitarbeiter oder Service-Techniker erhöht. Multimediale Ergänzungen werden durch das Dokumenteninterface (Werkzeug 9 ) und Multimedia- Dokumente (Werkzeug 20 )möglich. Suchsysteme sollten es dem Benutzer ermöglichen, ein Fehlerbild schnell und treffsicher anhand von (möglicherweise unvollständigen) Beschreibungen, z.b. der Symptome, zu identifizieren, um eine schnelle Fehlerfallbearbeitung zu unterstützen (vgl. auch [Sch97]). 2 Modell und Architektur sehen den Einsatz konkurrierender Suchsysteme vor, da verschiedene Techniken auf unterschiedlichen Ähnlichkeitsmodellen basieren und der Handlungsspielraum des Nutzers bei der Analyse erhöht wird. 2 Case-Based Reasoning [Kol93] und Volltextsuche sind solche alternative Such- und Retrievalformen, wobei Volltextsuche bei weniger gefüllten, Case-Based Reasoning bei gut gefüllten Basen ihre Vorteile haben [Bar92]. Da die Wissensbasis sich mit jeder Bearbeitung eines Fehlerfalls vergrößert, sollten nur Techniken in Betracht gezogen werden, deren Wissensbasen ohne großen Aufwand erweitert werden können (vgl. Abschnitt 3.3). Das eigentliche Suchsystem gehört zum Server. Der Anwender greift über die Kommunikationsschnittstellen (Werkzeug 3) im Schritt Analyse (vgl. Abschnitt 3.4.1) darauf zu.

125 5.1 Workflow-gestützte Helpdesk-Systeme 107 Die Erfassungs-, Analyse- und Kategorisierungskapazitäten eines HDS sind Teil der Lernfähigkeit eines HDS. Sowohl reaktives als auch proaktives Verbesserungsmanagement sollen unterstützt werden. Einerseits sollen im Fehlerfall Maßnahmen zur Bearbeitung eines Problems vorgeschlagen werden, so daß dem Benutzer optimale Informationen zum Fehlerbild zur Verfügung gestellt werden, andererseits soll das HDS auch typische Schwachstellen in präventive Verbesserungsmaßnahmen leiten. 3 Vollständige Information In der Ebene Vollständige Information werden Erweiterungen zur Erfassung und Nutzung von Fehlerwissen hinzugenommen. Ebene Werkzeug-Nr. Werkzeug Zuordnung Vollständige Information 7 Benachrichtigungssysteme Eskalationsmanager 8 Einbeziehung mobiler Arbeitsplätze Arbeitsplatz 2 9 DokumentenInterface Arbeitsplatz & Repository 10 Externe Wissensbasen Repository 11 Diskussionsforen Arbeitsplätze Tabelle 5.3: Ebene 2 - Vollständige Information Benachrichtigungssysteme bieten HDS die Möglichkeit, bei Bedarf eine Kommunikation aktiv zu eröffnen. Sie unterstützen damit Makroprozesse (vgl. Abschnitt 3.4.1). Dabei soll es unerheblich sein, ob ein Bearbeiter an seinem Arbeitsplatz ist. Deshalb muß die Möglichkeit asynchroner Kommunikation gegeben sein. 4 Je nach Unternehmen und Produkt verbringen z.b. Servicetechniker einen wesentlichen Teil ihrer Arbeitszeit beim Kunden außerhalb des Unternehmens. Um diese Techniker in ein Helpdesk-System einzubinden, muß es möglich sein, Helpdesk- Informationen (z.b. elektronische Vorgangsmappen) auch an mobilen Arbeitsplätzen getrennt vom System zu verarbeiten. Dazu ist die Replizierbarkeit der Information zu gewährleisten und geeignete Strategien zu entwickeln (vgl. Abschnitt 5.4). Bei neu eingegebenen Informationen muß ein Abgleich zwischen mobilem Rechner und 3 Der Arbeitsaufwand und die Erfassungs- und Analysekapazitäten können einen Zielkonflikt darstellen. Systeme wie Clientele in Verbindung mit dem CBR-Werkzeug von Inference, führen aufgrund des Eintretens in den Analyseschritt einen Dialog mit dem Bearbeiter, der mit der Lösung oder der Aussage, daß keine Lösung vorhanden sei, endet. In diesem Fall muß neues Wissen in Zusammenarbeit zwischen dem Experten, der eine Lösung erstellt hat, und einem Administratoren in das System eingepflegt werden. Systeme wie Applix mit der Suchmaschine von Fulcrum ermöglichen eine Informationsaufnahme ohne laufende Pflege. Dafür ist die Informationsrückgewinnung durch den Bearbeiter aufwendiger, denn im Fall einer fehlgeschlagenen Suche existiert keine Gewißheit, daß keine Lösung für den Fehlerfall vorhanden ist. Deshalb ist die Erfahrung bei der Formulierung der Anfrage entscheidend (vgl. auch [ABT98]). 4 Kommerzielle HDS nutzen vielfältige Techniken zur Benachrichtung, angefangen von eigenen Werkzeugen (z.b. SupportMagic: Notification Manager Magic Spy), , Fax bis hin zu Nachrichten für Pager und (mobile) Telefondisplays. Anlaß sind Eskalationen.

126 108 Informationssysteme im Verbesserungsmanagement Helpdesk-System erfolgen. Um das Datenvolumen der Replikation einzuschränken, müssen aus den Gesamtdaten Teilmengen extrahiert werden können, wobei dies z.b. die Fehlerfälle eines speziellen Kunden sein können. 5 Neben den in der Fehlererfassung dokumentierbaren Fehlerbilddaten sind auch noch weitere Dokumente, z.b. Faxe von Kunden, für ein vollständiges Fehlerbild wichtig. Deshalb sollten diese Dokumente ebenfalls in das Fehlerbild aufgenommen werden. Dies kann durch Digitalisierung der Dokumente oder durch Verweisstrukturen auf physische Objekte geschehen. Mit der Beschaffung externer Wissensbasen wird der Rahmen, in dem aus Fehlern gelernt werden kann, über die Unternehmensgrenzen hinweg erweitert (vgl. Abschnitt 3.3). 6 Diskussionsforen bilden im Rahmen der Groupware-Systeme die Möglichkeit, Fragen zu Problemen unabhängig von einem konkreten Fehlerfall zu stellen und Erkenntnisse einzubringen oder zu verbreiten. Damit kann die Wissensbasis ebenfalls erweitert werden. Gleichzeitig dienen sie dazu, den Dialog zwischen Experten und Suchenden herzustellen und zu stabilisieren (vgl. Abschnitt 5.3.4). Erweiterter Workflow Die Werkzeuge der Ebene Erweiterter Workflow unterstützen die Gestaltung service-orientierter Workflows mit zusätzlichen Kontroll- und Steuerungsmöglichkeiten und die Einbeziehung zusätzlicher Informationsquellen anderer Unternehmensbereiche. Ebene Werkzeug-Nr. Werkzeug Zuordnung Erweiterter Workflow 12 Eskalationsregeln Eskalationsmanager 13 Übergaberegeln Eskalationsmanager 14 Planung von Arbeitsschritten Eskalationsmanager 15 Teilbarkeit von Problemen Eskalationsmanager 3 16 Anlagenmanagement Repository 17 Kundenidentifikation Anfragemanager 18 Regeln zum Kundenanspruch Anfragemanager 19 Relevanz von Problemen Anfragemanager 20 Multimediadokumente Arbeitsplatz & Repository Tabelle 5.4: Ebene 3 - Erweiterter Workflow Eskalationsregeln sollen verhindern, daß Fehlerbilder in einer Eskalationsstufe über 5 In der durchgeführten Fallstudie (vgl. Abschnitt 7.2) waren Techniker einer Abteilung durchschnittlich mit 2,9 Fahrten 30 Tage im Jahr außerhalb des Unternehmens, wobei es sich in der Regel um Inbetriebnahmen handelte. 6 Es existieren für HDS kommerzielle Wissensbasen für unterschiedliche Themen (z.b. für Serviceware die Bereiche Netzwerke und Windowsversionen, für Siemens die Wissensbasis der eigenen Hotline). Damit steht bereits bei der Einführung eines Helpdesk-Systems ein Informationsangebot zur Verfügung, das die Akzeptanz des Systems erhöhen kann. Bei der methodischen Einführung von HDS ist dieser Punkt zu beachten.

127 5.1 Workflow-gestützte Helpdesk-Systeme 109 mehr als einen definierten Zeitraum hinweg keinen Fortschritt erkennen lassen. Die Eskalationsregeln müssen so formalisiert werden, daß ein HDS automatisch Eskalationen einleiten und die Beteiligten über das Benachrichtigungssystem (Werkzeug 7 ) informieren kann. Erforderlich sind sowohl zentral administrative Vorgaben aus den Geschäftsprozessen als auch Regeln zur Selbstkoordination der Bearbeiter. Eine Kombination beider Verfahren stellt die Regelung der Prioritäten von Fehlerbildern dar. Auslöser für automatische Eskalationen müssen definierte Ursachen sein. Die empirischen Befunde (vgl. Kapitel 4) zeigen, daß Eskalationen mitunter lange Durchlaufzeiten haben. Die Prioritätenregelung muß vom Unternehmen selbst definiert werden können, wobei Prioritäten durch neue Erkenntnisse oder Verbesserung der Geschäftsprozesse änderbar sein müssen. Die Verantwortlichkeiten für die Bearbeitung werden durch die Rollenvergabe, z.b. das Prinzip der Complaint Ownership (vgl. Abschnitt 3.4.3) geregelt. Wird die Verantwortung auf einen anderen Mitarbeiter übertragen, muß sichergestellt sein, daß dieser den Vorgang annimmt, damit die Vorgänge nicht ohne Zuständigkeit unbearbeitet bleiben. Anderenfalls kann es passieren, daß ein Fall von einer Eskalationsstufe abgegeben wird, aber nicht von der anderen angenommen wird, z.b. weil dieser sich nicht zuständig fühlt. Deshalb müssen alle Rollen innerhalb der Eskalation ausgefüllt sein, damit der Prüfer letztendlich auch eine willkürliche Zuweisung vornehmen kann. Die methodische Planung der Vorgehensweise kann auf der Mikroprozeßebene strukturell vorgegeben werden (vgl. Abschnitt 3.4.1), auf der Makroebene aber nur erfahrungsbasiert durch die Analyse von Fehlerfällen geschehen. Daher ist die Speicherung von Eskalationen notwendige Voraussetzung für die erfahrungsbasierte Analyse und Planung mittels eines Planungswerkzeuges. Die Eskalationsstrategien (vgl. Abschnitt 3.4.5) können eingesetzt werden, um entsprechend des service-orientierten Workflows-Ansatzes Probleme zu delegieren. Dabei kann die ursprüngliche Eskalation nicht abgeschlossen werden, bevor alle Delegationen abgeschlossen sind. Jede Teileskalation wird dabei wieder entsprechend als service-orientierter Workflow behandelt. Ein Anlagen- und Produktmodell verschafft den Bearbeitern einen schnellen Überblick über die Anlagen oder Produkte des Kunden. Mit ihrer Hilfe kann ein Fehlerort schnell und eindeutig bestimmt werden. Wenn keine klare Mitteilung über die Identität des Kunden besteht, können über verschiedene Suchstrategien, z.b. in Kombination mit dem Anlagen und Produktmodell, durch wenige abfragbare Informationen den Kunden identifizieren. Nicht jede Unzufriedenheit eines Kunden stellt eine berechtigte Beschwerde oder gar Reklamation dar (vgl. die Fallstudie in Abschnitt 2.7). Zum Teil sind Garantiefristen oder Wartungsverträge abgelaufen, zum Teil möchte der Kunde auch eine Leistungsänderung des von ihm erstandenen Produktes, oder eine vermeintliche Fehlfunktion hat eine Fehlbedienung zur Ursache. Für den Bearbeiter, ideal schon vor der Annahme in der Anfragephase, muß erkennbar sein, ob er einer rechtlichen Verpflichtung nachkommt, eine Kulanzleistung erbringt, oder eine Leistung verkauft. Falls der zu erwartende Aufwand bei der Prüfung für den Aufwand die Ersatzleistung

128 110 Informationssysteme im Verbesserungsmanagement übersteigt, ist es im Sinne der Kundenzufriedenheit, den Mangel, ohne zu zögern, zu beseitigen. Der Bearbeiter muß auch eine Grundlage haben, um die Bedeutung des Kunden für das Unternehmen einzuschätzen, z.b. um eine Kulanzleistung zu erbringen. Esmüssen erfahrungsbasiert Regeln aufgestellt werden, die eine Entscheidung ermöglichen, ob ein Kunde kostenlosen Support oder eine kostenpflichtige Dienstleistung erhält. Dabei muß dem Umstand Rechnung getragen werden, daß der Helpdesk die Schnittstelle des Kunden zum Unternehmens ist. Nicht nur die Einbeziehung von Wartungs- oder Dienstleistungsverträgen für die Nachvollziehung des Anspruchs auf Serviceleistungen sind wichtig, auch die Möglichkeit, Produktinformationen zur Anbahnung neuer Geschäftstransaktionen zu nutzen, in dem z.b. Daten an das Marketing oder die After-Sales Abteilungen weitergeleitet werden. Ein während der Fehlerfallbearbeitung erkanntes Problem hat, unabhängig von der Priorität des betreffenden Falls, eine Relevanz für andere Produkte (durch die Fertigung von Varianten), für die Prozesse, mit denen die Leistung erbracht wurde, und die Anlagen, auf denen möglicherweise Produkte gefertigt oder geprüft wurden. Die Relevanz ist abhängig von der Auswirkung eines Fehlers, von der Verbreitung und von der Wahrscheinlichkeit. Deshalb müssen Probleme auch unter präventiven und proaktiven Gesichtspunkten, z.b. durch FMEA oder durch die Produktplanung betrachtet werden. Externer Zugriff Werkzeuge für den externen Zugriff erlauben es, Abteilungen, die nicht direkt im Verbesserungsmanagement involviert sind, z.b. Marketing und After Sales, oder Kunden des Unternehmens, auf die Wissensbasis zuzugreifen. Zu den externen Zugriffen wird auch die direkte Einflußnahme des Helpdesks auf das Produkt des Kunden gezählt, z.b. für die Fernwartung. Ebene Werkzeug-Nr. Werkzeug Zuordnung Externer Zugriff 21 Report- und Analysewerkzeug Anfragemanager 22 Web-Schnittstelle Arbeitsplatz & Anfragemanager 4 23 Abgestufte Zugriffe Arbeitsplatz & Anfragemanager 24 Mehrsprachigkeit Repository 25 Teleservice Anfragemanager Tabelle 5.5: Ebene 4 - Externer Zugriff Statistische Funktionen lassen häufig auftretende Fehler in Produkten und Dienstleistungen erkennen [KR95]. Unterstützt werden diese Funktionen durch die Bildung von Fehlerklassen und das Variantenmanagement. Damit bilden Report- und Analysewerkzeuge eine wichtige Vorstufe für präventive Methoden des Verbesserungsma-

129 5.1 Workflow-gestützte Helpdesk-Systeme 111 nagements wie die FMEA (vgl. Abschnitt 2.5). Eine Web-Schnittstelle ermöglicht den Zugriff auf das Helpdesk-System, ohne daß vorher eine spezielle Zugriffssoftware für das System installiert werden muß. Deshalb ist sie insbesondere für den Zugriff von Kunden geeignet, die über diese Schnittstelle ihren Fehlerfall melden oder sich über den Bearbeitungsstand ihres Fehlerfalls informieren wollen. 7 Ein HDS muß über abgestufte Zugriffsrechte auf die Wissenbasis und deren mnemonische Prozesse verfügen. Speziell für einen Kundenzugriff muß die Isolation der Informationen sichergestellt sein, so daß kein Kunde auf Informationen über andere Kunden zugreifen kann. Auch persönliche Arbeitsnotizen und Mitteilungen müssen vertraulich behandelt werden. Kunden international arbeitender Unternehmen müssen ihren Fehlerfall formulieren und die Antwort verstehen können. Dafür muß der Zugriff auf den Helpdesk in einer dem Kunden geläufigen Sprache erfolgen. Automatisierte Zugriffe über die Web- Schnittstelle müssen zu Beschreibungen des Fehlerfalls passende Lösungen liefern, auch wenn der Fehlerfall in einer anderen Sprache formuliert wird. Lösungen müssen dem Kunden übersetzt geliefert werden. 8 Der Fernzugriff auf den Rechner, das Produkt bzw. die Anlage des Kunden kann dem Servicetechniker in vielen Fällen ein wesentlich genaueres Fehlerbild liefern, als eine vage Beschreibung von Beobachtungen durch den Kunden. Zustände können direkt geprüft und mit Sollwerten verglichen werden. Fernzugriffe erfordern umfangreiche Installationen beim Kunden. Erweiterungsmöglichkeiten Die hier aufgeführten Werkzeuge erleichtern die Einbettung des HDS in die vorgegebenen organisatorischen und technologischen Gegebenheiten. Dies entspricht den in Kapitel 4 geäußerten Anforderungen der Praxis nach offenen Funktions- und Datenschnittstellen sowie die Einbindung relevanter Informationssysteme in den Helpdesk. Ebene Werkzeug-Nr. Werkzeug Beschreibung Erweiterungsmöglichkeiten 26 Offene Datenschnittstellen Schnittstellenmanager 27 Offene Funktionsschnittstellen Schnittstellenmanager EW 28 Personaleinsatzplanung Anfragemanager 29 Lagerverwaltung Anfragemanager 30 Anbindung an andere HDS Anfragemanager Tabelle 5.6: Erweiterungsmöglichkeiten 7 Bei ausreichender Füllung der Wissensbasis kann dem Kunden mit dieser Schnittstelle ein zusätzlicher Service angeboten werden. Die Datenbasis dient als Ratgeber zu technischen Problemen (vgl. Microsoft Knowledge Base). 8 Als derzeitiger Lösungsansatz gelten Anbindungen an Übersetzungsdienste, wie sie z.b. die Firma Timeframe AG bietet.

130 112 Informationssysteme im Verbesserungsmanagement Ein HDS darf kein geschlossenes System sein. Alle Informationen, die in einem Helpdesk gespeichert sind, müssen Auswertungen, insbesondere den Methoden des Verbesserungsmanagements zur Verfügung stehen. Nur durch offene Datenschnittstellen kann ein Zugriff auf die Wissensbasis erfolgen. Weiterhin erlauben offene Datenschnittstellen die Integration externer Wissensbasen. Die empirischen Befunde (vgl. Abschnitt 4.4.2) weisen einen deutlichen Trend zur Benutzung relationaler Datenbankmanagementsysteme und deren Schnittstellen aus. Mit Hilfe offener Funktionsschnittstellen kann ein HDS flexible neue Funktionen einbinden. 9 Insbesondere in kleinen und mittelständischen Unternehmen, in denen der Kundendienst durch Arbeitskräfte bewältigt wird, die neben den Servicetätigkeiten noch andere Aufgaben, z.b. in der Produktentwicklung haben, muß ausreichend Personal für die Bearbeitung von Fehlerfällen zur Verfügung stehen. Absehbare Häufungen von Beschwerden, z.b. nach Markteintritt einer neuen Produktgeneration, muß bei der Personalplanung für das HDS berücksichtigt werden. 10 Die Anbindung an eine Lagerverwaltung kann ein Servicetechniker nutzen, um die Verfügbarkeit von beim Kunden ausgefallenen Komponenten zu prüfen. Zum einen kann er dem Kunden sofort Auskunft über die voraussichtliche Reparaturdauer geben, zum anderen wird die Bildung von Reserve- oder Reparaturlager unnötig, die zusätzliche Kosten verursachen. Eine Verbindung des Helpdesk-System mit denen der Zulieferer erhöht die Leistungsfähigkeit der Systeme in unternehmensübergreifenden Wertschöpfungsketten durch gegenseitigen Wissensaustausch. Eine Frage von zentraler Bedeutung für Unternehmen ist: Was tut der Kunde meines Kunden mit meinem Produkt? Kleine und mittelständische Unternehmen nutzen zudem in ihrer Produktion viele Fremdkomponenten, um ihre Fertigungstiefen gering zu halten. Das Problemlösungswissen über die Fremdkomponenten wird vom Kunden aber beim Erwerb einer Gesamtlösung vorausgesetzt. Unter dem Begriff Helpdesk-Systeme existieren Produkte, die jeweils einen Teil der beschriebenen Werkzeuge enthalten. Umgekehrt existiert zu jedem der beschriebenen Werkzeuge zumindest ein Anbieter, der das entsprechende Werkzeug implementiert hat. Kommerzielle HDS unterscheiden sich deutlich durch ihren Aufbau. Nur ein kleiner Teil der angebotenen Systeme sind offen und erweiterbar konzipiert. Abbildung 5.2 ist die Darstellung der Häufigkeit der eingesetzten Werkzeuge in kommerziellen Helpdesk-Systemen. Die Balkenlänge und die Zahlen kennzeichnen die Zahl der Systeme, welche das Werkzeug enthalten. Die Schraffierung der Balken beschreibt, in welcher Ebene des Modells das Werkzeug enthalten sind. Es wurden nur solche HDS aufgenommen, 9 Das bevorzugte Betriebssystem Windows NT (vgl. Abschnitt 4.4.5) stellt als Schnittstellen z.b. ActiveX bzw. DCom zur Verfügung. Offene Schnittstellen sind beispielsweise CORBA und RMI unter Java. 10 In der Praxis kommt es immer wieder zu Fällen, wo nach Fehlfunktionen eines Produktes auch noch der Ärger des Kunden mit einer nicht oder nur schwer zu erreichenden Hotline gesteigert wird, z.b. bei der Einführung von Premiere World (vgl. Der SPIEGEL 47/1999).

131 5.1 Workflow-gestützte Helpdesk-Systeme 113 welche die Ebene Minimaler Helpdesk abbilden (43 von 183 bekannten HDS) 11. Häufigkeit der Werkzeuge in kommerziellen Systemen Werkzeug Anzahl Workflowtechniken 43 Kommunkationsschnittstellen 43 Fehlererfassung 43 Fehleridentifikation 39 Benachrichtigungssysteme 36 Eskalationsregeln 33 Lernfähigkeit 32 Analyse 31 Anlagenmanagement 30 WEB-Schnittstelle 27 Fehlerdatenmodell (FDM) 20 ExterneWissensbasen 20 Kundenidentifikation 20 Offene Datenschnittstellen 16 Abgestufte Zugriffsrechte 13 Dokumenteninterface Anspruch Werkzeug der Ebene Multimediadokumente 9 Workflowkern Offene Funktionsschnittstellen Mobile Arbeitsplätze Übergaberegeln (Handshake) Teilbarkeit von Problemen Minimaler Helpdesk Vollständige Information Erweiterter Workflow Relevanz von Problemen Personaleinsatzplanung Lagerverwaltung Externer Zugriff Erweiterungsmöglichkeiten Diskussionsforen 3 Planung von Arbeitsschritten 3 Mehrsprachigkeit 3 Teleservice 1 Andere Helpdesksysteme 1 Abbildung 5.2: Häufigkeit der untersuchten Werkzeuge in kommerziellen Systemen Die Ebenen des Modells werden nicht gleich stark durch die Systeme unterstützt (vgl. Abbildung 5.3). Während die Stufen 2 und 3 durch einzelne Systeme mit allen Werkzeugen unterstützt werden, nimmt die Anzahl der unterstützten Werkzeuge für die Ebenen Externer Zugriff und Erweiterungsmöglichkeiten deutlich ab. Dies gilt gleichermaßen für die Implementierungen in den jeweiligen Systemen und die Zahl der Systeme, die keinerlei 11 Quellen waren der Messekatalog der CeBit 1998 und das amerikanische Helpdesk-Institut.

132 114 Informationssysteme im Verbesserungsmanagement Werkzeuge für die letztgenannten Ebenen enthalten. Basis der Erhebung waren 29 Systeme, die als Minimaler Helpdesk verfügbar sind. Mit dem erarbeiteten Katalog steht ein Durchschnittliche Abgeschlossenheit der Ebenen 45% 40% 35% 45% 41% 37% 30% 25% 25% 20% 15% 10% 5% 0% Vollständige Information Erweiterter Workflow Externer Zugriff Erweiterungsmöglichkeiten Abbildung 5.3: Durchschnittliche Abgeschlossenheit der Ebenen Werkzeug zur Verfügung, um ein konkretes HDS unternehmensspezifisch auszuwählen und die Implementierung des HDS anhand der einzelnen Ebenen und Werkzeuge zu überprüfen. Diese Vorgehensweise wurde in einer Fallstudie in Kapitel 7 validiert. Darüber hinaus liefert der Katalog durch die Zuordnung von Werkzeugen zu Komponenten wichtige Hinweise zur Realisierung von eigenen Verbesserungsmanagementsystemen. Gleichwohl bleibt die Gestaltung der einzelnen Werkzeuge eine anspruchsvolle Aufgabe. 5.2 Repository-Technologien für das VVM Grundlage für die Gestaltung von Verbesserungsmanagementsystemen sind Repository- Technologien, die externalisiertes Wissen speichern, mit vorhandenem Wissen neu kombinieren und Schnittstellen für die effektive Internalisierung des Wissens liefern. Grundlegende Ergebnisse zur besseren Nutzbarkeit von Fehlerwissen im Unternehmen haben insbesondere die interdisziplinären Projekte WibQuS 12 [Pfe96] und FOQUS 13 [Pfe97] geliefert, an denen der Verfasser dieser Arbeit beteiligt war. 12 Wissensbasierte Systeme in der Qualitätssicherung : Gefördert im Rahmen des BMBF-Programms Qualitätssicherung Fehlermanagement mit objektorientierten Technologien in der qualitätsorientierten Produktion : Gefördert im Rahmen des BMBF-Förderprogramms Produktion 2000 in Zusammenarbeit des Lehrstuhl

133 5.2 Repository-Technologien für das VVM WibQuS: Repository und Qualitäts-Trader Das Projekt WibQuS hat auf Forschungsseite zur Weiterentwicklung der Informationssystemunterstützung von team- und wissensorientierten Ansätzen im Verbesserungsmanagement beigetragen (vgl. Abschnitt 2.5). Die WibQuS-Forschungsgruppe bestand aus neun Forschungsinstituten, von denen drei Institute auch im Nachfolgeprojekt FOQUS involviert waren. Ziel des Projekts WibQuS war die Grundlagenforschung für unternehmensweite Qualitätsinformationssysteme, speziell die Unterstützung und Integration von Qualitätsmanagementmethoden mittels eines Repository-Ansatzes sowie die Unterstützung von Teams durch wissensbasierte Informationssysteme. Innerhalb des Projekts wurde eine informationssystem-gestützte, explizite Wissensbasis für das Verbesserungsmanagement realisiert. Der Forschungsschwerpunkt lag auf Seite der Informatik bei der Unterstützung des verteilten Modellierungsprozesses zur Überwindung räumlicher, zeitlicher und konzeptueller Distanzen. Die Grundlagen, die mit dieser Forschung verbunden waren, flossen in das Projekt FOQUS. Die Wissensbasis wurde durch Repository-Technologien realisiert [JJPP97], mit dem Ziel, Methoden des Verbesserungsmanagements konzeptuell zu integrieren. Das Repository wurde mittels des IRDS-Rahmenwerks strukturiert. Auf der obersten Ebene befindet sich eine Geschäftsprozeßmodellierungssprache, die Konzepte für die integrierte Modellierung von Methoden bereithält, die auf der nächsten Ebene realisiert sind. Auf dieser Ebene werden Schnittstellen und Regelkreise identifiziert. Auf der darunter liegenden Ebene befinden sich Prozeßbeschreibungen konkreter Projekte des Verbesserungsmanagements. Zunächst folgen einige Definitionen. Ein Verzeichnissystem für Informationsressourcen (engl.: information resource dictionary system (IRDS)) ist ein Repository-System, das Informationen über Informationen repräsentiert, speichert, verwaltet, verteilt und wartet [BD94]. Es besitzt deshalb folgende Eigenschaften: Informationsmodell: Eine symbolische Repräsentation von Technologien, Schemadefinitionen und organisatorischen Aspekten, z.b. Prozesse und Agenten. Informationsmanagementsystem: Unterstützt die Erzeugung, den Zugriff und die Verwaltung einer Informationsbasis. Kontrollfunktionen: Auf DBMS Funktionalitäten aufsetzende Möglichkeiten, wie z.b. Versions- und Konfigurationsmanagement. Ein Verzeichnis für Informationsressourcen (IRD) ist ein gemeinsam nutzbares Repository, welches in einem IRDS gespeichert wird. Im ISO Rahmenwerk besteht ein IRD aus vier Ebenen (Abbildung 5.4): für Informatik V, RWTH Aachen, mit dem Lehrstuhl für Fertigungsmeßtechnik und Qualitätsmanagement, WZL, RWTH Aachen, dem Lehrstuhl für Fertigungtechnik und Betriebsorganisation, FBK, Universität Kaiserslautern, dem Aachener Demonstrationslabor für integrierte Produktionstechnik ggmbh (ADITEC) und einem Firmenkonsortium.

134 116 Informationssysteme im Verbesserungsmanagement IRD Definition Schema Level IRD Definition Level IRD Level } IRD Definition } Level Pair IRD Level Pairs IRD Application Level Application }Level Pairs Abbildung 5.4: IRDS Rahmenwerk für Repository-Gestaltung Die IRD Applikationsebene enthält Daten der Applikation, d.h. Produkt- oder Prozeßstrukturen, die durch Schemata festgelegt werden. Die IRD Ebene enthält Schemata von Applikationen, z.b. das Fehlerdatenmodell. Die IRD Definitionsebene enthält Definitionen, die Typen von Objekten beschreiben, über die Informationen gesammelt werden sollen. Im Projekt WibQuS waren dies Beschreibungen von Methoden des Verbesserungsmanagements wie SPC und QFD. Die IRD Definitionsschemaebene definiert eine Sprache, mit der Typen der IRD Definitionsebene beschrieben werden können. Im Projekt WibQuS war dies die Geschäftsprozeßmodellierungsprache, die im folgenden näher vorgestellt wird. Das IRDS ist entlang der Klassifikationsdimensionen semantischer Datenmodellierung organisiert. Die Konzepte einer Ebene n+1 definieren ein Typsystem für eine Ebene n. Um nun diese Ebenen gemäß dem IRDS Standard zu verbinden, wird in eine Architektur von Ebenenpaaren eingeführt, die ebenfalls in Abbildung 5.4 abgebildet ist. Beziehungen zwischen benachbarten Ebenen werden durch eine Hierarchie von drei Datenbankspezifikationen erzeugt, das Ebenenpaar der Applikationen, das IRD Ebenenpaar und das IRD Definitionsebenenpaar. Das Applikationsebenenpaar enthält die zu integrierenden Applikationen. Das IRD Ebenenpaar enthält die Spezifikation der Modellierungsumgebung, bestehend aus den Modellierungssprachen, gegeben als Schemata, und den resultierenden Applikationsschemata als ihren Daten. Das IRD Definitionsebenenpaar enthält die Beschreibung von Modellierungstechniken als Daten und eine feste Beschreibungsweise dieser Methoden, bestehend aus

135 5.2 Repository-Technologien für das VVM 117 einer Anzahl von SQL Tabellen nach ISO Diese Tabellen beschreiben, welche Konzepte als Entitäten und welche als Relationen modelliert werden. Prinzipiell erlaubt eine auf dem IRDS-Standard basierende Architektur die Föderierung beliebiger Applikationen, wenn die entsprechenden Paare definiert werden können. Solche Architekturen werden z.b. eingesetzt zur Überwindung der Heterogenität von Modellierungansätzen wie in den Method Engineering Ansätzen MERET [HO92], GOPPR [GF94], MetaPHOR [TL92] und NATURE[NAT96], zur erfahrungsbasierten Prozeßaufzeichnung und -verbesserung [PDH + 95, PDJ97, Döm99], zur Überwindung der Heterogenität von Systemen durch Interoperabilität[JPW + 98] und zur Unterstützung der Koordination und Kooperation in einer föderierten Umgebung wie in WibQuS [JJS93] und FOQUS [KPJ98]. In der Dissertation von Szczurko wurde das WibQuS-Repository für die Steuerung von Informations- und Arbeitsflüssen genutzt. Das Repository diente drei Hauptzielen [Szc96, S. 154 ff.]: Definition eines Metamodells für Prozesse im Qualitätsmanagement Bei der Einwicklung des Metamodells auf der obersten Repository-Ebene (IRD Definitionsschemaebene) wurden folgende Aspekte berücksichtigt: Der Aufbau einer Begriffsbasis für das Qualitätsmanagement diente der Terminologiearbeit für ein unternehmensweites Verständnis der verwendeten Begriffe. Die Implementierung im Repository erleichterte beispielsweise die Identifizierung von Homonymen und Synonymen. Das Metamodell schränkte die sprachlichen Ausdrucksmittel ein und fokussierte auf die Modellierung von Informations- und Arbeitsflüssen in und zwischen Methoden des Verbesserungsmanagements. Für die Steuerung wurden rein vorwärtsgerichtete Arbeits- oder Materialflüsse von prozeßübergreifenden Informationsflüssen zur Realisierung von Regelkreisen unterschieden. Die Abbildung verschiedener Workflow-Arten (dokument-, service- und aktivitätsbasiert) wurde berücksichtigt. Verteilte Methodenmodellierung Die verteilte Methodenmodellierung wurde mittels der Implementierung des Repositories in der Modellierungsumgebung ConceptBase [JGJ + 95] realisiert. Dazu wurde das Metamodell in der Sprache O-Telos [Jeu92] beschrieben, einer Erweiterung von Telos [MBJK90]. Details der Sprache sind [Szc96, Pet96] zu entnehmen. Für den verteilten Modellierungsprozeß waren die analytischen Fähigkeiten von ConceptBase von entscheidender Bedeutung. Die Teilmodelle wurden von den Teilmodellentwicklern als Instantiierungen des Metamodells auf der IRD Definitionsebene realisiert. Die Konsistenz der Modelle wurde mit Hilfe der in ConceptBase enthaltenen Konsistenzchecks automatisch überprüft. Verschiedene Aspekte der Geschäftsprozeßmodellierung wie die Hierarchisierung von Objektkategorien, Ketten von Aufgaben und Objekten und Beziehungen zwischen Methoden und Aufgaben wurden unterstützt.

136 118 Informationssysteme im Verbesserungsmanagement Die Querbezüge zwischen Teilmodellen konnten grafisch und textuell visualiert werden. Erste Schnittstellen konnten aufgrund der Verkettung der modellierten Begriffe erkannt werden. Die graphische Notation war für die beteiligten Ingenieure eine entscheidendee Erleichterung bei der Modellierung. Integration der Methodenbeschreibungen zu einem Gesamtmodell Mittels der Anfragesprache konnte die Vollständigkeit und Korrektheit der Teilmodelle bezüglich des Metamodells ermittelt werden. Ein in ConceptBase realisierter kooperativer Abstimmungsprozeß sicherte Verständnis und Zustimmung der Teilmodellentwickler zur Methoden- und Schnittstellenmodellierung. Der verteilte Modellierungsansatz führte schließlich zu einem gemeinsamen Verständnis über Methoden im Qualitätsmanagement unter den Vorgaben des Metamodells. Schnittstellen und Berührungspunkte konnten identifiziert werden und führten zu einer verbesserten Kommunikation unter den Modellierern, die von einigen sogar mehr geschätzt wurden als die entstandenen Modelle. Die verteilte Modellierung mit dem Repository-Ansatz erbrachte aber auch erhebliche konzeptuelle und technische Herausforderungen. Die nicht vertraute Modellierungssprache und -umgebung mußte den Modellierern in Schulungen vertraut gemacht werden. Trotzdem entstanden aufgrund divergierender Denk- und Vorgehensweisen Modelle unterschiedlicher Granularität, die in den Abstimmungsprozessen angeglichen werden mußten. Technisch war die Realisierung der verteilten Modellierungsumgebung aufgrund geringer Transferraten und organisatorischer Barrieren nur mit sehr großem Aufwand zu realisieren. Daraus resultierende lokale Installationen erschwerten die Verwirklichung des Gesamtmodells. includes Method knows Agent includes supports works on owns includes Task takes produces Object includes Abbildung 5.5: WibQuS Metamodell zur Integration von Methoden (adaptiert aus [Pet96, Szc96]) Das im WibQuS Projekt verwendete Metamodell (vgl. Abb. 5.5) sah schließlich folgende Komponenten vor: Aufgaben (Task ) werden entlang der Geschäftsprozesse ausgeführt Methoden (Method) sind strukturierte Prozesse, die Aufgaben unterstützen (supports) Menschliche oder technische Agenten (Agent) kooperieren in Geschäftsprozessen. Sie kennen (knows) Methoden und arbeiten an (works on) Aufgaben

137 KB-QFD KB-XSPC KB-FTA 5.2 Repository-Technologien für das VVM 119 Objekte (Object), die Agenten gehören (owns), werden entlang der Geschäftsprozesse weitergegeben. Sie werden von Aufgaben erzeugt (produces) oder konsumiert(takes). Das konzeptuelle Modell wurde in ein föderatives Informationssystem eingebettet und prototypisch implementiert. Das zusätzliche technische Problem bei der Integration von Methoden im Qualitätsmanagement ist, daß zwar viele der Werkzeuge zur Unterstützung der Methoden auf der Basis relationaler Datenbanksysteme realisiert sind, aber weder die Schemata zur Beschreibung der Daten noch die Schemata der verschiedenen Datenbank- Hersteller selbst miteinander interoperabel sind. Daher mußte die Interoperabilität sowohl konzeptuell (durch die Verwendung des Modells) als auch technisch (durch Verwendung eines Omni-SQL-Gateways) hergestellt werden. Kern der Einbettung ist der Qualitäts-Trader [JJS93, PS94, PSJJ95, Szc96, JJPP97]. Dieser Trader enthält zusätzlich zum konzeptuellen Modell eine Steuerungskomponente, die auf der Basis verzahnter Workflow-Modelle die Ausführung und Administration von Aufträgen und Anfragen im System erlauben. Dazu wurde im Trader-System (vgl. Abbildung 5.6) eine Repräsentation (Informationsmodell) des verteilten, föderierten Systems geschaffen. Dieser Grundgedanke wird in Kapitel 6 weiter verfolgt. INTERNET SQL subsystem QFD KB-QFD SQL subsystem QFD SQL subsystem XSPC SQL subsystem FTA SQL subsystem SPC KB-XSPC Meta-KB TRADER SQL SQL subsystem FA KB-FTA Meta-KB TRADER SQL Abbildung 5.6: WibQuS Trader Architektur (adaptiert aus [Szc96]) Die wesentliche Leistung des Trader-Systems ist damit die Schaffung einer interoperablen Ausführungsplattform auf der Basis konzeptueller Modelle in einer von Heterogenität und Verteilung gekennzeichneten DV-Infrastruktur FOQUS: Kooperative Modellierung von Arbeits- und Informationsflüssen Fokussierte Modellinteraktion auf konzeptueller Ebene und Interoperabilität auf technischer Ebene waren schon im Projekt WibQuS bestimmende kooperative Techniken zur Realisierung von vernetzten Systemen in heterogenen Anwendungskontexten (vgl. auch [JPW + 98]). Im Projekt FOQUS wurden die in WibQuS entwickelten Vorgehensweisen weiter in Richtung Praxis und damit auf die konkrete Systemgestaltung hin entwickelt. Nicht

138 120 Informationssysteme im Verbesserungsmanagement mehr die Methoden und deren konzeptuelle Integration standen im Vordergrund, sondern die werkzeuggestützte Praxis des Verbesserungsmanagements. Das zugrundeliegende FOQUS-Sprachmodell [Pfe97, KPJ98, JK98] selbst ist aus dem WibQuS-Sprachmodell [Szc96] entstanden und ist im wesentlichen durch die Ersetzung des Konzepts Methoden durch das generalisierende Konzept Hilfsmittel gekennzeichnet, welches Methoden und ihre Unterstützung durch Systeme vereinigt. Wie schon in WibQuS wurde für die Modellierung eine graphische Notation gewählt, die von der Realisierung in O-Telos abstrahiert und den beteiligten Ingenieuren den Zugang erleichtern sollte. Jede geometrische Figur repräsentiert ein Konzept im Metamodell. Der Name des Konzepts steht innerhalb der Figur. Relationierende Attribute werden durch gerichtete und benannte Pfeile repräsentiert. Ein mit isa benannter Pfeil repräsentiert eine Spezialisierung eines Konzepts. Die Modellierung folgt damit einem erweiterten Entity-Relationship Ansatz [Che76]. Das formale Sprachmodell in Abbildung 5.7 geht letztendlich im Kern vom Prozeßmodell von McMenamin und Palmer [MP84] aus. Eine Eingangsgröße (Objekt) wird von einem System manipuliert und eine Ausgangsgröße wird erzeugt. Das System selbst wird durch den Prozeß definiert, der den Arbeitsablauf beschreibt, den Agenten, der den Ablauf durchführt, und die Hilfsmittel, die der Agent bei der Durchführung benutzt. Die enthält enthält Agent benutzt Hilfsmittel enthält führt_aus unterstützt Objekt erzeugt nutzt Prozeß enthält isa Aktivität Abbildung 5.7: FOQUS-Sprachmodell (adaptiert aus [KPJ98]) Bedeutung der Klassen, die die Begriffe definieren, und der Attribute, die die Beziehungen zwischen den Begriffen beschreiben, sind wie folgt: 1. Agent: Das Konzept Agent beschreibt den Mitarbeiter oder die Maschine, die einen Prozeß durchführt. Der menschliche Agent hat dabei die Prozeßverantwortung und er besitzt, über die vorgegebene Prozeßspezifikation hinaus, Freiheiten bei dessen Durchführung, d.h. er ist stets frei in der Auswahl weiterer Hilfsmittel. Sobald ein menschlicher Agent explizit in den Prozeß eingebunden ist, werden Maschinen prinzipiell als Hilfsmittel

139 5.2 Repository-Technologien für das VVM 121 modelliert. Ein Agent kann ein Team sein, weshalb das Modellierungskonzept ein Attribut enthält besitzt, das wieder auf Agent verweist. Der Agent Verbesserungsmanagementgruppe kann so aus mehreren Agenten wie Prüfplaner, Fertigungstechniker, Konstrukteur durch enthält erzeugt werden. 2. Prozeß/Aktivität: Der Prozeß beschreibt den Arbeitsablauf, der von Agenten für eine Aufgabe durchgeführt werden muß. Prozesse werden mit enthält in Teilprozesse verfeinert, die über Objekte gekoppelt sind. So verbindet der Prüfplan die Teilprozesse Prüfplan erstellen und Prüfplan durchführen, wenn er von einem Teilprozeß erzeugt und vom anderen genutzt wird. Prozesse können verzweigen (erzeugte Objekte werden in verschiedene Prozessen genutzt) oder sich vereinen. Eine Aktivität ist eine Spezialisierung des Prozeßbegriffs. Sie zeichnet sich dadurch aus, daß sie nicht weiter in Teilprozesse zerlegbar ist, also den atomaren Baustein für Prozeßketten bildet. Innerhalb einer Aktivität kann der Agent völlig eigenverantwortlich handeln, solange die modellierten Objekte erzeugt werden. 3. Hilfsmittel: Mit Hilfsmittel wird die Technologie beschrieben, die die Agenten bei der Durchführung ihrer Arbeiten unterstützen. Damit sind beispielsweise CAQ-Systeme oder Prüfmittel gemeint, die es dem Prüfer erlauben, seine Arbeit effizienter und mit höherer Qualität auszuführen. Dabei ist explizit zwischen den Betriebsmitteln zu unterscheiden, die Agenten unterstützen und den Informationen, die sie bei ihrer Arbeit nutzen. Alte Prüfpläne sind keine Hilfsmittel im hier betrachteten Sinne, da sie als Objekte aus frühreren Prozessen hervorgegangen sind und daher auch als solche in neue Prozesse einfließen. 4. Objekt: Unter einem Objekt wird ein Artefakt verstanden, der in einem Prozeß genutzt, manipuliert oder erzeugt wird. Jedes der Objekte kann mittels des enthält-attributs detailliert und strukturiert werden. So kann ein Prüfplan aus Produkten, Meßpunkten, Prüfmitteln usw. bestehen, die untereinander wiederum in Beziehung zu setzen sind. Bei den empirischen Untersuchungen in Kapitel 4 stellte sich die Gestaltung der Arbeitsabläufe und Informationsflüsse im Verbesserungsmanagement als zentrale Herausforderungen der DV-Unterstützung heraus (vgl. Tabelle 4.2). Deshalb wurden in der Modellierung zwei Schwerpunkte betrachtet: Modellierung von Arbeitsabläufen: Die Arbeitsabläufe innerhalb des Verbesserungsmanagements sollen mit den Prozessen im Unternehmensumfeld verzahnt werden. Die explizite Beschreibung dieser Abläufe soll sicherstellen, daß ein allgemeines Verständnis hinsichtlich der verwendeten Begriffe und Arbeitsabläufe, soweit für die Systementwicklung und -koppelung notwendig, etabliert

140 122 Informationssysteme im Verbesserungsmanagement wird, die Schnittstellen sowohl zwischen den einzelnen Verantwortungsbereichen des Verbesserungsmanagements als auch mit anderen Aufgabenbereichen des Unternehmens definiert sind und eine Unterstützung von bereichsinternen und bereichsübergreifenden Arbeitsabläufen aus dem allgemeinen Begriffsverständnis heraus auf der Basis der definierten Schnittstellen möglich ist. Während die Arbeitsabläufe auf der Grundlage von Objekttransformationen in Aufgabenketten gestaltet wurden, wurde für die Etablierung von Schnittstellen das Konzept der Vor- und Nachbedingung genutzt, wie es aus der Modellierung von Workflows mittels Petrinetzen (vgl. z.b. [WK93, OSS + 97, van98] bekannt ist und auch in anderen Prozeßmodellierungsansätzen wie ARIS [Sch98a] verwendet wird. Bedingungen beschreiben Zustände von Objekten, Hilfsmitteln und Agenten, die vor und nach der Prozeßausführung bekannt sein müssen. Prozesse können nur gestartet werden, wenn alle Vorbedingungen zutreffen. Sie sind abgeschlossen, wenn alle Nachbedingungen erfüllt sind. Während Bedingungen innerhalb des Verbesserungsmanagements die Schnittstellengestaltung erleichtern sollte, wurden für die Unterstützung systemübergreifender Schnittstellen die Konzepte Ereignis und Aktion eingeführt (vgl. Abbildung 5.9). Ereignis: Arbeitsabläufe im Verbesserungsmanagement werden durch das Auftreten eines Fehlerereignisses in der Umwelt ausgelöst. Ein solches Ereignis startet den Prozeß der Fehlerfallbearbeitung. Aktion: Arbeitsabläufe im Verbesserungsmanagement lösen Aktionen in der Umwelt, also außerhalb der modellierten Systemgrenzen aus. Aktionen beschreiben nicht mehr durch das Verbesserungsmanagement zu kontrollierende Maßnahmen. Modellierung von Informationsflüssen: Hier sollten die Informationen beschrieben werden, die innerhalb des Verbesserungsmanagements benötigt oder erzeugt werden. Bei der Modellierung werden sowohl die Inhalte als auch die Aufbereitung von Daten betrachtet. Die Informationsflußmodellierung sollte sicherstellen, daß Medienbrüche und Informationslücken zwischen den Verantwortungsbereichen vermieden werden, eine Datenspezifikation auf Systemebene möglich ist, der Informationsaustausch in einer heterogenen Systemwelt unterstützt wird und eine vollständige und, soweit notwendig, einheitliche Beschreibung von Informationen im Verbesserungsmanagement vorhanden ist. Das verfeinerte Modell für die Informationsflußanalyse ist in Abbildung 5.8 dargestellt. Drei Aspekte werden dadurch beschrieben. Den Inhalt eines Informationsflusses, die Art und Weise, wie die Information abgelegt ist (das Medium) und auf welche Weise die Information dem Nutzer angeboten wird (die Präsentation).

141 5.2 Repository-Technologien für das VVM 123 enthält wird_beschrieben Objekt erzeugt nutzt Prozeß enthält Inhalt wird_abgelegt stellt_dar Medium erlaubt Präsentation Abbildung 5.8: Modell zur Informationsflußanalyse (adaptiert aus [KPJ98]) Inhalt: Die Struktur eines Informationsobjekts, die Bedeutung der Information und die Nutzung dieser Information an verschiedenen Stellen des Unternehmens. Speziell, wenn Objekte durch die enthält-beziehung komplex strukturiert werden, dient der Inhalt dazu, einen Überblick über die Informationen im Objekt zu verschaffen. 14 Medium: Das Medium beschreibt die Form, in der ein bestimmtes Objekt abgelegt ist. Dies können computerisierte oder auch nicht computerisierte Formen der Informationsverwaltung sein. Im Rahmen der Informationsflußanalyse ist die Medialität von Objekten wichtig, um z.b. Medienbrüche zu erkennen, die Kosten für Lagerung, Wartung und Versand abzuschätzen und um Transformations- Schnittstellen zu bestimmen. Präsentation: Die Präsentation von Objekten kann allein (muß aber nicht) vom Medium abhängen, welches die Information trägt. Speziell computerisierte Medien erlauben, abhängig von den Präsentationswerkzeugen, verschieden Präsentationsformen, deren Nutzung vom Prozeß abhängt, in dem sie genutzt werden. Daher wurde im Modell eine Abhängigkeit sowohl vom Medium als auch von der Nutzung definiert. Die Modellierung wurde mittels des ConceptBase-Systems durchgeführt. Zur besseren Unterstützung des Modellierungsprozesses wurde eine alternative graphische Palette eingeführt, die zum einen außenstehenden Personen, die mit den Modellen konfrontiert wurden, durch Verringerung der konzeptuellen Distanz zwischen repräsentiertem Konzept und gewählter Darstellung das Verständnis erleichtern sollte, zum anderen die Übersichtlichkeit der Modelle durch Führung der Augen verbessern sollte. In Abbildung 5.9 sind die oben beschriebenen Konzepte mit der alternativen Palette dargestellt. Die Repräsentation des Sprachmodells wurde mit dem Graph-Browser des ConceptBase-Systems erstellt. Auf folgende Aspekte soll hingewiesen werden: Als Icon für das Hilfsmittel wurde ein Computer gewählt, um explizit darauf hinzuweisen, daß die im Verbesserungsmanagement betrachteten Prozesse im wesentlichen durch rechnerbasierte oder rechnernahe Hilfsmittel (digitale Meßinstrumente u.ä.) 14 Ein ausführliches Modell für die Inhaltsbeschreibung durch sogenannte Dockets wird in [SS99a] beschrieben.

142 124 Informationssysteme im Verbesserungsmanagement Abbildung 5.9: Alternative graphische Palette (ConceptBase-Bildschirmabzug) unterstützt werden. Das Icon für Bedingung deutet an, daß hier die Prüfung von Gegebenheiten durch die Agenten erfolgen kann. Die Spezialisierungsbeziehung zwischen Prozeß und Aktivität wird durch die Spezialisierung der Icons ausgedrückt. Gleiches gilt für die Komposition von Objekten durch Medium, Inhalt und Repräsentation. Auf der Sprachebene sind alle Konzepte als Umrißzeichnungen repräsentiert, während auf der Modellebene die beschriebenen Begriffe (teilweise) ausgefüllt sind (vgl. Abbildung 5.10). Dies erleichtert die Unterscheidung zwischen den Modellierungsebenen. Mittels der Konzepte wurden autonome Mikroprozesse in den einzelnen Bearbeitungsbereichen beschrieben, die den Strukturmerkmalen Fehlererfassung, Fehleranalyse und Fehlerkorrektur folgen. Abbildung 5.10 zeigt drei Beispiele solcher Mikroprozesse: Reklamationserfassung im Call-Center, Reklamationsbearbeitung durch einen Serviceingenieur und eine FMEA-Sitzung aus dem Bereich Produktentwicklung. Die Kopplung dieser Mikroprozesse erfolgt über Eskalationen. Die dazu notwendigen Informationen können mittels bilateraler Schnittstellenanalyse ermittelt werden. 1. Bei der zentralen Annahme werden Beschwerden telefonisch von einem Team von Telefonistinnen erfaßt, denen ein Reklamationserfassungswerkzeug zur Verfügung steht. Dieses liefert neben der Dokumentation der Fehlerereignisse auch Unterstützung bei der Analyse und Maßnahmenfindung, so daß einfache Fehlerfälle idealerweise schon

143 5.2 Repository-Technologien für das VVM 125 Abbildung 5.10: Beispiel Reklamationsbearbeitung (ConceptBase-Bildschirmabzug)

144 126 Informationssysteme im Verbesserungsmanagement während des Gesprächs bearbeitet und behoben werden können. Komplexere und unbekannte Fehlerfälle werden an die nächste Kompetenzstufe weitergeleitet. 2. Bei der Reklamationsbearbeitung führt geschultes Fachpersonal, z.b. Serviceingenieure, eine genauere Analyse des Fehlerfalls durch. Dazu werden mit Hilfe eines Fehlermanagementwerkzeugs unternehmensinterne Produkt- und Prozeßdaten mit dem in der ersten Kompetenzstufe erfaßten Fehlerbild in Beziehung gesetzt, wodurch ein neues Fehlerbild entstehen kann. Die definierten Maßnahmen können sowohl reaktiv den reklamierenden Kunden als auch präventiv die eigenen Produktions- und Dienstleistungsprozesse betreffen. Sollte mit den getroffenen Maßnahmen der Fehlerfall nicht prinzipiell erledigt werden können, so wird die nächste Eskalationsstufe angestoßen. 3. Aufbauend auf den bisherigen Fehlerbildern kann nun in der Entwicklung eine Entscheidung getroffen werden, ob ein Re-Design eines fehlerhaften Produktes zu realisieren ist. Dabei können verschiedene Design- und Analysewerkzeuge zum Einsatz kommen. In der Abbildung ist zu erkennen, daß Agenten und Hilfsmittel entweder Prozessen oder Aktivitäten zugeordnet sind. Entsprechend einer vereinbarten Konvention gilt die Zuordnung auf Prozeßebene gleichfalls für alle Unterprozesse, wenn nicht explizit anders vereinbart. Ein FMEA-Werkzeug in der Entwicklung unterstützt also nur den Analyseprozeß in der Entwicklung, während das Fehlermanagementwerkzeug den gesamten Reklamationsbearbeitungsprozeß unterstützt. Abbildung 5.11 stellt die prinzipielle Vorgehensweise bei der Integration von Prozessen über die nutzt- und erzeugt-beziehungen zu Objekten. Im einzelnen beschreibt das Modell folgende Schritte bei der Wissenserzeugung und -nutzung in der Reklamationsbearbeitung. 1. Beim Erfassen der Beschwerde wird ein neuer Fehlerfall angelegt. Teil des Fehlerfalls ist das Beschwerdeformular. Dieses Formular enthält das Fehlerdatenmodell mit Informationen zu Symptomen, Ort und Umständen des Fehlerbildes, soweit sie durch das Telefongespräch zu ermitteln sind. Gleichzeitig werden Verwaltungsinformationen zum Fehlerfall abgelegt (Erfasser, Schlüssel, Zeit usw.) 2. Bei der Analyse wird (möglicherweise), ausgehend vom Beschwerdeformular und einem vorhandenen Fehlerkatalog, eine Maßnahme definiert, die dem Kunden beim direkten Beseitigen oder Managen des Fehlers unterstützen soll. Der Analysevorgang und der Korrekturvorschlag werden dokumentiert. 3. Bei der Eskalation besteht die erste Aufgabe des Serviceingenieurs darin, das Fehlerbild, wie es in der zentralen Annahme erfaßt wurde, in eine spezifische Fehlerbeschreibung umzusetzen. Dies fügt zusätzliche analyserelevante Informationen hinzu. 4. Getroffene Analysen und Maßnahmen werden bei erfolgreicher Bearbeitung im Fehlerkatalog eingearbeitet, der der zentralen Annahme zur Verfügung steht.

145 5.2 Repository-Technologien für das VVM 127 Abbildung 5.11: Verknüpfung der Mikroprozesse (ConceptBase-Bildschirmabzug)

146 128 Informationssysteme im Verbesserungsmanagement 5. Sollte der Fehlerfall bis in die Entwicklung eskaliert werden, kann der Entwicklungsingenieur zusätzliche entwicklungsrelevante Fehlerfallcharakterisierungen hinzufügen. 6. Das geänderte Entwurfskonzept ist das letzte Dokument, welches als Ergebnis der Entwurfsanalyse erzeugt wird. Die hier verfolgte Modellierungsstrategie ist die Minimierung der Informationsbeschreibung. Jedes Dokument taucht nur einmal auf, enthält aber Verweise auf die Prozesse, in denen es genutzt wird. Dies ist zu schwach, um die Art des Informationsaustausches und die Arbeitsabläufe vollständig, d.h. auf der operativen Ebene zu charakterisieren. Abbildung 5.12 ist ein Beispiel für die operative Spezifikation anhand der Attribute Inhalt, Medium und Präsentation, die hier nur schlaglichtartig beleuchtet werden soll. Zunächst ist man in der Lage, festzustellen, wo Medienverwerfungen oder -brüche existieren. So ist das Beschwerdeformular im Beispiel Teil des Fehlerfalls.Während letzterer von einer Datenbank verwaltet wird, ist ersteres auf Papier zu erstellen. Hier wird ein Transformationsschritt notwendig, der das Design eines Informationssystems beeinflußt. 1. Es gibt als Abschluß der zentralen Annahme noch einen Schritt Fehlerfall erstellen, der die Transformation des Beschwerdeformulars und der Datei mit dem Korrekturvorschlag in die Fehlerwissensbasis beschreibt. 2. Beschwerdeformular und Korrekturvorschlag werden als Attribute eines Fehlerfalls betrachtet und entsprechend eingescannt, wobei die Attribute auf die entsprechenden Dateien verweisen. 3. Es wird ein elektronisches Werkzeug zur Beschwerdeerfassung erstellt, das direkt mit der Fehlerwissensbasis verbunden wird. Ein weiteres Beispiel betrifft die Präsentation. In der Reklamationsbearbeitung wird der Maßnahmenvorschlag in einer Freitextbeschreibung festgelegt. Der Fehlerkatalog, in den der Maßnahmevorschlag eingepflegt werden soll, braucht aber strukturierte Informationen zur schnellen Nutzbarkeit im Gespräch. Auch hier besteht wieder die Möglichkeit, einen speziellen Transformationsschritt in den Prozeß zu integrieren, oder aber den Korrekturvorschlag so zu strukturieren, daß die Informationen in den Fehlerkatalog übernommen werden können. Nicht alle Prozesse können direkt über den Austausch von Wissen spezifiziert werden. Es gibt einerseits Situationen in denen Informationen alternativ oder abhängig von anderen Informationen genutzt werden, andererseits gibt es externe Einflüsse, die Prozesse starten oder von diesen beeinflußt werden. Schließlich möchte man auch Folgen von Aktivitäten ohne Informationsaustausch beschreiben können. Abbildung 5.13 zeigt die Einsatzmöglichkeiten der Modellierungskonzepte Aktion, Vor- und Nachbedingung sowie Ereignis zur Spezifikation von Abläufen. Diese Mittel werden wie folgt eingesetzt: 1. Ein Ereignis (Anruf ), dargestellt durch einen Blitz aus heiterem Himmel, startet den Prozeß der Reklamationsannahme. Dies erfolgt aber nur, wenn die Bedingung Leitung frei erfüllt ist. In diesem Fall wird die Aktion Anruf annehmen ausgeführt und die Aktivität Beschwerde erfassen kann beginnen.

147 5.2 Repository-Technologien für das VVM 129 Abbildung 5.12: Strukturierte Informationsflüsse (ConceptBase-Bildschirmabzug)

148 130 Informationssysteme im Verbesserungsmanagement Abbildung 5.13: Arbeitsflüsse (ConceptBase-Bildschirmabzug)

149 5.2 Repository-Technologien für das VVM Da alle Prozesse das Objekt Fehlerfall benutzen, ist ohne nähere Erklärung nicht klar, welcher der jeweilige Nachfolgeprozeß ist. Spezielle Bedingungen, z.b. beschrieben durch Beschwerde eskalieren, verbinden deshalb die Prozesse und definieren eine Reihenfolge. Der Entwurf solcher Bedingungen und die Bestimmung ihres Wahrheitsgehaltes kann auf verschiedene Arten erfolgen: Durch Setzen einer Variablen bis hin zum team-orientierten Verhandlungsprozeß. 3. Aktionen können auch genutzt werden, um Aktivitäten zu beschreiben, die ihre Wirkung außerhalb des Prozesses entfalten. So schickt der Serviceingenieur dem Kunden ein Fax mit einer entsprechenden Fehlerbeseitigungmaßnahme in der Aktivität Reklamation korrigieren. Die verwendeten Sprachmittel decken den Informationsbedarf im Verbesserungsmanagement ab. Die Konzepte, die berücksichtigt wurden, stimmen mit dem Rahmenwerk kooperativer Informationssysteme überein (vgl. Abschnitt 3.3.1). Das Konzept Prozeß erfaßt die formale Organisationsgestaltung. Das Konzept Agent ist in der Lage, die am Prozeß interessierten und beteiligten Mitarbeiter abzubilden und das Konzept Hilfsmittel faßt die verwendeten Werkzeuge. Im Abschlußbericht des Projekts FOQUS [Pfe97, S. 65ff] wurden von den beteiligten Ingenieuren zwei Szenarien mit jeweils drei Eskalationsstufen als Grundlage der prototypischen Systemgestaltung modelliert. Im internen Verbesserungsmanagement wurde das Szenario Zellebene (Werkerselbstprüfung erzeugt Fehlerereignis), Bereichsebene und Betriebsebene gestaltet, im externen Verbesserungsmanagement wurde das Szenario Hotline, Servicetechniker vor Ort, Reparaturwerkstatt modelliert. Als Ausnahmeszenario wurde zusätzlich die Eskalation ins Qualitätsmanagement und die daraus resultierende Einrichtung einer Task-Force betrachtet. Bei der Modellierung der Szenarien, deren Umsetzung bei den Industriepartnern und bei der Realisierung der Prototypen wurden folgende Erfahrungen gemacht. Die unterschiedlichen Kompetenzen und die unterschiedlichen Werkzeuge werden durch die Betrachtung von Mikroprozessen unterstützt. Gleichwohl gehen die Szenarien von der Annahme aus, daß die zu unterstützende Eskalation relativ einfach und stabil ist. Bei der Realisierung in den Unternehmen stellte sich dagegen heraus, daß Fehlerfälle aufgrund unterschiedlichster Faktoren verschiedenste Wege durch Unternehmen nehmen können. Die Komplexität der Modelle ist beträchtlich und steigt, je näher man sich der Systemebene nähert. Deshalb blieben die modellierten Szenarien auf einer generischen Ebene. Aber erst das Zusammenspiel von Mikro- und Makroprozessen auf der Systemebene verdeutlicht die unterschiedlichen Informationsbedürfnisse der Bearbeitungsbereiche und die damit verbundenen Schwierigkeiten der Gestaltung von Informationsflüssen auf operativer Ebene. Erfahrungen aus dem FOQUS-Projekt bei der Durchführung einer Kopplung zwischen PPS und CAQ, die in der ADITEC durchgeführt wurden, bestätigen, daß die Hersteller diesen Prozeß nicht gerade vereinfachen. Die Realisierung der Kopplung deckte auf, daß bewußt Komponenten, die eine Datenbank netzwerkfähig

150 132 Informationssysteme im Verbesserungsmanagement machen sollten, aus der Installation für ein CAQ-System gelöscht wurden. Wenn eine neue Version des CAQ-Systems lizenziert wurde, mußte daher auch der gesamte Rechner an den Hersteller geschickt werden. Zwischen den beiden Systemen sollten Prüfaufträge ausgetauscht werden, die das PPS-System generiert und im CAQ- System durchgeführt werden. Das Reengineering der nicht dokumentierten relationalen Datenbanktabellen umfaßte beim PPS System 276 Tabellen mit insgesamt 7358 Attributen, beim CAQ-System 254 Tabellen mit insgesamt 2337 Attributen. Alle Tabellennamen waren nicht-sprechend, z.b. F1001P, lediglich die Attribute hatten teilweise sprechende Namen, z.b. REF KOSTELLE für Kostenstelle. Um den bilateralen Informationsbedarf zu klären, wurden daher anhand der Programmdokumentation und der Bildschirmmasken die austauschrelevanten Daten ermittelt. Dies waren insgesamt nur sieben Attribute. Um nun heraus zu bekommen, welche Bildschirmeingaben welchen Attributen in den Datenbanken entsprachen, wurde ein Transaktionsmonitor an die Datenbanken angeschlossen. Im nächsten Schritt wurden die Domänen der Attribute verglichen. Keine der Attributdomänen entsprachen einander. Da sowohl Netzwerkkomponenten als auch die Programmierkomponenten von der Herstellern des CAQ-Systems entfernt wurden, mußte das Trader-System die Datenübertragung extern steuern. Dazu wurde auf dem PPS-System ein Skript gestartet, welches SQL-Skripte für das CAQ-System erzeugte. Diese Skripte wurden mit einer Remote Shell auf dem CAQ-Rechner gestartet, der die Daten konvertiert in die entsprechenden CAQ-Tabellen einspielte. Danach konnten im CAQ-System, die vom PPS-System generierten Prüfaufträge ausgeführt werden. Änderungen an den Modellen, die sich durch Überarbeitung, Verfeinerung, Aushandlung, Verbesserung, neue Systeme usw. ergeben, sind nicht zu erkennen. Sowohl die Adaptierung an spezifische Unternehmensbedürfnisse als auch der langfristige Aufbau von Fehlerwissen verlangen eine Nachvollziehbarkeit sowohl der planbaren Prozeßmodellierung als auch der aktuellen Arbeitspraxis. Welche Schlußfolgerungen lassen sich aus den Erfahrungen im Projekt FOQUS ziehen? Eine generell auf alle Unternehmen zutreffende präskriptive Beschreibung von Eskalationen ist nicht zu leisten. Eskalationen verlaufen idealerweise fallbasiert, d.h. durch den Fehler bestimmt, unter den der aktuelle Fehlerfall subsumiert werden kann, üblicherweise aber ad hoc. Das Prozeßwissen muß durch die Ausführung von Prozessen gesammelt, bewahrt und genutzt werden. Das zur Bearbeitung des Fehlerfalls notwendige Wissen ist extrem verteilt und besitzt unterschiedliche Medien und Repräsentationen. Deshalb ist es notwendig, während der Fehlerfallbearbeitung und auch nach abgeschlossener Fehlerfallbearbeitung den Problemkontext zu behalten. Ersteres ist notwendig, damit die Informationen gebündelt am jeweiligen Arbeitsplatz vorliegen, der Bearbeiter sich keine Informationen zusammensuchen muß und er sich aufgrund des bis zu diesem Zeitpunkt gesammelten Wissen in den Fehlerfall hineinversetzen kann. Letzteres ist notwendig, um eine einfache Rekonstruktion des Fehlerfalls, d.h. seiner Eskalationshistorie und des gesammelten Fehlerwissens zu gewährleisten, damit aus Fehlerfällen und deren Bearbeitung gelernt

151 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens 133 werden kann. Jeder Arbeitsplatz muß individuell unterstützt werden. Die Anforderungen an Mitarbeiter im Call-Center unterscheiden sich von der Arbeitsweise von FMEA-Teams. Das notwendige Wissen, die Aktivitäten und die Hilfsmittel müssen konfiguriert werden. 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens Viele Systeme unterstützen die kurzfristige Kommunikation, Kooperation und Koordination in verteilten Unternehmen oder Teams. Manche dieser Systeme sind aufgrund einer Metapher erfolgreich, die den Trainingsaufwand verringert und die Akzeptanz des Systems erhöht, u.a. elektronische Umlaufmappen zur Steuerung gebündelter Informationen [KR91, PS98], strukturierte Informations- und Arbeitsräume für die aufgabenbezogene Kooperation [RG96, BAB + 97] und Sprechakte zur Koordinierung von Workflows [FGHW88]. Diese Ansätze werden für ihre Eignung im VVM untersucht. Dagegen finden sich erst in letzter Zeit Ansätze, welche die Metapher des Unternehmensgedächtnisses explizit nutzen und sie mit kurzfristigen Aufgaben der Kommunikation, Kooperation und Koordination vernetzen [AM95, Hos95, DES96, Pet96, WWT98, vjsr99]. Aus diesen Überlegungen sind auch einige prototypische Systeme entstanden, die teilweise völlige Neuimplementierungen sind, teilweise aber auch auf kommerziell verfügbaren Systemen aufsetzen. Im folgenden werden einige dieser Systeme, die neue Akzente gesetzt haben unter den bisherigen Anforderungen der Wissensorganisation, den dazu notwendigen Prozessen und der Integration untersucht. Dabei geht es nicht darum, einen Ansatz für die Realisierung eines VVM auszuwählen, sondern eine möglichst solide Basis bisheriger Realisierungsideen zu sichten. Die Anforderungen, die bisher erarbeitet wurden, werden hier noch einmal für das Unternehmensgedächtnis-System fokussiert. Die Kürzel dienen der späteren Identifikation der Anforderungen Verknüpfung im Rahmen kooperativer Informationssysteme Das Unternehmensgedächtnis-System (UG-System) sollte sowohl inhaltlich als auch technisch mit dem Unternehmen verknüpft sein (vgl. Abschnitt 3.3.3). (AI1) Inhaltliche Einbettung des UG-Systems in die Arbeitspraxis und Geschäftsprozesse (AI2) Technische Einbettung des UG-Systems in die DV-Landschaft Um das Unternehmensgedächtnis-System nachhaltig in die betrieblichen Abläufe und die Arbeitspraxis einzubetten, ist es notwendig, die explizite Wissensbasis auch explizit mit den

152 134 Informationssysteme im Verbesserungsmanagement betrieblichen Prozessen zu verzahnen. Diese Verzahnung ist nur auf einer sowohl inhaltlichen als auch technologischen Ebene möglich. Sind die Prozesse nur auf einer konzeptuellen Ebene miteinander gekoppelt, kann der tatsächliche Austausch von Wissensrepräsentationen an technischen Unzulänglichkeiten scheitern und gefährdet damit die Akzeptanz und die Effizienz der Kopplung. Ist die Kopplung nur technologisch, z.b. durch intransparente Schnittstellen realisiert, können technologische, personelle oder organisatorische Änderungen die bis dahin effiziente Kopplung zerstören. Erst durch eine sowohl konzeptuelle als auch technologische Verzahnung ist es nun möglich, Wissen dauerhaft zwischen einzelnen Prozessen oder organisatorischen Funktionen auszutauschen. Konzeptuelle Änderungen können nachvollziehbar in der Wissensbasis geplant werden und Änderungen auf der operativen Ebene können registriert und kontrolliert werden. Dabei sollten die bisher diskutierten Eigenschaften der expliziten Wissensbasis die Untersuchung fokussieren, zum einen ist es die Struktur der Wissensbasis selbst, und zum anderen sind es die Mittel zur Strukturierung der Wissensbasis Gestaltung der Wissensbasis Die explizite Wissensbasis des Unternehmensgedächtnis-Systems sollte mit Repository- Technologien realisiert sein und die prozeß- oder aufgabenzentrierte Speicherung von Wissen zulassen, wobei alle Phasen der Wissentransformation unterstützt werden müssen (vgl. Abschnitt 3.5). (AW1) Speicherung des Wissens in einem Repository (AW2) Prozeßbasierte Speicherung des Wissens (AW3) Unterstützung der dynamischen Wissensumwandlung Wie die positiven Erfahrungen aus den Projekten WibQuS und FOQUS zeigten, sind Repository-Technologien geeignet, um die verschiedenen Aufgaben eines Unternehmensgedächnis-Systems zu unterstützten. Der duale Charakter von Fehlerwissen, gleichzeitig Objekt (Fehlerfall) und Prozeß (Eskalation) zu sein, aber auch die Transformation des impliziten Fehlerwissens in explizites Fehlerwissen sollten von einem Unternehmensgedächtnis- System unterstützt werden. Die Erfahrungen bei der Gestaltung eines ersten Unternehmensgedächtnis-Systems für das Verbesserungsmanagement (vgl. Abschnitt 2.6) zeigten, daß gerade die Unterstützung impliziten Wissens für die Nutzbarkeit eines solchen Systems wichtig sind, da nur ein Bruchteil des verfügbaren Wissens abgebildet werden kann Gestaltung mnemonischer Prozesse Ein Unternehmensgedächtnis-System sollte zumindest Prozesse definieren, um neues Wissen zu akquirieren, die Suche und Wiedergewinnung des gespeicherten Wissens zu reali-

153 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens 135 sieren und die Wissensbasis durch die Wissensverwalter zu warten (vgl. Abschnitt 3.3.6). Zusammengefaßt also: (AM1) Prozesse zur Akquisition neuen Wissens (AM2) Prozesse zur Suche und Wiedergewinnung des gespeicherten Wissens (AM3) Prozesse zur Wartung des gespeicherten Wissens Akquisitionsprozesse Das Wissen eines Unternehmens stellt eine dynamische Größe dar, da nicht mehr produzierten Produkten oder nicht mehr genutzten Prozessen zugeordnetes Wissen nicht mehr angewandt werden kann, dagegen durch die immer schneller werdenden Produktlebenszyklen ständig neues Wissen erzeugt werden muß. Die Akquisition soll Prozesse anbieten, die neues Wissen in das Unternehmensgedächtnis-System transferiert, um z.b. die Aktualität des Wissensbestands zu gewährleisten. Hierzu muß jeder Agent die Möglichkeit haben, das Unternehmensgedächtnis-System um neues Wissen zu erweitern. Jede der im folgenden aufgeführten Strategien (ohne Anspruch auf Vollständigkeit) muß im VVM unter einem Kosten-Nutzen-Gesichtspunkt betrachtet werden. Archivarische Akquisition Die archivarische Akquisition beschreibt das Konzept des selbständigen Eintragens neuen Wissens durch Wissensagenten. Geführte Akquisition Die geführte Akquisition erfolgt durch das gezielte Ansprechen eines Wissensagenten, der das gewünschte Wissen besitzt, z.b. kann nach einer erfolglosen Anfrage direkt ein Experte beauftragt werden, fehlendes Wissen einzutragen. Automatische Akquisition Dieses Konzept beschreibt periodische Anfragen an Wissensträger oder andere Wissensquellen, z.b. externe Archive, den Wissensbestand zu erweitern. Such- und Wiedergewinnungsprozesse Auf dem Unternehmensgedächtnis-System müssen Such- und Wiedergewinnungsprozesse definiert werden, die notwendigerweise alle Phasen der Wissenstransformation durchlaufen. Somit kann sich die Suche und Wiedergewinnung nicht allein auf explizit gespeichertes Wissen über Fehler beschränken, sondern muß sowohl die soziale Dimension von Wissen berücksichtigen, um räumliche, zeitliche und konzeptuelle Barrieren zu überwinden, aber auch die aktive Rolle des Fehlerwissens für die Internalisierung beachten. Asking an Expert Anfragen werden direkt an einen Wissensträger, der in dem entsprechenden Gebiet als Experte gilt, weitergeleitet. Anfrage Die Anfrage besteht aus einer möglicherweise durch Eingabemasken und Attribute eingeschränkten Anfrage auf einem Wissensspeicher (z.b. SQL-Anfragen an eine Datenbank).

154 136 Informationssysteme im Verbesserungsmanagement Geführte Suche Dieser Prozeß beschreibt die durch einen Vermittler unterstützte Informationssuche. Der Vermittler kann sowohl menschlich als auch ein intelligenter Softwareagent sein. Filterung Dieses Konzept beschreibt die erweiterte Filterung von Treffern einer Anfrage. Es soll erreicht werden, daß der Benutzer nur die für ihn relevanten Daten erhält. Navigation Die Navigation beschreibt eine Verbindung einzelner Daten in einem Wissensspeicher. Der Benutzer kann über diese Verbindungen in dem Wissensbestand navigieren (z.b. Links im Internet). Abonnement Dieses Konzept beschreibt das automatische periodische Versenden von Informationen aus dem Wissensbestand an einen Benutzer. Hierbei legt der Benutzer fest, zu welchen Themengebieten er den Informationsversand abonnieren will. Aufgabenspezifisches Pushen Falls der Wissensspeicher aufgabenspezifisch organisiert ist, werden Benutzer hierbei automatisch mit Wissen versorgt, welches auf ihre Aufgaben zugeschnitten ist. Wartungsprozesse Ziel der Wartung ist es, die Integrität und Aktualität des Wissensbestandes zu erhalten. Durch die Akquisition wird ständig neues Wissen in die Wissensbasis überführt. Ohne angemessene Integrations- und Validierungsprozesse kann es zu einem Wildwuchs in der Wissensbasis kommen, der nicht beabsichtigt ist. Veraltetes Wissen muß adäquat behandelt werden, wobei ein einfaches Löschen nicht die Anforderungen erfüllt, da die Historie eines Produktes oder Prozesses nicht bewahrt wird. Integration Dieses Konzept beschreibt die (Verwaltungs-)Funktionen, die zum Einfügen von neuem Wissen in den Wissensspeicher ausgeführt werden müssen. Veralterung Das Wissen in einem Wissensspeicher muß regelmäßig auf Aktualität hin überprüft werden. Außerdem muß festgelegt werden, wie mit veraltetem Wissen umgegangen wird. Dieses wird durch Veralterung beschrieben. Reorganisation Die Reorganisation beschreibt die Umstrukturierung des Wissensbestandes. Validierung Dieses Konzept beschreibt die Überprüfung neu erfaßten Wissens auf Gültigkeit hin und den Umgang mit dem als ungültig erkanntem Wissen Analyse und Bewertung existierender Lösungen Die untersuchten Systeme sind der AnswerGarden [AM90, Ack94a, AM96], der auch im FOQUS-Projekt zur einer ersten Strukturierung der Fehlerwissensbasis genutzt wurde (vgl.

155 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens 137 Abschnitt 2.6 und [KJ97, JK98]) und ASSIST [AM95]. Beide Systeme wurden von Ackerman mit entwickelt und haben maßgeblich zur Etablierung des Themas in der Informatik- Forschung beigetragen. Weiterhin werden drei Systeme vorgestellt, die schon Eingang in die Praxis gefunden haben und schon die Verzahnung von kurzfristigen von langfristigen Perspektiven leisten, wenn auch nicht durch eine explizite Notation unterstützt. Diese Systeme sind EULE2 [RMN96, Rei97, vjsr99], WebNet [Sta97, FOS97] und Work- Brain [WW97, WWT97, WWT98, WH98]. Es ist klar, daß noch eine Vielzahl von Systemen existiert, die zumindest Teilaspekte aller Anforderungen erfüllen oder in einigen Anforderungen herausragend sind. Einige wichtige Plattformen wie das BSCW-System [HB97, BAB + 97], der Microsoft Exchange Server [Mic96, Mic99] und Lotus Notes (vgl. [TSMB95, DS97]) werden in Abschnitt untersucht, sind aber natürlich mögliche Plattformen für die Realisierung von UG-Systemen (vgl. auch [BP97, ABH + 98, LMK98]). Andere Systeme wie beispielsweise Information Lens und Object Lens [MGT + 87, LMY88], InfoMaster [DG97], Atelier FX [Poi98], INFOrmer [SOO97], Ariadne [SD97], D3E[SB98] und SOPHIA [AA98] haben die hier betrachteten Systeme beeinflußt oder sind von ihnen beeinflußt worden. Eine vertiefende Betrachtung würde aber den Rahmen der Arbeit sprengen. AnswerGarden Die erste Version des AnswerGarden wurde 1990 am MIT von Ackerman und Malone als [AM90] Datenbank für besonders häufig zum Thema X-Windows gestellte Fragen entwickelt. Der AnswerGarden beruhte auf drei Schlüsselideen: 1. Ein verzweigtes Netz von Diagnosefragen führt den Benutzer zur gesuchten Antwort, falls diese im System vorhanden war. 2. Fragen, die noch nicht im System waren, werden mit einer an einen Experten weitergeleitet. Dieser fügt Frage und Antwort an entsprechender Stelle ein, so daß das System wächst. 3. Das Netz kann bei Bedarf durch Experten neu strukturiert werden. Mit dem AnswerGarden wird implizites Expertenwissen durch entsprechende Fragen externalisiert. Häufig wird die Gartenmetapher des Systems gegen den Wildwuchs des Dschungels Internet gestellt. Das entstehende Unternehmensgedächtnis-System bietet vor allem individuelle Vorteile für Benutzer und Experten. Benutzer können schnell Antworten auf bereits gestellte Fragen finden, ohne auf die Anwesenheit von Experten angewiesen zu sein. Das Vertrauen in die Auskünfte von Experten ist dabei potentiell höher. Experten werden von der Beantwortung relativ einfacher, aber immer wieder auftauchender Fragen entlastet und gewinnen somit Zeit für andere Tätigkeiten. Die Auswirkungen von AnswerGarden wurden in einer Feldstudie mit sechs Organisationen untersucht. In der Studie wurden vier Probleme deutlich [Ack94a, Ack94b].

156 138 Informationssysteme im Verbesserungsmanagement 1. Verlust von kontextabhängiger Information durch Externalisierung: Durch die Externalisierung des impliziten Wissen müssen Fragen allgemeinverständlich beantwortet werden, da das Hintergrundwissen des Fragenden und des Experten oder der Expertengruppe 15 unterschiedlich sind. Allerdings darf die Frage nicht zu verallgemeinernd beantwortet werden, da das konkrete Problem adressiert werden muß. 2. Idealisierungen des Systems durch anthropologisierende Vorstellungen: Durch die Gleichsetzung des Systems mit einem menschlichem Gehirn erwarten Benutzer die jederzeitige und kontextuelle Verfügbarkeit von Wissen. Organisatorische, technische und und konzeptuelle Schwierigkeiten verhindern aber die kontextuelle Abbildung von Wissen in Datenbanken bei gleichzeitiger Verfügbarkeit. Deshalb schlug Ackerman die Begrenzung von Systemen auf Gruppen und Abteilungen vor, da Kontexte klarer definiert und gestellte Erwartungen geringer seien. 3. Politische Bedenken der Experten: Experten fürchten um ihren Arbeitsplatz, weil durch die Externalisierung ihres persönlichen Wissens das Unternehmensgedächtnis-System ihren Platz einnehmen könnte. Dies erschwert die Mitarbeit von Experten, die für den Betrieb der Systeme unerläßlich ist. 4. Trennung von Experten und Nutzern widerspricht den Voraussetzungen des sozialen Netzwerks: Benutzer können Hemmungen haben, Experten relativ einfache Fragen zu stellen und hemmen damit die Entwicklung des Systems. Bewertung und Fazit: Repository: Der AnswerGarden unterstützt die Speicherung von Wissen in einem Repository (AW1), allerdings nur das Erfahrungswissen von Experten. Es bleibt die Frage offen, ob ein Frage- und Antwortnetz auch für sehr große Wissensbestände realistisch ist. Ein solches Netzwerk kann so komplex werden, daß Benutzer bestenfalls nach langer Suche zu dem gesuchten Wissen gelangen (AW3). Das gespeicherte Wissen wird nicht prozeß- sondern fallbasiert abgespeichert und dargestellt (AW2). Mnemonische Prozesse: Die Prozesse auf dem Wissensbestand sind relativ beschränkt. Die Akquisition neuen Wissens kann nur durch explizit bestimmte Experten getätigt werden, die nur durch die Anfrage eines Benutzers ausgelöst wird (AM1). Die Suche nach Wissen ist eine Navigation durch das Frage- und Antwortnetz, so daß der Suchende erst das Netz durchlaufen muß, um zu erfahren, ob das gesuchte Wissen enthalten ist. Bei erfolgloser Suche kann der mnemonische Prozeß Asking an expert aktiviert werden, wodurch der Wissensbestand erweitert wird (AM2). Die Bewahrung der Integrität wird durch die Reorganisation seitens der Experten gesichert. Die Aktualität wird durch neue Fragen und dadurch folgende Erweiterung des Netzes durch 15 Ackerman verwendet hier den Begriff Group Memory

157 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens 139 die Antworten der Experten erreicht. Die Konsistenz kann durch explizite Reorganisation seitens der Experten erreicht werden, wobei die Größe des Netzwerks wiederum eine Rolle spielt (AM3). Einbettung: Das System wird nicht in den Arbeitsalltag integriert, da es lediglich Unterstützung bei offenen Fragen bietet (AI1). Das ursprüngliche System lief auf X Windows Plattformen (AI2). ASSIST ASSIST [AM95] sollte Astrophysiker durch Zusammenfassung von Daten, Software und anderen Informationen, die von den Wissenschaftlern benutzt werden, unterstützen. Entwicklungsziele waren die ständige Erweiterbarkeit und eine einheitliche, flexible und erweiterungsfähige Schnittstelle. ASSIST ist eine Weiterentwicklung des ursprünglichen AnswerGarden und besitzt die Möglichkeit, über standardisierte Eingabemasken Programme, deren Fehler sowie weitere Hinweise und Hilfestellungen einzugeben. Daneben ist ein weiteres Merkmal des Systems, das Living Cookbook, ein informelles Austauschforum für Erfahrungen, Vorgehensweisen usw. Bewertung und Fazit: Repository: ASSIST unterstützt die Speicherung von Wissen über verschiedene Programme und Anwendungserfahrungen mit diesen Programmen (AW1). Es wird sowohl implizites als auch explizites Wissen gespeichert (AW3), und das gespeicherte Wissen ist aufgabenbezogen strukturiert (AW2), wobei dann die Benutzung der Programme die Aufgabe darstellt. Mnemonische Prozesse: Die Realisierung der Akquisitionsprozesse wird nicht erläutert, aber die Erweiterung des Bestandes um die Erfahrungen der Benutzer ist möglich (AM1). Gesucht wird in ASSIST mittels Navigation durch die in einer Baumstruktur angeordneten Programme. Zusätzlich ist, wie schon in AnswerGarden, ein Asking an Expert Prozeß implementiert worden (AM2). Direkte Anfragemöglichkeiten existieren nicht. Die Wartung des Wissensbestands wird in [AM95] nicht erwähnt. Einbettung: ASSIST bietet einheitliche Schnittstellen für unterstützte Programme an, so daß direkt aus dem System die Programme mit den erforderlichen Parametern gestartet werden können (AI1). ASSIST ist immer auf der gleichen Plattform wie die unterstützten Programme vorhanden (AI2). ASSIST sollte das Problem der Kontextualität in AnswerGarden lösen. Das Wissen wird daher prozeßorientiert anhand der Benutzung von Programmen gespeichert. Zwischen den Anwendern wird der Erfahrungsaustausch durch das Living Cookbook gefördert, da hier implizites Erfahrungswissen externalisiert wird. Über den Nutzungsbezug kann der Kontext erhalten werden. Allerdings werden keine anderen Aufgaben unterstützt.

158 140 Informationssysteme im Verbesserungsmanagement EULE2 EULE2 wurde zur Neustrukturierung der Sachbearbeitung bei der Rentenanstalt/Swiss Life ab 1994 entwickelt [RMN96, Rei97] und stellt eine Kombination von Vorgangsbearbeitungs- und Unternehmensgedächtnis-System dar. Der Einsatz des Systems wurde mittlerweile aufgegeben. Ein Sachbearbeiter, der früher nur Experte für eine bestimmte Sorte von Geschäftsvorfällen war, soll nach der Umstrukturierung einem bestimmten Kundenstamm zugeordnet werden und ist somit für alle in diesem Kundenstamm möglichen Geschäftsvorfälle verantwortlich. Da das Expertenwissen sehr komplex ist, soll das System zur Anleitung bei der Bearbeitung der Geschäftsvorfälle dienen, insbesondere dann, wenn der Bearbeiter noch nicht damit vertraut ist. Der Geschäftsvorfall wird nach Auswahl durch den Bearbeiter als Graph dargestellt, wobei Knoten einzelne Aktionen darstellen und Kanten Bedingungen symbolisieren, die erfüllt sein müssen, um darauf folgende Aktionen auszuführen. Aus verschiedenen Datenbanken werden nun benötigte Daten so selbständig wie möglich nachgeladen und weitere Daten vom Bearbeiter erfragt. Aus den gegebenen Daten berechnet EULE2 dann die folgenden Pfade im Graph, läßt aber weitere Aktionen erst nach Erfüllung der aufgestellten Bedingungen zu. Wird ein Endknoten des Graphen erreicht, so ist die Bearbeitung abgeschlossen. Standardaufgaben können von EULE2 autonom durchgeführt werden, wenn alle Voraussetzungen erfüllt sind. Bewertung und Fazit: Repository: Grundlage des Systems ist eine Wissensbasis zur Repräsentation von Geschäftsfällen (AW1, AW2). Unterstützt wird allerdings nur regelbasiertes Wissen, Erfahrungen oder Erkenntnisse der Mitarbeiter bei der Ausführung werden nicht berücksichtigt (AW3). Mnemonische Prozesse: Die Akquisition neuen Wissens erfolgt durch speziell ausgewählte Mitarbeiter (AM1), da EULE2 nicht nur ein Unternehmensgedächtnis-System ist, sondern die Speicherung der Geschäftsprozesse mit deren Ausführung verknüpft. Daher wird die Integrität des Wissens durch systemexterne Mechanismen geschützt. Die Aktualität und Konsistenz wird durch eine zentrale Stelle gewährleistet. Dieser Punkt ist besonders hervorzuheben, da das in EULE2 gespeicherte Wissen für alle Mitarbeiter verbindlich ist (AM3). EULE2 unterstützt die aktive Bereitstellung relevanten Wissens und leitet den Bearbeiter einer Aufgabe an (AM2). Einbettung: Die inhaltliche Verknüpfung ist umfassend realisiert, da das Unternehmensgedächtnis-System mit der Prozeßbearbeitung zusammenfällt (AI1). Die technische Verknüpfung wird nicht näher beschrieben. Da es den Sachbearbeitern des Unternehmens zur Verfügung steht, ist von einer Verknüpfung auf Grundlage der DV- Landschaft des Unternehmens auszugehen. EULE2 unterstützt zielgerichtet Prozesse, ohne das aktive Eingreifen des Benutzers zuzulassen. Dadurch wird eine vollständige Einbettung in den Arbeitsalltag erreicht, jedoch

159 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens 141 reglementiert es den Benutzer stärker als es ihn unterstützt, womit aus der Sicht der kooperativen Informationssysteme eine einseitige Verknüpfung vorgenommen wurde. WebNet WebNet ist das Ergebnis eines 1997 durchgeführten Forschungsprojekts an der University of Colorado. Es dient der Unterstützung des Lernens, des Arbeitens und des Kooperierens in Arbeitsgruppen [FOS97, Sta97]. Der Anwendungsfall war eine Gruppe von LAN-Entwerfern. Beim Einwählen in das System erscheinen auf den Benutzer abgestimmte Informationen, die in dessen Verantwortungsbereich fallen. Dies sind Informationsquellen, Neuigkeiten, eine Mitteilungsliste, eine persönliche Aufgabenliste und eine gruppenweite Aufgabenliste. Weitere Informationen können über ein Suchwerkzeug im Informationsbestand des WebNet gefunden werden. Dieser umfaßt auch s und Lesezeichen. Jeder Benutzer kann das WebNet inhaltlich und strukturell erweitern. Bewertung und Fazit: Repository: Dem WebNet liegt eine zentrale Datenbank zur Speicherung von Wissen über den Aufbau von LAN, auf die alle Klienten zugreifen können (AW1), wobei eine spezielle Orientierung der Speicherung nicht festgestellt werden konnte (AW2). Der Wissensbestand kann neben technologischen Daten auch Erfahrungen und Erkenntnisse von Nutzern enthalten (AW3). Mnemonische Prozesse: Die Akquisition neuen Wissens erfolgt durch Nutzer, die eigene Informationen, Anmerkungen, getätigte s usw. dem existierenden Wissen hinzufügen (AM1). Das System bietet sowohl einen navigierenden Zugriff als auch eine Anfragemöglichkeit an. Weiterhin werden Lesezeichen auf der eigenen Homepage unterstützt (AM2). Das Wissen kann reorganisiert und einzelne Informationen neuformuliert werden, womit eine Erhaltung und die Wiederverwendung in künftigen Aufgaben ermöglicht wird. Prinzipiell ist WebNet ein World Wide Web im Kleinen und unterliegt den gleichen Gefahren des Wildwuchses (AM3). Einbettung: In WebNet werden erforderliche Programme sowie Arbeits- und Mitteilungslisten vernetzt (AI1). Da das System einen Web-Browser als Schnittstelle nutzt, kann eine technische Einbettung erreicht werden (AI2). Das System zeichnet sich durch die gelungene Aufnahme von Programmen aus, die direkt aus dem System heraus aufgerufen werden können. Die Unterstützung von WebNet ist flexibel, wobei die Wissensbestände durch Hinzufügen und Verknüpfung von Wissen ausfransen können. Eine Behandlung dieser Problematik wird nicht erwähnt. WorkBrain Auf dem FLEXWARE-System (vgl. Abschnitt 5.4.4) setzt ein Unternehmensgedächtnis- System auf, mit dem der Benutzer auf die persönlichen und unternehmensbezogenen Gedächtnisse sowie auf Workflow- und Diskussionsgedächtnisse zugreifen kann. Weiterhin wird eine Benutzerschnittstelle zur Modellierung, Konfiguration und Beobachtung von Workflows,

160 142 Informationssysteme im Verbesserungsmanagement zum Anzeigen von Aufgabenlisten und Vorgangsdaten in Form von elektronischen Vorgangsmappen und zum Editieren und Hinzufügen von Dokumenten zur Verfügung gestellt. Dieses System wird WorkBrain genannt [WWT98]. WorkBrain besteht aus einem HTTP-Server (engl.: Hypertext Transfer Protocol), der mit der Workflow-Maschine FLEXWARE gekoppelt ist. Das System generiert für die Benutzer HTML-Seiten (engl.: Hypertext Markup Language), die bei Bedarf Java-Applets enthalten können. Mit herkömmlichen Browsern kann über eine Login-Seite auf das System zugegriffen werden. Eine Kontrollseite bietet die obengenannten Gedächtnisse an, untergliedert in die Bereiche Persönliches, Organisation, Workflow und Diskussion. Ausgehend von diesen Bereichen kann auf die gesamte Systemfunktionalität über HTML-Seiten zugegriffen werden. Repository: Workflows werden in einer fallbasierten Wissensbasis gespeichert, zusätzlich kann auf eine Organisationswissensbasis und eine Dokumentenbasis zugegriffen werden (AW1,AW2). Die Unterstützung der Wissensumwandlung erfolgt primär durch die fallbasierte Rekonfiguration von Workflows, wodurch ein erfahrungsbasierter Verbesserungszyklus initiiert wird, weiterhin durch die Pflege einer Diskussionsbasis, die Möglichkeit, persönliche Speicher zu pflegen, durch die Generierung von Wissenslandkarten aus dem System heraus und einen Know-How Counter, der hochgezählt wird, sobald ein Nutzer einen Workflow ausführt (AW3). Mnemonische Prozesse: Neues Wissen wird primär durch die Konfiguration und Ausführung von Workflows in das System gebracht (AW1). Daneben existieren noch Schnittstellen zu anderen Systemen. Neben der Navigation durch die verschiedenen als HTML-Seiten realisierten Listen, Foren und Verzeichnisse ist die zentrale Suchmöglichkeit die CBR-Komponente, mittels derer auf die abgespeicherten Workflowausführungen zugegriffen werden kann (AM2). Die Wartung des Wissens erfolgt einerseits über die CBR-Komponente, andererseits über die Rekonfiguration von Workflows. Da die fallbasierte Speicherung der Workflow-Ausführung durch eine CBR-Komponente erfolgt, wird dieses Wissen konsistent abgespeichert (AM3). Einbettung: Die inhaltliche Einbettung ist durch die Ausrichtung auf die Geschäftsprozesse sowie der Integration weiterer Wissensquellen gelungen (AI1). Die technische Integration ist auf die zugrundeliegende Implementierung von FLEXWARE/BusinessFlow 3.3 ausgerichtet. Die Hauptfunktionalitäten konnten auf Java Applets abgebildet werden (AI2). EULE2 und WorkBrain sind die einzigen Unternehmensgedächtnis-Systeme, die explizit die Ausführung von Geschäftsprozessen unterstützen. Während der Schwerpunkt von EULE2 die Anleitung des Sachbearbeiters ist, unterstützt WorkBrain in besonderem Maße die erfahrungsbasierte Verbesserung der Workflow-Definitionen. Zusammen mit der gelungenen inhaltlichen und technischen Einbettung zeichnet dies WorkBrain aus. Allerdings werden mnemonische Prozesse nur implizit genutzt, aber nicht wiederum explizit modelliert, wodurch die eingangs diskutierten Probleme auftreten können.

161 5.3 Nachhaltige Bewahrung aktivitätsorientierten Wissens 143 Die Bewertung der verschiedenen Systeme hinsichtlich der aufgestellten Anforderungen werden in Tabelle 5.7 zusammengefaßt dargestellt. AW1 AW2 AW3 AM1 AM2 AM3 AI1 AI2 AnswerGarden Assist ? +? ++ + Eule o WebNet WorkBrain : gut umgesetzt o: teilweise erfüllt?: keine Angabe +: erfüllt -: nicht umgesetzt Tabelle 5.7: Untersuchte Unternehmensgedächtnis-Systeme Anforderungen Das WebNet-Projekt hebt die Bedeutung eines zentralen, mehrbenutzerfähigen Datenbank- Systems zur Verteilung des Wissens an die Benutzer (AW1). Die Vorteile der prozeßbasierten Speicherung des Wissens wurde von EULE2 hervorgehoben. Das Wissen kann sofort auf die durchzuführende Aufgabe angewendet werden. In ASSIST werden Benutzererfahrungen bei der Durchführung von Aufgaben in das System übertragen. Der AnswerGarden zeigt deutlich, wie die Kommunikation zwischen den Experten und den Wissenssuchenden unterstützt werden kann, auch wenn beide Parteien örtlich und zeitlich getrennt sind (AM2). In EULE2 wird Wissen aktiv angeboten. Zur gewählten Aufgabe wird das vorhandene und vernetzte Wissen automatisch angezeigt (AM2). Es wird aber deutlich, daß in keinem untersuchten System eine wirklich gute Akquisition realisiert wurde. Diese Systeme lassen entweder keine Benutzereingaben zu oder die Eingaben führen zu einem Wildwuchs innerhalb des Wissensbestands. Daher sollte die Akquisition auf Grundlage der Prozesse des Verbesserungsmanagements erfolgen. Die inhaltliche Verknüpfung wurde durch ASSIST, EULE2 und WorkBrain verwirklicht. In diesen Systemen können benötigte Werkzeuge direkt aus dem System heraus gestartet werden, allerdings nur unter der Voraussetzung, daß das System adaptiv neue Programme einbinden kann (AI1). WebNet und WorkBrain demonstrieren, wie die technische Verknüpfung mittels plattformunabhängigen Werkzeugen realisiert werden kann. Auf diese Weise sind sie in heterogenen DV-Landschaften einsetzbar und passen sich den Änderungen auf der Systemseite an. Die Untersuchung zeigt, daß der Einsatz der Systeme auf bestimmte Gebiete oder Prozesse beschränkt ist. Der hier verfolgte metamodell-gestützte Ansatz soll das Repository prozeßorientiert strukturieren. Eine sowohl inhaltliche als auch technische Verknüpfung mit der Arbeitspraxis und der Systemlandschaft soll durch das Unternehmensgedächtnis-System gefördert werden. In der untersuchten Literatur finden sich keine Ansätze, die explizit langfristige Perspektiven der Wissensorganisation, wie sie von mnemonischen Prozessen unterstützt werden, und

162 144 Informationssysteme im Verbesserungsmanagement kurzfristige Perspektiven, wie sie von CSCW und/oder WFMS unterstützt werden, vereinen und eine explizite Verzahnung zwischen diesen Perspektiven herstellen. Eine Architektur, die auf dem im Abschnitt 6.2 realisierten Metamodell ein Gedächtnis für das VVM realisiert, verbindet mnemonische Prozesse der Wissensorganisation mit Arbeitsflüssen. 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen Zunächst werden einige Grundbegriffe des Software-Konfigurationsmanagements (SKM) eingeführt, die für die Untersuchung einzelner Ansätze notwendig sind [CW98]: (Software-)Objekt: Identifizierbare Entität, die durch das Software-Konfigurationsmanagement verwaltet wird. Es gibt atomare und zusammengesetzte Entitäten. Version: Implizite oder explizite Instanz eines versionierten Objekts. Es wird zwischen Revisionen (historische Versionen) und Varianten (parallele Versionen) unterschieden. Konfiguration: Konsistente und vollständige Version eines zusammengesetzten Objekts. Produktraum: Beschreibt die Struktur eines (Software-)Objekts ohne Berücksichtigung der Versionierung. Verschiedene Beziehungstypen zwischen Objekten (Kompositionsund Abhängigkeitsbeziehungen) werden berücksichtigt. Versionsraum: Legt die zu versionierenden Objekte, die Gemeinsamkeiten aller Versionen eines Objektes und ihre Deltas (Unterschiede zwischen ihnen) fest. Ein versioniertes Objekt ist eine Zusammenstellung einer Menge V von Versionen. Die Funktionalität der Versionskontrolle ist stark von der Art beeinflußt, wie V definiert ist. Extensionales Versionieren bezeichnet die einfache Aufzählung der zu V gehörenden Versionen. Es wird die Wiederherstellung früherer Versionen unterstützt. Versionen werden explizit verwaltet. Jede Version hat in der Regel eine Versionsnummer. Intensionales Versionieren bietet umfassendere Unterstützung für größere Versionsräume durch eine flexible automatische Konstruktion von Versionen. V wird durch ein Prädikat definiert, das die auszuwählenden Elemente festlegt. Versionen sind in diesem Fall implizit. Das Prädikat gibt Bedingungen an, die für alle Elemente von V erfüllt sein müssen. Konfigurationen werden entsprechend einer Anfrage konstruiert. Zur Integration von Produkt- und Versionsraum gibt es drei Möglichkeiten: 1. Die Produktstruktur wird zuerst ausgewählt, anschließend werden die Versionen der Komponenten festgelegt. Dadurch kann die Struktur nicht versioniert werden. 2. Gegenstück dazu ist die Auswahl der Version als erstes, durch die die Komponentenversionen eindeutig bestimmt sind. Auf diese Weise lassen sich verschiedene Versionen in unterschiedlicher Weise strukturieren.

163 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen Als dritte Möglichkeit kann die Integration vermischt erfolgen. Versionen und Produkte werden in alternierender Form selektiert. Die Granularität bestimmt, ob jede Komponente des Produktes einzeln oder zusätzlich die Produkthierarchie oder das Produkt als Ganzes versioniert wird Versionierung der Vorgangsdurchführung Nachfolgend sind die Anforderungen an die Versionierung von Vorgangsmappen aufgelistet. Ihre detaillierte Erläuterung erfolgt im Anschluß. (AV1) Grobgranulares Versionieren: Erzeugen von Vorgangsmappenversionen mit Verweisen auf die zugehörigen Inhaltsdatenversionen und historischen Beziehungen (AV2) Feingranulares Versionieren: Erzeugen von Inhaltsdatenversionen (AV3) Erzeugen beliebig vieler Varianten zur Unterstützung von parallelem Arbeiten (AV4) Zusammenführen von Vorgangsmappenversionen unter Berücksichtigung verschiedener Inhaltsdatentypen Vorgänge sollen parallel bearbeitet werden können. Daher müssen verschiedene Versionen einer Vorgangsmappe verwaltet werden. Jeder Bearbeiter erhält eine eigene Version der Mappe, deren Inhalte er ändern kann. Auf diese Weise lassen sich Inkonsistenzen in der Mappe vermeiden, da immer nur ein Bearbeiter schreibend Zugriff auf eine Version hat. Durch die Versionierung lassen sich Informationen zur Nachvollziehbarkeit festhalten. Jeder einzelne Bearbeitungsschritt wird dadurch von den übrigen getrennt, so daß sich Defizite im Ablauf leicht lokalisieren lassen. Für die Betrachtung der Historie einer Mappe müssen die einzelnen Versionen rekonstruierbar sein. Die von einer Vorgangsmappe erzeugten Versionen spiegeln das jeweils aktuelle Fehlerbild wider, wodurch der zeitliche Ablauf der Fehlerbearbeitung dokumentiert wird. Diese historischen Versionen werden Revisionen genannt. Der Zeitpunkt ist durch die Weiterleitung einer Mappe bestimmt, da nach dem Verschicken keine Änderungen mehr möglich sind. Die Versionierung der Mappe als Ganzes wird im folgenden als grobgranulares Versionieren bezeichnet. Zusätzlich wird feingranulares Versionieren durchgeführt, das sich auf die einzelnen Inhalte einer Mappe bezieht. Eine Vorgangsmappe enthält neben den vorgangsbezogenen Daten auch Informationen zum Ablauf des Vorgangs. Jedes Inhaltsdatum wird einzeln versioniert, um so kleine Einheiten zur Verfügung zu haben, die ein ressourcensparendes Replizieren von Mappenversionen möglich machen. Die Replikation ist notwendig zur Unterstützung von verteiltem Arbeiten. Beim Replizieren müssen somit nur die neu erzeugten Inhaltsdatenversionen berücksichtigt werden und nicht die Mappenversion als Ganzes.

164 146 Informationssysteme im Verbesserungsmanagement Für das parallele Arbeiten ist es erforderlich, von einer Mappe und ihren Inhaltsdaten beliebig viele Varianten erzeugen zu können. Das Zusammenführen ist notwendig, um eine vollständige Version der Mappe zur Dokumentation der gesamten Bearbeitung zu erhalten. Wie sich die Inhaltsdaten zusammenführen lassen, hängt von ihrer Art ab. Für Daten, die nur einen eindeutigen Wert zulassen, ist eine Interaktion mit dem Bearbeiter vorzusehen, damit dieser entscheiden kann, welcher der parallel existierenden Werte in einer konkreten Situation am sinnvollsten ist. Auf das Verbesserungsmanagement bezogen zählt die Klassifikation eines Fehlers zu diesem Wertetyp, denn die Art eines Fehlers ist eindeutig festzulegen. Numerische Werte (Kosten, Bearbeitungsdauer eines Fehlers) können durch Addition zusammengeführt werden. Daten, die sich aus mehreren gleichartigen Elementen zusammensetzen, lassen sich beim Zusammenführen verschmelzen. Beispiele hierfür sind Listen von Fehlersymptomen und -orten. In Abbildung 5.14 sind die Anforderungen für die verschiedenen Datentypen graphisch dargestellt. Eskalationen werden durch Replikationen zwischen zwei Arbeitsplätzen abgebildet. a) eindeutige Werte b) numerische Werte c) Listen Va Benutzerinteraktion Vb Va Addition Vb Va Anfügen Vb Va Vc Vc Legende: I(V) = Inhalt von V mit I(V c) = I(V a ) + I(V b) mit I(V c) = I(V a ), I(V b) Abbildung 5.14: Zusammenführen verschiedener Datentypen Aufgaben- und rollenspezifische Unterstützung Zunächst eine Übersicht über die Anforderungen an die Konfiguration: (AK1) Rollenspezifische Bindung der Vorgangsmappe beim Laden (AK2) Umsetzung der Rollen am lokalen Arbeitsplatz (rollenspezifische Sicht) (AK3) Berücksichtigung von rollenspezifischen (Zugriffs-)Rechten auf Vorgangsmappen (AK4) Konfiguration von Vorgangsmappenversionen: Auswahl der zugehörigen Inhaltsdatenversionen Informationsüberfrachtung stellt insbesondere bei der Vorgangsbearbeitung unter Verwendung von elektronischen Vorgangsmappen ein Problem dar, weil in den Mappen jede zum

165 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen 147 Vorgang gehörende Information abgelegt wird. Für den einzelnen Bearbeiter bedeutet dies, daß er aus einem großen Informationsangebot die für ihn relevanten Teile heraussuchen muß, bevor er sich seiner eigentlichen Aufgabe zuwenden kann. Je mehr Informationen vorhanden sind, um so größer ist die Gefahr, daß wesentliche Einzelheiten für die Bearbeitung übersehen werden. Abhilfe schafft ein Rollenkonzept, durch daß eine rollenspezifische Konfiguration einer Vorgangsmappe möglich wird. In Abhängigkeit von den Kompetenzen einer Rolle werden nur die zum jeweiligen Bearbeiten notwendigen Inhalte einer Mappe dem Rolleninhaber gezeigt, alle übrigen werden ausgeblendet. Dadurch ergeben sich rollenspezifische Sichten auf eine Vorgangsmappe. Ebenso werden Rechte mit Rollen verknüpft, so daß Bearbeiter nur entsprechend der Eskalation Operationen auf Mappen durchführen können. Zur arbeitsplatzspezifischen Unterstützung läßt sich über die Rolle festlegen, welche Hilfsmittel zur Durchführung der Vorgangsbearbeitung angeboten werden sollen. Da nicht alle Hilfsmittel an jedem Arbeitsplatz verfügbar sind, ist es notwendig, das Angebot auf den jeweiligen Arbeitsplatz abzustimmen. Die Replikation von Vorgangsmappen kann wegen der rollenspezifischen Konfiguration effizienter realisiert werden. Neben dem Rollenaspekt spielt die Zusammenstellung einer Version bei der Konfiguration einer Mappe eine wichtige Rolle. Für jedes einzelne Inhaltsdatum ist festzulegen, welche Version davon zu einer Vorgangsmappenversion gehört. Die Konfiguration von Mappenvarianten, die bei der parallelen Bearbeitung einer Mappe notwendig wird, entspricht dem Vorgehen bei Revisionen. Varianten unterscheiden sich nur dadurch von Revisionen, daß sie gleiche Vorgängerversionen haben. Zusammengeführte Varianten, die zwei oder mehr Vorgängerversionen besitzen, entsprechen wieder Revisionen. Der Spezialfall Deeskalation ruft ebenfalls keine weiteren Anforderungen an die Konfiguration hervor, weil Primär- und Sekundärkopie lediglich unterschiedlichen Versionen einer Mappe entsprechen. Die Anforderungen an die Konfiguration sind in Abbildung 5.15 graphisch veranschaulicht Replikation Überblick über die Anforderungen an die Replikation von Vorgangsmappen: (AR1) Datenabgleich zwischen den lokalen Arbeitsplatzdatenbanken und der zentralen Server-Datenbank (AR2) Rollenspezifische Replikation: Nur die für die jeweilige Rolle interessanten Informationen werden repliziert, überflüssiger Datentransfer ist zu vermeiden. (AR3) Neue Mappenversionen sollen vorherigen Bearbeitern unmittelbar nach dem Weiterleiten bzw. Schließen zur Verfügung stehen. (AR4) Netzunabhängiges Arbeiten

166 148 Informationssysteme im Verbesserungsmanagement Abbildung 5.15: Rollenspezifische Konfiguration Die Vorgangsbearbeitung findet räumlich verteilt statt. Die einzelnen Komponenten eines verteilten Systems agieren weitgehend autonom, d.h. Fehler, z.b. schlechte Netzwerkverbindungen und Systemausfälle, wirken sich weniger stark aus. Benötigte Daten zur Vorgangsbearbeitung müssen dezentral zur Verfügung stehen. An den lokalen Arbeitsplätzen kann so unabhängig gearbeitet werden. Der Server wird während der eigentlichen Arbeit nicht benötigt, sondern nur zum Datenabgleich. Ein weiterer Vorteil ergibt sich aus dem zeitweise netzunabhängigen Arbeiten für den mobilen Einsatz des Systems durch z.b. Außendienstmitarbeiter, die nur von Zeit zu Zeit eine Verbindung zum Server aufbauen müssen, um den Datenbestand zu synchronisieren. Die Replikation von Mappenversionen an alle vorherigen Arbeitsplätze erhöht die Transparenz des Bearbeitungsstandes eines Vorgangs. Die Bearbeiter haben so die Möglichkeit, alle Vorgänge, an denen sie beteiligt waren, zu beobachten. Entsprechend des Gesamtansatzes existieren ein zentrales Repository im Server und lokale Repositories an den einzelnen Arbeitsplätzen. Die Replikation muß somit zwischen diesen Repositories stattfinden. Neue Vorgangsmappen werden in das Repository des nächsten Bearbeiters kopiert und nach Abschluß der Bearbeitung an das Server-Repository zurückgeleitet. Neu erzeugte Versionen werden an alle vorherigen Bearbeiter verteilt. Durch die Konfiguration der Vorgangsmappen läßt sich die Replikation effizienter realisieren. Es müssen nur Inhalte, die für die betreffende Rolle sichtbar sind, bei der Aktualisierung von Sekundärkopien an lokalen Arbeitsplätzen berücksichtigt werden. Dadurch wird der Datentransfer beim Replizieren auf ein Mindestmaß reduziert.

167 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen Analyse und Bewertung existierender Lösungen Hinsichtlich der Anforderungen an die Konfiguration, Versionierung und Vorgangsdurchführung replizierter elektronischer Vorgangsmappen werden das BSCW-System, der Microsoft Exchange Server, ProMInanD, Lotus Notes, PoliTeam und FLEXWARE untersucht (vgl. Abschnitt 4.4.3). Diese Systeme wurden aus der Vielzahl der Systeme aus diesen Bereichen ausgesucht, weil sie die Versionierung und Konfiguration der Vorgangsdurchführung zumindest in Ansätzen unterstützen. ProMInanD Das System ProMInanD [Kar94] ist von der IABG, Ottobrunn, innerhalb des ESPRIT- Projektes Extended Office Process Migration with Interactive Panel Displays entwickelt worden. Mittelpunkt des Systems bildet das Konzept der elektronischen Vorgangsmappe, das bereits im Abschnitt erläutert wurde. Zu einer Beschreibung gehört die Vorgangsspezifikation und der Status (aktueller Bearbeitungszustand, beteiligte Bearbeiter und Historie aller bisherigen Schritte sowie Informationen über verwandte Vorgänge). Der Inhalt setzt sich bei ProMInanD aus Hauptteil, Anhang und Haftzettel zusammen. Im Hauptteil sind die zur Bearbeitung zwingend notwendigen Dokumente enthalten. Im Anhang finden sich weitergehende Informationen. Der Haftzettel dient zur informellen Kommunikation, über ihn können Hinweise wie Bitte um Rücksprache an die nächsten Bearbeiter übermittelt werden. Bewertung und Fazit: Versionierung: Die Vorgangssteuerung geschieht zentral, wobei Vorgangsspezifikationen unmittelbar nach Beendigung eines Schritts, jedoch vor dem Verlassen einer Bearbeitungsstation, ausgewertet werden. Danach erfolgt der Versand an die zentrale Steuerung, die den Vorgang an einen Bearbeiter mit der geforderten Rolle weiterleitet. Parallelbearbeitung wird durch voneinander abhängige parallele Vorgänge unterstützt. Die Art der Abhängigkeit kann dabei sehr unterschiedlich sein: Ein abhängiger Vorgang kann freilaufend sein oder sein Ergebnis an den startenden Vorgang zu einem festen oder variablen Zeitpunkt zurückliefern. Jedoch ist keine Versionierung von Vorgangsmappen vorgesehen (AV1, AV2). Varianten von Mappen (AV3, AV4) können nicht erzeugt werden. Konfiguration: Die Parallelbearbeitung in ProMInanD beschränkt sich daher auf verschiedene Teilaspekte, deren Ergebnisse bei Bedarf zusammengeführt werden können. Konkurrierendes Arbeiten an einem Vorgang mit dem Ziel, bessere Gesamtergebnisse zu erzielen, ist nicht vorgesehen. Eine Konfiguration von Vorgangsmappenversionen (AK4) ist damit nicht notwendig. Zur Definition von Zuständigkeiten ist ein Rollenkonzept vorgesehen. In einer Organisationsdatenbank werden Organisationseinheiten inklusive ihrer hierarchischen Beziehungen, ihrer Stellen und ihrer organisatorischen Funktionen festgelegt, wobei die beiden letzteren als Rollen bezeichnet werden. Für

168 150 Informationssysteme im Verbesserungsmanagement jeden Bearbeitungsschritt wird festgelegt, von welcher Rolle er durchgeführt werden darf (AK3). Für die eigentliche Bearbeitung stehen Anwendungsprogramme zur Verfügung. Informationen über deren Art sind im Vorgang enthalten. Jedoch ist in der Vorgangsbeschreibung nicht festgelegt, welches Programm an einem speziellen Arbeitsplatz angeboten wird, sondern die Organisationsdatenbank gibt Auskunft über die an den Arbeitsplätzen verfügbaren Programme. Dadurch wird eine vorgangsspezifische Konfiguration des Arbeitsplatzes realisierbar, Rollen werden hierbei aber nicht berücksichtigt (AK2). Zur Vermeidung von Informationsüberfrachtung werden Bereichsgrenzen für die einzelnen Bearbeiter genutzt, die nur einen Teil des Gesamtablaufs sichtbar machen. Die Inhalte eines Vorgangs werden jedoch nicht mit Hilfe einer Sichtendefinition eingeschränkt (AK2). Replikation: Die Verteilung von Vorgängen wird durch einen globalen Migrationsserver (GMS) übernommen, um den lokale Migrationsserver (LMS) gruppiert sind. Die LMS bieten Unterstützung für die Vorgangsbearbeitung; sie interpretieren und manipulieren Vorgangsbeschreibungen und führen automatisch Schritte aus. Für Anwendungsprogamme stellen sie eine Schnittstelle zum Datenaustausch zur Verfügung. Weiterhin realisieren sie die Weiterleitung von Vorgängen an den GMS über einen Store&Forward-Mechanismus. Als Schreibtischwerkzeuge werden ein Formularkasten (Schemadefinitionen initiierbarer Vorgänge), ein Eingangskorb (wartende Vorgänge), ein Aktenstapel (in der Bearbeitung unterbrochene Vorgänge), ein Ausgangskorb (mit Spuren von weitergeleiteten Vorgängen) und Vorgangsmappen (zur Bearbeitung) angeboten. Die Spuren weitergeschickter Vorgänge im Ausgangskorb ermöglichen es jedem Bearbeiter, jederzeit Informationen über den Aufenthaltsort und den Bearbeitungszustand dieser Vorgänge abrufen zu können. Der globale Bearbeitungszustand enthält dafür den initiierenden, den dynamisch nächsten und den dynamisch letzten Schritt. Der komplette Vorgang mit allen Inhalten kann jedoch nicht beobachtet werden. Replikation von Vorgängen findet nicht statt (AR1-AR3). Über die Möglichkeit von netzunabhängigem Arbeiten wird in [Kar94] keine Aussage getroffen. Jedoch ist zu vermuten, daß dies nicht vorgesehen ist, weil die LMS auf die globale Organisationsdatenbank zugreifen. Ein wesentlicher Aspekt in ProMInanD sind Abweichungen von vordefinierten Wegen (Schritte delegieren, einfügen, verschieben, überspringen, etc.). Diese Laufwegemodifikationen betreffen nur konkrete Vorgänge, jedoch keine Vorgangsschemata. Von den hier untersuchten Systemen setzt ProMInanD den Vorgangsmappenansatz am konsequentesten um. Jedoch werden die Aspekte des parallelen Arbeitens und der rollenspezifischen Konfiguration nur ansatzweise realisiert. Ein Versionierungsmechanismus, mit dem u.a. Varianten von Mappen angelegt werden können, fehlt für umfassendes paralleles Arbeiten. Ebenso bleiben ohne Versionierung die einzelnen Bearbeitungsschritte nicht nachvollziehbar. Eine adäquate Sichtendefinition zur Vermeidung von Informationsüberfrachtung fehlt. Gut gelöst ist hingegen die Verwaltung von Rollen, Vorgangsschemata und Applikationen in einer Organisationsdatenbank. Eine Replikation von Vorgangsmappen wird nicht durchgeführt.

169 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen 151 POLITeam: LinkWorks für die Vorgangsbearbeitung DasPoliTeam-System der GMD ist zur Vorgangssteuerung in deutschen Bundesministerien entwickelt worden [KMS + 95, PK96]. PoliTeam ermöglicht eine flexible Workflow-Steuerung von Dokumenten bei gleichzeitiger Aufzeichnung ihrer Historie, um die Entstehung nachvollziehbar zu machen. Dies ist für Dokumente mit politischem Inhalt von besonderer Bedeutung, weil Verantwortlichkeiten eindeutig feststellbar sein müssen. Zur Authentifizierung von Dokumenten werden elektronische Unterschriften eingesetzt. Um die Vorgangsbearbeitung zu beschleunigen, wird paralleles Arbeiten in eingeschränkter Form unterstützt. Ein grundlegendes Konzept bilden elektronische Vorgangsmappen, die für die Datenhaltung und den Transport von Vorgängen verwendet werden. PoliTeam wurde mit Hilfe des kommerziellen Systems LinkWorks der Firma Digital implementiert. LinkWorks stellt sogenannte Container-Klassen zur Verfügung, die beliebige Dokumente und weitere Container- Klassen aufnehmen können. In PoliTeam wurden sie zur Implementierung der elektronischen Vorgangsmappen herangezogen. Bewertung und Fazit: In LinkWorks ist eine Versionskontrolle für Dokumente vorgesehen. Im PoliTeam-Projekt war es jedoch erforderlich, bei der Weitergabe eines Vorgangs den jeweiligen Dokumentenstand festzuhalten und mit einer elektronischen Unterschrift zu autorisieren. Dazu wurde das System SecuDE(Security Development Environment) zum elektronischen Unterzeichnen herangezogen. Die Realisierung in PoliTeam sieht vor, daß die einzelnen Unterzeichner eines Dokuments zusammen mit Namen, Datum, Uhrzeit und Kommentar in einer Liste aufgeführt werden; zu jedem Eintrag kann die zugehörige Dokumentenversion abgerufen werden. Versionierung: Dafür werden verschiedene Versionen des Dokuments gespeichert; welcher Versionierungsmechanismus hierbei zum Einsatz kommt, ist in [PK96] nicht angegeben. Grobgranulares Versionieren (AV1) kann auf diese Weise umgesetzt werden. Inwieweit feingranulares Versionieren (AV2) unterstützt wird kann nicht beurteilt werden. Parallele Bearbeitung ist nur eingeschränkt möglich, weil keine Varianten von Vorgangsmappen erzeugt werden können (AV3, AV4). Für die parallele Bearbeitung von Mappen steht ein Werkzeug zur Nutzung eines gemeinsamen Arbeitsbereichs zur Verfügung: Der aktuelle Bearbeiter einer Mappe übernimmt eine Koordinationsfunktion. Nur er kann die gemeinsame Nutzung mit anderen Bearbeitern initiieren, die ihrerseits die Vorgangsinhalte sehen und Dokumente hinzufügen können. So wird ein gewisses Maß an Parallelität erreicht. Konfiguration: Rollen in PoliTeam dienen nur zur Dokumentation der Bearbeitung. Jeder Rolle wird eine Farbe für Anmerkungen zu einem Dokument zugeordnet, so daß in einer Mappe sofort ersichtlich ist, von welcher Rolle ein Dokument bearbeitet worden ist. Über Zugriffsrechte können Vorgangsmappen geschützt werden, indem festgelegt wird, wer Dokumente und Adressaten hinzufügen oder löschen darf. Für Dokumente kann angegeben werden, von wem sie gelesen, verändert oder gelöscht werden dürfen

170 152 Informationssysteme im Verbesserungsmanagement (AK3). Rechte sind jedoch nicht an Rollen gebunden. Eine benutzerspezifische Arbeitsplatzkonfiguration ist in LinkWorks möglich [KMS + 95]. Jeder Benutzer kann nach seinen Vorlieben die Struktur und den Inhalt seines Arbeitsplatzes verändern. Jedoch geschieht dies nicht rollenabhängig. Weder die Sicht auf eine Vorgangsmappe noch für die Bearbeitung notwendige Hilfsmittel können am Arbeitsplatz umgesetzt bzw. angeboten werden (AK1, AK2). Die Konfiguration der Versionen (AK4) kann aus den Unterlagen nicht beurteilt werden. Replikation: In PoliTeam werden Vorgangsmappen als elektronische Nachrichten verschickt. Beim Absenden wird ein Schattenobjekt einer Mappe angelegt, über das der aktuelle Bearbeitungsstand ermittelt werden kann. Das Schattenobjekt stellt eine Referenz auf die zugehörige Mappe zur Verfügung, über die der aktuelle Status der Mappe abgefragt werden kann. Weitere Informationen werden in PoliTeam aus Datenschutzgründen nicht sichtbar gemacht. LinkWorks bietet jedoch die Möglichkeit, zusätzliche Details darzustellen. Die Schattenobjekte machen zwar das Beobachten vonmappenmöglich, aber an den lokalen Arbeitsplätzen existieren keine Kopien, die laufend aktualisiert werden (AR1-AR3). Es werden keine Aussagen darüber getroffen, ob netzunabhängiges Arbeiten (AR4) unterstützt wird. Über die Form der Datenhaltung werden keine Angaben gemacht. In PoliTeam werden Nachvollziehbarkeitsinformationen sehr gut aufgezeichnet, so daß jeder Bearbeitungsschritt genau dokumentiert ist. Paralleles Arbeiten wird zwar ermöglicht, aber es werden keine Varianten von Vorgangsmappen angelegt. Infolgedessen muß ein Bearbeiter die Koordination übernehmen. Ein rollenspezifische Konfiguration der Mappen ist nicht vorgesehen. Es fehlt ein Replikationsmechanismus, der das verteilte Arbeiten durch dezentrale Datenhaltung verbessern kann. Insgesamt gesehen erfüllt das PoliTeam-System nur sehr wenige der Anforderungen an die Versionierung, Konfiguration und Replikation von Vorgangsmappen. FLEXWARE FLEXWARE [WWT97] ist eine prototypische Workflow-Maschine, mit der konfigurierte, flexible Workflows gesteuert werden können. FLEXWARE ist in das kommerzielle System WFMS BusinessFlow 3.3 der COI GmbH (Consulting for Office and Information Management) integriert worden. Um der Starrheit und der unhandlichen Größe von Workflows zu begegnen, wird eine Zerlegung in kleinere Einheiten (Module) vorgenommen, die fallspezifisch für einen konkreten Vorgang zusammengesetzt werden können. Historische Workflow-Fälle lassen sich dabei als Erfahrungswissen nutzen. Ziel dieser Vorgehensweise ist zum einen eine kontinuierliche Prozeßverbesserung und zum anderen eine qualitative Verbesserung der Workflows. In der Einführungsstufe werden Grobstrukturen und Workflow-Module festgelegt, die in einer Strukturierungsstufe laufend verfeinert werden (engl.: learning by doing). Für die Prozeßverbesserung können Daten über ausgeführte Workflows herangezogen werden (engl.: learning by supervision). Ziel ist es, ausgehend von groben Workflow(-entwürfen) immer besser angepaßte Versionen

171 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen 153 im laufenden Betrieb zu erarbeiten. Existierende Workflows sind als Muster zur Definition neuer verwendbar. Bei der Ausführung von Workflows werden professionelle Erfahrungen und prozedurales Wissen generiert, das festgehalten wird, um eine Wiederverwendung zu ermöglichen. Bewertung und Fazit: Versionierung: Eine Versionierung von Vorgangsmappen bzw. deren Inhalte wird in FLEXWARE und WorkBrain (vgl. Abschnitt 5.3.4) nicht angesprochen, sie spielt dort keine Rolle. Jedoch sieht die Steuerungskomponente Floware von BusinessFlow die parallele synchronisierte Bearbeitung von Vorgängen vor. Inwieweit dabei Versionierungsmechanismen zum Einsatz kommen, ist in [WWT97] und [WWT98] nicht erläutert, so daß keine Aussagen zu den Anforderungen AV1-AV4 und AK4 getroffen werden können. Zur Beobachtung von laufenden Workflows kann deren Status aus der zentralen Datenbank abgefragt werden. Weitere Vorgangsdaten werden nicht zugänglich gemacht. Konfiguration: Im Bereich Organisation ist ein Rollenkonzept niedergelegt, das Benutzer, Aktivitäten und Rechte zu einer Rolle mit dem Ziel zusammenfaßt, die Orga- nisationsstruktur zu dokumentieren und die Zuordnung von Aufgaben zu Personen zu erleichtern (AK3). Den Aktivitäten, aus denen die Workflows bestehen, ist ebenfalls eine eigene Seite zugeordnet, die u.a. Benutzerrollen, zugehörige Applikationen, Ersteller und Varianten der Aktivität beinhaltet. Von jeder Aktivität kann eine Variante abgeleitet werden, wobei zur Nachvollziehbarkeit die Beziehung zur ursprünglichen festgehalten wird. So kann für die Vorgangsbearbeitung, die durch Workflows gesteuert wird, ein konfigurierter Arbeitsplatz in Abhängigkeit von der durchzuführenden Aktivität und unter Berücksichtigung der Benutzerrolle zur Verfügung gestellt werden (AK1, AK2). Die Vorgangsdaten, die für die Bearbeitung notwendig sind, werden als Vorgangsmappen verwaltet. Replikation: Zum verteilten Arbeiten ist auf der Klienten-Seite lediglich ein Web-Browser erforderlich, der Anfragen an den HTTP-Server weiterleitet und deren Ergebnisse darstellt. Die Datenhaltung und das Workflow-Management geschehen zentral. Netzunabhängiges Arbeiten ist damit nicht möglich (AR4). Die Replikation von Daten ist nicht vorgesehen (AR1-AR3). Aufgrund der Ausrichtung auf die fallbasierte Konfiguration von Workflows und auf das organisationale Lernen spielt das Vorgangsmappenkonzept in FLEXWARE und WorkBrain nur eine untergeordnete Rolle. Vorgangsmappen werden nur als Hilfsmittel eingesetzt. Abgesehen von dem Rollenkonzept und der Arbeitsplatzkonfiguration werden wesentliche Anforderungen nicht erfüllt.

172 154 Informationssysteme im Verbesserungsmanagement BSCW Das BSCW-System (engl.: BasicSupport for Cooperative Work) [HB97, BAB + 97] wurde in einer ersten Version 1995 vom GMD-Forschungszentrum Informationstechnik vorgestellt und hat seitdem schnelle Verbreitung gefunden. Es wurde mittlerweile mit dem europäischen IT-Innovationspreis ausgezeichnet. Das System ermöglicht das verteilte Erstellen von Dokumenten auf der Basis des World Wide Web. Im BSCW-System stehen Dienste für das Ablegen von Dokumenten beliebigen Typs, das Editieren entfernter Dokumente, das Versionsmanagement, die Gruppenverwaltung und die Zugangskontrolle zur Verfügung. Das System ist plattformunabhängig, da es auf einem Standard-Web-Server aufsetzt. Daher erfolgt der Zugriff mit herkömmlichen Web-Browsern. Damit kann das System auch als weltweit verfügbares Dateisystem genutzt werden. Bewertung und Fazit: Versionierung: Das System versioniert Dokumente [GHA97] als Ganzes (AV1, AV2), deren historischer Zusammenhang in einer Tabelle abgelegt wird. Von Dokumenten können Varianten erzeugt werden (AV3), wobei ein Abgleich nur manuell über die Versionstabelle möglich ist. Es wird keine Unterstützung zum Zusammenführen von Varianten geboten (AV4). Sichtbarkeit und Kompetenzen können detailliert für Benutzergruppen definiert werden [Sik97], wobei Benutzergruppen als Rollen aufgelöst werden. Konfiguration: Dadurch ist eine rollenspezifische Konfiguration (AK2) teilweise über die Definition von Sichten möglich, die einer Informationsüberfrachtung entgegen wirken. Über den Dokumenttyp im MIME-Format (engl.: Multipurpose Internet Mail Extensions) können Dokumente, die im Browser angezeigt werden, automatisch mit entsprechenden Applikationen verknüpft werden. Die Verknüpfung der Applikationen mit der Rolle oder der Konfiguration des Arbeitsplatzes ist nicht vorgesehen. Rechte sind an Objekte gebunden, die beim Zugriff berücksichtigt werden (AK3), wobei das Zusammenstellen eines Ordners aus verschiedenen Versionen der Inhalte nur bedingt möglich, d.h. es wird jeweils die letzte Version im Ordner angeboten. Ältere Versionen können nur von einzelnen Dokumenten betrachtet werden, jedoch nicht vom gesamten Ordner (AK4). Ordner können nicht als Ganzes kopiert werden, jedoch einzelne Dokumente, wobei die Ordnerzusammenstellung verloren gehen kann. Transparentes, rollenspezifisches Arbeiten am Arbeitsplatz wird nicht gewährleistet (AK1). Replikation: Die Dokumente werden auf einem Server zentral verwaltet, netzunabhängiges Arbeiten wird dadurch erschwert (AR4). Datenabgleich findet nicht statt (AR1). Neue Versionen stehen durch den zentralen Ansatz immer zur Verfügung, sobald sie auf dem Server geladen wurden (AR3). Nicht der Austausch von Informationen zwischen Rollen sondern die gemeinsame Aufgabenbearbeitung steht im Vordergrund (AR2). Die bei der Vorgangsbearbeitung erforderliche Weitergabe von Dokumenten gestaltet sich damit schwierig. Auch Aktionen (z.b. Verschicken einer ), die durch Ereignisse ausgelöst werden können, helfen wenig, den Informationsaustausch

173 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen 155 zwischen Gruppen zu realisieren. Vom System werden wesentliche Anforderungen an die elektronische Vorgangsbearbeitung nicht erfüllt. Bedingt durch die zentrale Verwaltung der Dokumente wird verteiltes netzunabhängiges Arbeiten nicht in ausreichendem Maße unterstützt. Replikation von Daten findet nicht statt. Konfigurationsaspekte, bezogen auf die Benutzerrolle und den Arbeitsplatz, sind gut umgesetzt. Paralleles Arbeiten wird nicht in ausreichendem Maße unterstützt. Es können zwar Varianten von Dokumenten erzeugt werden, aber ein Zusammenführen ist nicht vorgesehen. Workflow-Funktionalitäten sind nicht in ausreichendem Maße vorhanden. Entsprechend der Ausrichtung auf die Unterstützung bei der gemeinsamen Nutzung von Daten ist das BSCW-System für die Vorgangsbearbeitung kaum einsetzbar. Microsoft Exchange Server Der Microsoft Exchange Server [Mic96, Mic99] wurde 1996 auf den Markt gebracht. Entsprechend der allgemeinen Microsoft-Strategie ist es nur für das Betriebssystem MS Windows NT verfügbar. Zum Austausch von Daten mit anderen Systemen (u.a. Lotus Notes) stehen jedoch Mechanismen zur Verfügung. Obwohl der Hauptaspekt des Systems auf dem Bereich Kommunikation via liegt, kann der -Mechanismus als Grundlage für weitergehende Workflow-Management-Aufgaben genutzt werden. Neben privaten Benutzerpostfächern können zum Informationsaustausch innerhalb von Gruppen öffentliche Ordner angelegt werden. Über einen Replikationsmechanismus lassen sich verteilte Kopien dieser Ordner konsistent halten. Zur Weiterverarbeitung von Nachrichteninhalten sind Schnittstellen zu gängigen Microsoft-Produkten vorgesehen, wie z.b. MS Office und MS SQL Server. Für benutzerspezifische Erweiterungen können die Microsoft-Versionen verbreiteter Programmiersprachen eingesetzt werden. Speziell zur Implementierung von ereignisgesteuerten Workflow-Lösungen zur Automatisierung von Geschäftsvorfällen ist ein Exchange Scripting Agent vorgesehen. Bewertung und Fazit: Versionierung: Beim Bearbeiten von Nachrichten und darin enthaltenen Dokumenten werden Änderungen direkt in der ursprünglichen Nachricht gespeichert. Eine Versionierung findet nicht statt. Parallel geänderte Nachrichten führen bei der Replikation zu Konflikten, die erkannt werden. Jedoch stehen keine automatischen Mechanismen zur Auflösung zur Verfügung, sondern es wird manuelles Eingreifen notwendig (AV1-AV4, AK4). Konfiguration: Für jeden Ordner können Berechtigungen definiert werden, die das Erstellen, Lesen, Löschen und Bearbeiten festlegen (AK3). Rechte können zu Funktionen gruppiert werden, die im wesentlichen Benutzerrollen entsprechen. Die Abstimmung von Hilfsmitteln (AK1), die zur Bearbeitung angeboten werden, auf die Rolle des Benutzers und eine rollenspezifische Sicht auf die Inhalte eines Ordners (AK2) werden nicht umgesetzt. Replikation: Zur Vorgangsbearbeitung lassen sich öffentliche Ordner mit Nachrichten

174 156 Informationssysteme im Verbesserungsmanagement oder Dokumenten verwenden, so daß Bearbeiter Vorgänge beobachten können, an denen sie mitgearbeitet haben. Von öffentlichen Ordnern lassen sich Kopien auf mehreren Exchange Servern anlegen und durch Replikation automatisch aktualisieren. Eine dezentrale, arbeitsplatzlokale Datenhaltung wird damit nur bedingt unterstützt, da an jedem Arbeitsplatz ein Exchange Server vorhanden sein muß (AR1). Arbeiten ohne Netzwerkverbindung ist auf diese Weise ebenfalls möglich (AR4). In welchen zeitlichen Abständen Replikationen stattfinden, kann vom Benutzer eingestellt werden (AR3). Die Replikation ist nicht von der Rolle des Benutzers abhängig (AR2). Es kann lediglich festgelegt werden, welche Server Kopien eines Ordners verwalten. Dem Exchange Server stehen für das Versenden von Nachrichten neben persönlichen auch öffentliche Ordner zur Verfügung. Zur Unterstützung von verteilter Datenhaltung ist ein Replikationsmechanismus vorhanden, der die Kopien der Ordner konsistent hält. Für Ordner lassen sich Zugriffsrechte definieren. Diese Aspekte sind akzeptabel umgesetzt, jedoch fehlt ein Versions- und Konfigurationsmanagement vollkommen. Paralleles Arbeiten ist damit nur unter Schwierigkeiten möglich, und die Nachvollziehbarkeit einzelner Bearbeitungsschritte ist nicht gegeben. Negativ zu bewerten ist die Konzentration auf die Windows NT-Plattform, wodurch plattformunabhängiges Arbeiten kaum möglich wird. Lotus Notes/Domino Das System Lotus Notes [TSMB95, DS97] wurde 1989 in einer ersten Version auf den Markt gebracht und ist seitdem vielfach erweitert worden. Anfang 1997 wurde Notes von Grund auf für die Nutzung unter Internet-Standards überarbeitet und unter neuem Namen, Lotus Domino, auf den Markt gebracht [FPU98]. Im Laufe der letzten Jahre hat sich Lotus Notes bzw. Domino zu einer Standard-Groupware-Plattform entwickelt. Die folgenden Betrachtungen beziehen sich auf die Version 4.6. Lotus Notes bzw. Domino kann als Entwicklungsumgebung für Workflow-Management- Systeme genutzt werden. Es lassen sich asynchrone, nachrichten- und dokumentenbasierte Applikationen zur Unterstützung von Gruppenarbeit implementieren. Dafür stehen zum einen die Notes-Formelsprache und zum anderen LotusScript zur Verfügung. Weiterhin gibt es die Möglichkeit, Java-Applets zu integrieren, was insbesondere für Internetanwendungen von Bedeutung ist. Zentraler Bestandteil des Systems ist eine dokumentenorientierte Datenbank, in der unstrukturierte Daten beliebiger Größe verwaltet werden können. Zum Anlegen neuer Dokumente enthält die Datenbank Eingabefelder in Masken, in die bei Bedarf umfangreiche Funktionalitäten integriert werden können. Ansichten und Ordner erlauben unterschiedliche Sichten auf Daten. Gemeinsamer Zugriff auf einen Dokumentenbestand ist für Benutzer mit den entsprechenden Zugriffsberechtigungen möglich. Lotus Notes stellt ein zweistufiges Client/Server-Konzept zur Verfügung: Die eine Stufe besteht aus den Notes-Datenbanken und -Programmen (Server), die andere umfaßt die Präsentation im Notes-Client. Der Client kann jedoch auch direkt auf Datenbanken zugreifen. Der Zugriff ist in diesem Fall exklusiv, d.h. für andere Clients ist die Datenbank

175 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen 157 gesperrt. Da Lotus Notes für eine Vielzahl von Plattformen verfügbar ist, lassen sich heterogene, verteilte Systeme nach Client/Server-Architektur realisieren. Bewertung und Fazit: Versionierung: Für Dokumente existiert in Lotus Notes eine Versionsverwaltung, mit der Revisionen und Varianten von einzelnen Dokumenten erzeugt werden können (AV1, AV3). Dokumente können hierarchisch aufgebaut werden. Die (feingranulare) Versionierung von Unterdokumenten ist so möglich (AV2). Mechanismen zum Zusammenführen von Varianten (AV4) sind nicht vorgesehen. Konfiguration: Dokumente sind in Ansichten und Ordnern dem Benutzer zugänglich. Ansichten enthalten Listen von Dokumenten, die bestimmten Auswahlkriterien (gebunden an den Dokumenttyp) entsprechen. Inhalte von Ordnern können vom Benutzer nach Belieben festgelegt werden, wodurch sie sich als Grundlage für Vorgangsmappen eignen. Die rollenspezifische Konfiguration von Ordnern wird nicht angeboten (AK1, AK2). Ebensowenig können direkt Versionen von Dokumenten zu einer Ordnerversion zusammengestellt werden (AK4). Mit Hilfe von LotusScript lassen sich diese Anforderungen sicherlich realisieren, sie bedeuten aber zusätzlichen Programmieraufwand. Zur personenunabhängigen Beschreibung von Abläufen können Rollen definiert werden. Der Zugriff auf Dokumente läßt sich durch die Vergabevon Privilegien (Leser, Autor, Herausgeber), die an eine Rolle gebunden sind, kontrollieren (AK3). Elektronische Unterschriften machen es möglich, nachzuvollziehen, wer welches Dokument wann erhalten, gelesen oder verändert hat. Beim Speichern von Dokumenten kann eine neue Version erzeugt werden, um die Entstehungsgeschichte festzuhalten. Zum Datenaustausch mit anderen Anwendungen wird u.a. eine CORBA-Schnittstelle (engl.: Common Object Request Broker Architecture) angeboten, über die Objekte in standardisierter Form übergeben werden können. Replikation: Eine Besonderheit des Systems stellt der Replikationsmechanismus dar, wodurch sich Kopien einer Datenbank auf Rechner, die über ein Netzwerk verbunden sind, verteilen und synchronisieren lassen, auch wenn die Netzwerkanbindungen nicht ständig bestehen. Die zu replizierenden Teile einer Datenbank können frei gewählt werden, es können gesamte Dokumente, Teile davon, aber auch Funktionalitäten und Designelemente einer Datenbank repliziert werden (AR1, AR4). Für eine rollenspezifische Replikation (AR2) ist es erforderlich, den Replikationsmechanismus anzupassen. Dies kann z.b. mit LotusScript erfolgen, indem Rollensichten bei der Replikation berücksichtigt werden. Über eine einstellbare Replikationszeit wird festgelegt, in welchen zeitlichen Abständen die verteilten Datenbestände repliziert werden (AR3). Lotus Notes umfaßt Funktionalitäten in allen geforderten Bereichen. Jedoch sind einzelne Anforderungen nicht ausreichend erfüllt. Da Lotus Notes als Entwicklungssystem zur Implementierung von WFMA eingesetzt werden kann, lassen sich die fehlenden Funktionalitäten hinzufügen. Der Aufwand hängt von der Anpassungsfähigkeit der integrierten

176 158 Informationssysteme im Verbesserungsmanagement Funktionen ab. Die sehr gut umgesetzte Replikation von Daten in verteilten Systemen läßt sich nur bei der Verwendung von Notes-Datenbanken nutzen. Relationale Datenbanken können zwar über ODBC-Schnittstellen (engl: Open Database Connectivity) angesprochen werden, aber der Replikationsmechanismus ist für sie nicht verwendbar. AV1 AV2 AV3 AV4 AK1 AK2 AK3 AK4 AR1 AR2 AR3 AR4 ProMInanD - - o - o POLITeam +? o - - -? FLEXWARE BSCW MS Exchange Lotus Notes : gut umgesetzt o: teilweise erfüllt?: keine Angabe +: erfüllt -: nicht umgesetzt Tabelle 5.8: Untersuchte Systeme Anforderungen In Tabelle 5.8 sind die Bewertungen der vorangegangen Abschnitte noch einmal zusammengefaßt dargestellt. Am BSCW-System ist insbesondere die Bindung von Rechten an Rollen gelungen, die einen detaillierten Zugriff auf Dokumente ermöglichen. Das Konzept der elektronischen Vorgangsmappe, das für die Vernetzung im Verbesserungsmanagement herangezogen wurde, basiert auf dem ProMInanD-System, welches diesen Ansatz auch bisher am konsequentesten umsetzt. In Lotus Notes ist die Realisierung der Replikation hervorzuheben, in POLITeam die Nachvollziehbarkeit der Bearbeitungsschritte. Flexware verknüpft Workflows, Rollen und Applikationen zur Unterstützung des rollenspezifischen Arbeiten. Keines der in Tabelle 5.8 aufgeführten Systeme erfüllt die Anforderungen im ausreichende Maße. Zur Entwicklung eines Versions- und Konfigurationsmodells für replizierte Vorgangsmappen ist eine Untersuchung bisheriger Ansätze zur Konfiguration und Versionierung notwendig Untersuchung von Systemen zur Versionierung und Konfiguration Versions- und Konfigurationsmodelle werden verstärkt im Bereich der Softwarekonfigurationsmanagements (SKM) verwendet. Der derzeitige Stand der Unterstützbarkeit ist in [CW98] dokumentiert. Die prinzipielle Vorgehensweise ist sehr intensiv untersucht worden und die Systeme sind ausgereift. Die meisten Systeme unterstützten allerdings nicht direkt das verteilte Arbeiten (außer ClearCase), so daß eine Bewertung der Replikationsanforderung nicht sinnvoll ist. Für das Zusammenspiel zwischen Versions- und Datenmodell gibt es verschiedene Ansätze. Das Versionsmodell kann auf das Datenmodell aufgesetzt sein oder umgekehrt; oder das Versionsmodell ist in das Datenmodell integriert. Entsprechend

177 5.4 Versionierung und Konfiguration replizierter Vorgangsmappen 159 der Kategorisierung nach [CW98] erfolgte im Rahmen einer Diplomarbeit [Thy99] eine Betrachtung einer Auswahl von Ansätzen: Versionsgraphen: RCS/RCE[Tic85, Tic99], DAMOKLES [DGL86], ClearCase [Leb94, AFK + 95], CoMa [Wes94, Wes96] Änderungsorientiertes Versionieren und bedingtes Übersetzen:COV[LCD + 89], [MLG + 93] Programmieren im Großen: SIO [BLLV87] Andere Ansätze: Adele 2 [BEM91, EC94] Die hier erwähnten SKM-Systeme werden für die Realisierung der Konfiguration und Versionierung von replizierten elektronischen Vorgangsmappen als Ideengeber genutzt. Dabei ist zu berücksichtigen, daß insbesondere die Verwendung akzeptierter Standards durch Verwendung von wenig verbreiteter Technologie nicht verletzt wird. Viele der Ansätze sind zumindest auf Implementierungsebene technologiegetrieben, so daß eine Adaption der Konzepte z.t. schwierig wird. Ziel ist es deshalb, für die Anforderungen AV1-AV4 und AK1-AK4 gute, für Vorgangsmappen geeignete Umsetzungen zu finden. Zunächst ist es notwendig, die Gebiete Vorgangsbearbeitung und Softwareentwicklung in Bezug auf Konfiguration und Versionierung voneinander abzugrenzen: Für die Vorgangsbearbeitung ist es unerläßlich, die Rolle des jeweiligen Benutzers zu berücksichtigen (AK2, AK3), durch die die Sicht und der Zugriff auf die Vorgangsdaten festgelegt wird. Nur Adele 2 enthält ein Rollenkonzept. Die Struktur der Vorgangsdaten, d.h. der Vorgangsmappe, ändert sich nicht während der Bearbeitung, d.h. der Benutzer erstellt selbst keine Konfigurationen. In der Softwareentwicklung ändert sich die Struktur des entwickelten Systems durch Erweiterungen oder Reimplementierungen häufig, so daß ein SKM-System darauf flexibel reagieren können muß. Bei der Erstellung von Software wird in der Regel nur eine Version eines Objekts in einem Arbeitsbereich zur Verfügung gestellt. Einem Bearbeiter von Vorgangsmappen soll jedoch jederzeit die Möglichkeit gegeben werden, andere Versionen der Mappe betrachten zu können. In Adele 2 ist das nicht möglich, da die Teildatenbanken der Arbeitsbereiche nur jeweils eine Version enthalten. RCS sieht es ebenfalls nicht vor, aber durch Kopieren von versionierten Dateien in andere Verzeichnisse könnte es mit einigem Aufwand realisiert werden. Die Systemarchitektur legt die Verwendung von Datenbanktechnologie fest, wodurch dateibasierte SKM-Systeme (RCS, ClearCase) nur unter Schwierigkeiten verwendbar sind. Die Systeme DAMOKLES, COV und SIO arbeiten auf relationalen Datenbanken und kommen der Realisierung in einem Repository damit entgegen. Das CoMa-System, das in der grundsätzlichen Idee DAMOKLES gleicht, baut auf einer sehr speziellen, nicht relationalen Graphdatenbank auf. Zur Versionierung: Alle betrachteten Systeme unterstützen sowohl Revisionen als auch Varianten. Die Anforderungen AV2 und AV3 lassen sich somit prinzipiell mit allen erfüllen. DAMOKLES

178 160 Informationssysteme im Verbesserungsmanagement eignet sich durch die Verwendung von Versionsgraphen gut zur Dokumentation historischer Abhängigkeiten zwischen Versionen (AV1). Weiterhin lassen sich generische Konfigurationen zwischen Objekten definieren, die bei der Konfigurationsbildung berücksichtigt werden. Auf diese Weise könnten die Beziehungen zwischen einer Vorgangsmappe und ihren Inhaltskomponenten umgesetzt werden (AV1). Ähnliches bietet CoMa in Form der Objektund Versionsebene. In AV4 wird das Zusammenführen von Vorgangsmappenversionen gefordert. In der Regel bereitet das Zusammenführen von Versionen Schwierigkeiten, wenn es automatisch geschehen soll, und kommt daher kaum ohne Benutzerinteraktion aus [Wes91]. In CoMa sind gute Ansätze für Softwaredokumente vorhanden, die sich auf Vorgangsmappen übertragen lassen. Nach AV4 soll es möglich sein, verschiedene Inhaltskomponenten auf unterschiedliche Arten zusammenzuführen, z.b. Addition von numerischen Werten, Aneinanderhängen von Listen mit Vorgangsdaten, wobei doppelte Elemente eliminiert werden. Für Listen existiert in CoMa eine Lösung (3-Wege-Mischen [Wes91]), die in angepaßter Form für Listen in Vorgangsmappen verwendet werden kann. Zur Konfiguration: Für die Konfiguration einer Vorgangsmappe ist es erforderlich, Versionen der einzelnen Inhaltskomponenten zusammenzustellen (AK4). Dafür stehen in CoMa, SIO, ClearCase, COV und Adele 2 Regeln zur Verfügung, mit denen Konfigurationen beschrieben werden können. Die Konfigurationsunterstützung ist in SIO durch SQL-ähnliche Anweisungen gut umgesetzt. Da SIO eine relationale Datenbank zugrunde liegt, bietet sich diese Vorgehensweise an. Zur Umsetzung einer Rollensicht (AK2) ist in den untersuchten SKM-Systemen kaum direkte Unterstützung vorhanden. Alternativ können Sichtendefinitionen in COV und SIO in Form von Präferenzen nachgebildet werden, die sich bei der Konfigurationsbildung einschränkend auswirken. Die rollenspezifische Bindung einer Vorgangsmappe (AK1) läßt sich mit keinem der untersuchten SKM-Systeme adäquat realisieren. In Adele 2 ist zwar ein Rollenkonzept vorhanden, mit dem im wesentlichen Zugriffsrechte auf Dokumente festgelegt werden (AK3), eine weitergehende Konfiguration der Arbeitsumgebung ist jedoch nicht vorgesehen. 5.5 Zusammenfassung Ziel dieses Kapitels war es, den Stand der Technik bei der Verwendung von Informationssystemen im Verbesserungsmanagement festzustellen. Dazu wurden ein Ebenenmodell mit einem Werkzeugkatalog für Helpdesk-Systeme geschaffen. Diese Systeme stellen einen Kern für die Realisierung von VVM-Systemen dar. wesentliche Vorarbeiten und eigene Erfahrungen bei der Gestaltung von Repositories für das Verbesserungsmanagement diskutiert.

179 5.5 Zusammenfassung 161 fokussierte Literaturuntersuchungen für forschungsrelevante Aspekte bei der Realisierung von VVM-Systemen betrieben. Bisherige Systeme zur langfristigen Wissensorganisation und Vorgangsgestaltung wurden unter den aus dem Gesamtansatz ermittelten Anforderungen hinsichtlich ihrer Eignung bewertet. Zusammenfassend läßt sich sagen, daß in der Literatur wenig Unterstützung gefunden wurde für eine explizite Verzahnung von kurzfristigen operativen Prozessen und langfristigen Prozessen der Wissensorganisation. In Unternehmensgedächtnis-Systemen werden die kurzfristigen Prozesse implizit genutzt oder sind im System fest kodiert. In den Systemen, die primär die langfristige Wissensorganisation unterstützen, ist keine explizite Unterstützung von kurzfristigen Abläufen vorgesehen, d.h. ein ausführbares Modellierungskonzept von Prozessen oder Vorgängen wird nicht eingeführt. In WFMS werden mnemonische Prozesse implizit genutzt, sind im System kodiert oder werden delegiert. In WFMS oder anderen Systemen zur Koordinationsunterstützung gibt es eine explizite Darstellung von Geschäftsprozessen. Die Ausführung von mnemonischen Prozessen beschränkt sich zumeist auf den Aufruf von eingebauten Funktionen oder wird gar delegiert, so daß die Informationsbeschaffung oder -erzeugung manuell erfolgen muß. In einigen neueren Forschungsprototypen, z.b. EULE2 [vjsr99], KnowMore [ABS99], OntoBroker [SS99b] or WorkBrain [WWT98], gibt es eine integrierte Betrachtung von Geschäftsprozessen und mnemonischen Prozessen. In keinem diese Systeme gibt es allerdings eine explizite Modelldarstellung der Prozesse, die eine Verzahnung auf der konzeptuellen Ebene und damit eine verzahnte operative Unterstützung durch ein System erlauben würde. Helpdesk-Systeme sind ein für das in Absatz 3.5 entworfene Gesamtkonzept des Verbesserungsmanagements prädestinierter Ansatzpunkt. Obwohl in diesen Systemen ebenfalls kaum Unterstützung für die explizite Verzahnung vorhanden ist, ist die eskalationsorientierte Prozeßunterstützung und die fehlerorientierte Wissensorganisation stark ausgeprägt. Die notwendigen Repository-Technologien und Metamodelle zur Verzahnung von mnemonischen Prozessen mit Geschäftsprozessen wurden in Abschnitt 5.2 vorgestellt. Die Erfahrungen zeigen allerdings, daß eine präskriptive Beschreibung von Eskalationen nur in einfachen, unrealistischen Szenarien überschaubar bleibt und das Herunterbrechen von Modellierungsinformationen bis auf Systemebene zu komplexen Informations- und Arbeitsflüssen führt. Arbeitsplätze im Verbesserungsmanagement bedürfen einer individuellen Unterstützung. Im nächsten Kapitel soll ein VVM-System zur elektronischen Vorgangsbearbeitung beschrieben werden, welches den aufgestellten Anforderungen gerecht wird.

180 Kapitel 6 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Krisen meistert man am besten, indem man ihnen zuvorkommt. Walt Whitman Rostow Ziel dieses Kapitels ist es, das Design eines nachhaltigen vernetzten Verbesserungsmanagement-Systems auf Grundlage der bisherigen Untersuchungen zu konzipieren. Der prinzipielle Aufbau und die Einbettung in den Wissenstransformationsansatz, der das Lernen aus Fehlern auf der Grundlage der langfristigen Organisation von Fehlerwissen erlaubt, wurde in Kapitel 3 vorgestellt. Keines der in Kapitel 5 untersuchten Systeme erfüllte die Teilanforderungen im gewünschten Maße. Deshalb existiert kein System, das den Gesamtansatz des nachhaltigen vernetzten Verbesserungsmanagements ohne weiteres umsetzen kann. Die Erfahrungen bei der Analyse der Systeme sind in die Gestaltung eines Verbesserungsmanagement-Systems zur verzahnten elektronischen Vorgangsbearbeitung und Wissensorganisation eingeflossen. Die ermittelten Anforderungen dienen der Spezifikation einer organisatorischen Wissenbasis auf der Grundlage eines Repositories, das mittels mnemonischen Prozessen organisiert wird. Der gewählte Ansatz unterstützt die Wissenstransformation von Sozialisierung, Externalisierung, Kombination und Internalisierung durch explizite und verzahnte Prozeßmodelle. Ein flexibles teamorientiertes Vorgangssteuerungssystem koordiniert die verteilte Bearbeitung von Fehlerfällen. Folgende Gestaltungselemente von VVM-Systemen werden adressiert. Eine Architektur unterstützt auf der Grundlage einer expliziten organisatorischen Wissensbasis (mobile) Arbeitsplätze im Verbesserungsmanagement problemspezifisch bei der Fehlerfallbearbeitung und greift dabei auf die Wissensquellen im Unternehmen zu (vgl. Abschnitt 6.1). Ein Modellierungsrahmenwerk zur nachhaltigen Wissensorganisation und zur Nut-

181 6.1 Architektur eines VVM-Systems 163 zung von Wissen im Unternehmen (vgl. 6.2) gestattet die uniforme Einbindung von Komponenten des Verbesserungsmanagements in eine organisatorische Wissensbasis. Die einzelnen Komponenten sind ein Modell für replizierte elektronische Vorgangsmappen zur Bündelung und Verteilung des Problemkontextes (vgl. Abschnitt 6.2.5). ein rollenbasiertes Versionierungs- und Konfigurationsmodell für Vorgangsmappen zur Unterstützung der Arbeitsplätze für divergierende Profile in der Eskalation (vgl. Abschnitt 6.2.6). ein Fehlerdatenmodell zur strukturierten Speicherung und Nutzung von (multimedialem) Fehlerwissen (vgl. Abschnitt 6.2.7). Werkzeuge unterstützen die verteilte Bearbeitung von Fehlerfällen, im einzelnen: ein Eskalationsmanager koordiniert die beteiligten Rollen in der Eskalation (vgl. Abschnitt 6.3). ein Mappenmanager steuert Vorgangsmappen in Eskalationen (vgl. Abschnitt 6.4). ein Anfragemanager nutzt variantenorientiertes Fehlerwissen und heterogene Informationsquellen im Unternehmen (vgl. Abschnitt 6.5). 6.1Architektur eines VVM-Systems Heterogenität, Verteilung, Instabilität und die Forderung der Adaptibilität kennzeichnen das vernetzte Verbesserungsmanagement. VVM-Systeme müssen die existierenden, verteilten Lösungsinseln verbinden. Aber auch die konkreten Anforderungen an ein VVM-System sind zu berücksichtigen. Daher gibt es zwei Integrationsdimensionen zu beachten. 1. Technische Integration der existierenden Lösungsinseln (Externe Integration). Existierende Prozesse, Werkzeuge und verfügbare Informationsquellen eines Unternehmens müssen berücksichtigt werden. Das prinzipielle Vorgehen ist ein kooperativer bottom-up Reengineering-Prozeß von Daten und Abläufen zur Modellgewinnung. Die existierenden Werkzeuge und Systeme im Verbesserungsmanagement werden auf einer abstrakten Ebene beschrieben. Die Beschreibungen dienen der Identifikation und Realisierung von Schnittstellen, über die Daten hinweg fließen können. Dieses Vorgehen wurde in Abschnitt beschrieben. 2. Integration innerhalb des Verbesserungsmanagementsystems (Interne Integration). Im VVM-System müssen die Voraussetzungen für ein einheitliches Verständnis von Verbesserungsprozessen innerhalb eines Unternehmens geschaffen werden. Auf Basis des Fehlerdatenmodells und der gespeicherten Eskalationen ist dazu der Aufbau von Strukturwissen über diesem Wissen notwendig. Daher gilt es, die verschiedenen Teilaspekte des Verbesserungsmanagements in Beziehung zu setzen und damit zur Interaktion beizutragen.

182 164 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Daraus wird ersichtlich, daß die Entwicklung von VVM-Systemen und deren Einbettung in ein konkretes Unternehmen methodisch unterschiedlich zu behandeln sind. Innerhalb des VVM-Systems findet die Entwicklung und (Neu-)Implementierung von Lösungen in einer relativ homogenen Umgebung statt, während der Einsatz dieses Systems unter nicht vorher bekannten organisatorischen und technischen Bedingungen stattfindet, die die Architektur des VVM-Systems zu berücksichtigen hat. heterogene Informationsquellen Netzwerk föderative externe Kommunikation Anfrageschnittstelle UG-Trader Eskalationsmanager Unternehmensgedächtnis Arbeitsplatzschnittstelle DB-Kommunikation Beide Ansätze sind notwendig, um sowohl die interne als auch die externe Integration im Verbesserungsmanagement zu realisieren. Um existierende Systeme in das VVM-System einzubinden, müssen Eigenarten der Lösungsinseln berücksichtigt werden. Innerhalb des Verbesserungsmanagements müssen kurzfristige und langfristige Aspekte von Prozeßgestaltung und Wissensorganisation verknüpft werden. Ausgangspunkt stellt ein Repository dar. Die in Abbildung 6.1 dargestellte Architektur konzipiert ein flexibles VVM-System, das sowohl die technische Integration der existierenden Inseln als auch die Gestaltung der Fehlerfallbearbeitung auf Grundlage des Eskalationsprinzips gestattet. Die Architektur be- Anfragemanager Mappen- Manager Arbeitsplätze Netzwerk Abbildung 6.1: Architektur des Verbesserungsmanagements (adaptiert aus [KPJ98]) steht aus einem metadaten-gestützten semantischen Trader-System [KPJ98], vernetzten Arbeitsplätzen und den verteilten und heterogenen Informationsquellen eines Unternehmens. Im Zentrum der Architektur steht der UG-Trader. Die wesentlichen Komponenten sind das modellgestützte Gedächtnis des Verbesserungsmanagements (Unternehmensgedächtnis-System) und die operativen Komponenten Anfragemanager, Mappenmanager und Eskalationsmanager. Die operativen Komponenten koordinieren die verteilte Bearbeitung von Fehlerfällen auf der Grundlage der expliziten und verzahnten Modelle. Das Unternehmensgedächtnis-System speichert zum einen die Prozesse und Informationsflüsse des Verbesse-

183 6.1 Architektur eines VVM-Systems 165 rungsmanagements, zum anderen aber auch DV-technische Informationen (Schemainformationen, Kommunikationsprotokolle, Arbeitsplatzinformationen usw.) über die verwendete Infrastruktur. Damit gewährleisten die operativen Komponenten eine informationstechnologisch durchgängige Unterstützung der externalisierten Arbeits- und Informationsflüsse. Die Realisierung des UG-Traders erfolgt auf der Basis relationaler DBMS. Alle Komponenten sind so spezifiziert worden, daß sie unabhängig voneinander realisiert werden konnten. Dies war zum einen wichtig für die Realisierung von Komponenten in einem kommerziellen Helpdesk-System, zum anderen für die Ausdifferenzierung in Systeme mit verschiedenen Schwerpunkten. (vgl. Kapitel 7). Der Entwurf der Modelle und deren Verzahnung im Repository bilden meinen Arbeitsschwerpunkt. Die Umsetzung in ein kommerzielles Helpdesk- System wurde in der Diplomarbeit von Katzke [Kat98] vorgenommen. Der Mappenmanager wurde in der Diplomarbeit von Thyen [Thy99] entworfen und implementiert. Der Umgang des Anfragemanagers mit variantenorientiertem Fehlerwissen wurde von Stolz in seiner Diplomarbeit [Sto00] auf Grundlage des in [Szc96] vorgestellten Systems untersucht und implementiert. Der Eskalationsmanager bildet in Kombination mit dem Repository ein prozeßorientiertes Unternehmensgedächtnis-System, der das transparente Modellieren zur Laufzeit erlaubt. Er wurde von Schlaphof [Sch98b] in ihrer Diplomarbeit entworfen und implementiert. Die Komponenten arbeiten über Schnittstellen mit den verteilten Systemen zusammen, wobei über die föderative Anfrageschnittstelle vornehmlich Daten, über die Arbeitsplatzschnittstelle auch Prozeß- und Kommunikationsinformationen ausgetauscht werden. Föderativer Anfragemanager: Der Anfragemanager konzentriert sich auf den Aufbau und die Nutzung von Fehlerstrukturwissen und die Zerlegung der gespeicherten Schemainformationen, um Anfragen eines Arbeitsplatzes in (Teil-)Anfragen umzuwandeln und diese an die heterogenen Informationsquellen zu schicken. Aus den einlaufenden Antworten wird eine vollständige Antwort konstruiert. Der Anfragemanager nutzt dabei phasenorientierte Prozeßmodelle, welche die komplexe Steuerung des Anfrageprozesses übernehmen. Diese Funktionalität wurde aus dem von [Szc96] entwickelten System übernommen und weiter entwickelt. Der Aufbau und die Nutzung von Fehlerstrukturwissen ist als eigenständige Aufgabe hinzugekommen. Eskalationsmanager: Der Eskalationsmanager arbeitet kontextfrei auf den definierten Arbeits- und Informationsflüssen des Verbesserungsmanagements, wie sie im Unternehmensgedächtnis-System definiert sind. Er abstrahiert völlig von der konkreten Modellierung von Prozessen. Es ist möglich, Teile der Prozesse mit Hilfe des Eskalationsmanager durch strukturierte s zu unterstützen. Wesentliche Aufgabe des Eskalationsmanagers ist die Einhaltung der in Abschnitt definierten rollenbasierten Ausführung von Prozessen, wobei die Durchführung eines Prozesses oder Vorgangs mindestens einen Koordinator, einen Durchführer und einen Prüfer haben muß. Der Eskalationsmanager erlaubt aber auch die Vereinigung von Rollen in einer Person. Diese Vereinigung bleibt aber nachvollziehbar. Mit Hilfe des Eskalationsmanagers ist die rollenbasierte Modellierung zur Laufzeit mittels mnemonischer Prozesse

184 166 Ein nachhaltiges vernetztes Verbesserungsmanagement-System möglich. Diese werden aus der laufenden Bearbeitung von Fehlerfällen aufgerufen und erzeugen bzw. modifizieren die Fehlerwissensbasis. Mappenmanager: Der Mappenmanager verwaltet die Erzeugung, die Verwendung und die Archivierung elektronischer Vorgangsmappen. Er steuert und überwacht weiterhin die Versionierung und Konfiguration replizierter Vorgangsmappen. Dabei kann er das Wissen der Fehlerwissensbasis zum Routing der Mappen mittels der Eskalationsmanagers nutzen, aber auch die Ad-Hoc-Eskalation von Vorgangsmappen unterstützen. Er nutzt weiterhin DV-technische Informationen über Arbeitsplätze zur DV-spezifischen Konfiguration der Mappeninhalte. Z.B. sind im Fehlermappenmodell Informationen über Software-Werkzeuge in Abhängigkeit vom verwendeten Betriebssystem gespeichert. Die vernetzten Arbeitsplätze sind verantwortlich sowohl für die Annahme und Weitergabe von Vorgangsmappen (Makroprozeß) als auch für die lokale Verwaltung und Bearbeitung dieser Vorgangsmappen (Mikroprozesse). Jeder Arbeitsplatz besitzt eine lokale Datenbank für die Speicherung von Vorgangsmappen. Der am Arbeitsplatz installierte Klient kann die Vorgangsmappen annehmen, bearbeiten und weiterleiten. Der Arbeitsplatz kommuniziert über die Arbeitsplatzschnittstelle mit dem UG-Trader. Ist der Arbeitsplatz nicht am Netz, sind nur die Vorgangsmappen zugänglich, die in die lokale Arbeitsplatzbank repliziert wurden. Der Zugriff von mnemonischen Prozessen auf das Unternehmensgedächtnis-System wird somit stark eingeschränkt. 6.2 Ein Unternehmensgedächtnis-Repository für das VVM Ziel dieses Abschnitts ist es, ein Repository für das VVM zu konzipieren, das zum einem die Aufgaben des Verbesserungsmanagements gerecht wird, und zum anderen die Bedrohungen durch eine sich ständig ändernde Um- und Innenwelt durch die Transformation von Wissen entgegenwirkt. Wesentlich dabei ist die Externalisierung von Teilen des Unternehmensgedächtnisses. Diese Arbeit geht dabei von der Theorie kooperativer Informationssysteme und verschiedenen Prozeßsorten aus, die miteinander verzahnt werden müssen. Die konzeptuelle Verzahnung der Prozesse des Verbesserungsmanagements und der Leistungserstellung mit denen der langfristigen Wissensorganisation erfolgt mittels Metamodellierungstechniken. Diese Techniken erlauben die generische Beschreibung von Unternehmensgedächtnis-Systemen und die Spezialisierung dieser Beschreibungen für das Verbesserungsmanagement. Innerhalb des Repositories sind zwei wesentliche Aufgaben zu leisten: Introspektion und Reflexion der externalisierten Prozesse, Agenten und Hilfsmittel sowie die Sicherstellung der fortlaufenden Kooperation in einer sich ändernden Um- und Innenwelt. In die wertschöpfende Prozesse eingebettet werden diese Techniken durch die Einbeziehung der Produktions- und Produktnutzungskontexte heutiger Ferti-

185 Fehlerbild eskalieren Feedback Erfassen z.b. Call Center Korrigieren Fehlerbild eskalieren Feedback Erfassen Analysieren Korrigieren Fehlerbild eskalieren Feedback Erfassen Analysieren Korrigieren Gehäuse Staubsauger Deckel Boden Antrieb Wele M otor Strom versorgung Rotor enthält Motoren Gehäuse Bohrm aschine Antrieb Körper Bohrkopf führt_aus führt_aus Wele Trafos M otor benutzt benutzt Strom versorgung W icklung unterstützt erzeugt nutzt unterstützt erzeugt nutzt sucht stellt_dar Gehäuse Haartrockner Träger Auslaß Antrieb Wele M otor Strom versorgun Rotor Meta-Ebene Meta-Meta-Ebene enthält 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 167 gungsbetriebe, welche durch die Globalisierung und Transparenz der Märkte zunehmend von Variantenvielfalt geprägt sind. Zunächst folgt in Abschnitt eine überblicksartige Darstellung des Repositories, bevor in den folgenden Abschnitten auf die Gestaltung der Modelle eingegangen wird Gesamtdarstellung des Repositories Die Gesamtdarstellung des Repositories findet sich in Abbildung 6.2. Das Unternehmensgedächtnis-Repository abstrahiert in unternehmensspezifischen und generischen Schritten von den bearbeiteten Fehlerfällen in einem Unternehmen. 2 Fokussiertes M -Modell Beschreibt Konzepte der Theorie kooperativer Informationssysteme Legt Sprachmittel und Verknüpfungen für das Unternehmensgedächtnismodell fest aufgabenbasiertes dokumentenbasiertes Modell Modell Agent benutzt enthält Hilfsmittel enthält hat_beziehung_zu führt_aus unterstützt enthält erzeugt enthält Objekt Prozess nutzt isa Aktivität Hoch Verzahntes Unternehmensgedächtnismodell Introspektion und Reflexion von Modellen Rollenkonzepte, Geschäftsprozesse, Mnemonische Prozesse spezialisiert Replizierte Elektronische Vorgangsmappen Eskalationsbereich Eskalationsbereich z.b. FMEA Teamsitzung Aufbau von Strukturwissen Unternehmensspezifische Anpassungen Rollenmodelle, Geschäftsprozesse, Mnemonische Prozesse Unternehmensspezifische Fehlermappen Fehlerdatenmodell, Fehlerstrukturwissen Unternehmensspezifisches Fehlerwissen Sammlung von Fehlerfällen Sonstige Fehlerwissensquellen Kunde Eskalationsbereich z.b. Serviceingenieur instantiiert Agent Wissensagent Prozess Hilfsmittel UGS- Repository Wissenserzeuger Mmenonischer- Wissensverbraucher Prozeß Wissensträger Wissensadministrator Akquisition Suche Wiedergewinnung Monitoring spezialisiert instantiiert instantiiert Objekt UGS-Objekt Abstrakstionsgrad Niedrig Unternehmensgedächtnis- Repository Abbildung 6.2: Gesamtdarstellung des Repositories

186 168 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Auf der IRD Definitionsschemaebene ist ein fokussiertes Metameta-Modell (M 2 - Modell 1 ) angesiedelt. Es definiert grundlegende Modellierungskonzepte und deren Beziehungen untereinander. Die Konzepte fokussieren auf die Konzepte der Theorie kooperativer Informationssysteme. Alle Konzepte der IRD Definitionsebene sollten Instantiierungen der hier zur Verfügung gestellten Konzepte sein. Auf der IRD Definitionsebene sind zunächst die Konzepte des verzahnten Unternehmensgedächtnismodells als Metamodell definiert. Aufgabe der Modellierung auf dieser Ebene ist es, die Modelle so zu gestalten, daß Introspektion und Reflexion der Modelle nachvollziehbar ermöglicht wird. Grundlegende Elemente dieser Ebene sind Rollenkonzepte, Geschäftsprozeßmodellierungskonzepte und Konzepte zur Gestaltung mnemonischer Prozesse. Die Modelle sind nicht auf das Verbesserungsmanagement beschränkt und können daher für verschiedene Zwecke spezialisiert werden. Auf der gleichen Ebene sind Spezialisierungen der Vorgangsbearbeitung durch replizierte elektronische Vorgangsmappen und mnemonische Prozesse zum Aufbau von Strukturwissen im Repository auf dieser Ebene beschrieben. Die IRD Ebene enthält die Anpassung der Konzepte an das nachhaltige vernetzte Verbesserungsmanagement; neben dem Fehlerdatenmodell die Anpassung des Vorgangsmappenkonzepts an unternehmensspezifische Fehlermappen, die für das Unternehmen definierten leistungserstellenden Prozeßmodelle und die mnemonischen Prozeßmodelle, die im Unternehmen angewendet werden, um z.b. Fehlerstrukturwissen aufzubauen. Die eigentliche Sammlung von Fehlerfällen befindet sich auf der IRD Applikationsebene. Auch sonstige Quellen für die Bearbeitung von Fehlerquellen, z.b. Beschreibungen von Produkten und Prozessen, die durch Schemata auf der darüberliegenden Ebene beschrieben werden, sind hier verortet Anpassungen des fokussierten M 2 -Modells Das M 2 -Modell folgt in wesentlichen Zügen dem FOQUS-Prozeßmodell, welches in Abschnitt vorgestellt wurde. Die hier vorgenommene Anpassung berücksichtigt die Rolle von Dokumenten explizit in der Metameta-Modellierung. Instantiierte Metamodelle können explizit dokumentbasierte, explizit prozeßbasierte und auch gemischte Ansätze sein. Die Anpassung wird im folgenden kurz begründet und skizziert. Fragestellungen zur Gestaltung von Unternehmensgedächtnis-Systemen haben ihren Niederschlag in der konzeptuellen Modellierung gefunden (vgl. [DES96, Sim96, HdSK96, SD97, Sch98c, Sta98]). Ramesh [Ram97] hat ein Metamodell eingeführt, welches auf die Erfassung der Entscheidungsfindung fokussiert. In Abbildung 6.3 ist das Metamodell mit seinen Konzepten dargestellt. Der Stakeholder repräsentiert einen Mitarbeiter einer Organisation, die in den Entscheidungsprozeß eingebunden ist. Sie besitzen Rollen (has role in)bezüglich 1 Zu den Aufgaben der Modellierungsebenen vgl. auch [JPW + 98].

187 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 169 der Prozesse (Task ), der durch diese erzeugten Objekte (Object) und der Beziehungen zwischen den Objekten. Objekte sind Ausgang und Ziel der Entscheidungsfindung. Objekte können untereinander in Beziehung stehen (traces to) und durch Quellen (Source) dokumentiert (documents) werden. Diese Quellen werden von Mitarbeitern erzeugt und gepflegt (manages) und können sowohl physikalischer als auch virtueller Natur sein. Abbildung 6.3: Metamodell nach Ramesh (adaptiert aus [Ram97]) Da Objekte Eingangsgrößen für die Entscheidungsfindung sind, bildet die Trennung zwischen Objekt und Quelle eine wichtige Unterscheidung für die Informationsflußanalyse hinsichtlich der Vertrauenswürdigkeit, Validierbarkeit und Nachvollziehbarkeit von verschiedenen Quellen, die sich auf das gleiche Objekt beziehen. So können Entscheidungen dadurch beeinflußt werden, ob den Objekten eine beglaubigte Urkunde oder eine telefonisch übermittelte Information zugrundeliegt. Dem Modell fehlen Repräsentationsmöglichkeiten für die Werkzeuge, mit denen ein Prozeß bearbeitet wird. Für das Verbesserungsmanagement ist dies wichtig, da z.b. Fehler an Produkten aufgrund fehlerhafter Produktionsanlagen entstehen können. enthält dokumentenbasiertes Modell Agent benutzt aufgabenbasiertes Modell Hilfsmittel enthält hat_beziehung_zu führt_aus unterstützt enthält Objekt erzeugt enthält Prozeß nutzt isa Aktivität Abbildung 6.4: Unterstützung von Aufgaben und Dokumenten Wie in Abschnitt 3.3 beschrieben, lassen sich Ansätze zur Rechnerunterstützung für Unternehmensgedächtnisse grob in dokumentbasierte und prozeßbasierte Ansätze unterteilen. Obwohl das Prozeßmodell sowohl durch empirische Studien [Ack94a, AM95] als auch durch

188 170 Ein nachhaltiges vernetztes Verbesserungsmanagement-System den Theorierahmen der dynamischen Wissensschaffung und kooperativen Informationssysteme im wesentlichen prozeßorientiert determiniert ist, läßt sich durch die hat Beziehung zu Relation zwischen Agent und Objekt eine dokumentorientierte Sicht herstellen. Deshalb sind andere Metamodellierungsansätze, z.b. [SNZ95, Ram97], in dieses Metamodell - auch durch Erweiterungen - abbildbar Aufgaben des Unternehmensgedächtnis-Systems Aufgrund der Tatsache, daß das Unternehmensgedächtnis-System wiederum ein kooperatives Informationssystem ist, müssen Methoden der Introspektion der Modelle zur Verfügung gestellt werden, um Adaptibilität und fortlaufende Änderungen in der organisatorischen Wissensbasis aufzufangen. Aus der Theorie kooperativer Informationssysteme können dazu drei Ansatzpunkte herausgebildet werden. 1. Prozeßbasierte Introspektion: Prozeßmodelle sind Objekte des Unternehmensgedächtnis-Systems. Ich betrachte hier drei Arten von Prozessen. Erstens leistungserstellende Prozesse des Unternehmens, deren Qualität (oder die derer Ergebnisse) gesichert oder verbessert werden sollen, zweitens die Prozesse des VVM, die zur Sicherung und Verbesserung der Prozesse, Dienstleistungen und Produkte eingesetzt werden und drittens die Prozesse, die zur prozeßorientierten Wissensorganisation beitragen. Um die prozeßbasierte Introspektion zu realisieren, müssen alle Prozeßarten wiederum Ein- und Ausgangsobjekte von Prozessen der Wissensorganisation werden. So ist es möglich, Änderungsprozesse zu definieren, die Auswirkungen auf die Prozeßarten haben. Ein Ansatz wird in Abschnitt 6.3 vorgestellt, wo mittels mnemonischer Prozesse Änderungen an Prozessen zur Laufzeit des Systems durchgeführt werden. 2. Agentenbasierte Introspektion: Prozesse werden von Agenten rollenbasiert durchgeführt. Diese Agenten erzeugen, besitzen, nutzen und verändern Wissen. Deshalb müssen Agenten einerseits in der Lage sein, die Prozesse der Wissensbasis zu untersuchen und zu ändern, andererseits muß das Unternehmensgedächtnis-System in der Lage sein, das Wissen der Agenten darzustellen. Dabei müssen zwei Rollenmodelle zum Tragen kommen. Erstens stellt die Aufbauorganisation eines Unternehmens ein Rollenmodell zur Verfügung. Dieses Rollenmodell muß mit dem Rollenmodell des Verbesserungsmanagements verknüpft werden, d.h. während der Verbesserungsprozesse werden dynamisch die Rollen des Koordinators, des Prozeßausführers und des Prüfers vergeben. Dies hat nicht nur Konsequenzen in der Rechtevergabe, sondern kann bei der Introspektion genutzt werden, um das Profil von Agenten in Verbesserungsprozessen zu analysieren. Weiterhin werden während der Ausführung von mnemonischen Prozessen dynamisch Rollen an 2 Diese Relationierung wurde auch schon vom WibQuS-Metamodell (vgl. Abschnitt 5.2.1) geleistet (durch die Beziehung Agent owns Object).

189 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 171 Wissensagenten vergeben, so daß später z.b. auf einfache Weise Wissensprofile vom System generiert werden können (vgl. Abschnitt ). 3. Systembasierte Introspektion: Die Schnelligkeit, mit der Änderungen durchgeführt werden müssen und die Komplexität der Modelle stellen Anforderungen dar, denen nicht allein durch prozeß- oder agentenbasierte Introspektion begegnet werden kann. Das System selbst muß eine aktive Rolle bei der Modelländerung übernehmen. Dies kann zum einen durch explizite Analyse der Prozeßausführungsspuren [Döm99] geschehen, zum anderen kann durch die komponentenorientierte Realisierung die Änderung durch die solcherart gestalteten Werkzeuge eigenständig nachvollzogen werden [PWD + 99]. Die Folgerungen dieser drei Introspektionsarten können nun in folgenden Aussagen über die Struktur der organisatorischen Wissensbasis zusammengefaßt werden. 1. Prozesse sind die primären Objekte der organisatorischen Wissensbasis. 2. Agenten sind in unterschiedlichen Rollen in allen Prozessen involviert. 3. Das System übernimmt eine aktive Rolle bei der Organisation der Wissensbasis Ein Metamodell für das Unternehmensgedächtnis-System Spezialisierungsbeziehungen objektivieren die wesentlichen Konzepte auf der IRD Definitionsebene. Diese Objektivierung ist notwendig für die nachvollziehbare Introspektion des Repositories durch das Repository. Alle Prozeßmodelle sind Objekte des Unternehmens- Legende: instance of isa Relation enthält Prozeß isa erzeugt nutzt Objekt enthält 2 M -Ebene Meta-Ebene Objekt Prozeß Mmenonischer- Prozeß erzeugt nutzt sucht stellt_dar UGS-Objekt isa Prozeßmodell Abbildung 6.5: Mnemonische Prozesse und Geschäftsprozesse als Objekte des Unternehmensgedächtnisses gedächtnisses. Ich betrachte also die Kernprozesse einer Unternehmung, die Prozesse des Verbesserungsmanagements sowie weitere denkbare als Teil des Unternehmensgedächtnisses. Ich betrachte weiterhin auch die Konzepte des Unternehmensgedächtnis-Systems als

190 172 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Teil des Unternehmensgedächtnisses. Diese unterliegen also genau wie die Kernprozesse der änderungsorientierten Modellierung. Durch die damit vollzogene Objektivierung können alle externalisierten Prozeß-, Agenten- und Hilfsmittelbeschreibungen Gegenstand der Untersuchung (Introspektion) durch mnemonische Prozesse werden. Dies gilt auch für die das Unternehmensgedächtnis beschreibenden Konzepte, also für mnemonische Prozesse, Wissensagenten und das Repository, wodurch das Unternehmensgedächtnis-Repository sich selbst zum Gegenstand der Untersuchung machen kann (Reflexion). Wie ist dies nun modellierungstechnisch beschreibbar? Wie in Abbildung 6.5 zu erkennen ist, sind alle Prozesse des Unternehmensgedächtnisses, d.h. mnemonische Prozesse und Prozeßmodelle, wiederum Unternehmensgedächtnis-Objekte. 3 Dazu wird die Sprache zu einem Metamodell des Unternehmensgedächtnis-Systems instantiiert. Das Konzept Prozeß wird durch Mnemonischer-Prozeß instantiiert und das Konzept Objekt durch UGS-Objekt. Die Beziehungen zwischen Mnemonischer-Prozeß und UGS-Objekt werden erweitert. So kann ein Mnemonischer-Prozeß nicht nur Objekte erzeugen und nutzen, erkannauchugs- Objekt suchen und darstellen. Die Existenz einer isa-beziehung zwischen Mnemonischer- Prozeß bzw. Prozeßmodell und UGS-Objekt beschreibt nun, daß alle Prozesse wieder Objekte des Systems sind. Somit ist es dem Unternehmensgedächtnis-System möglich, alle Konzepte uniform als Gegenstand der eigenen Betrachtung darzustellen. 4 Durch den gemeinsamen Abstraktionskern ist es nun möglich, isolierte Geschäftsprozesse auf Modellebene mit Funktionen des Unternehmensgedächtnis-Systems zu verzahnen. Dadurch wird die Informationslogistik, die zwischen den Prozessen für die ausreichende Versorgung der zu erledigenden Prozesse mit Informationen sorgt, externalisiert. Durch die reflexive Externalisierung ist es nun möglich, zeitliche, räumliche, technische und konzeptuelle Barrieren zu überwinden, die eine Nutzung von Informationen bisher erschwert haben. Die diesem Prinzip zugrunde liegenden Konzepte werden nun vorgestellt. Die mnemonischen Prozesse, die auf einem Unternehmensgedächtnis-System ausgeführt werden können, sind ein wichtiger Faktor für die Effizienz der Wissensarbeit, da ohne sie Wissen nicht erzeugt und das gespeicherte Wissen nicht genutzt werden kann. Aus diesem Grund müssen die mnemonischen Prozesse durch das Unternehmensgedächtnis-System explizit unterstützt werden. Im folgenden werden diese Prozesse in das Metamodell eingebunden. Als Klassen möglicher mnemonischer Prozesse wurden bereits die Akquisition, Suche, Wiedergewinnung und das Monitoring identifiziert. Diese Prozesse arbeiten auf UGS-Objekten. 5 Dieser Zusammenhang wird - wie bereits erwähnt - durch die Beziehungen nutzt, erzeugt, sucht und stellt dar modelliert. Die Wissensagenten sind Instantiierun- 3 Dies gilt auch für Unternehmensgedächtnis-Agenten und Unternehmensgedächtnis-Hilfsmittel. Aus Gründen der Vereinfachung werden diese Beziehungen nicht dargestellt. 4 Dies steht in Analogie zu der Basisklasse Objekt eines objektorientierten Rahmenwerkes, welche erst die Introspektion und Selbstmodifikation erlaubt, da alle anderen Klassen aus Sicht der Introspektion uniform behandelt werden können. Ein Vertreter dieser Rahmenwerke ist JavaBeans [Eng97, Jub98]. 5 Konkrete mnemonische Prozesse sind entsprechend der Literaturuntersuchung in Abschnitt 5.3 (vgl. auch [KJ99]) Instantiierungen dieser Prozeßklassen (nicht in der Abbildung dargestellt).

191 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 173 Legende: instance of isa Relation Objekt Prozeß Agent enthält benutzt führt_aus unterstützt Prozeß Hilfsmittel erzeugt nutzt enthält Objekt enthält Agent 2 M -Ebene Meta-Ebene Hilfsmittel Wissensagent benutzt UGS- Repository Wissensverbraucher Wissensträger Wissensadministrator führt_aus Wissenserzeuger Mmenonischer- Prozeß unterstützt erzeugt nutzt sucht stellt_dar Akquisition Suche Wiedergewinnung Monitoring UGS-Objekt Abbildung 6.6: Wissensagenten nutzen mnemonische Prozesse gen des Agenten auf M 2 -Ebene. Sie benutzen bei der Ausführung der Prozesse das UGS- Repository, also den, vom Unternehmensgedächtnis-System unterstützten Wissensspeicher als Hilfsmittel. Das UGS-Repository ist damit Instanz von Hilfsmittel. 6 Je nach Art der durchgeführten Prozesse nehmen die Wissensagenten unterschiedliche Rollen ein, welche im Modell als Spezialisierungen des Wissensagenten spezifiziert sind. Die Rollen entsprechen dabei Klassen, die durch Repräsentationen konkreter Angestellter eines Unternehmens instantiiert werden. 7 Für die Akquisition nimmt der Benutzer die Rolle des Wissenserzeugers ein. Er erzeugt neue UGS-Objekte. DerWissensverbraucher führt Prozesse der Suche- und Wiedergewinnung von Wissen durch, wobei UGS-Objekte gesucht und dargestellt werden. Das Monitoring kann vom Unternehmensgedächtnis-System selbst durchgeführt werden, es kann aber auch vom Wissensadministrator explizit durchgeführt werden. Die Rolle des Wissensträgers ist im Gegensatz zu den vorher genannten Rollen passiver Natur. Sie ist nicht an bestimmte Prozesse gebunden. Wissensträger zeichnen sich durch einen eigenen Wissenspeicher aus, der aus nur ihnen zugänglichem Wissen besteht. Die erläuterten Konzepte sind in Abbildung 6.6 dargestellt. Ein prozeßorientiertes Unternehmensgedächtnis-System muß als Wissensobjekte die Prozesse des Unternehmens unterstützen. Die Geschäftsprozesse werden in Prozeßmodellen 6 Das UGS-Repository ist entsprechend der Klassifikation (Dimension Verbreitung) in Abbildung 3.9 in Abschnitt partioniert (nicht in der Abbildung dargestellt). Das Konzept UGS-Repository wird in die Konzepte Privates-Repository, Projekt-Repository, Abteilungs-Repository, Unternehmens-Repository und Archiv unterteilt. 7 Die Instantiierung im Verbesserungsmanagement ist durch die Verwendung eines weiteren Rollenmodells etwas komplexer. Das Rollenmodell wird in Abschnitt erläutert.

192 174 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Objekt enthält 2 M -Ebene Meta-Ebene Legende: instance of isa Relation Objekt UGS-Objekt Prozeßmodell Prozeß Agent Hilfsmittel FOQUS- PM Prozeßmodell A Prozeßmodell B Prozeßagent Agent benutzt Prozeßhilfsmittel hat_beziehung_zu führt_aus unterstützt Kernprozeß Wertschöpfungsobjekt erzeugt nutzt Kernaktivität Abbildung 6.7: Geschäftsprozesse spezifiziert. Diese Prozeßmodelle müssen eine verständliche Darstellung aufweisen, damit eine Einigung über den beschriebenen Sachverhalt erzielt werden kann und das Modell als Ausgangspunkt für Diskussionen dienen kann. Weiterhin sollte es formalen Analysetechniken zugänglich sein, so daß Auswertungen unter bestimmten Gesichtspunkten durchgeführt werden können. Letztlich soll das Modell auf operative Prozesse abbildbar sein. In Abbildung 6.7 ist die Modellierung von Prozeßmodellen im Unternehmensgedächtnis-System angedeutet. Ein Prozeßmodell ist als Aggregation der verwendeten Konzepte darstellbar. Unter den verwendeten Konzepten gibt es wiederum Beziehungen. Prinzipiell gibt es keine Beschränkung, welche Prozeßmodelle ein Unternehmensgedächtnis-System unterstützen kann. Deshalb sind gewünschte Prozeßmodelle Spezialisierungen von Prozeßmodell. In der in Abschnitt 7.4 beschriebenen Fallstudie wurde als Prozeßmodell das FOQUS-Prozeßmodell mit sich selbst instantiiert und für die Modellierung von Prozessen im Unternehmen verwendet. Weitere Modelle sind denkbar und können miteinander interagieren (vgl. [JK99] für weitere Einzelheiten). Abbildung 6.8 zeigt das Gesamtmodell noch einmal im Überblick. Es wurde darauf geach-

193 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 175 Legende: instance of isa Relation Objekt Prozeß enthält Agent führt_aus enthält benutzt unterstützt Prozeß Hilfsmittel erzeugt nutzt enthält Objekt enthält Agent 2 M -Ebene Meta-Ebene Hilfsmittel Wissensagent benutzt UGS- Repository Wissenserzeuger Wissensverbraucher Wissensträger Wissensadministrator führt_aus Wiedergewinnung Monitoring Mmenonischer- Prozeß unterstützt erzeugt nutzt sucht stellt_dar Akquisition Suche FOQUS- PM UGS-Objekt Prozeßmodell Prozeßmodell A Prozeßmodell B enthält Prozeßagent Agent benutzt Prozeßhilfsmittel enthält enthält hat_beziehung_zu führt_aus unterstützt Kernprozeß Wertschöpfungsobjekt erzeugt nutzt enthält Kernaktivität Abbildung 6.8: Gesamtmodell im Überblick

194 176 Ein nachhaltiges vernetztes Verbesserungsmanagement-System tet, eine relativ kleine Anzahl von Konzepten zu modellieren. In diesem Abschnitt ging es um die Frage, wie Wissen prinzipiell langfristig in einer Wissensbasis so organisiert werden kann, daß dieses Wissen rollenbasiert aus den im Unternehmen durchgeführten Prozesse erzeugt, bewahrt und wiederum in diesen Prozessen genutzt werden kann. Dazu wurde das Gedächtnis des VVM mittels Metamodellierungstechniken im Rahmenwerk der kooperativen Informationssystem strukturiert und drei Blickweisen zur Introspektion vorgestellt. Die Modelle erlauben die prozeß, agenten- und systembasierte Untersuchung der Gegenstände des Repositories, welches sich weiter zum Gegenstand der eigenen Untersuchungen machen kann. Die spezifische Anpassung dieser Lösung an den Gesamtansatz erfolgt in einem ersten Schritt über die Modellierung elektronischer Vorgangsmappen. Der Vorgangsmappenansatz verbirgt das Repository weitestgehend vor dem Benutzer, so daß er sich auf die Vorgangsbearbeitung konzentrieren kann. Durch die eingeführten Modellierungmechanismen wird trotzdem der Aufbau, die Füllung und die Nutzung der Wissensbasis sichergestellt. Instantiiert man diesen Ansatz für die Fehlerbearbeitung, so wird weiter sichergestellt, daß aus Fehlern und aus der Bearbeitung von Fehlerfällen gelernt werden kann. Die Einbeziehung des Variantenmanagements mit den Mitteln der Modelle erlaubt das Lernen aus Fehlern, trotz der in der heutigen Produktion verbreiteten Variantenvielfalt Aufbau elektronischer Vorgangsmappen Ausgehend von der in Abschnitt 6.1 erläuterten Architektur erfolgt nun die Gestaltung elektronischer Vorgangsmappen. Die grundsätzliche Idee, replizierte Vorgangsmappen mittels Konfiguration an die spezifischen Bedürfnisse von Arbeitsplätzen anzupassen und die Bearbeitung von Vorgängen nachvollziehbar zu versionieren, haben wir in [KPJ98] anhand des Verbesserungsmanagements entwickelt. Der Aufbau der Vorgangsmappe orientiert sich deshalb an der Unterstützung des Fehlerfallbearbeiters in der aktuellen Eskalation, läßt sich aber für andere vorgangsorientierte Arbeitsabläufe verallgemeinern. Die Darstellung des Aufbaus elektronischer Vorgangsmappen ist deshalb zunächst generisch und wird erst dann an das Verbesserungsmanagement angepaßt. E s lassen sich fünf Segmente identifizieren, die in Tabelle 6.1 aufgelistet sind. Neben dem Segmentnamen sind noch der primäre Verwendungszweck des Segments und die Bindung des Segments innerhalb der Vorgangsmappe aufgeführt. Eine persistente Bindung bedeutet den Erhalt der Informationen über den gesamten Lebenszyklus der Mappe hinweg (wobei noch Informationen hinzugefügt werden können). Eine temporäre Bindung bedeutet, daß das Segment nur an einem Arbeitsplatz gültig ist und dementsprechend von Arbeitsplatz zu Arbeitsplatz vom Mappenmanager ausgetauscht wird. Die Bindung der Segmente an die Vorgangsmappe ist unabhängig von der Sicht auf die Segmente. Das Projektmanagement-Segment umfaßt alle Ablaufstrukturen und Kennzahlen sowohl für die globale als auch die lokale Vorgangsbearbeitung. Wesentliche Aufgaben der Vor-

195 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 177 Segment Verwendungszweck Bindung Projektmanagement Kontrolle und Steuerung des Mappenlebenszyklus Persistent Inhalte Den Vorgang betreffende Daten Persistent Rollenbindungen Zuordnung von Rollen zu Agenten Temporär Applikationsbindungen Zuordnung von Applikationen zur Bearbeitung Temporär Historie Bisher durchlaufende Versionierungen und Persistent Änderungen an den Segmenten Tabelle 6.1: Vorgangsmappensegmente gangsbearbeitung für das Verbesserungsmanagements sind die Kontrolle und Steuerung des Mappenlebenszyklus nach dem Eskalationsprinzip. 8 Das Inhaltssegment enthält alle für die Vorgangsbearbeitung notwendigen Daten bzw. Dokumente. Im Verbesserungsmanagement sind dies die Daten des aktuellen Fehlerbildes, die sich aus der Erfassung, Analyse und Maßnahmedefinition der bisherigen Fehlerfallbearbeitung ergeben haben und, so vorhanden, die Klassifikation des Fehlers. Neben der Historie haben die Rollenbindungen eine wesentliche Bedeutung. Durch sie erfolgt die Konfiguration der Vorgangsmappe. Die Rollenbindungen stellen die Verbindung zwischen ausgewählter Rolle für den nächsten Bearbeiter und Agenten, der die Rolle ausfüllt, her. Über die Rechteprofile der Rolle werden die Bearbeitungsmöglichkeiten festgelegt, während die Rollensicht angibt, welche Inhalte für den Agenten sichtbar sind. Über die in der Rollenbeschreibung aufgeführten Software-Werkzeugtypen und den aktuellen Arbeitsplatz des Agenten werden die Applikationsbindungen festgelegt. Das Historiensegment enthält die bisher erzeugten Versionen der Vorgangsmappe und gibt damit einen detaillierten Überblick über die bisherige Bearbeitung des Vorgangs. Für jeden neuen Bearbeiter wird eine neue Version der Mappe angelegt, mit dem Ziel, die einzelnen Bearbeitungsabschnitte getrennt voneinander im nachhinein analysieren zu können. Von einer Vorgangsmappe und ihren Inhalten können mehrere Versionen existieren. Eine Version wird von genau einem Agenten an einem Arbeitsplatz erzeugt. Jede Version kann beliebig viele Vorgänger und Nachfolger haben, außer der ersten Version (keine Vorgänger) und der letzten Version (keine Nachfolger). 8 Teil des Projektmanagements ist das Weiterleiten von Vorgangsmappen, die nach dem Eskalationsprinzip abläuft (vgl. Abschnitt 3.4). Eine Mappe wird an die nächste Kompetenzstufe geschickt, falls der aktuelle Bearbeiter den Vorgang nicht abschließend bearbeiten kann. Dieses Prinzip soll eine zügige Bearbeitung von Fehlerfällen dadurch ermöglichen, daß die Weitergabe von Mappen aufgrund wohldefinierter Kriterien erfolgt, die die Auswahl des besten nachfolgenden Bearbeiters vorsieht.

196 178 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Fehlermappenmodell Das weiter oben vorgestellte M 2 -Modell abstrahiert beim Konzept Agent von der konkreten Realisierung in Vorgangsbearbeitungssystemen, d.h. es wird nicht zwischen der Rolle und dem Rollenausfüller unterschieden. Jedoch ist für eine rollenspezifische Konfiguration und die Nachvollziehbarkeit der Bearbeitung eine Trennung von Rolle und Agent notwendig. So lassen sich z.b. Sichten und Rechte für eine Rolle definieren, die von verschiedenen Agenten eingenommen werden kann. Zur eindeutigen Identifikation des Bearbeiters eines Vorgangs ist es erforderlich, neben der Rolle auch den Rollenausfüller, d.h. den Bearbeiter, festzuhalten. Die vorgeschlagene Trennung ist beispielsweise in dem Metamodell von Rolle besitzt Person kann bestehen aus produziert führt aus Aktivität Dokument kann be- stehen aus wird benötigt für wird benutzt für Werkzeug Abbildung 6.9: Metamodell nach Deiters (adaptiert aus [Dei97]) Deiters [Dei97] vorhanden, das in Abbildung 6.9 dargestellt ist. Dieses Modell erlaubt die Darstellung von Aktivitäten, die wiederum in weitere Aktivitäten unterteilt werden können. Die Aktivitäten werden mittels Rollen von Personen ausgeführt (führt aus). Jede Person besitzt somit eine Rolle in der Prozeßausführung. Werkzeuge werden bei der Durchführung von Aktivitäten benutzt (wird benutzt in).aktivitäten benötigen (wird benötigt in) und erzeugen (produziert) Dokumente, die wiederum aus Teildokumenten zusammengesetzt sein können (kann bestehen aus). Graphisch ist das Vorgangsprozeßmodell in Abbildung 6.10 veranschaulicht. Die bisherigen Konzepte sind weiß dargestellt, grau die hinzugefügten. Die nachfolgende Übersicht konkretisiert die einzelnen Modellelemente, indem auf ihre Bedeutung für die Vorgangsbearbeitung eingegangen wird. Um eine rollenspezifische Vorgangsbearbeitung mit aufgabenabhängiger Unterstützung in einer heterogenen Hard- und Softwarelandschaft angemessen abzubilden, sind neben der Trennung von Bearbeiter und Rolle zusätzliche Modellierungskonzepte notwendig: Ein Bearbeiter arbeitet bei der Durchführung eines Vorgangs in einer Rolle an einem Arbeitsplatz, an dem spezielle Software-Werkzeuge zur Verfügung stehen. Der Arbeitsplatz visualisiert die Vorgangsmappe. Über Software-Werkzeugtypen, die in

197 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 179 Legende: Prozeßmodell Relation Objekt Prozeß Bearbeiter Agent Vorgangs- PM Agent Hilfsmittel arbeitet_an Arbeitsplatz Inhalte besteht_aus_inhalt füllt_aus hat_beziehung_zu besteht_aus_pm Rolle Rollenbeschreibung erzeugt repräsentiert nutzt Vorgangsmappe Projekt- Management benutzt führt_aus Vorgang bestimmt unterstützt Software- Werkzeugtyp Software- Werkzeug visualiert stellt_zur_verfügung Abbildung 6.10: Vorgangs-Prozeßmodell des VVM der Rollenbeschreibung festgelegt sind (bestimmt), werden die Zugriffsrechte einer Rolle auf Vorgangsmappen und ihre Inhalte umgesetzt. Am Arbeitsplatz erfolgt die Instantiierung der Typen mit konkreten Software-Werkzeugen. E in Vorgang wird von einer Vorgangsmappe repräsentiert. Durch die Einbettung des Vorgangsprozeßmodelles in das Unternehmensgedächtnis-System wird es möglich, daß Vorgänge auch von anderen Prozessen genutzt und erzeugt werden können. D.h., einerseits lassen sich abgeschlossene Vorgänge so im Unternehmensgedächtnis-System verwalten, andererseits können Vorgänge von Prozessen angestoßen werden. 9 Eine Vorgangsmappe repräsentiert - wie gesagt - einen Vorgang. In ihr sind sowohl vorgangsbezogene Inhalte als Informationen zur Kontrolle und Steuerung (Projektmanagement) enthalten. Bei den Vorgangsbearbeitungen treten im wesentlichen die drei aufgeführten Instantiierungen von Objekt auf: 9 Über die nicht dargestellte Instantiierung des M 2 -Modells können Vorgänge modelliert werden, die ihrerseits Vorgänge zum Inhalt haben. Z.B. läßt sich dadurch eine Begutachtung der Effizienz von Vorgängen in Form einer Vorgangsbearbeitung durchführen.

198 180 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Vorgangsmappe: Eine Vorgangsmappe aggregiert alle für einen Vorgang notwendigen Daten, d.h. Inhalte und Projektmanagement. Sie bietet dem Bearbeiter so gute Unterstützung, weil die in der Regel aufwendige Suche nach Informationen für die Durchführung des Vorgangs vermieden wird. Fehlermappen sind Instanzen von Vorgangsmappen. Inhalte: Inhalte umfassen die eigentlichen Daten eines Vorgangs. Sie werden über eine abstrakte, nicht instantiierbare Klasse modelliert und bedürfen daher einer konkreten Spezialisierung für ein Anwendungsfeld. Für das Verbesserungsmanagement sind dies primär die Fehlerdaten. Projektmanagement: Das Projektmanagement legt den Weg von Vorgangsmappen fest; es enthält u.a. Daten zur Überwachung des Vorgangs (Bearbeitungsdauer, Liegezeit, Status etc.). Software-Werkzeugtypen Browser Datenmanipulation Datenaufbereitung Prozeßmanagement Wissenspflege Zugriff auf Daten Lesen Lesen/Transformieren/Schreiben Lesen/Transformieren Lesen/Schreiben Lesen/Transformieren Tabelle 6.2: Software-Werkzeugtypen Hilfsmittel dienen dem Bearbeiter zur Durchführung von Prozessen. Über die Rollenbeschreibung lassen sich Typen definieren, die für die Zugriffsrechte der Rolle adäquat sind. Im folgenden werden Hilfsmittel auf Software beschränkt. 10 Software-Werkzeugtyp: Software-Werkzeugtypen stellen Kategorisierungen von Software-Werkzeugen dar (vgl. Tabelle 6.2). Für jede Rolle ist in der Rollenbeschreibung unter Berücksichtigung der Rechteprofile festgelegt, welche Kategorien zur Verfügung stehen sollen. Ist im Rechteprofil kein Schreibrecht vorgesehen, sind Werkzeuge zur Datenmanipulation und zum Prozeßmanagement nicht nutzbar. Software-Werkzeug: Software-Werkzeuge sind an einen speziellen Arbeitsplatz gebunden (nicht jedes Werkzeug steht an jedem Arbeitsplatz zur Verfügung). Sie werden nach Typen kategorisiert. Aus der Rollenbeschreibung der Rolle des Agenten erfolgt bei der Konfiguration einer Vorgangsmappe die Instantiierung der Typen mit konkreten, am aktuellen Arbeitsplatz vorhandenen Werkzeugen. Auf diese Weise wird der Bearbeiter bei der Durchführung eines Prozesses aufgabenspezifisch unterstützt, ihm werden nur Werkzeuge angeboten, die entsprechend seiner Rolle sinnvoll und am Arbeitsplatz vorhanden sind. Die angesprochenen Beziehungen zwischen den Modellelementen Vorgangsmappe, Version und Rolle sind in Abbildung 6.13 dargestellt. 10 Es sind für die Vorgangsbearbeitung auch andere Hilfsmittel denkbar, sie werden jedoch nicht betrachtet.

199 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 181 Legende: Verantwortung besitzt Rolle besitzt_aktives besitzt_passives Rechteprofil Relation Objekt hat_beziehung_zu Prozeß Agent Hilfsmittel Arbeitsplatzanweisung Anforderung leitet_ab erzeugt Rollenbeschreibung legt_fest Sicht bestimmt Software- Werkzeugtyp Abbildung 6.11: Rollenmodell Bearbeiter: Ein Bearbeiter nimmt für die Durchführung eines Vorgangs eine Rolle an, über die sein Arbeitsplatz und die entsprechende Vorgangsmappe konfiguriert werden. Er erhält so eine aufgabenspezifische Unterstützung, in dem ihm eine zugeschnittene Sicht auf den Mappeninhalt gegeben wird und sinnvolle Hilfsmittel angeboten werden. Als Rolleninhaber kann er Inhalte der Vorgangsmappe nutzen und erzeugen. Arbeitsplatz : Ein Arbeitsplatz stellt dem Agenten eine Umgebung für die Vorgangsbearbeitung zur Verfügung. Dazu gehören u.a. die Visualisierung der Vorgangsmappe und das Anbieten aktuell verfügbarer Werkzeuge. Rolle: Zu einer Rolle gehören nach [BS95, Ste97] genau eine Rollenbeschreibung, definierte Verantwortungen und zwei Rechteprofile, ein aktives und ein passives (vgl. Abbildung 6.11). Rollenbeschreibung: Die Rollenbeschreibung enthält neben mehreren Arbeitsplatzanweisungen und Anforderungen für die Rolle die Definition einer Sicht auf die Inhalte einer Vorgangsmappe. Weiterhin gehören eine beliebige Anzahl Software-Werkzeugtypen, die auf den Aufgabenbereich der Rolle abgestimmt sind, zur Beschreibung. Eine Vorgangsmappe läßt sich durch diese Angaben auf die Intention einer Rolle abstimmen. Für jede Inhaltskomponente der Mappe wird festgelegt, ob sie für die Rolle von Bedeutung ist, mit dem Ziel, Informationsüberfrachtung zu vermeiden. Nur notwendige Daten sollen für den Rolleninhaber sichtbar sein. Verantwortung : Die Verantwortung gibt Aufschluß über die grundsätzlichen Zuständigkeiten und Kompetenzen der Rolle. Rechteprofile: Die beiden Rechteprofile legen den Zugriff auf eine Vorgangsmappe fest, das aktive Rechteprofil wird beim Bearbeiten einer Mappe wirksam,

200 182 Ein nachhaltiges vernetztes Verbesserungsmanagement-System das passive nach dem Weiterleiten, wenn die nachfolgende Bearbeitung beobachtet wird. Es existieren vier Profile, die in Tabelle 6.3 aufgeführt sind. Dort ist angegeben, welche Operationen für das jeweilige Recht zulässig sind. Rechteprofile sind notwendig, Kompetenzen umzusetzen und verteiltes Arbeiten zu unterstützen. Z.B. sollte das Schließen einer Mappe nur in einer Rolle durchführbar sein, die gewährleistet, daß der Inhaber in der Lage ist, eine sinnvolle Entscheidung über das Schließen zu einem bestimmten Zeitpunkt zu treffen. Soll eine Mappe nach dem Weiterleiten erneut geladen werden, um den Fortschritt zu ermitteln, so dürfen Operationen, die den Inhalt verändern, nicht möglich sein, da sonst zwei Agenten dieselbe Version einer Mappe verändern, wodurch Inkonsistenzen auftreten können. Außerdem wäre die Nachvollziehbarkeit beeinträchtigt, weil nicht erkennbar ist, welcher Agent welche Änderungen durchgeführt hat. Koordinator Prüfer Durchführer Benutzer Lesen ja ja ja ja Erzeugen ja ja nein nein Schreiben ja ja ja nein Zusammenführen nein ja nein nein Schließen nein ja nein nein Tabelle 6.3: Rechteprofile Fehlerdatenmodell Für die Erfassung, Analyse und Klassifikation von kommunizierbaren und interpretierbaren Fehlerfällen und die Entwicklung von Werkzeugkomponenten des Verbesserungsmanagements ist ein einheitliches Fehlerdatenmodell (vgl. auch [Pfe97]) notwendig, das präzise die zum Begriff Fehler gehörenden Konzepte und dessen Umfeld strukturiert. Abbildung 6.12 zeigt das Modell im Überblick. Es lassen sich drei inhaltliche Bereiche der Beschreibung identifizieren. Fehlerfallerfassung, -analyse und -korrektur: Im Laufe des Analyseprozesses werden hier die möglichst multimedialen Beschreibungen (um die Kontextualität der Beschreibung anzureichern) der erfaßten Symptome, die möglichen und tatsächlich identifizierten Ursachen, die möglichen und tatsächlich durchgeführten Maßnahmen und die Rückmeldungen aufgrund der durchgeführten Maßnahmen festgehalten. Ein solches Analysetupel wird zusammenfassend als SUMOR-Element 11 bezeichnet. Solche Analysen setzen vollständige Fehlererfassung voraus. Jedes SUMOR-Element wird durch möglicherweise multimediale Elemente beschrieben. Deshalb bildet das 11 Symptom - Ursache - Maßnahme - Ort - Rückmeldung

201 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 183 Fehlerdatenmodell diese fünf Fehlerattribute in der relationalen Datenbank auf Binary large objects (Blobs) ab. Symptome beschreiben das Fehlerereignis, wie es sich durch Messungen, Augenschein oder andere Erhebungsmethoden dem Erfasser darstellt. Ursachen bieten Aufschluß über die Gründe eines Fehlerfalls. Sie nehmen Bezug auf die Symptome und Orte eines Fehlerereignisses und bilden analytisch die Grundlage für die Ableitung von Maßnahmen. Ursachen für einen Fehlerfall können zutreffen oder nicht zutreffen. Dies muß festgehalten werden. Ebenso kann ein Fehlerfall eine monokausale oder multikausale Ursachen-Wirkungs- Kette haben. Maßnahmen umfassen Handlungen zur Beseitigung eines Fehlerfalls oder Fehlers. Maßnahmen können somit einen reaktiven oder proaktiven Handlungshorizont haben. Maßnahmen können hinsichtlich ihrer Wirksamkeit und ihres Horizonts bewertet werden. Orte beschreiben, wo das Fehlerereignis aufgetreten ist. Ein Fehlerereignis kann einen oder mehrere Orte besitzen. Rückmeldungen enthalten Bemerkungen, die den vorherigen Bearbeitern Informationen über die Korrektur des Fehlers geben könnten. Dies geht noch einmal über die reine Replikation der Vorgangsmappe hinaus. In der Rückmeldung steht eine möglicherweise abschließende Bemerkung, die als konkrete Handlungsanweisung eine schnellere und zielgerichtete Bearbeitung eines Fehlerfalls erlaubt. Analyseergebnisse sollten in die proaktiven Methoden des Verbesserungsmanagement einfließen und entsprechend aufbereitet werden. Fehlerfallklassifikation: Diese Kategorie beschreibt das Fehlerstrukturwissen in der Wissensbasis. Hier wird festgelegt, welche Fehlerattribute bei der Fehlererfassung aufgenommen werden. Dazu gehört eine eindeutige Identifizierung des Fehlerereignisses (Art und Bedeutung); Informationen über das fehlerhafte Produkt oder den fehlerhaften Prozeß, die Folgen (z.b. Maschinenstillstand) und die Behandlung (z.b. Stoppen des Prozesses) des Fehlers. Daraufhin ist der Fehler hinsichtlich seiner Wichtigkeit und Dringlichkeit einzuordnen. In der Art wird festgehalten, nach welchen Kriterien, z.b. Produktfehler, Prozeßfehler, Nutzungsfehler, Anlagenfehler, kategorisiert wird (Fehlerartenbaum), und in welche Fehlerfallklasse (Fehler) er damit eingeordnet werden kann. Fehler sind somit Blattknoten eines baumartigen Fehlerartengraphen. Dieses Fehlerstrukturwissen muß wegen der Komplexität der Nachvollziehbarkeit von Einzelfällen und der Relevanzbildung (vgl. Abschnitt 3.3.8) variantenorientiert erfolgen. Zur Erstellung von flexiblen, varianten- und problemorientierten Fehlerfallklassifikation wird ein eigenes Werkzeug in Abschnitt 6.5 vorgestellt. Die Bedeutung beschreibt die Wichtigkeit eines Fehlerfalls für das Unternehmen, deshalb ist die Art der Realisierung auch unternehmensabhängig, um

202 184 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Lösungen zu respektieren, die im Unternehmen eingeführt sind. Eine Möglichkeit ist beispielsweise eine vierstufige Gewichtung von Fehlerfällen in keine, niedrige, mittlere und hohe Bedeutung. Die Dauer gibt die Bearbeitungszeit einer Fehlermappe an. Dauer läßt sich in Liege- und Bearbeitungszeiten unterscheiden. In der Endversion einer Vorgangsmappe kann die akkumulierte Dauer eingetragen werden. Die Kosten lassen sich auch nur unternehmensspezifisch ermitteln, hängen sie doch zumeist an einer übergreifenden Kostenrechnung. Diese Auswertung kann quantitativ oder qualitativ erfolgen. Qualitative Analysen erfolgen aufgrund der Erfahrung der Mitarbeiter oder Kundenstammdaten, in denen die Bedeutung des Kunden für das Unternehmen hinterlegt ist. Für eine quantitative Analyse müssen Fehlerereignisse bereits während der Erfassung kategorisiert werden. Anwendbare Methoden für Fehlerkategorien sind z.b. nach [SS98, S. 198ff.]: Häufigkeitsverteilungen: Nennungen von Kategorien können durch statistische Funktionen wie Mittelwert und Streuung verglichen werden. Kreuztabellierungen: Aus allen Kategoriekombinationen werden Paare gebildet, deren Nennung ebenfalls verglichen werden kann. Frequenz-Relevanz-Analyse: Zu Fehlerereignissen werden Relevanzfaktoren erhoben, die ein Maß für die Bedeutung eines Ereignisses aus Kundensicht darstellen. Das Produkt aus Häufigkeit und durchschnittlicher Relevanz bildet über alle Kategorien einen vergleichbaren Relevanzwert. Fehlerfallumfeld: Das Fehlerfallumfeld (Kontext) beschreibt Datenquellen, von denen das Fehlerdatenmodell mittels Schnittstellen Daten importieren kann. Dies sind z.b. Werkzeuge aus den Ebenen Vollständige Information und Erweiterter Workflow eines Helpdesk-Systems, also externe Wissensbasen (Werkzeug 10), Anlagen- und Produktmodell (Werkzeug 16) und Kundenidentifikation (Werkzeug 17). Die Realisierung dieser Werkzeuge ist abhängig vom konkreten Unternehmen. Zusätzlich gehören die leistungserstellenden Prozesse, die die Fehlerfälle erzeugt haben, zum Fehlerfallumfeld. In der Modellierung bedeutet dies, daß jedes UGS-Objekt Kontext eines Fehlerfalls sein kann Versionierung und Konfiguration replizierter Vorgangsmappen Die folgende Vorgehensweise zur Versionierung und Konfiguration von Vorgangsmappen basiert auf relationalen Datenbanken, die schon im Abschnitt 4.5 als Standard-Datenbanken für das Verbesserungsmanagement vorgeschlagen wurden. Es wird davon ausgegangen, daß eine SQL-Schnittstelle zur Verfügung steht. Die bisher erarbeiteten Lösungsideen werden

203 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 185 Vorgangsmappe besteht_aus_inhalt Inhalte Legende: ordnet_ein Fehler Fehlermappe besteht_aus_fd Fehlerdaten Relation Objekt Prozeß Fehlerartenbaum Agent Hilfsmittel steht_in Art Bedeutung Dauer Kosten Ort Rückmeldung SUMOR Kontext Symptom Ursache Maßnahme Abbildung 6.12: Fehlerdatenmodell nun zu einem Gesamtmodell zusammengeführt, indem für jede Anforderung zur Versionierung und Konfiguration eine konkrete Umsetzung angegeben wird. Legende: erzeugt Relation Objekt Vorgänger Version Nachfolger Bearbeiter Agent Prozeß versioniert_vm Agent Hilfsmittel versioniert_inhalte besteht_aus_inhalt wird_erzeugt_an Vorgangsmappe Arbeitsplatz Inhalte Abbildung 6.13: Vorgangsmappe - Version - Bearbeiter Versionierung Das Versionierungsmodell für Vorgangsmappen unterscheidet grundsätzlich zwischen Objekt- und Versionsebene in Anlehnung an CoMa. In die Objektebene werden die Datenmodelle der Vorgangsmappe, d.h. das Vorgangsmappen- und das Inhaltsdatenmodell, eingebettet (vgl. Abbildung 6.13). Zu den Anforderungen im einzelnen:

204 186 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Abbildung 6.14: Versionierung von Vorgangsmappen AV1: Eine Version (Revision) einer Vorgangsmappe wird in der Datenbank als ein Tupel abgelegt. Historische Beziehungen zwischen Versionen werden als Versionsgraph dargestellt. Zu jeder Mappenversion existieren Verweise auf die zugehörigen Inhaltskomponenten. Dies ist schematisch in Abbildung 6.14 dargestellt: Die Objektebene jeder Version unterscheidet sich nicht. Es differiert lediglich die Auswahl der Inhaltskomponentenversionen auf Versionsebene bei der Konfiguration. Die zur Nachvollziehbarkeit der Bearbeitung einer Mappe notwendigen Informationen sind im ER-Modell (vgl. Abbildung 6.15) festgehalten. 12 Eine neue Version einer Vorgangsmappe wird automatisch bei jedem Laden erzeugt, der Benutzer hat darauf direkt keinen Einfluß. Dadurch läßt sich die nötige Nachvollziehbarkeit der Bearbeitung gewährleisten, weil so Bearbeitungszeiten und Arbeitsplatzwechsel genau erfaßt werden können. Um auch bei weltweiter Bearbeitung einer Mappe eindeutige Annahmeund Abgabezeitpunkte definieren zu können, ist es notwendig, die universelle Weltzeit (vgl. RCS) zu verwenden. In der relationalen Datenbank (vgl. Abbildung 6.16) wird für die Vorgangsmappen eine Tabelle mit ID, Namen und Beschreibung angelegt, für Versionen eine Tabelle mit den Spalten ID, Name, Beschreibung, Annahme, Abgabe und Verweisen auf Rolle und Arbeitsplatz des Agenten sowie einen Verweis auf die zugehörige Vorgangsmappe. Fehlerattribute werden im Fehlerdatenmodell in eigenen Tabellen abgelegt. In der Konfigurationstabelle werden die zur Version gehörenden Fehlerattribute festgehalten. AV2: Für die Inhaltskomponenten einer Mappe werden ebenfalls Versionstupel in der Datenbank erzeugt. Jedoch werden explizit keine Beziehungen zwischen den Versionen einer Komponente festgehalten, sie sind implizit in den Versions- und Konfigura- 12 Vergleiche auch die Überlegungen zum Workflow-Historie-Management in [KAD98].

205 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 187 tionsbeziehungen der Vorgangsmappe enthalten. Dies sei am Beispiel aus Abbildung 6.14 verdeutlicht: Gehört Version 1 von Komponente 2 (als K 2 V 1 bezeichnet) zu Version 2 der Vorgangsmappe (VMV 2 ), so ist K 2 V 1 neu in VMV 2 erzeugt worden, es sei denn, K 2 V 1 gehört auch zu VMV 1. AV3: Varianten von Vorgangsmappen unterscheiden sich nicht von Revisionen, sie sind lediglich im Versionsgraphen dadurch erkennbar, daß eine vorhergehende Mappenversion mehrere Nachfolger hat (vgl. Abbildung 6.14 Ve2 mit Ve3 und Ve4). Varianten werden beim Weiterleiten einer Mappe erzeugt, falls mehr als eine Rolle für die nachfolgende Bearbeitung gewählt wird. AV4: Das Zusammenführen von Vorgangsmappen wird auf Ebene der Inhaltskomponenten durchgeführt, wobei dafür in Abhängigkeit von der Art der Komponenten verschiedene Möglichkeiten vorgesehen sind. Komponentenlisten werden automatisch aneinandergehängt. Doppelte Elemente werden dabei eliminiert. Komponentenlisten sollten jedoch auch benutzergesteuert zusammenführbar sein. Numerische Werte lassen sich auf einfache Weise addieren. Für Inhaltskomponenten, für die nur ein eindeutiger Wert existieren darf, z.b. Priorität eines Vorgangs, ist eine Auswahl durch den Agenten am sinnvollsten. Name Name Beschr. AR Vorgangsmappe gehört zu Version Historie Beschr. gehört zu AP Annahme Abgabe gehört zu Inhalt Inhalt Typ Inhaltskomponente N Inhaltskomponente 1 Typ AR = Agent in Rolle AP = Arbeitsplatz Beschr. = Beschreibung Abbildung 6.15: ER-Modell der Versionsinformationen Version Relation Fehlerattribut 1 (FA1) ID Name Beschreibung Annahme Abgabe... Version FA1 ID Inhalt keine Lösung <Bild1> erfolgr. beh <Bild2> 2 2 Abbildung 6.16: Abbildung von Versionen in Tabellen der relationalen Datenbank

206 188 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Konfiguration Die Konfiguration baut auf dem Versionsmodell auf. Neben der Auswahl von Versionen ist die Rolle des aktuellen Agenten und sein Arbeitsplatz zu berücksichtigen. Zu den Anforderungen im einzelnen: AK1: Beim Laden einer Vorgangsmappe vom UG-Trader werden die temporären Segmente Rollenbindungen und Applikationsbindungen an konkrete Instanzen gebunden, d.h. an die aktuell im Klienten gewählte Rolle und die am Arbeitsplatz verfügbaren Werkzeuge. AK2: Am lokalen Arbeitsplatz wird das Rollenmodell umgesetzt: Die Inhaltskomponenten werden in der rollenspezifischen Sicht angezeigt, d.h. für den Rolleninhaber nicht interessante Daten werden ausgeblendet. Die Sichtbarkeit für jede Komponente wird als boolesche Option (vgl. COV) modelliert. Wie sich die Sicht auf die Komponenten auswirkt, ist in Abbildung 6.17 beispielhaft veranschaulicht. Verfügbare Werkzeuge werden nach Typen kategorisiert angeboten. Weitere Rolleninformationen (Verantwortung, Arbeitsplatzanweisungen, Anforderungen) werden dargestellt. Abbildung 6.17: Konfigurationsmodell für Vorgangsmappen AK3: Die Rechteprofile der Rolle, die die Zugriffsrechte auf eine Mappe festlegen, wirken sich auf die durchführbaren Operationen aus. Das aktive Rechteprofil wird

207 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 189 verwendet, wenn eine Mappe aus der Aufgabenliste geladen worden ist, das passive, wenn schon weitergeschickte Mappen beobachtet werden. AK4: Beim Erzeugen einer neuen Version einer Vorgangsmappe wird die Konfigurationsliste der Vorgängerversion kopiert. Beim Hinzufügen, Verändern und Löschen von Inhaltskomponenten durch den Agenten wird die Konfigurationsliste automatisch angepaßt. Diese Konfigurationslisten werden beim Laden einer Mappe ausgewertet. Wird eine Mappe neu erzeugt, wird dafür eine initiale Version mit Verweisen auf initiale Inhaltskomponenten angelegt, die zwingend in der Mappe enthalten sein müssen Replikation Die verteilte Architektur sieht vor, daß die Vorgangsbearbeitung dezentral an lokalen VVM- Arbeitsplätzen geschieht. Die dort generierten Daten sollen jedoch im gesamten System verfügbar sein. Daher ist ein Replikationsmechanismus notwendig, der die Verteilung der Daten übernimmt. Im Unterschied zu Replikationsstrategien in anderen Ansätzen, wie z.b. Lotus Notes, ist für versionierte Vorgangsmappen keine Replikationskontrolle vorzusehen, die die Konsistenz der Datenverteilung gewährleistet, weil Versionen nur während ihrer Erstellungsphase verändert werden können. Die Erstellungsphase bezeichnet den Zeitraum zwischen dem Laden und Schließen einer Version bzw. dem Weiterleiten oder Schließen der Vorgangsmappe. Eine nachträgliche Veränderung würde dem Grundgedanken der Versionierung widersprechen. Eine Version hält den Zustand eines Objekts zu einem bestimmten Zeitpunkt fest. Die Replikation beschränkt sich daher auf die Verteilung neuer Versionen, bestehende Daten müssen nicht aktualisiert werden. Die Umsetzung der Anforderungen im einzelnen: AR1: Beim Laden von Vorgangsmappen am Arbeitsplatz werden alle im UG-Trader für die aktuelle Agent-Rolle-Kombination wartenden Vorgangsmappen in die lokale Datenbank kopiert. Es wird nicht nur die letzte Version repliziert, sondern alle bisher erzeugten Versionen, um am lokalen Arbeitsplatz auf die Historie zugreifen zu können. In Abbildung 6.18 a) ist das Laden schematisch dargestellt. Der Datenabgleich in umgekehrter Richtung zwischen den lokalen Arbeitsplatzdatenbanken und der zentralen Datenbank erfolgt beim Weiterleiten oder Schließen einer Mappe. Dabei werden alle lokal neu erzeugten Versionen in die zentrale Datenbank kopiert und bei Bedarf mit den wegen der eingeschränkten Rollensicht nicht sichtbaren Inhaltskomponenten der Ausgangsversion vervollständigt. AR2: Bei der Replikation werden nur die am lokalen Arbeitsplatz nach der aktuellen Rollensicht sichtbaren Inhaltskomponenten der Versionen in die Arbeitsplatzdatenbank kopiert. Nicht sichtbare Komponenten würden überflüssigen Datentransfer verursachen, sie werden daher nicht repliziert. Das Beispiel in Abbildung 6.18 veranschaulicht die rollenspezifische Replikation: Die Komponente K3 ist für die aktuelle Rollensicht nicht sichtbar und wird daher nicht in die Arbeitsplatzdatenbank kopiert

208 190 Ein nachhaltiges vernetztes Verbesserungsmanagement-System zentrale Datenbank lokale Arbeitsplatz- Datenbank zentrale Datenbank lokale Arbeitsplatz- Datenbank V1 V2 K1 K2 K3 K1 K2 K3 V1 V2 K1 K2 K1 K2 V1 V2 V3 V4 K1 K2 K3 K1 K2 K3 K1 K2 K3 K1 K2 K3 V1 V2 V3 V4 K1 K2 K1 K2 K1 K2 K1 K2 a) Laden b) Weiterleiten/Schließen Legende: kopieren vervollständigen V1 K1 K2 Version einer Vorgangsmappe mit Konfigurationsliste Abbildung 6.18: Replikationsmechanismus (Teil a der Abbildung). Beim Replizieren von der lokalen Datenbank in den UG- Trader muß beachtet werden, daß nicht sichtbare Komponenten (im Beispiel K3) im UG-Trader mit Hilfe der letzten Vorversion (V2) vervollständigt werden (Teil b der Abbildung). AR3: Die nach dem Weiterleiten im UG-Trader neu vorhandenen Versionen können von den bisherigen Bearbeitern der Vorgangsmappe prinzipiell sofort eingesehen werden. Jedoch bietet sich eine andere Vorgehensweise an, mit der die Zugriffe auf den Vermittler und damit die Netzbelastung gering gehalten werden können. In veränderbaren zeitlichen Abständen stellt ein Überwachungsprozeß im Mappenmanager eine Anfrage nach neuen Versionen an den UG-Trader. Die eigentliche Replikation in die Arbeitsplatzdatenbank erfolgt erst auf expliziten Wunsch des Bearbeiters. Diese zeitlich verzögerte Replikation entspricht dem Vorgehen in CES und ClearCase, neue Versionen werden allen Systembenutzern erst nach ihrer Fertigstellung zugänglich gemacht. AR3: Zum netzunabhängigen Arbeiten ist es notwendig, alle im Vermittler für eine Rolle-Agent-Kombination wartenden Mappen in die lokale Datenbank zu kopieren. Dies wird standardmäßig durchgeführt. Für weitergeleitete Vorgangsmappen kann der Benutzer das Replizieren neu erzeugter Versionen anstoßen. Die Operationen Weiterleiten und Schließen sind netzunabhängig nicht möglich, da für sie der UG- Trader zwangsläufig benötigt wird, alle übrigen Operationen können durchgeführt werden.

209 6.2 Ein Unternehmensgedächtnis-Repository für das VVM Mnemonische Prozesse Über die Akquisition kann der Mitarbeiter Fehlerwissen hinzufügen und existierendes Fehlerwissen nachvollziehbar verändern. Die Attribute des gewählten Konzepts werden entsprechend angezeigt und können gefüllt oder geändert werden. Die Änderung eines Attributwertes würde zur Überschreibung, d.h. zur Löschung des bisherigen Wertes führen. Da aber eine Aufgabe des Unternehmensgedächtnis-Systems die Bewahrung des Unternehmenswissens ist, wird zuvor das zu überschreibende Wissen in einer Hintergrunddatenbank ausgelagert, so daß keine endgültige Löschung erfolgt, dieses Wissen aber nicht zu Inkonsistenzen im aktuellen Wissensbestand führt. Durch den möglichen gleichzeitigen Zugriff auf das Unternehmensgedächtnis-System müssen während der Akquisition die betroffenen Elemente gegen parallele Änderungen geschützt werden. Dies wird durch Schreibsperren auf den entsprechenden Tabellen erreicht. Mit dem Element wird auch der eingebende Benutzer als Wissenserzeuger abgespeichert. Dadurch kann später auf diesen Wissenserzeuger zugegriffen werden, falls kein Wissensexperte ermittelt werden kann. Außerdem kann Vertrauen in das erzeugte Element geschaffen werden, falls der Wissenserzeuger auch als Experte für dieses Objekt gilt. Die Generierung von Wissensprofilen wird in Abschnitt behandelt. Weiterhin wurden folgende Such- und Wiedergewinnungsprozesse im Unternehmens-Gedächtnisrepository realisiert: Geführte Suche über die Konzepte des Metamodells Durch die Nutzung des Metamodells kann die Suche über Anfragen nach Konzepten des Metamodells durchgeführt werden. Es kann nach kompletten Prozeßmodellen, einzelnen Prozessen, nach Hilfsmittel und Mitarbeitern gesucht werden. Alle genannten Konzepte können mit enthält-relationen im Modell verfeinert werden. Auch der mnemonische Prozeß bildet dies nach. Nach Wahl der Suchkategorie wird eine Auswahlliste mit Instanzen der Konzepte angeboten, aus der der Benutzer das gesuchte Element anwählen kann. Indexsuche Neben der Suche über Konzepte, ist der gesamte Wissensbestand indexiert und kann über einen Index, der den Namen der Instanz und seine Konzeptklasse darstellt, ausgewählt werden. Volltextsuche Der gesamte textuelle Bestand des Unternehmensgedächtnis-Systems kann nach vom Benutzer gewählten Schlagworten oder Zeichenketten durchsucht werden. Mit dieser Funktion kann auf Elemente des Wissensbestands zugegriffen werden, von denen weder Name noch Konzeptklasse bekannt sind. Anzeige des gesuchten Elements und Navigation Ist das gesuchte Element gefunden, wird es mitsamt seinen relevanten Attributen angezeigt. Zusätzlich sind alle Beziehungen, die durch das Metamodell definiert sind, als Links dargestellt und damit anwählbar. So kann vom gefundenen Element aus

210 192 Ein nachhaltiges vernetztes Verbesserungsmanagement-System der Wissensbestand navigierend durchsucht werden. Direkter Zugriff auf Dokumente Dokumente, deren Dateiformat auf dem Rechner zugänglich sind, können direkt aus dem Unternehmensgedächtnis-Systeme aufgerufen werden. Hierzu wird das benötigte Programm zur Präsentation der Datei mit der entsprechenden Datei gestartet. Das manuelle Starten und das Durchsuchen der Verzeichnispfade von Datei-Servern entfällt dadurch. Asking an Expert Die Wissensträger zu einem gesuchten Element werden zusätzlich angezeigt. Durch den Prozeß Asking an Expert wird eine vorkonfigurierte an diesen Wissensträger erzeugt, die weiter ergänzt werden kann. Sowohl die Kommunikation zu nicht anwesenden Wissensträgern als auch der Zugriff auf weiteres implizites Wissen des Wissensträgers werden unterstützt. Verwaltungsprozesse auf dem Wissensbestand sorgen für die Dauerhaftigkeit und Konsistenz des Wissens. Dazu werden den Wissensadminstratoren, die diese Prozesse durchführen, gesonderte Rechte übertragen. Agentenverwaltung Die Agentenverwaltung verlangt, daß sich jeder Benutzer vor der Nutzung des Systems mit seinem Namen und einem Password identifiziert. Jede Interaktion mit dem System wird festgehalten. Dies bezieht sich sowohl auf die Interaktion mit der Benutzeroberfläche als auch auf Transaktionen im Repository. Nur so können die Beziehungen zwischen dem aktuellen Wissensagenten und den Prozessen festgehalten werden. Weiterhin ist die Identifizierung des Benutzers für die Zuordnung und die Überwachung der Prozesse innerhalb des Eskalationsmanagers notwendig. Datensicherung Eine Datensicherung des Bestandes wird für eine dauerhafte Speicherung auf tertiären Datenträgern vorgenommen. Dazu werden die Exportfunktionalitäten des relationalendbmsgenutzt. Generierung von Daten für Volltextsuche Für eine effiziente Volltextsuche ist die Erzeugung einer Tabelle notwendig, die allen Elementen des Wissensbestands die aktuellen textuellen Beschriftungen zuordnet. Der dazu notwendige Platz wird aus Geschwindigkeitsgründen in Kauf genommen. Die Reorganisation kann explizit oder in Leerlaufzeiten automatisch angestoßen werden Generierung von Wissensprofilen Für ein Unternehmen ist es wichtig zu wissen, welches Wissen Mitarbeiter besitzen. Die Transparenz des Wissens innerhalb und außerhalb der Organisation kann gesteigert werden, um herauszufinden, auf welchen Gebieten Wissensdefizite herrschen oder welcher Mitarbeiter für eine bestimmte Aufgaben hinreichende Kompetenzen besitzt, d.h. als Experte

211 6.2 Ein Unternehmensgedächtnis-Repository für das VVM 193 gilt. Diese Informationen sind auch dann von Bedeutung, wenn ein Mitarbeiter das Unternehmen verläßt, da die entstehenden Wissenslücken bestimmt werden können. Die Veranschaulichung dieser Informationen kann in sogenannten Wissensträgerkarten erfolgen, die in verschiedenen Ausprägungen in der Literatur aufgegriffen worden sind. Zwei Beispiele, Wissenstopographien [Sch98a] und Wissensquellenkarten [PRR97], sind in Abbildung 6.19 dargestellt. [PRRo97] Abbildung 6.19: Beispiele für Wissensträgerkarten Der Repository-Ansatz gestattet es, ohne Aufwand solche Wissenlandkarten automatisch zu erstellen. Im Unternehmensgedächtnis-System sind Beziehungen zwischen den Agenten und den Objekten des Systems dokumentiert. Diese Beziehung kann nun ausgenutzt werden, um ein Wissensprofil für jeden Mitarbeiter zu erzeugen, das angezeigt werden kann. Dieses Profil wird auf Anfrage neu generiert, so daß automatisch die jeweils neueste Version des Profils zur Verfügung steht. Abbildung 6.20 zeigt einen Bildschirmabzug des Systems mit dem Ausschnitt eines Mitarbeiters. 13 Das Profil wurde mittels eines einfachen mnemonischen Prozesses aus der Datenbank extrahiert. Kern des mnemonischen Prozesses ist folgende, in SQL formulierte Abfrage. Sie durchsucht zwei Tabellen nach dem Namen eines Agenten. Die Tabellennamen wurden in englischer Sprache gehalten. OMSObject entspricht dem Konzept UGS-Objekt. AgentFulfilOMSObjectRole enthält die Rolle eines Wissensagenten bezüglich eines bestimmten Objekts. Es drückt die hat Beziehung zu Relation aus Abbildung 6.4 aus und verdeutlicht die Vorzüge des dokumentbasierten Modells. In OMSObject stehen gemäß der Metamodellierung alle Objekte der Wissensbasis in einer Tabelle, so daß über Agenten, Prozesse, Hilfsmittel und deren Spezialisierung uniform gesucht werden kann. Die Anfrage differenziert mittels AgentFulfilOMSObjectRole.Type zwischen den möglichen Wissensagenten des Modells, wodurch die Spezialisierungsbeziehung in der konzeptuellen Modellierung aufgelöst wurde. Das Join-Kriterium der Abfrage ist die ID der Objekte. "<NAME>" deutet auf den einzigen Parameter der Abfrage; der Name des Agenten. SELECT AgentFulfilOMSObjectRole.Type, 13 Teile des Bildschirmsabzugs sind aus Gründen des Vertrauens- und Datenschutzes unleserlich gemacht.

212 194 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Abbildung 6.20: Wissensprofil eines Mitarbeiters im Unternehmensgedächtnis-System (Bildschirmabzug) OMSObject.Name, OMSObject.Description, OMSObject.Type FROM AgentFulfilOMSObjectRole, OMSObject WHERE AgentID = "<NAME>" && AgentFulfilOMSObjectRole.OMSObject = OMSObject.ID 6.3 Modellierung zur Laufzeit Im Zusammenspiel mit dem Unternehmensgedächtnis-Repository sind Modelländerungen zur Laufzeit durch die Ausführung der Prozeßbearbeitung möglich. Dazu soll zunächst der Eskalationsmanager beschrieben werden. Der Eskalationsmanager unterstützt den Arbeitsablauf der Mitarbeiter durch Begleitung der Prozeßausführung. Die Mitarbeiter können dabei die Rollen des Koordinators, des Durchführers und des Prüfers annehmen. Der Ablauf der vollständigen Ausführung eines

213 6.3 Modellierung zur Laufzeit 195 Prozesses ist in den Abbildungen 6.21, 6.22 und 6.23 aus Sicht der Rollen dargestellt. Die Ausführung von Prozessen wird kontextfrei mittels endlicher Automaten spezifiziert. Der Prozeß durchläuft dabei für jede Rolle drei verschiedene Zustände (vgl. Abschnitt 3.4.3). Ein Prozeß ist neu, wenn er dem Benutzer zur Erledigung zugeteilt wurde, der Benutzer ihn aber noch angenommen hat. Nimmt der Benutzer den Prozeß an, geht dieser in den Status aktiv über. In allen anderen Fällen, in dem der Benutzer zwar mit dem Prozeß verbunden ist, aber zu diesem Zeitpunkt nicht direkt in die Bearbeitung eingreifen kann, hat der Prozeß für diesen Benutzer einen passiven Zustand. Die Übergabe der Prozesse zwischen zwei Rollen wird durch die entsprechend eingekreisten Ziffern in den Abbildungen symbolisiert. Der Eskalationsmanager ist unabhängig von einer konkreten Prozeßmodellierung konzipiert. Das Symbol der Vorgangsmappe deutet lediglich an, daß strukturierte Informationen übertragen werden. Die Koordination der Aktivitäten erfolgt über . Koordinator neu erzeugter Prozeß Eskalation passiver Prozeß 1 Legende: Übergang Initialzustand Änderung 1 Zustand mit Übergang neuer / zu bearbeitender Prozeß 3 vom Durchführer abgelehnter Prozeß 4 vom Prüfer abgelehnter Prozeß Änderung geänderter Prozeß Eskalation Endzustand Weiterleiten einer Mappe passiver Prozeß 2 6 gepüfter Prozeß Archivierung archivierter Prozeß Abbildung 6.21: Prozeßablauf aus Sicht des Koordinators Der Prozeßablauf aus Sicht des Koordinators kann folgendermaßen beschrieben werden. Aus dem Startzustand sind vier Übergänge möglich. Im Normalfall leitet der Koordinator in der Eskalation die Vorgangsmappen an den Durchführer weiter, der sie dann bearbeitet (Übergang 1 ). Der Zustand der Prozeßbearbeitung wechselt für den Koordinator von aktiv auf passiv. Lehnt der Durchführer die Bearbeitung ab, z.b. weil er sich nicht zuständig fühlt oder die zeitlichen Vorgaben nicht haltbar sind (Übergang 3 ), kann der Koordinator mit dem Durchführer in Verhandlungen eintreten, die letztlich die Vorgaben ändern. Der geänderte Prozeß führt dann wieder auf den Normalfall zurück. Wird der Prozeß vom Prüfer abgelehnt (Übergang 4 ), weil ihm die Bearbeitung z.b. nicht erfolgreich erscheint, muß wiederum verhandelt werden und der geänderte Prozeß eskaliert werden (Übergang

214 196 Ein nachhaltiges vernetztes Verbesserungsmanagement-System 2 ). Der Zustand des Prozesses wechselt wiederum von aktiv auf passiv. Ein erfolgreich abgeschlossener Prozeß (Übergang 6 ) kann archiviert werden. Die Archivierung des Prozesses ist der Endzustand der Prozeßbearbeitung aus Sicht des Koordinators. Durchführer 1 neu zu bearbeitender Prozeß Annahme aktiver Prozeß Eskalation passiver Prozeß 1 neuer / zurückgegebener Prozeß 5 vom Prüfer zurückgegebener Prozeß Ablehnung passiver Prozeß 3 Fertigmeldung Legende: 1 passiver Prozeß Übergang Initialzustand Zustand mit Übergang 2 Weiterleiten einer Mappe Abbildung 6.22: Prozeßablauf aus Sicht des Durchführers Aus Sicht des Durchführers gibt es nur zwei Fälle zu beachten. Er bekommt einen Prozeß vom Koordinator (Übergang 2 ) oder vom Prüfer (Übergang 5 ) zurück. Bekommt er einen Prozeß vom Koordinator, kann er diesen annehmen oder ablehnen. Lehnt er ihn ab (Übergang 3 ), geht der Prozeß zur Verhandlung und Änderung an den Koordinator zurück. Der Zustand des Prozesses wechselt von aktiv auf passiv. Nimmt er ihn an, bearbeitet er den Prozeß. Entweder kann er den Prozeß nicht zu Ende führen, dann wird er zum nächsten Durchführer eskaliert (Übergang 1 ), oder er meldet den Prozeß als fertiggestellt (Übergang 2 ), worauf er zum Prüfer weitergeleitet wird. In beiden Fällen wechselt der Zustand von aktiv zu passiv. Wird der Prozeß vom Prüfer abgelehnt, muß der Prozeß wieder neu bearbeitet werden. Eine Möglichkeit zur Ablehnung besteht nicht, worauf der Prozeß aktiv wird und auf die Möglichkeiten der Eskalation und Fertigstellung zurückführt. Der Prüfer hat die Aufgabe, Prozesse, die ihm zur Prüfung vorgelegt werden, abzulehnen oder anzunehmen (Übergang 2 ). Nimmt er den Prozeß an, wird dieser geprüft. Ist der Prozeß nicht zufriedenstellend bearbeitet, kann er ihn an den Durchführer zurückleiten (Übergang 5 ), der ihn wieder annehmen muß. Der Zustand wechselt von aktiv auf passiv. Ist der Prozeß zufriedenstellend geprüft, wird er als fertiggestellt gemeldet und kann dann archiviert werden (Übergang 6 ). Der Zustand wechselt von aktiv auf passiv. Wie der Durchführer kann der Prüfer einen Prozeß vom Koordinator ablehnen (Übergang 4 ), worauf wieder eine Änderung des Prozesses erfolgen kann. Der Zustand des Prozesses wechselt aus Sicht des Prüfers wieder von aktiv auf passiv. Ein Beispielablauf soll die Arbeitsweise des Eskalationsmanager im Zusammenspiel mit dem Unternehmensgedächtnis-System verdeutlichen. Hierbei wird beschrieben, wie ein In-

215 6.3 Modellierung zur Laufzeit 197 Prüfer Rückgabe an Durchführer passiver Prozeß 5 2 neuer Prozeß Ablehnung aktiver Prozeß Fertigmeldung passiver Prozeß 6 Annahme passiver Prozeß 4 Legende: Übergang Initialzustand 1 Zustand mit Übergang Weiterleiten einer Mappe Abbildung 6.23: Prozeßablauf aus Sicht des Prüfers genieur den Prozeß Montagebuch ändern initiiert und an einen Mitarbeiter der Dokumentation zur Durchführung weitergibt. Um die in den Prozeßabläufen beschriebenen Übergänge zu verdeutlichen, werden die Übergänge durch Ziffern an den entsprechenden Stellen des Beispiels hervorgehoben. Dabei wird nicht auf Vorgangsmappen zurückgegriffen, sondern das FOQUS-Prozeßmodell als Modellierungsmechanismus verwendet. Das ändert nichts an der prinzipiellen Vorgangsbearbeitung durch den Eskalationsmanager. In Abbildung 6.24 sind die beiden Prozesse Montagebuch ändern und Formatvorlage erzeugen als Instanzen des Prozeßmodells dargestellt. Jede Änderung am Montagehandbuch im Beispiel beruht auf einer Formatvorlage, die das Handbuch konform mit den Dokumentationsvorschriften des Unternehmens halten soll. Die beiden Prozesse sind über das Objekt Formatvorlage verzahnt. Der Prozeß Formatvorlage erzeugen wurde zu diesem Zeitpunkt vom Ingenieur schon durchgeführt. Initiierung eines neuen Vorgangs Der Ingenieur erkennt einen Fehler im Montagehandbuch und erzeugt einen neuen Vorgang. Er bekommt automatisch die Rolle des Koordinators zugewiesen. Die Rollen Durchführer und Prüfer kann er explizit vergeben. Der erzeugte Vorgang wird instantiiert. Der Vorgang erhält als zusätzliche Attribute Verweise auf die Belegung der Rollen. Start- und Endzeiten sowie Felder für die Speicherung von Anmerkungen und Erfahrungen der einzelnen Rollen werden ebenfalls neu angelegt. Nach der Eskalation des Vorgangs wird dem Durchführer die neue Aufgabe per mitgeteilt (1).

216 198 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Agent führt_aus benutzt Hilfsmittel unterstützt Legende: instance of isa Relation 2 M -Ebene Meta-Ebene Prozeß nutzt erzeugt Objekt Objekt Prozeß Agent enthält benutzt Wissensagent UGS- Repository Hilfsmittel führt_aus Mnemonischer- Prozeß unterstützt erzeugt nutzt sucht stellt_dar enthält UGS-Objekt Prozeßmodell FOQUS-Modell enthält Aufgabenagent Durchführer benutzt führt_aus hat_beziehung_zu unterstützt Hilfsmittel enthält Wertschöpfungsobjekt enthält erzeugt nutzt Kernprozeß enthält Modell-Ebene Ingenieur Formatvorlage Montagebuch benutzt führt_aus erzeugt Formatvorlage erzeugen unterstützt Textverarb.- prog. 1 Mitarbeiter nutzt benutzt Textverarb.- prog. 2 führt_aus unterstützt Montagebuch erzeugt Montagebuch ändern Abbildung 6.24: Prozesse Formatvorlage erzeugen und Montagebuch ändern

217 6.3 Modellierung zur Laufzeit 199 Ausführung eines Vorgangs Beim nächsten Zugriff auf seinen VVM-Klienten werden dem betroffenen Mitarbeiter die neuen Vorgänge und die Rollen, die er in Bezug auf den neuen Vorgang hat, angezeigt Der Durchführer entscheidet, ob er den Vorgang annimmt oder ablehnt. Bei einer Ablehnung wird der Koordinator per benachrichtigt, worauf dieser nun einen Verhandlungsprozeß mit dem Durchführer beginnen kann oder dem Prozeß einen neuen Durchführer zuordnen kann (3). Nimmt der Durchführer den Prozeß an, hat er nun die Möglichkeit, sich allgemeine Informationen über den Vorgang und die Fehlerdaten, die andere Mitarbeiter erzeugt haben, vom System anzeigen zu lassen. Ebenfalls kann er selbst Erfahrungen oder Anmerkungen zum Vorgang eintragen. Leider hat der Ingenieur bei Durchführung des Prozesses Formatvorlage erzeugen vergessen, den genauen Ablageort der erzeugten Datei im Unternehmensgedächtnis-System festzuhalten. Der Mitarbeiter der Dokumentation als Durchführer wendet sich nun in der Rolle des Wissensverbrauchers über den mnemonischen Prozeß Asking an Expert an einen vermeintlichen Experten für diese Formatvorlage. Das Unternehmensgedächtnis-Repository ermittelt nun, ob ein Agent existiert, der über eine ist Experte-Beziehung mit dieser Formatvorlage verbunden ist. Da dies nicht der Fall ist, weist das System den suchenden Mitarbeiter automatisch an den Erzeuger der Formatvorlage weiter; in diesem Fall also der koordinierende Ingenieur. Die Weiterleitung ist eine wertvolle Information für den Mitarbeiter, da dieser nicht wußte, wer die Formatvorlage für den Prozeß Montagebuch ändern erzeugt hatte. Das Unternehmensgedächtnis-System stellt selbständig eine Verbindung zwischen dem Wissenserzeuger eines Prozesses und dem Wissenssuchenden eines anderen Prozesses her. Der Mitarbeiter kann nun über eine vom Unternehmensgedächtnis-System erzeugte den Kontakt zum Ingenieur herstellen (vgl. Abbildung 6.25). Der Ingenieur erfährt über die des Mitarbeiters von der Wissenslücke und kann neben der Verschickung einer Antwortmail auch einen mnemonischen Akquisitionsprozeß im Unternehmensgedächtnis-System anstoßen, über den er die fehlenden Metainformationen der Formatvorlage im Wissensbestand des Unternehmensgedächtnis- Systems einträgt. Hierfür nimmt der Ingenieur die Rolle des Wissenserzeugers an (vgl. Abbildung 6.26). Nachdem der Durchführer die im Beispiel beschriebenen Probleme durch den Prozeß Asking an Expert beheben konnte, führt er den Prozeß komplett durch und beendet ihn, indem er den Vorgang zur Prüfung weiterleitet. Prüfung eines Vorgangs Nach der Fertigmeldung der Durchführung dieses Prozesses wird der beteiligte Prüfer per mit der Prüfung beauftragt (2). Auch dieser Mitarbeiter hat die Möglichkeit, den Prozeß abzulehnen, worauf in Analogie zu der Durchführung wieder Verhandlungsprozesse aufgenommen werden können (4). In diesem Beispiel nimmt der Ingenieur, der neben der Rolle des Koordinators auch die Rolle des Prüfers für den Prozeß Montagebuch ändern innehat, die Prüfung an und kann z.b. den Vorgang zur nochmaligen Bearbeitung zurückgeben (5) oder die Prüfung und damit den Prozeß beenden (6).

218 200 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Agent benutzt Hilfsmittel führt_aus Prozeß unterstützt nutzt erzeugt Objekt Legende: instance of isa Relation Objekt 2 M -Ebene Meta-Ebene enthält Wissensagent benutzt UGS- Repository Prozeß Agent Hilfsmittel Wissensverbraucher Wissenserzeuger führt_aus Mnemonischer- Prozeß unterstützt erzeugt nutzt sucht stellt_dar enthält UGS-Objekt Prozeßmodell Suche Akquisition FOQUS-Modell enthält Aufgabenagent Durchführer benutzt führt_aus hat_beziehung_zu unterstützt Hilfsmittel enthält Wertschöpfungsobjekt enthält erzeugt nutzt Kernprozeß enthält Modell-Ebene Ingenieur Formatvorlage Montagebuch benutzt führt_aus erzeugt Formatvorlage erzeugen unterstützt Textverarb.- prog. 1 nutzt Asking an Expert führt_aus Mitarbeiter benutzt Textverarb.- prog. 2 führt_aus unterstützt Montagebuch ändern Montagebuch erzeugt Abbildung 6.25: Mnemonischer Prozeß Asking an Expert

219 6.3 Modellierung zur Laufzeit 201 Agent benutzt Hilfsmittel Legende: führt_aus unterstützt instance of isa Relation 2 M -Ebene Meta-Ebene enthält Wissensagent Prozeß benutzt nutzt erzeugt UGS- Repository Objekt Objekt Prozeß Agent Hilfsmittel Wissensverbraucher Wissenserzeuger führt_aus Mnemonischer- Prozeß unterstützt erzeugt nutzt sucht stellt_dar enthält UGS-Objekt Prozeßmodell Suche Akquisition FOQUS-Modell enthält Aufgabenagent Durchführer benutzt führt_aus hat_beziehung_zu unterstützt Hilfsmittel enthält Wertschöpfungsobjekt enthält erzeugt nutzt Kernprozeß enthält Modell-Ebene Direkte- Akquisition führt_aus Ingenieur benutzt führt_aus Textverarb.- prog. 1 unterstützt erzeugt Formatvorlage Montagebuch erzeugt Formatvorlage erzeugen nutzt Asking an Expert führt_aus Mitarbeiter benutzt Textverarb.- prog. 2 Metadaten der Formatvorlage nutzt führt_aus Montagebuch ändern unterstützt Montagebuch erzeugt Abbildung 6.26: Mnemonischer Prozeß Akquisition

220 202 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Archivierung des Vorgangs Letztendlich muß der Vorgang vom Koordinator archiviert werden (6). Er gilt nun für alle Mitarbeiter als erledigt. Bei einem neuen Vorgang kann gleichwohl auf die gemachten Erfahrungen und Anmerkungen zurückgegriffen werden. Im Mittelpunkt des Unternehmengedächtnis-Systems steht das Wissensrepository (AW1). Es erlaubt die Speicherung, Nutzung und Wartung des Wissens aufgrund des in Abschnitt 6.2 vorgestellten prozeßbasierten Modellierungskonzeptes (AW2). Es unterstützt alle Phasen der dynamischen Wissensumwandlung (AW3) durch die explizite Bereitstellung der entsprechenden mnemonischen Prozesse im Repository selbst (AM1 - AM3), insbesondere können Verweise auf implizites Wissen von Mitarbeitern gemacht werden. Die technische und inhaltliche Integration (AI1 und AI2) erfolgt über den Eskalationsmanager und die in den folgenden Abschnitten vorgestellten Mappen- und Anfragemanager. Zusammenfassend läßt sich sagen, daß das Unternehmensgedächtnis-System durch das Zusammenspiel zwischen der eigentlichen Prozeßausführung und den mnemonischen Prozessen die prozeßorientierte Erzeugung, Nutzung und Wartung von Wissen unterstützt. Während der Prozeßausführung können von den Rollen mnemonische Prozesse aufgerufen werden, die Änderungen an der Wissensbasis vornehmen, ohne daß der Benutzer mit der Modellierungssprache oder dem Repository konfrontiert wird. 6.4 Ein Mappenmanager für elektronische Vorgangsmappen Für die Umsetzung der in Abschnitt erarbeiteten Eskalationsstrategien wurden folgende Anwendungsfälle für die Unterstützung durch ein System zur Fehlerfallbearbeitung erarbeitet: Sequentielles, paralleles und zyklisches Weiterleiten von Vorgangsmappen: Auswahl sinnvoller nachfolgender Rollen anbieten; Regeln festlegen, nach denen die Vorgangsbearbeitung abläuft. Überblick über Bearbeitungsstand einzelner Vorgangsmappen: Bearbeitungsdauer, Liegezeiten etc. Suche nach Vorgangsmappen im System; Überwachung der Vorgangsbearbeitung Schließen von Vorgangsmappen Für die Vorgangsbearbeitung auf Basis von elektronischen Mappen ergeben sich spezielle Anforderungen an Workflow-Funktionalitäten, mit denen koordiniertes Arbeiten unterstützt werden soll. Bei der Weiterleitung (Eskalation) ist es erforderlich, drei Möglichkeiten anzubieten. Der einfachste Fall ist das sequentielle Verschicken einer Mappe an eine nachfolgende Bearbeiterrolle, für die parallele Bearbeitung werden mindestens zwei Rollen ausgewählt, die die Mappe erhalten sollen. Die zyklische Weiterleitung an einen schon vor-

221 6.4 Ein Mappenmanager für elektronische Vorgangsmappen 203 her beteiligten Rolleninhaber tritt als Spezialfall auf (Deeskalation), wenn der Vorgang z.b. falsch eingeschätzt worden ist. Der letzte Rolleninhaber ist wegen fehlender Kompetenzen nicht in der Lage, den Vorgang zu bearbeiten, und schickt ihn daher zurück. Ein Überblick über die drei Fälle wird in Abbildung 6.27 gegeben. Um die Weiterleitung von Vorgangsmappen zu vereinfachen, ist eine Vorauswahl nachfolgender Bearbeiterrollen wünschenswert, die vom Inhalt der Mappe abhängt, so daß fehlerhafte Eskalationen nach Möglichkeit vermieden werden. Der UG-Trader (vgl. Abbildung 6.28) übernimmt die Funktionen ei- Rolle 1 Rolle 1 Rolle 1 Rolle 2 Rolle 2... Rolle N Rolle N a) sequentiell b) parallel c) zyklisch Abbildung 6.27: Möglichkeiten bei der Weiterleitung nes Dienstvermittlers. Er nimmt Vorgangsmappen an und leitet sie bei Nachfrage an den betreffenden Arbeitsplatz weiter. Zur Überwachung der Eskalation hält er alle Vorgangsmappen innerhalb der Trader-Datenbank, wo in einer globalen Aufgabenliste alle wartenden und weitergeleiteten Vorgangsmappen verwaltet werden. An den Arbeitsplätzen erfolgt die eigentliche Bearbeitung der Vorgangsmappen, die bis zum Weiterleiten oder Schließen (netz-)unabhängig vom UG-Trader verläuft. Zum Bearbeiten werden beim Trader die für die aktuelle Rolle des Agenten vorgesehenen Vorgangmappen in die lokale Arbeitsplatzdatenbank kopiert und in eine lokale Aufgabenliste eingefügt. Aus dieser Liste können Mappen geladen werden, d.h. sie werden in der rollenspezifischen Konfiguration im lokalen Mappenmanager angezeigt. Der lokale Mappenmanager stellt daraufhin Operationen (Datenerfassung, Versionsgraph anzeigen, Zusammenführen von Versionen, Schließen und Weiterleiten) zur Verfügung und bietet in Form von Verknüpfungen zu Software-Werkzeugen weitere Unterstützung. In Abhängigkeit von der Rolle werden aktuelle Versionen weitergeleiteter Mappen angezeigt. Laden Die in der globalen Aufgabenliste wartenden Vorgangsmappen werden entsprechend der aktuellen Rollen in die Arbeitsplatzdatenbank kopiert und in die lokale Aufgabenliste eingefügt. Abbildung 7.7. zeigt die grundlegende Interaktion zwischen lokaler Arbeitsplatzdatenbank, lokalem Mappenmanager, zentralem Vermittler und zentraler Datenbank in einem Nachrichten-Sequenz-Diagramm [ITU93], das hier den UML-Sequenz-Diagrammen vorgezogen wird, da diese die Darstellung von Aktionen und Zuständen nicht unterstützen. Der Benutzer befragt beim Laden den zentralen Vermittler, ob Vorgangsmappen für die Agent-Rolle Kombination vorliegen, worauf dieser eine Anfrage an die zentrale Datenbank

222 204 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Zentraler Vermittler Anfragemanager Mappenmanager Mappenaustausch Trader- Datenbank Eskalationsmanager Mappenmanagement mit VVM-Arbeitsplätzen VVM-Arbeitsplatz Klient Mappenmanagement Werkzeugmanagement Aufgabenmanagement Benutzeroberfläche Workflow-Management mit VVM-Arbeitsplätzen Aufgabenaustausch lokale Datenbank Start, Kontrolle Rückmeldung Werkzeug Abbildung 6.28: Architektur der VVM Arbeitsplätze stellt. Als Ergebnis werden neue Vorgangsmappen geliefert, die im zentralen Vermittler rollenspezifisch konfiguriert werden. Anschließend werden die Vorgangsmappen über den lokalen Mappenmanager an die Arbeitsplatzdatenbank weitergeleitet, wonach auch netzunabhängig weiter gearbeitet werden kann. Zur Nachvollziehbarkeit wird die gesamte Historie der Fehlerfallbearbeitung repliziert. Das eigentliche Laden erfolgt nun über die lokale Aufgabenliste, welche die replizierten Mappen enthält. Aus der Liste kann im Mappenmanager eine Vorgangsmappe angezeigt werden. Weiterleiten Beim Weiterleiten sind mindestens zwei Rollen involviert. Koordinatoren leiten Mappen an Bearbeiter weiter, Bearbeiter an andere Bearbeiter oder an den Prüfer. Der verschickt in der Regel keine Mappen. Nur falls bei der Prüfung Unstimmigkeiten festgestellt werden, sendet die Rolle Prüfer die Mappe an den entsprechenden vorherigen Bearbeiter zurück. Dem Eskalationsprinzip gemäß wird ein Fehlerfall an die nächsthöhere Kompetenzstufe übermittelt. Dies läuft in drei Schritten ab: 1. Ist ein Fehlerfall beim Initiieren erfaßt worden oder konnte die Bearbeitung nicht

223 6.4 Ein Mappenmanager für elektronische Vorgangsmappen 205 Abbildung 6.29: Interaktion beim Laden einer Mappe abgeschlossen werden, wird mindestens eine nachfolgende Rolle ausgewählt. Zur parallelen Bearbeitung eines Vorgangs ist die Selektion von mehreren (auch gleichen) Rollen möglich. 2. Zur Zuordnung von Vorgängen zu konkreten Agenten muß eine Rollenauflösung vorgenommen werden, bei der Mehrdeutigkeiten eliminiert werden. Dies geschieht interaktiv mit dem Rolleninhaber, der die Mappe verschickt. 3. Die Rolleninhaber, für die eine Mappe eingegangen ist, werden per darüber informiert. Auf der Systemebene wird unter dem Weiterleiten einer Vorgangsmappe das Replizieren einer im lokalen Mappenmanager geladenen Mappe in den UG-Trader verstanden. Abbildung 6.30 veranschaulicht die einzelnen Kommunikationsschritte. Der UG-Trader vervollständigt zunächst die eine eingegangene Mappe, in dem er am Arbeitsplatz nicht vorhandene (also nicht replizierte) Inhaltskomponenten der Ausgangsversion im Trader den neu erzeugten Versionen hinzufügt. So entsteht eine neue konsistente Gesamtsicht auf die Vorgangsmappe. Die vervollständigten Versionen werden in der zentralen Datenbank gespeichert. Die neu replizierten Versionen können nun von allen bisherigen Bearbeitern eingesehen werden. In die globale Aufgabenliste werden Einträge eingefügt, die der aktuellsten Version nachfolgende Bearbeiter zuordnen. Ist der gesamte Vorgang erfolgreich abgeschlossen, erfolgt das Entfernen der Vorgangsmappe aus der lokalen Aufga-

224 206 Ein nachhaltiges vernetztes Verbesserungsmanagement-System Abbildung 6.30: Interaktion beim Weiterleiten einer Mappe benliste. Mit dieser Reihenfolge wird vermieden, daß eine Mappe unterwegs verlorengeht. Das Schließen einer Vorgangsmappe bzw. einer Version ist dem Weiterleiten ähnlich, lediglich das Einfügen in die globale Aufgabenliste fällt weg. Beobachten Zur Beobachtung der Fehlerfallbearbeitung ist es insbesondere für die Rolle Kontrolle von Bedeutung, sich einen Überblick über alle Mappen verschaffen zu können. Schon sehr lange wartende Mappen lassen sich so aufspüren, mit dem Ziel, den nächsten Rolleninhaber anzuweisen, den Vorgang durchzuführen. Zur Prozeßverbesserung ist es erforderlich, geschlossene Mappen analysieren zu können, um Schwachstellen aufzudecken (z.b. zu lange Bearbeitungs- oder Liegezeiten). Für die Ermittlung des aktuellen Bearbeitungsstands einer Mappe muß eine Suche nach Mappen im System möglich gemacht werden. Die Suche wird ebenfalls für das Schließen von Vorgangsmappen benötigt, die nur sinnvoll durchgeführt werden kann, wenn vorher alle Versionen zusammengeführt werden, um so die Inhalte aus allen Versionen in der Mappe zusammenzufassen. Dazu müssen die entsprechenden Versionen im System gesucht und angefordert werden. Der lokale Mappenmanager startet für die Beobachtung von Änderungen an Vorgangsmappen einen nebenläufigen Prozeß, der rollenspezifisch Anfragen nach neuen Versionen von Vorgangsmappen an den zentralen Vermittler. Falls neue Versionen vorhanden sind, wird dies im lokalen Mappenmanager angezeigt (vgl. Abbildung 6.31). Die eigentliche Replikation wird auf Anforderung des Benutzers durchgeführt. Der Beobachtungsprozeß wird in festlegbaren zeitlichen Abständen aus der Suspendierung erweckt. Die lokale Arbeitsplatzdatenbank wird in der Beobachtung nicht angefragt, daher wird sie erst bei der Replikation belastet. Der Kom-

225 6.4 Ein Mappenmanager für elektronische Vorgangsmappen 207 Abbildung 6.31: Interaktion beim Beobachten einer Mappe munikationsaufwand mit dem zentralen Vermittler ist vertretbar, da nur Name und ID der neuesten Mappen angefragt werden. Im Mappenwerkzeug werden dem aktuellen Bearbeiter einer Mappe der letzte oder die letzten Bearbeiter präsentiert (vgl. Abbildung 6.32). Abbildung 6.32: Mappenwerkzeug - Versionsübersicht (Bildschirmabzug) Zusätzlich kann der Bearbeiter die bisherige Eskalation über den Versionsgraphen verfolgen. In Abbildung 6.33 ist der Versionsgraph einer Eskalation dargestellt. Wählt der Bearbeiter

226 208 Ein nachhaltiges vernetztes Verbesserungsmanagement-System eine beliebige Vorgangsmappe aus dem Graphen an, werden ihm (nur lesend) die zu diesem Zeitpunkt vorliegenden Fehlerbilder und die Bearbeitungsdaten angezeigt. Abbildung 6.33: Versionsgraph (Bildschirmabzug) 6.5 Ein Anfragemanager Der Anfragemanager FAST (engl.: Failure Analysis and Search Tool) nutzt die in einer relationalen Datenbank abgelegten Modelle, um dynamisch SQL-Anfragen zu generieren, die die gewünschten Fehlerfälle mittels des Strukturwissens aus der Datenbank extrahieren (vgl. Abschnitt 6.5). Mit FAST kann das variantenorientierte Strukturwissen mit Mitteln der in Abschnitt 6.2 vorgestellten Modelle über den Vorgangsmappen aus dem Repository und heterogenen Informationsquellen aufgebaut werden. Abbildung 6.34 zeigt eine Abbildung des Werkzeuges. Der Aufbau von Strukturwissen über Fehlerwissen hält sich an die in Abschnitt beschriebenen Kategorien der produktbezogenen und prozeßbezogenen Variantenbildung. Im Falle der produktbezogenen Bildung von Varianten werden Konzepte der objektorientierten Modellierung zur Repräsentation des Strukturwissens herangezogen. Dies entspricht der Vorgehensweise bei der Bildung von Produktmodellen. Die Aggregations- und Spezialisierungshierarchien strukturieren die Produktmodelle auf Baugruppenebene. Die Variantenbildung läuft nun über die Klassifikation der Baugruppen, in einer weiteren Hierarchie. Ein Beispiel soll die Vorgehensweise verdeutlichen. In Abbildung 6.35 sind Produktbäume zu drei Produkten (Staubsauger, Haartrockner und Bohrmaschine) dargestellt, die hinsichtlich der Fehleranalyse zunächst einmal nichts miteinander zu tun haben. Ein Blick auf die Baugruppen, zeigt aber, wie auf verschiedenen Dekompositionsstufen unterschiedliche Variantenbeziehungen bestehen können, die bei der Suche nach Fehlerfällen genutzt werden können. Angenommen, ein Servicetechniker soll bei einem Kunden einen defekten Staubsauger reparieren und er stellt im Fehleranalyseschritt 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 Variante hinsichtlich des Motors angeboten, weil dieser in einem benachbarten Knoten der Klassenhierarchie angesiedelt ist.