Die vom Technischen Kundendienst (TKD) im Maschinen- und Anlagenbau
auszuführenden Instandhaltungsarbeiten sind ebenso komplex und
informationsintensiv wie die instand zu haltenden Produkte selbst
Servicewissen im Zusammenhang mit technischen Kundendienstleistungen
basiert auf Informationen unterschiedlicher Art, die aufzeigen, wie und in welcher
Reihenfolge die jeweiligen Arbeitsschritte auszuführen sind. Die Dokumentation
dieses Servicewissens erfolgt nach derzeitigem Stand der Technik vorwiegend
papierbasiert oder auf elektronischen Datenträgern. Dieser State-of-the-Art der
Serviceinformationsdokumentation weist zwei Schwachstellen auf:
Die Informationen sind oftmals veraltet, da die entsprechenden
Dokumentationen nur periodisch (z. B. bei Varianteneinführung oder Versionswechsel eines
Produktes) aktualisiert werden. Zudem ist die Distribution der
Dokumentationen zu den jeweiligen Servicetechnikern nicht sichergestellt, da bspw. in
TKDOrganisationen die Zuständigkeiten nicht klar definiert sind oder
Dokumentationen bei Kundeneinsätzen verloren gehen und nicht zeitnah ersetzt werden.
Es wird nicht das gesamte, im Kontext eines Produktes zur Verfügung stehende,
Servicewissen erfasst. Neben den Organisationseinheiten der Produkthersteller
(bspw. Entwicklung, Qualitätssicherung) ist Servicewissen auf weitere
Organisationen verteilt (bspw. unabhängige TKD-Organisation). Die Wertschöpfung
aus Kundensicht wird zwar in Form einer Wertschöpfungspartnerschaft
erbracht, jedoch findet kein nachhaltiger Informationsfluss bezüglich der
Serviceinformationen innerhalb der Partnerschaft statt. Auch fließt das verteilt
vorliegende implizite Wissen nicht oder nur unzureichend in die Dokumentation ein
Durch den Einsatz von Informationssystemen mit mobilen Komponenten für
den TKD wird den beschriebenen Schwachstellen begegnet
Im vorliegenden Beitrag werden zunächst die bestehenden Methoden und Sprachen der Dienstleistungsmodellierung als Bestandteil hybrider Wertschöpfung identifiziert und systematisch analysiert. Anhand eines Scoringverfahrens wird daraus die Modellierungssprache ausgewählt, welche die Modellierung technischer Serviceinformationen im Kontext hybrider Wertschöpfung am besten unterstützt. Anschließend wird eine Modellierungsmethode zur effizienten Modellierung technischen Servicewissens entwickelt und an einem Praxisbeispiel evaluiert. 2
Technische Kundendienstleistungen sind eine Teilmenge von Dienstleistungen
Im Kontext von Dienstleistungen beziehen sich Modellierungsansätze
vorwiegend auf die Dienstleistungscharakteristika Prozessdimension (zeitliche und
räumliche Aspekte von Dienstleistungen), Potenzialdimension (Leistungsfähigkeit der
Ressourcen) und Ergebnisdimension (Leistungsergebnis)
Becker et al. (2008) prüfen, inwiefern sich bestehende Modellierungsansätze
für die verschiedenen Dienstleistungsdimensionen kombinieren lassen.
Die prozessorientierte Dimension bildet die Übertragung der Dienstleistung auf
den Kunden – oder dessen Objekt (z. B. technisches Produkt) – als eine Abfolge
von Tätigkeiten ab und spielt eine zentrale Rolle in der Modellierung von
Dienstleistungen
Die in der wissenschaftlichen Literatur aufgeführten Modellierungsmethoden im Kontext der Prozessdimensionen sind in nachfolgender Tabelle 1 dargestellt. Tabelle 1. Modellierungsmethoden mit dem Fokus Prozessdimension
Ereignisgesteuerte Prozesskette (EPK) OASIS 2007
Neben den in der Tabelle angeführten Methoden gibt es noch weitere Ansätze, die der Vollständigkeit halber aufgezählt werden, im Folgenden jedoch nicht weiBusiness Process Modeling Notation (BPMN) Business Process Workflow-Sprache, insbesondere zur OrchesExecution Language trierung von Web Services. (BPEL) Unified Modeling Language (UML) Service Blueprinting
Als Methode im Zusammenhang des Konzeptes Keller et al.
ARIS (Architektur integrierter Informations- 1992; Scheer systeme) ein verbreiteter Standard im Bereich 2001 der Geschäftsprozessmodellierung.
Standard für die graphische Notation von Ge-
Spezifikation zur Modellierung von Software,
Für Prozesse sind Aktivitätsdiagramme geeignet.
Methode zur Modellierung der Dienstleistungs-
In der Potenzialdimension werden interne Potenzialfaktoren identifiziert und zusammengefasst, die zur Dienstleistungserbringung erforderlich sind und entsprechend kombiniert werden können. Im Rahmen der Informationsunterstützung zur Erbringung technischer Kundendienstprozesse werden diese Potenzialfaktoren u. a. aus den – dem jeweiligen Arbeitsschritt bereitzustellenden – Serviceinformationen (z. B. Bilddokument, detaillierte Arbeitsbeschreibung, Ersatzteilinfo) gebildet und können bspw. in Ressourcenmodellen dargestellt werden. Tabelle 2 gibt einen Überblick der Modellierungsmethoden zur Darstellung der Potenzialdimension von Dienstleistungen.
Tabelle 2. Modellierungsmethoden mit dem Fokus Potenzialdimension
ARIS (Architektur integrierter Informationssysteme) Service Blueprinting Entity Relationship Model (ERM)
5-Sichten-Architektur (ARIS-Haus): Scheer 2001
Organisations-, Daten-, Leistungs-,
Funktions- und Steuerungssicht
Methode zur Modellierung der Dienst-
Gegenstands-Beziehungs-Modell Chen 1976
Die Methoden der Potenzialdimension werden von
In dieser Dimension wird der Zustand nach Erbringung der Dienstleistung
beschrieben. In der Literatur wird hierbei zwischen prozessualem Endergebnis, dem
Erreichen der eigentlichen Ziele und deren Wirkungen differenziert
Tabelle 3. Modellierungsmethoden mit dem Fokus Ergebnisdimension
ARIS (Architektur integrierter Informationssysteme) STEP REBECA
5-Sichten-Architektur (ARIS-Haus):
Organisations-, Daten-, Leistungs-,
Funktions- und Steuerungssicht
Produktdaten während des gesamten
Produktlebenszyklus
Entwicklung eines Werkzeugs zur
kundenindividuellen Konfiguration
von modulartig aufgebauten
Dienstleistungen
In der Gesamtsicht zeigt sich, dass bis dato kein Konsens darüber existiert, welche
der aufgezeigten Methoden ganzheitlich für die Modellierung der drei
Dienstleistungsdimensionen geeignet ist. Unabhängig von den dargestellten Methoden
schlägt
Um die Auswahl einer Modellierungsmethode für hybride Dienstleistungen systematisch durchzuführen, werden im Folgenden die Anforderungen an die Methoden dargestellt. 3
Von den in Abschnitt 2 dargestellten Modellierungssprachen und -methoden sind nicht alle geeignet, um technische Serviceprozesse abzubilden. Für die systematische Auswahl einer Modellierungsmethode zur Visualisierung dieser Art hybrider Wertschöpfung ist eine eingehende Untersuchung von Modellierungsnotationen anhand differenzierter Anforderungskriterien unerlässlich. Nachfolgend werden in einem ersten Schritt zwei Hauptgruppen von Anforderungen identifiziert: notwendige und hinreichende Anforderungen. Die einzelnen Anforderungskriterien beschränken sich auf die Auswahl einer geeigneten Sprache zur Modellierung von Serviceinformationen und werden diesen Gruppen zugeteilt. Einzelne Anforderungskriterien können beiden Gruppen zugeordnet werden, es muss also nicht zwangsläufig eine dichotome Einordnung erfolgen. Die Anforderungen sind in Tabelle 4 subsummiert.
Die Auswahl der geeigneten Modellierungssprache und des entsprechenden Modellierungswerkzeugs erfolgt hierfür sowohl aus theoretischer als auch praktischer Sicht. Es wurden einerseits theoretische Konstrukte auf ihre Stärken und Schwächen untersucht. Andererseits wurden gängige und Open-Source-Modellierungstools getestet und die Hersteller der Modellierungswerkzeuge bei Workshops interviewt. Anhand der zuvor klassifizierten Anforderungen wurde zur Bewertung ein entsprechender Kriterienkatalog entwickelt. Basierend auf diesem Kriterienkatalog wurden gängige Modellierungssprachen evaluiert. Wegen der Verbreitung und der Werkzeugunterstützung wurden Modellierungssprachen ex-ante ausgewählt: EPK (Ereignisgesteuerte Prozesskette), UML (Unified Modeling Language), Petrinetze (PN), XML (Extensible Markup Language), Adonis und BPMN (Business Process Modeling Notation). Die Ergebnisse der Evaluation sind der Tabelle 4 zu entnehmen.
EPK
UML
Tabelle 4. Evaluationsergebnisse
Prozessorientierung Explizite Zustandsdarstellung Explizite Ereignisdarstellung Explizite Darstellung des Zeitverlaufs Organisationsstrukturabbildung Graphische Notation Anschaulichkeit Einfachheit Benutzbarkeit Erlernbarkeit Intuitivität Kommunikationsunterstützung Korrektheit der Abbildung Exaktheit der Abbildung Konsistenz der Abbildung Vollständigkeit der Abbildung Eindeutigkeit der Abbildung Eindeutigkeit der Notationssymbole Flexibilität Erweiterbarkeit Anpassbarkeit Interpretierbarkeit Konfigurierbarkeit Skalierbarkeit Modularität Feingranularität Detailliertheit Integration von Teilmodellen Ausdrucksmächtigkeit Angemessenheit Abbildung der statischen Sachverhalte Abbildung der dynamischen Sachverhalte
Vollständige und detaillierte Spezifikation Eindeutige Zuordn. Sprachnotation/Symbol Verwechslungsfreiheit der Symbole Simulationsfähigkeit Quellcodegenerierung Workflow-Unterstützung Herstellerunabhängigkeit Textuelle Notation zur Anreicherung (Halb)automatische Dokumentation Wiederverwendbarkeit der (Teil)modelle Formalisierungsgrad Präzisierungsgrad Gewichtete Summe Legende: die Anforderungen werden binär mit ja = erfüllt, nein = nicht erfüllt bewertet; die sonstigen Anforderungen werden auf einem dreistufigen Skala mit 0 = nicht erfüllt/mäßig, 1 = teilweise erfüllt/gut, 2 = vollständig erfüllt/sehr gut bewertet.
Die Punktevergabe orientiert sich an folgendem Schema: Die Anforderungen, die dichotom mit erfüllt/nicht erfüllt bewertet werden können, sind in der Tabelle mit ja/nein gekennzeichnet und erhalten jeweils 2 Punkte bei Erfüllung und 0 Punkte bei Nicht-Erfüllung. Sonstige Anforderungen werden auf einem dreistufigen Skala mit 0 = nicht erfüllt/mäßig, 1 = teilweise erfüllt/gut, 2 = vollständig erfüllt/sehr gut bewertet und erhalten jeweils entsprechend viele Punkte.
Die Summenberechung erfolgt gewichtet und wird durch folgende Formel beschrieben:
Summegewichtet 2 i j, i Anforderungnotwendig , j Anforderunghinreichend
Demnach wurden die notwendigen Anforderungen wegen ihrer Wichtigkeit zweimal höher gewichtet als die hinreichenden Anforderungen. Der höchste Punktestand von 147 Punkten wird gemäß der Berechnungsmethodik der EPK zugewiesen. An zweiter Stelle kommt BPMN mit 142 Punkten. Auf dem dritten Platz folgt die UML mit 134 Punkten. Den vierten Platz erreichen Petrinetze mit 120 Punkten. Adonis bekommt 116 Punkte und den vorletzten Platz, und an letzter Stelle kommt XML mit 110 Punkten.
Die Ergebnisse sowohl der theoretischen Evaluation als auch der Workshops, Tagungen und Interviews lassen sich anschließend wie folgt zusammenfassen: Wegen einer zu technischen Ausrichtung und Darstellungsweise scheiden die Petrinetze von vorneherein aus, obwohl sie vorwiegend durch unterschiedliche Modellierungswerkzeuge unterstützt werden. Der Hauptgrund für die Untauglichkeit der Petrinetze ist, dass die zu modellierenden Inhalte zwischen allen ProjektBeteiligten kommuniziert werden müssen. Die rein textbasierten Modellierungssprachen wie XML können ebenso wenig als Projekt-Modellierungssprache fungieren, da sie unübersichtlich und daher wenig verständlich sind. UML ist im Gegensatz zu XML eine graphische Beschreibungssprache, wodurch sie besser lesbar und intuitiv verständlicher ist. UML bietet aber zu viele unterschiedliche Diagrammtypen mit jeweils voneinander abweichenden Symbolen für differente Modellierungssachverhalte an, wodurch eine ständig wiederkehrende Einarbeitung aller Projektbeteiligten durchzuführen wäre. UML eignet sich hervorragend für die objektorientierte Software-Entwicklung, weist aber im Gegensatz zu EPK im Rahmen der Prozessmodellierung zu viele Nachteile auf, als dass eine Eignung für Serviceprozessmodellierung gewährleistet ist. Obwohl es ebenso einfache und intuitiv verständliche Modellierungssprachen wie EPK gibt, bspw. der ADONISStandard, werden sie wegen ihrer geringen Verbreitung und mangelnder Werkzeugunterstützung (es gibt nur ein einziges Software-Tool, das die Notation unterstützt) nicht ausgewählt. BPMN schneidet den Evaluationsergebnissen nach als Zweitbeste ab. Das Fehlen von Sprachkonstrukten zur Darstellung von Zielen, Ressourcen und org. Zuständigkeiten (sie lassen sich nur indirekt darstellen) sowie das Konzept der „Schwimmbahnen“ wird aber vor dem Hintergrund der Entwicklung komplexer Serviceprozesse als nicht ausreichend flexibel erachtet. BPMN erscheint daher als ungeeignete Sprache zur Darstellung der geforderten Sachverhalte.
Die EPK hat sich seit Jahren für die Geschäftsprozessmodellierung als adäquat erwiesen. Die erweiterte EPK besitzt alle Sprachkonstrukte, um technische Arbeitsschritte abbilden zu können. Somit kann also EPK als Basissprache für die Serviceprozessmodellierung empfohlen werden, da sie alle betrachteten Anforderungen mit der höchsten Punktzahl erfüllt und um fehlende Konstrukte bzw. Sprachelemente für die Serviceprozessmodellierung ergänzt werden kann. Um den speziellen Anforderungen der Serviceprozessmodellierung gerecht zu werden, sollte somit das Meta-Modell der EPK um Sprachkonstrukte mit dem Fokus auf die Serviceprozessmodellierung erweitert werden. 4 4.1
Eine standardisierte Möglichkeit zur inhaltlichen Klassifikation technischer
Serviceprozesse bietet die DIN 31051. Sie unterteilt technische Serviceprozesse in
Inbetriebnahme, Instandhaltung und Entsorgung
Die während des Inbetriebnahmeprozesses durchzuführenden Arbeitsschritte
sind der Montage nachgelagert und überführen das Produkt in einen
funktionsfähigen Zustand. Zu den Instandhaltungsarbeiten werden die Prozesse
zusammengefasst, die der Überwachung, Erhaltung und Wiederherstellung der ursprünglichen
technischen Leistungsfähigkeit des Produktes dienen. Die jeweiligen Tätigkeiten
der Instandhaltung werden wiederum in die Tätigkeitsfelder (1) Wartung, (2)
Inspektion, (3) Instandsetzung und (4) Verbesserung unterteilt
Die Komplexitätsbewertung der Serviceprozesse impliziert auch die Vorgehensweise, nach der die einzelnen Arbeitsschritte abgearbeitet werden. Grundsätzlich können sie nach einer linearen bzw. deterministischen Bearbeitungsabfolge (mit antizipierbarem Verlauf) und einer nicht-linearen bzw. nicht deterministischen Bearbeitungsstruktur (kaum antizipierbarer Ablauf) gegliedert werden. Die Arbeitsschritte in den Inbetriebnahme-, Inspektions- und Wartungsprozessen folgen im Wesentlichen einer linearen Bearbeitung. Diese werden in der Regel schon während der Konstruktions- und Entwicklungsphase des Produktes identifiziert, in einer sinnvollen Reihenfolge geordnet und als explizites Wissen dokumentiert. Instandsetzungsprozesse – also Diagnose- und Reparaturprozesse – sind komplexe Prozesse, in denen sich Arbeitsschritte zur Fehlerdiagnose mit den Arbeitsschritten einer Reparatur abwechseln. Der Instandhaltungsprozess folgt einer nicht-linearen, dynamischen und verzweigten Bearbeitungsstruktur. Der individuelle Prozessverlauf ist abhängig vom Kontext der Störung und steht nicht im Vorfeld des Serviceprozesses fest.
Die detaillierte Konstruktion technischer Serviceprozesse ist sehr komplex und
daher auch interdisziplinär angelegt. Bislang existiert in der Literatur und in der
Praxis keine adäquate Beschreibung zur Lösung dieser Problemstellung. Im
Folgenden wird eine den Anforderungen zur Modellierung technischer
Serviceprozesse entsprechende 5-stufige Entwicklungsmethodik vorgestellt, die in Abb. 1
dargestellt ist. Entsprechend der DIN PAS 1090 sind Serviceinformationen
produktspezifische Informationen, die je nach Anforderung in unterschiedlicher Granularität
in Serviceinformationsmodellen, Serviceprozessartefakten und
Serviceprozessmodellen abgebildet werden
Produkthierarchie entwickeln
Produkt-/BauteilInformations
Modell entwickeln
Funktions-/ TätigkeitsInformations
modell entwickeln
Serviceprozessartefakt entwickeln
Serviceprozessmodell entwickeln Abb. 1. Entwicklungsmethodik zur Modellierung von Serviceinformationen
Ausgangspunkt der Modellierung ist in der ersten Stufe die Entwicklung einer geeigneten Produkthierarchie. Sie orientiert sich am jeweiligen Produktsortiment des Herstellers und hat zwei Abbildungsaufgaben. Zum Einen werden die zu modellierenden Produkte in eine Baumstruktur eingeordnet, zum Anderen bildet sie einen Ordnungsrahmen zur Einordnung der modellierten Serviceinformationsmodelle und erleichtert so deren Wiederverwendung. In der zweiten und dritten Stufe werden die Serviceinformationsmodelle erstellt. Serviceinformationsmodelle stellen eine Anordnung verknüpfter Informationsobjekte, beispielsweise detaillierte Beschreibungen, Bilder oder Ersatzteilinformationen (z. B. Darstellung von Art und Verfügbarkeit des Ersatzteils) zur Beschreibung von Arbeitsschritten dar. Zur eindeutigen Abgrenzung wurden im Rahmen dieser Entwicklungsmethodik die beiden Modelltypen: a) Produkt- bzw. Bauteilinformationsmodell und b) Funktions- oder Tätigkeitsinformationsmodell eingeführt. Die vierte Stufe dient der Modellierung der Serviceprozessartefakte. Auch dieser Modellbegriff wird neu eingeführt und bildet die Ergebnisse der auszuführenden Servicetätigkeiten ab. Diese Modellart wird daher der Ergebnisdimension zugeordnet. Die aus den Einzeltätigkeiten gebildeten Serviceprozessartefakte können selbst wiederum zu größeren Artefakten kombiniert werden. In Stufe fünf wird aus den Serviceprozessartefakten das eigentliche Serviceprozessmodell entwickelt. Dieses komplexe Modell beinhaltet oder referenziert alle zuvor beschriebenen Modelltypen. Da dieses Modell den Serviceprozess strukturiert abbildet, wird es der Prozessdimension zugeordnet.
Zur Modellierung der Serviceinformationen folgen wir dem konstruktionsorientierten Modellbegriff und betrachten ein Modell als eine durch einen Konstruktionsprozess gestaltete zweckrelevante Repräsentation eines Objekts, das in einem Konstruktionsprozess von einem Modellierer konstruiert wird (Thomas 2005).
In Anlehnung an die Konstruktionslehre des Maschinenbaus, die als Strategie
zur Entwicklung technischer Problemlösungen verstanden wird, verwenden wir
zur Entwicklung der Produkthierarchie die systemtechnische Betrachtung
technischer Gebilde
Produktbaum mit
Produktsparten Produktgruppen
Produktreihen einzelne Produkte
Aufbau der einzelnen Produkte aus Baugruppen und Bauteilen Abb. 2. Zweigeteilte Produkthierarchie
Hierfür wird zunächst die Produkthierarchie in zwei Modellierungsebenen aufgespannt (vgl. Abb. 2). In der oberen Ebene werden die abstrakten Objekte der technischen Gebilde platziert. Abstrakte Objekte sind in diesem Kontext abstrakte Produktgruppen, -sparten oder -reihen. Die real existierenden Objekte, beispielsweise Baugruppen und Bauteile, werden in der unteren Ebene eingeordnet. Bindeglied zwischen beiden Modellierungsebenen sind die Bezeichnungen der realen Produkte. Die Zweiteilung der Produkthierarchie trägt der unterschiedlichen Art der Wiederverwendung der Serviceinformationsmodelle in beiden Bereichen Rechnung. In der Ebene der abstrakten Objekte werden die modellierten Informationsobjekte durch Vererbung wiederverwendet: wird eine Information für eine ganze Produktreihe erstellt und entsprechend eingeordnet, so erbt jedes zu dieser Reihe gehörende Objekt die modellierte Information, ohne dass sie dem Gerät separat zugeordnet werden muss. Der Wiederverwendungsmodus von Informationsmodellen im unteren Teil der Produkthierarchie ist ein anderer: Serviceinformationen hängen hier an Bauteilen und Baugruppen und werden durch wiederholte Verwendung einer Komponente geteilt.
Das Produkt-/Bauteilinformationsmodell wird in den jeweiligen Objekten der
Produkthierarchie hinterlegt und damit kategorisiert. In diesem Modell werden die
allgemeingültigen Informationsobjekte und die am Objekt zu verrichtenden
Tätigkeiten bzw. Funktionen eingeordnet. Die Funktionen werden
verrichtungsorientiert zusammengefasst, jedoch nicht hierarchisch angeordnet, sondern nur auf der
Ebene der Elementarfunktionen beschrieben
Die Funktions-/Tätigkeitsinformationsmodelle werden in den Funktionen der
Produkt-/Bauteilinformationsmodelle hinterlegt. Zu jeder Funktion werden die
Serviceinformationen in die Informationsobjekte (Kurzbeschreibung bzw.
detaillierte Beschreibung des durchzuführenden Arbeitsschrittes, Bilddokumente)
eingegeben und mit der Funktion verknüpft. Die Gesamtlösung sieht vor, dass die
jeweiligen Informationsobjekte in unterschiedlichen Abteilungen und von
unterschiedlichen Mitarbeitern konstruiert werden. Durch diese „verteilte“
Modellkonstruktion wird es möglich, unterschiedliches Fach- und Erfahrungswissen der
Modellierer einzubinden, beispielsweise dadurch, dass die Abteilungen eine
Arbeitstätigkeit gemeinsam detailliert
Die Ergebnisse einer Tätigkeit werden im Serviceprozessartefakt (SPA) abgebildet. Ein SPA ist mit dem Produkt-/Bauteilinformationsmodell und dem Funktions-/Tätigkeitsinformationsmodell verknüpft und besteht aus einer Tätigkeit mit mindestens einem Ergebnis. Die aus den Einzeltätigkeiten gebildeten Serviceprozessartefakte können entsprechend der Definition in Abb. 3 selbst wiederum zu größeren Artefakten kombiniert werden. Sie werden so zu Teilprozessen. Diese modularen Artefakte zeichnen sich durch ihre hohe Wiederverwendbarkeit in verschiedenen Serviceprozessmodellen aus. SPA bilden den Baukasten, aus dem sich der Modellierer seine Serviceprozessmodelle zusammenstellen kann.
SPA Tätigkeit Ergebnis Abb. 3. Definition Serviceprozessartefakt
Die Serviceprozessmodelle entstehen in der fünften Stufe des Vorgehensmodells. Sie werden aus den zuvor modellierten Serviceprozessartefakten gebildet.
SP Startereignis SPAVorb. SPAHauptt. SPAAbschl. Ende Abb. 4. Definition Serviceprozessmodell
Jedes Serviceprozessmodell, unabhängig davon ob es sich um einen Wartungsoder Diagnose- und Reparaturprozess handelt, lässt sich nach der in Abb. 4 dargestellten Definition systematisieren. Wie jeder Geschäftsprozess wird auch der Serviceprozess (SP) mit einem den Prozess definierenden Startereignis konstruiert. Dies kann beispielsweise die mittels einer Diagnosesoftware identifizierte Fehlermeldung eines technischen Produktes sein. Die Arbeitsschritte im SP lassen sich zusammenfassen und modellieren nach: (1) vorbereitende Tätigkeiten (SPAVorb.), (2) Haupttätigkeiten (SPAHauptt.) und (3) Abschlusstätigkeiten (SPAAbschl.). Ein definiertes Endereignis markiert das Ende des Serviceprozesses. Ein Serviceprozessmodell wird mittels der SPA zu linearen und nicht-linearen Bearbeitungsstrukturen oder einer Kombination aus beiden zusammengesetzt und entsprechend sequenziell oder dynamisch bearbeitet. Die Klassifizierung des Serviceprozesses nach den drei beschriebenen Tätigkeitsarten vereinfacht die Modellierung unterschiedlicher Serviceprozesse, da sich dadurch die jeweiligen Teilprozesse entsprechend kategorisieren lassen und in unterschiedlichen Serviceprozessmodellen verwendet werden können.
Die Verknüpfung von bereits relevanten SPA zur dynamischen Bearbeitungsstruktur von Haupttätigkeiten eines Diagnose- und Reparaturprozesses ist beispielhaft in Abb. 5 skizziert, zunächst ohne die Notation einer Modellierungssprache zu verwenden. Dieser Modellausschnitt knüpft an der „Prozessschnittstelle Haupttätigkeit“ an das Teilmodell der vorbereitenden Tätigkeiten an und wird an der „Prozessschnittstelle Abschluss“ mit den Abschlusstätigkeiten des Serviceprozesses zusammengeführt und verdeutlicht die hohe Komplexität der Konstruktion dieses Prozessteiles, bedingt durch die unterschiedlichen Wirkungsbeziehungen zwischen den einzelnen Informationsobjekten.
.8 .8 .8 II .8 II II II .t II II – – – t apuH jtke itke is1 is2 is3
b ig n n n A O t b b b P ä e e e S T rg rg rg
E E E IV .1 IV IV IV .t IV IV – – – t up tk it 1 2 3 aH je ke is is is
b ig n n n A O t b b b P ä e e e S T rg rg rg
E E E
e - ll s s e s s t u
s l e t h zo it c P nh sb r c A s .3 .3 I 3 I I X I I. X X . tt X X – – pu tk it 1 2 aH je ke is is A P S b ig n n O t b b ä e e T rg rg
E E schen den einzelnen Serviceprozessartefakten – dargestellt anhand der Pfeillinien – sorgt für die mitunter hohe Komplexität während der Konstruktion der Serviceprozesse. Die SPA in Abb. 5 beschreiben unterschiedliche Tätigkeiten und deren Ergebnisse an verschiedenen Objekten. Die abgebildeten Objekte stehen beispielhaft für unterschiedliche abstrakte bzw. konkrete Objekte, entsprechend der oben beschriebenen Klassifizierung und deren Einordnung in der Produkthierarchie. Im Beispiel führt Ergebnis 1-XII.3 der Tätigkeit XII.3 am Objekt XII zu Tätigkeit IV.3 am Objekt IV. Tritt allerdings Ergebnis 2-XII.3 ein, ist Tätigkeit II.4 am Objekt II durchzuführen. Das Ergebnis des zuletzt durchgeführten Arbeitsschrittes bestimmt den nächsten Arbeitsschritt und verdeutlicht damit, dass der individuelle Prozessverlauf von Diagnose- und Reparaturprozessen abhängig vom Kontext der Störung ist und im Rahmen der Bearbeitung nicht im Vorfeld feststehen kann. Je nach Serviceprozess und Detaillierungsgrad ist die Anzahl hierbei verwendeter SPA erheblich hoch.
Da die Betrachtungsgegenstände im TKD technisch unterschiedlich komplexe Produkte darstellen, werden die Ergebnisse aus den durchzuführenden Arbeitstätigkeiten auch ganz unterschiedlich herbeigeführt. So ist das einfache Protokollieren einer durchgeführten Sichtprüfung eines bestimmten Maschinenteils ebenso möglich wie die differenzierte Interpretation des Messergebnisses der Abgasanalyse eines komplexen thermodynamischen Prozesses.
Serviceprozesse im TKD enden im Idealfall damit, dass das jeweilige Ziel der Servicearbeit erreicht wird. Im Abschlussteil des Serviceprozessmodells sollen zum einen die Tätigkeiten abbildet werden, die das Erreichen des definierten Ziels überprüfbar machen (z. B. erfolgreiche Inbetriebnahme, erfolgreich durchgeführte Reparatur) und zum anderen den Serviceprozess in eventuell erforderliche weitere Maßnahmen überführen (z. B. Anruf bei Hersteller, Bearbeitung einer neuen Störung). Der modellierte Serviceprozess gilt dann als abgeschlossen, wenn er über eine dieser Maßnahmen beendet wird. 5 5.1
Ein idealtypischer Vertreter des Maschinen-und Anlagenbaus ist der Sanitär-,
Heizungs- und Klimatechnikbereich (SHK), in dem neben den Herstellern der
Sachgüter vor allem ca. 50.000 kleine und mittelständische SHK-Betriebe produktnahe
Dienstleistungen, vor allem TKD erbringen
Abb. 6. IT-Architektur zur Unterstützung des Informationsaustauschs in der Wertschöpfungspartnerschaft (Walter et al. 2009)
In der Gesamtlösung werden die Serviceinformationen beim Hersteller des technischen Produktes entwickelt und in dessen Portalserver abgespeichert. Der Kundendiensttechniker stellt über den globalen Portalserver eine Informationsanfrage. Die modellierten Serviceinformationen werden auf das mobile Endgerät des Technikers übermittelt, in einer eigens dafür entwickelten Anwendung interpretiert und zur Nutzung im mobilen Endgerät bereitgestellt. Der Prozessverlauf und die Ergebnisse der einzelnen Arbeitsschritte werden automatisch dokumentiert. Nach Erbringung der Kundendienstleistung werden die Prozessdaten an den Portalserver des Herstellers zurückgemeldet und entsprechend ausgewertet. Die im Praxisbetrieb gewonnenen Informationen können auf diese Weise z. B. zur Produktentwicklung und Serviceprozessoptimierung verwertet werden. Im Kontext des Anwendungsszenarios wird die in Abschnitt 4 vorgeschlagene Modellierungsmethode angewandt und somit evaluiert. 5.2
Betrachtungsgegenstand für das Modellierungsbeispiel ist ein modernes Brennwert-Heizungsgerät. Es handelt sich hierbei um ein Produkt, in welchem komplexe thermodynamische, hydraulische und elektronische Prozesse miteinander kombiniert werden, um Heizwärme mit dem fossilen Energieträger Gas effizient und umweltverträglich zu erzeugen und bereit zu stellen. Das Anwendungsbeispiel verdeutlicht beispielhaft am Fehler F.0 die Umsetzung der Modellierungsmethodik anhand der entwickelten Modelle und mithilfe der identifizierten Modellierungssprache. Die Gerätestörung F.0 wird von der Elektronik durch Auswertung verschiedener Parameter im Display des Brennwertgerätes angezeigt und deutet auf einen Fehler im Umfeld des Vorlauftemperaturfühlers hin.
Zur Konstruktion der zuvor beschriebenen Modelle wird das
ARIS-Rahmenkonzept verwendet
NTC-Fühler Vorlauf Allgemeine Info NTC-Fühler
PDF-Dokument "NTC-Werte" Serviceprozessartefakt (EPK)
NTC-Fühler Vorlauf mit Kabel Widerst. messen
NTC-Fühler am
Vorlauf Widerstand messen NTC-Fühler Vorlauf mit Kabel Widerst. messen
NTC-Fühler Vorlauf tauschen
Kabelbaum (Gerät) - NTC ti h üf
NTCWiderstandswer t korrekt
NTCWiderstandswer t nicht korrekt Abb. 7. Modelltypen zur Konstruktion komplexer Serviceinformationen
Die modellierten Informationsobjekte (z. B. „detaillierte Beschreibung“, „wichtige Info SHK“ oder „Bilddokument Widerstand im Stecker messen“) stellen die Ressourcen zur korrekten Dienstleistungserbringung dar und werden anhand ausgewählter Sprachkonstrukte an die Tätigkeit konstruiert, die hier in einer Funktion abgebildet wird. In ihnen werden die zur späteren Bearbeitung erforderlichen Serviceinformationen hinterlegt. Die Auswahl der jeweiligen Sprachkonstrukte und deren Zuordnung zu den entsprechenden Informationsobjekten wird zu Beginn festgelegt und deren einheitliche Verwendung im gesamten Konstruktionsprozess beibehalten. Die zu erwartenden Ergebnisse der Arbeitsausführung werden im SPA im Modelltyp „EPK“ modelliert. Die Ergebnisse werden als Ereignis über den XOR-Konnektor (Verwendung nur bei mehr als einem Ergebnis) und entsprechenden Kanten mit der Funktion aus dem Funktions-/Tätigkeitsinformationsmodell verbunden. Da innerhalb des Lebenszyklus eines SPA weitere Ergebnisse zu einer bereits konstruierten Tätigkeit entwickelt werden können, ist deren Anzahl variabel. Im SPA sind zur Tätigkeit „NTC-Fühler Vorlauf mit Kabel Widerstand messen“ zwei Ergebnisse modelliert: (1) NTC-Widerstandswert korrekt und (2) NTC-Widerstandswert nicht korrekt. Durch die Trennung von Informationsobjekten und Ergebnissen im Funktions-/Tätigkeitsinformationsmodell bzw. im SPA wird die Konstruktion der Serviceprozessmodelle erleichtert, da der Modellierer später diese Modelle nur anhand der Anordnung und Verknüpfung entsprechender SPA erstellt.
Abb. 8 zeigt ausschnittsweise die Anordnung relevanter SPA zur Konstruktion der Haupttätigkeiten zur Diagnose und Reparatur des Fehles F.0. Diese beginnen mit der Tätigkeit „Kabelbaum (Gerät) – NTC optisch prüfen“. Zum Zeitpunkt der Modellierung waren hierzu fünf mögliche Ergebnisse bekannt, die in den Ereignissen: (1) Kabelbaum (Gerät) sichtbar defekt, (2) Kabelbaum und NTC sichtbar defekt, (3) Kabelanschluss am NTC defekt, (4) Stecker am NTC war abgezogen und (5) Kabelbaum kann nicht geprüft werden hinterlegt sind. m TC fen u N rü ba - p l ) h e t ab reä itc
s K G p ( o
n m th red TC en N g
o n C la T e N e C b T a N K r a b m t u ch tk a i lb s fe e ) e b t a rä d K e
G ( Abb. 8. Haupttätigkeiten im Fehlerbild F.0 (Ausschnitt) e e r e is " it e n
e e w d w s i re ne he b h c "ü rge tsn u o e z V am lre en r h k e ü c
e ck -F t e C fs t T u S N a m au t) en
ä h lb r c e e s b G u a ( a
t K m au t) en
ä h lb r c e e s b G u a ( a
t K m au t) en
ä h lb r c e e s b G u a ( a
t K S te m a e K g t h c m s u u a a b t l e e g b a t
h K c i n um th a c b s l u e a b t a e K g t h c m s u u a a b t l e e g b a t
h K c i n m t u h a c b s l u e a b t a e K g t h c m s u u a a b t l e e g b a t
h K c i n
Jedes einzelne Ereignis führt zu einer nachfolgenden Funktion. Ergebnis 5 führt dabei sofort in den Abschlussteil zur Tätigkeit „über weitere Vorgehensweise entscheiden“. Der Teilprozess der Abschlusstätigkeiten wird analog konstruiert. Zentrales SPA bildet hierbei die Funktionsprüfung. Bei erfolgreicher Funktionsprüfung endet der Serviceprozess. Löst die Funktionsprüfung einen weiteren Fehler aus, wird das Serviceprozessmodell mit einer entsprechenden Prozessschnittstelle beendet. Das mögliche Scheitern der Fehlerbehebung wird in diesem Modellausschnitt mittels der schon erwähnten Tätigkeit „über weitere Vorgehensweise entscheiden“ abgebildet. Im Modell wird für einen solchen Fall vorgesehen, dass: (1) der Werkskundendienst beauftragt werden soll, (2) der Serviceprozess abgebrochen werden soll, (3) mit einem selbst gewählten Arbeitsschritt weiter gearbeitet wird, (4) die Profi-Hotline des Herstellers angerufen werden kann oder die Funktionsprüfung wiederholt wird. 6
Der vorliegende Beitrag untersuchte bestehende Sprachen der Dienstleistungsmodellierung systematisch auf ihre Eignung zur Modellierung von technischen Serviceprozessen. Anschließend wurde eine Methode zur Modellierung vorgeschlagen, die anhand eines Fallbeispiels evaluiert wurde. Dieser Beitrag zeigt somit, wie die Entwicklung von Serviceprozessmodellen – als Grundlage der Informationsversorgung im TKD – nach der hier detailliert vorgestellten Entwicklungsmethodik effizient durchgeführt werden kann. Es zeigt sich aber auch, dass durch die Arbeit in verschiedenen Modellen unter Verwendung vielfältiger Sprachkonstrukte die Gestaltung der Serviceprozessmodelle mit den darin enthaltenen Serviceinformationen ein sehr komplexes Unterfangen ist. Zur Komplexitätsreduktion wurde daher ein IT-basiertes Modellierungswerkzeug prototypisch entwickelt, welches die speziellen Sprachkonstrukte zur Verfügung stellt und die Eingabe der Serviceinformationen innerhalb einer Modellierungsoberfläche ermöglicht. Die entwickelten Serviceinformationen werden damit automatisch in das Produkt-/Bauteilinformationsmodell, das Funktions-/Tätigkeitsinformationsmodell und in das SPA überführt. Die Evaluation des Modellierungswerkzeugs wird derzeit im Feldtest umgesetzt. 7
Becker J, Beverungen D, Knackstedt R (2008) Reference Models und Modeling Languages for Product-Service Systems Status-Quo und Perspectives for Further Research. In Proceedings of the 41st Annual Hawaii International Conference on System Sciences, 105–105 Becker J, Beverungen D, Knackstedt R, Müller O (2009) Konzeption einer Modellierungssprache zur softwarewerkzeugunterstützten Modellierung, Konfiguration und Bewer