Erweiterung des Supply Chain Operations Reference-Modells

Transkript

1 Erweiterung des Supply Chain Operations Reference-Modells Anforderungen, Konzepte und Werkzeuge Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors der Wirtschaftswissenschaften durch die Wirtschaftswissenschaftliche Fakultät der Westfälischen Wilhelms-Universität Münster vorgelegt von Armin Stein aus Backnang Münster, Februar 2010

2 Geleitwort Das Supply Chain Operations Reference-(SCOR-)Modell ist eines der weltweit am weitesten verbreiteten Referenzmodelle für das Supply Chain Management. Es wurde bereits vielfach in dokumentierten Supply Chain-Modellierungsprojekten eingesetzt. Trotz des großen Supply Chain- Wissens und der umfangreichen Supply Chain-Erfahrung seiner Mitglieder geht der Supply Chain-Council (SCC), Entwickler des SCOR-Modells, sehr konservativ vor und lässt lediglich die Erweiterungen zu, die einen langwierigen Diskussionsprozess innerhalb des Council durchlaufen haben. Eine verteilte Entwicklung zur Erstellung spezifischer Varianten wird nicht in Betracht gezogen. Der SCC begründet dies damit, dass das SCOR-Modell in seiner derzeitigen Form bereits grundsätzlich in der Lage sei, jede Supply Chain abbilden zu können. Ein Wildwuchs des Modells soll nachvollziehbar vermieden werden. In seiner Arbeit geht Herr Stein im Gegensatz zur Auffassung des SCC davon aus, dass das SCOR- Modell nicht in der Lage ist, jede Supply Chain entsprechend den Anforderungen der Anwender zu beschreiben. Eine explorative Befragung sowie die Analyse von SCOR-Anwenderberichten stützt seine Annahme. Darauf aufbauend werden von Herrn Stein Konzepte vorgeschlagen und entwickelt, wie das SCOR-Modell unter Einbeziehung der Mitglieder des SCC beschleunigt weiterentwickelt werden kann. Für diese Konzepte beschreibt er Werkzeuge, die eine technische Unterstützung sowie den Nachweis der Anwendbarkeit bieten. Hierdurch wurden Grundlagen gelegt, um eine verteilte Weiterentwicklung des SCOR-Modells zu ermöglichen und somit eine höhere Spezifizierung in zusätzlichen Bereichen zu erreichen. Die Arbeit von Herrn Stein leistet einen sehr innovativen Beitrag in diesem Kontext und bietet durch den Bezug zum SCOR-Modell eine deutliche Relevanz für die Praxis. Münster, im April 2010 Prof. Dr. Jörg Becker ii

3 Vorwort Time sure flies. It s already past twelve! Harmonica Im Oktober 2005 schrieb ich bei Dr. Ralf Knackstedt die letzte Seminararbeit meines Wirtschaftsinformatikstudiums, welche ich im Januar 2006 auf der Zaferna-Hütte im Kleinwalsertal vorstellen durfte: Konfiguration des Supply Chain Operation Reference (SCOR) Models. Ralf war erfreulicherweise von den Konzepten, die daraus entstanden sind, angetan. Als nächster, recht konsequenter Schritt bot er mir an, meine Diplomhausarbeit im Rahmen dieses Themas zu schreiben, woraus, so Ralf,...unter Umständen auch eine wissenschaftliche Publikation entstehen könne. Die vorliegende kumulative Dissertation ist das Ergebnis. Auf dem Weg zur Erstellung der Arbeit (und auch schon zuvor!) haben mich privat sowie beruflich viele Menschen unterstützt, ohne deren Hilfe dieses Werk nicht hätte entstehen können. Erfreulicherweise ist privat und beruflich bei den im Folgenden erwähnten Personen nur schwer zu unterscheiden. Die Reihenfolge der Erwähnung orientiert sich am ehesten an der Entstehungsgeschichte der Arbeit. Anzufangen ist bei Dr. Patrick Delfmann, der mich zunächst in meinem Projektseminar auf den Geschmack der Herausforderungen konzeptioneller Modellierung brachte und währenddessen dazu überredet hat, mich am Lehrstuhl von Prof. Becker zu bewerben. Er hat nicht lange dafür gebraucht. Die Bekräftigungen vor allem durch Ralf und Dr. Tobias Rieke unterstützten mich bei der Entscheidungsfindung. Ein großer Teil meiner Publikationen ist zusammen mit Ralf entstanden. Er ist derjenige, den ich, wenn ich gefragt werde, als meinen Mentor bezeichne. Vielen Dank für Dein Verständnis, Deine Anleitung, Deinen Nachdruck und Dein Konzept des Kaputtmachens. Für die Möglichkeiten, die ich dann am Lehrstuhl für Wirtschaftsinformatik und Informationsmanagement während meiner Zeit als Wissenschaftlicher Mitarbeiter hatte, um mich einerseits wissenschaftlich, andererseits aber auch persönlich zu entfalten und zu entwickeln, habe ich Prof. Dr. Jörg Becker zu danken. Durch Gespräche mit Mitarbeitern anderer Lehrstühle weiß ich, dass solche Freiheiten nicht selbstverständlich sind. Weiterhin möchte ich ihm für die Möglichkeit meiner weiteren Tätigkeit am ERCIS danken. In diesem Zusammenhang möchte ich mich auch bei Prof. Dr.-Ing. Bernd Hellingrath bedanken, der sich bereit erklärt hat, sich als Zweitgutachter zur Verfügung zu stellen, sowie bei Herrn Prof. Dr. Herbert Kuchen für die Übernahme des Drittgutachtens. Am Lehrstuhl habe ich neben Ralf und Patrick zumeist mit zwei Kollegen zusammengearbeitet, auf die jederzeit Verlass war: Sebastian Herwig und Łukasz Lis. Vielen Dank für die vielen Gespräche, die gemeinsamen Publikation, die interessanten Themen, den Pragmatismus, die gemeinsamen Forschungsanträge, die gemeinsamen Abfahrten und FoPis, die TeaTimes, die geiii

4 Vorwort iv meinsame Zeit! Ich glaube daran, dass erfolgreiche Forschung und Arbeit vor allem im Team funktioniert. Die Zeit mit Euch ist für mich der beste Beweis. Ich danke Philipp Bergener, der mich bei den ersten Schritten des Schreibens der Dissertation begleitet hat und bei Dr. Michael Räckers und Katrin Bergener, die mir jederzeit hilfsbereit zur Seite standen und mir anliegende operative Dinge ohne Frage abgenommen haben, wenn sie mir über den Kopf gewachsen sind. Weiterhin möchte ich mich bei Marcel Heddier für seine tolle Implementierung von SCOR bedanken, die als Grundstein für die Umsetzung der Konzepte dient. Christian Ullrich hat durch seine Bachelorarbeit sowie seine Arbeit am Lehrstuhl ebenfalls viel zu den Gedanken, aus denen diese Arbeit entstanden ist, beigetragen. Schließlich möchte ich mich bei allen Co-Autoren und jenen bedanken, die meine Arbeit trotz enger zeitlicher Restriktionen Korrektur gelesen haben. Neben der Arbeit möchte ich mich explizit bei Johannes Schwall für die Gespräche, seine kritischen Fragen, die Pedanterie in Bezug auf die Typografie sowie die immer vorhandene Hilfsbereitschaft bedanken! Bei Tobias und Monika möchte ich mich dafür bedanken, dass sie zusammen mit Johannes immer für entspannte, außeruniversitäre Zeiten sorgen. Dank auch an meine Tante Gisella und meinen Onkel Gottfried Möller für die Möglichkeit, eine beruflich vollständig andere Richtung auszuprobieren. Diese Zeit hat alles Weitere nachhaltig geprägt. Liebe Sonja, Du hast mich in den vergangenen Jahren nicht nur das machen lassen, was ich für richtig gehalten habe, sondern Du hast Dich daran beteiligt und mich unterstützt. Du hast mir zuliebe Dinge mitgemacht, die Du nicht unbedingt machen wolltest. Du hast es hingenommen, wenn mein Kopf zu voll war und akzeptiertest meine Nachlässigkeiten in diesen Zeiten. Wenn ich Dich brauche, bist Du da. Du bist toll und ich glaube an Dich und an uns. Danke für das alles! Ich liebe Dich und freue mich auf die kommenden gemeinsamen Jahre! Ich stelle es mir unglaublich schwer vor, als Elternteil die Ruhe zu bewahren, wenn sich der Sohn bei seiner Lebensgestaltung viel, sehr viel Zeit zum Überlegen nimmt. Ihr habt sie bewahrt und mich zu jeder Zeit voll unterstützt. Ich konnte und kann mich immer auf Euch verlassen. Das ist so viel wert. Euch, Mutti, Papa, Sonja, widme ich diese Arbeit. Danke! Münster, im April 2010 Armin Stein

5 Inhaltsverzeichnis Geleitwort Vorwort Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis Symbolverzeichnis ii iii iv v vi x Teil A 1 1 Exposition Wissenschaftliches Umfeld Problemstellung Forschungsfragen und Zielsetzung der Arbeit Wissenschaftstheoretische Positionierung Forschungsmethodik Verwendete Publikationen Grundlagen Informationsmodellierung Modellbegriff Modellierungssprachen Klassifikation von Informationsmodellen Referenzmodellierung Konfigurative Referenzmodellierung Referenzmodellierung im Supply Chain Management Supply Chain Management Supply Chain Operations Reference-Modell Supply Chain Operations Reference-Metamodell i

6 Inhaltsverzeichnis ii 3 Erweiterung des Supply Chain Operations Reference-Modells Erhebung von Anforderungen Explorative Umfrage Analyse von Anwenderberichten Auswertung der Anforderungen Konzepte zur Erweiterung des SCOR-Modells Konfiguration des SCOR-Modells Kopplung des SCOR-Modells Anpassung des Vorgehensmodells zur SCOR-Einführung Kollaborative Modellerweiterung Unterstützung durch Werkzeuge Verwendung von Standards Verwendung von Modellierungswerkzeugen Zusammenfassung und weiterführender Forschungsbedarf Diskussion der Forschungsfragen Weiterer Forschungs- und Handlungsbedarf Teil B 97 5 Extending the Supply Chain Operations Reference Model Taxonomies in the Context of Configurative Reference Modeling Ontology Support for Configurative Reference Modeling Enabling Widespread Configuration of Conceptual Models Modellierung integrierter Produktion und Dienstleistung Advances in Reference Model based Supply Chain Design Standards to Facilitate the Transition from Situational to Reference Model Formalizing Linguistic Conventions for Conceptual Models Distributed Conceptual Modelling through Naming Conventions Sicherstellung konventionsgerechter Modellelementbezeichner Pattern Matching in Conceptual Models 121

7 Inhaltsverzeichnis iii Literatur 123 Publikationsverzeichnis 143 Lebenslauf 147

8 Abbildungsverzeichnis 1.1 Vorgehen und Aufbau der Arbeit Modellierungsprozess Komponenten einer Technik Phasen des Lebenszyklus eines konfigurierbaren Referenzmodells Einflussbereich des SCOR-Modells Ebenen des SCOR-Modells Beispiel der Modellierung einer Supply Chain Beispiel eines SCOR-Benchmarks Metamodell des SCOR-Modells Ergebnisse der explorativen Umfrage Klassifizierung der Anwenderberichte nach NAICS Ergebnisse der Berichtsanalyse SCOR-Metamodell für die Konfiguration Konfigurierbarer Ebene-3-Prozess Konfigurierter Ebene-3-Prozess Ausgewählte Phasen des Lebenszyklus eines konf. Referenzmodells Morphologischer Kasten: Handel Beispielontologie Vorstellung des SCC der CCOR/DCOR/SCOR-Integration Kopplungsansatz Angepasstes Vorgehensmodell Unterschiedliche Modellierung des gleichen Sachverhalts in ERM Elemente, Mengen, Strukturdefinitionen und Strukturen Vorgehen zur Verwendung von Standards Ablauf der Konfiguration Referenzmodell vs. XML-Repräsentation Ausschnitt aus dem SCOR-Metamodell Beispiel eines SCOR-Modells [εm] Analyse der Modellelemente in [εm] Umsetzung der Sprachkonventionen in [εm] Anwendung des Pattern-Plugins in [εm] Screenshot: Konfiguration mit adapt(x) iv

9 Tabellenverzeichnis 1.1 Forschungsfragen Morphologischer Kasten zur wissenschaftstheoretischen Positionierung Wissenschaftstheoretische Positionierung Richtlinien nach Hevner et al. in Bezug auf diese Arbeit Verwendete Publikationen Design-Aspekte der Konfiguration des SCOR-Modells Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation Übersicht Publikation v

10 Abkürzungsverzeichnis AML ANSI ARIS ARM ASC ASCII BMBF BPEL BPEL4WS BPM BPMI BPMN BRMF BSC BSD BWW CCOR CCTS CIM CML CPBB ARIS Markup Language American National Standards Institute Architektur Integrierter Informationssysteme Advanced Manufacturing Research Accredited Standards Committee American Standard Code for Information Interchange Bundesministerium für Bildung und Forschung Business Process Execution Language BPEL for Webservices Business Process Management Business Process Management Initiative Business Process Modeling Notation Bereich der Referenzmodellierungsforschung Balanced Scorecard Business Scope Diagram Bunge-Wand-Weber Customer-Chain Operations Reference Core Component Technical Specification Computer Integrated Manufacturing Configurable Markup Language Coordinating Process Building Block DCOR Design-Chain Operations Reference DFG Deutsche Forschungsgemeinschaft DLR Deutsches Zentrum für Luft- und Raumfahrt DIN Deutsches Institut für Normung, e. V. DS Design Science DV Datenverarbeitung ECIS ECIS0X eepc European Conference on Information Systems Publikation des Autors bei der Konferenz ECIS 200X extended Event-driven Process Chain vi

11 Abkürzungsverzeichnis vii EMISA Enterprise Modelling and Information Systems Architectures EMISA Publikation des Autors beim EMISA-Workshop 2009 EMISAJ Publikation des Autors im EMISA-Journal 2009 EPC Event-driven Process Chain EPK Ereignisgesteuerte Prozesskette EPML EPC Markup Language ER International Conference on Conceptual Modeling ER09 Publikation des Autors bei der Konferenz ER 2009 ERM Entity-Relationship-Model ERP Enterprise Resource Planning EU Europäische Union F&E FlexNet Fertigung und Entwicklung, siehe auch R&D Flexible Informationssystem-Architekturen für hybride Wertschöpfungsnetzwerke GDT Global Data Types GfKl Tagung der Deutschen Gesellschaft für Klassifikation GfKl07 Publikation des Autors bei der Konferenz GfKl 2007 GrSCM Green Supply Chain Management HPSG InCoCo-S IJPE IRM IS ISO IT ITIL KPI KMU KSCM L4PE LCD MKWI Head-driven Phrase Structure Grammar Innovation, Coordination and Collaboration in Service Driven Manufacturing Supply Chains Publikation des Autors im International Journal on Production Economics InCoCo-S Reference Model Informationssystem / Information System International Organization for Standardization Informationstechnologie / Information Technology IT Infrastructure Library Key Performance Indicator Kleine und mittlere Unternehmen Knowledge Supply Chain Management Level-4-Process-Element Liquid Crystal Display Multikonferenz Wirtschaftsinformatik

12 Abkürzungsverzeichnis viii Mod10 MOF MS MSC NAICS OAGIS OASIS OMG OMI OTD PAS PDF PNML POS PPS PRINCE2 PRTM R&D RefModX RFP RFQ SC SCC SCDM SCM SCOR SLA SME SSC SSND TFT Publikation des Autors bei der Konferenz Modellierung 2010 Meta Object Facility Microsoft Manufacturing Supply Chain North American Industry Classification System Open Application Group Integration Specification Organization for the Advancement of Structured Information Standards Object Management Group Open Model Innitiative On Time Delivery Publicly Available Specification Portable Document Format Petri Net Markup Language Part of Speech Produktionsplanung und -steuerung Projects in Controlled Environments Pittiglio Rabin Todd & McGrath Research and Development, siehe auch F&E Publikation des Autors beim Workshop Referenzmodellierung 200X Request for Proposal Request for Quote Supply Chain Supply Chain Council Supply Chain Design Management Supply Chain Management Supply Chain Operations Reference Software Licence Agreement Small and Medium Enterprises Service Supply Chain Strategic Supply Network Development Thin-film Transistor

13 Abkürzungsverzeichnis ix UBL UCG UCM UML UN/CEFACT UN/EDIFACT USB VMI VSD W3C WI09 WKWI WSBPEL WSDL XMI XML XPDL XSL XSLT ZuO Universal Business Language Unified Categorical Grammar Unified Context Methodology Unified Modeling Language United Nations Centre for Trade Facilitation and Electronic Business United Nations Electronic Data Interchange For Administration, Commerce and Transport Universal Serial Bus Vendor Managed Inventory Serialisiertes Visio-Diagramm World Wide Web Consortium Publikation des Autors bei der Konferenz Wirtschaftsinformatik 2009 Wissenschaftliche Kommission Wirtschaftsinformatik BPEL for Web Services Web Services Description Language XML Metadata Interchange Extensible Markup Language XML Process Definition Language Extensible Stylesheet Language XSL Transformation Zuordnung

14 Symbolverzeichnis es gibt ein für alle Element von oder und Teilmenge ; Schnittmenge Schnittmenge von Ergebnissen Schnittmenge der gleichen Menge \ Komplement ; Vereinigungsmenge Vereinigungsmenge von Ergebnissen Vereinigungsmenge der gleichen Menge Komplement von Ergebnissen Abrundungsfunktion A Menge aller vorhandenen Elementtypen a A Ein konkreter Elementtyp (a, e) I Eine konkrete Instanziierung B Menge aller vorhandenen Objekttypen; B A b B Ein konkreter Objekttyp C Menge aller vorhandenen Relationen-Typen; C A c C Ein konkreter Relationen-Type E Menge aller verfügbaren Elemente e E Ein konkretes Element (e, r) T Ein konkrektes Ziel (e, r) S Eine konkrete Quelle I Menge aller vorhandenen Instanzen; I A E n x Positive, ganzahlige Nummer: n x N 1 O Menge aller vorhandenen Objekte; O E o O Ein konkretes Objekt P Potenzmenge R Menge aller vorhandenen Relationen; R E R d Menge aller verhandenen gerichteten Relationen r R Eine konkrete Relation x

15 Symbolverzeichnis xi S Menge aller vorhandenen Relationen-Quellen; S E R S d Menge aller Quellen von gerichteten Relationen; S d S, (r d R d ) (e, r d ) S S u Menge aller Quellen von ungerichteten Relationen; S u = S/S d T Menge aller vorhandenen Relationen-Ziele; T E R T d Menge aller Ziele von gerichteten Relationen; T d T, (r d R d ) (e, r d ) T T u Menge aller Ziele von ungerichteten Relationen; T u = T/T d X Menge von Elementen mit x X E X k Menge von Elementen mit X k E und k N 0 x l Einzelne Elemente mit x l E und l N 0 Y Menge von Objekten mit y Y O Z Menge von Relationen mit z Z R

16 Teil A

17 »[...] the [SCOR] Model can be used to describe supply chains that are very simple or very complex using a common set of definitions. As a result, disparate industries can be linked to describe the depth and breadth of virtually any supply chain.«supply Chain Council 2009b, S

18 1 Exposition 1.1 Wissenschaftliches Umfeld In den 1990er Jahren wurde eine ausgiebige Diskussion über den Nutzen der Gestaltung, Einführung und Verwendung betrieblicher Informationssysteme (IS) geführt, die bis heute andauert.1 Während der Diskurs über die Vorteilhaftigkeit des Einsatzes von Informationstechnologie (IT) weitergeführt wird,2 konnten empirische Studien positive Effekte auf unterschiedliche Unternehmensmerkmale belegen.3 Zur Gestaltung von Informationssystemen wird vor allem im deutschsprachigen und europäischen Raum ein ingenieurwissenschaftlicher Ansatz verfolgt,4 mit dem Ziel, die Qualität von Informationssystemen durch einen solchen Konstruktionsprozess zu gewährleisten. Ebenso wie in den Kernfeldern der Ingenieurwissenschaften wie bspw. dem Bauingenieurwesen, dem Maschinenbau oder der Elektrotechnik dienen in der Wirtschaftsinformatik Modelle als Methoden zur abstrakten Repräsentation von Betrachtungsgegenständen.5 Diese Informationsmodelle können Nutzern, die eine einem solchen Referenzinformationsmodell6 entsprechende Problemstellung betrachten, als Ausgangslösung zur Verfügung gestellt werden. Motiviert durch das oben angeführte ingenieurmäßige Vorgehen der Wirtschaftsinformatiker und den Zweck der Referenzmodellie- 1 Vgl. bspw. Krcmar 1990; Gurbaxani und Whang 1991; DeLone und McLean 1992; Davenport 1993; Venkatraman 1994; Henderson und Venkatraman Vgl. bspw. Carr 2004; Lertwongsatien und Ravichandran Vgl. bspw. Johnston 1988; Lertwongsatien und Ravichandran 2005 betrachten in ihrem Artikel empirische Studien über die Auswirkung von IS für IT-Firmen. Hierbei unterscheiden sie IS-Ressourcen und -Fähigkeiten ( IS resources and capabilities ; Lertwongsatien und Ravichandran 2005, S. 238) und leiten eine Theorie ab, die deren Auswirkung auf die Leistung eines Unternehmens ( firm performance ) zum Gegenstand hat. 4 Vgl. WKWI 1994, S. 81: Die Wirtschaftsinformatik ist weiterhin eine Ingenieurwissenschaft, da insbesondere die Gestaltung von IKS eine Konstruktionssystematik verlangt. [...] Die Gestaltung verlangt nach der ingenieurwissenschaftlichen Erstellung von Gestaltungshilfsmitteln (Methoden, Werkzeuge, Anwendungsprototypen) für den Gestalter in Wirtschaft und Verwaltung. Vgl. auch Hevner et al. 2004; Kurbel Vgl. Abschnitt 1.4 zur Einordnung dieser Arbeit. 5 Für eine differenzierte Auseinandersetzung mit dem Modellbegriff siehe Abschnitt Für eine differenzierte Auseinandersetzung mit dem Referenzmodellbegriff siehe Abschnitt 2.2. Siehe für die Begriffsbildung aber auch vom Brocke 2003, S. 34; Schwegmann 1999, S. 53 f. 3

19 1 Exposition 4 rungsforschung kann diese als eine der zentralen Disziplinen der Wirtschaftsinformatikforschung angesehen werden, in deren Kontext sich diese Arbeit einordnet. In der Referenzmodellierungsforschung können unterschiedliche Aspekte betrachtet werden, die in verschiedenen Arbeiten in den letzten Jahren bearbeitet wurden.7 Diese lassen sich folgendermaßen kategorisieren:8 1. Entwicklung von Sprachen zur Referenzmodellierung: Arbeiten aus diesem Bereich beschäftigen sich hauptsächlich mit der Fragestellung, welche Sprachen geeignet sind, um Referenzmodelle zu entwickeln und anzuwenden, d. h. nutzbare Instanzen der Referenzmodelle zu erzeugen.9 2. Entwicklung von Methoden zur Referenzmodellierung: Hierzu zählen neben Methoden zur Unterstützung der Referenzmodellerstellung (Vorgehensmodelle, Modellierungssprachen)10 auch Vorgehensmodelle zur Anwendung von Referenzmodellen Entwicklung konkreter Referenzmodelle: Hierbei handelt es sich um die Entwicklung von Informationsmodellen mit der Intention, dass sie wiederverwendet werden.12 Ob, und wenn ja, wie oft, die Wiederverwendung tatsächlich erfolgt, bleibt von der Intention unberührt. Um eine Wiederverwendung zu gewährleisten ist es notwendig, von individuellen Gegebenheiten zu abstrahieren und eine zumindest im intendierten Einsatzgebiet des Referenzmodells allgemeine Gültigkeit der enthaltenen Informationen sicherzustellen. 4. Entwicklung von Modellierungswerkzeugen: Hierbei kann es sich entweder um Werkzeuge handeln, die die Erstellung von Referenzmodellen unterstützen, oder auch um deren 7 Für eine vollständige Übersicht vgl. Fettke und Loos Vgl. Delfmann 2006, S Hierzu können bspw. die folgenden Arbeiten gezählt werden: Hars 1994; Frank 1994; Lang 1997; Remme 2001; Schütte 1998; Ohlendorf 1998; Schwegmann 1999; Hammel 1999; Schulze 2001; Wolf 2001; Fettke und Loos 2002; Becker et al. 2002; vom Brocke Hierzu können bspw. die folgenden Arbeiten gezählt werden: Hars 1994; Frank 1994; Nonnenmacher 1994; Kruse 1996; Lang 1997; Remme 2001; Schütte 1998; Ohlendorf 1998; Schwegmann 1999; Schlagheck 2000; Wolf 2001; Fettke und Loos 2002; Becker et al. 2002; Delfmann 2006; Rieke Vgl. zur Unterscheidung der Begriffe Holten 2000, S Beispiele bekannter Referenzmodelle sind: Das Y-CIM-Modell (Scheer 1997), das SAP R/3-Referenzmodell (Ricciuti und Semich 1993), das Aachener PPS-Modell (Luczak 1998), das Handels-H-Modell (Becker und Schütte 2004), das SCOR-Modell (Supply Chain Operations Reference; Supply Chain Council 2009b), das ITIL-Referenzmodell (van Bon et al. 2008) oder das WfMC-Referenzmodell der Workflow Management Coalition (WfMC; Hollingsworth 1995).

20 1 Exposition 5 Anwendung. Sie sollen im besten Fall die oben angesprochenen Modellierungssprachen, Methoden und Referenzmodelle unterstützen.13 Die vorliegende Arbeit ist als Querschnittsbetrachtung der angeführten Bereiche der Referenzmodellierungsforschung mit Domänenbezug zu sehen. In den enthaltenen Publikationen werden Wege vorgestellt, die Elemente des SCOR-Modells (Supply Chain Operation Reference) zu nutzen, um eine konsistente Modellierung von Supply Chains zu realisieren (1)14. Das Vorgehensmodell der SCOR-Anwendung (2) muss durch die Einführung von Methoden zur Ermöglichung der (verteilten) Erweiterung des SCOR-Modells (3) angepasst werden. Diese Konzepte werden durch den Einsatz von entsprechend entwickelten Software-Werkzeugen (4) unterstützt. 1.2 Problemstellung Grundsätzlich handelt es sich bei der Erstellung von Referenzmodellen um eine aufwändige Tätigkeit, die nicht ohne Risiko ist. Zeit und Ressourcen, die in die Entwicklung investiert werden,15 stehen einem unsicheren Absatz gegenüber. Eine verbreitete Nutzung des Referenzmodells obwohl mit der entsprechenden Absicht erzeugt im Anschluss an die Entwicklung ist während des Erstellungsprozesses unsicher. Zu detaillierte Modelle führen dazu, dass der Kreis der Anwender bzw. Abnehmer kleiner wird, der Anpassungsbedarf für die Kunden aber möglicherweise geringer ist. Abstraktere Modelle vergrößern entsprechend den Adressatenkreis, führen aber auch zu einem hohen Anpassungsaufwand für den Kunden. Diesem als Dilemma der Referenzmodellierung16 bekannten Problem sieht sich auch das Supply Chain Council (SCC), die für das SCOR-Modell verantwortliche Institution, gegenüber. Das Referenzmodell wird konservativ weiterentwickelt und auf hohem Abstraktionsniveau belassen,17 was darauf hindeutet, dass sich das SCC für eine abstrak- 13 Werkzeuge, die aus wissenschaftlicher Sicht in diesem Rahmen und mit der reinen Intention der Referenzmodellentwicklung und -anwendung entwickelt wurden, sind soweit bekannt am Markt nicht verbreitet. Einige kommerzielle Produkte die teilweise aus Forschungstätigkeiten entstanden sind sind jedoch in der Lage, den Referenzmodellierungsprozess den oben angeführten Anforderungen entsprechend zumindest teilweise zu unterstützen. Vgl. bspw. die ARIS-Suite der IDS Scheer AG (IDS Scheer 2010) oder das TIBCO Business Studio der TIBCO Software Inc. (TIBCO Software Inc. 2009). 14 In der Literatur finden sich verschiedene Schreibweisen für die Terme Supply Chain und Supply Chain Management in Bezug auf die Nutzung von Bindestrichen. In dieser Arbeit wird konsistent auf die Verwendung verzichtet. Für das SCOR-Modell wird die Schreibweise Supply Chain Operations Reference-Modell verwendet. 15 Hier sind vor allem die Zeit und der Aufwand zur Erhebung und Konsolidierung der in dem Referenzmodell hinterlegten Informationen sowie die Konsistenzsicherung der im Modell enthaltenen Informationen als maßgebliche Faktoren anzusehen. 16 Vgl. Becker et al. 2002, S Auf das SCOR-Modell wird detailliert in Abschnitt 2.4 eingegangen.

21 1 Exposition 6 te Version des Modells entschieden hat.18 Von Mitgliedern des SCC wurde jedoch der Wunsch nach Verfeinerungen und Erweiterungen des Modells artikuliert. Es kann also angenommen werden, dass das SCC sich mit dem SCOR-Modell in dem genannten Dilemma befindet. 1.3 Forschungsfragen und Zielsetzung der Arbeit Das SCC behauptet in der PDF-Version seines Modells, dass dieses in der Lage sei, grundsätzlich jede Supply Chain unabhängig von deren Tiefe und Breite abzubilden. Diese Aussage führte zu Beginn des Promotionsvorhabens zur ersten Forschungsfrage (FF) der Arbeit: FF1 Ist es wie vom SCC propagiert möglich, mit dem SCOR-Modell, wie es sich derzeit darstellt, jede Supply Chain den Anforderungen der Anwender entsprechend darzustellen? Aus den in Kapitel 3 vorgestellten und in den Artikeln Becker, Knackstedt und Stein sowie Knackstedt, Stein und Becker veröffentlichten empirischen Analysen19 lässt sich ableiten, dass bei den Nutzern des SCOR-Modells der Bedarf an spezifischeren Informationen vorhanden und somit eine Abbildung jeder Supply Chain im Sinne der Anwender nicht möglich ist. Hierauf beruht auch die Relevanz des Themas: Wenn es möglich ist, das SCOR-Modell so zu erweitern, dass sich der Adressatenkreis nicht wie vom SCC befürchtet aufgrund der entstehenden Spezifität reduziert, kann durch das Modell eine größere Wissensmasse abgebildet werden. Die Methoden der konfigurativen Referenzmodellierung bieten sich für diese Problemstellung als Lösungsansatz an, sodass die zweite Forschungsfrage lautet: FF2 Können die Methoden der konfigurativen Referenzmodellierung sinnvoll auf das SCOR- Modell angewendet werden, um einen von Anwendern gewünschten höheren Spezifizierungsgrad zu erreichen, ohne jedoch den Adressatenkreis einzuschränken? In den Publikationen von Knackstedt, Stein und Becker wird gezeigt, dass dies möglich ist.20 Das SCC schließt einige Informationen aus seinem Referenzmodell explizit mit dem Hinweis auf kompetentere Institutionen, die sich mit den entsprechenden Fragestellungen beschäftigen, 18 In Gesprächen mit Projektmitarbeitern des EU-Forschungsprojekts InCoCo-S (Rauhut 2005), das zum Gegenstand hatte, Dienstleistungsprozesse in das SCOR-Modell zu integrieren, wurde deutlich, dass das SCC nicht daran interessiert war, die Erkenntnisse des Projekts in das SCOR-Modell einzuarbeiten. Als Begründung wurde das oben erwähnte konservative Vorgehen sowie der Wunsch, Allgemeingültigkeit zu wahren, genannt. Dies führte dazu, dass als Ergebnis des Projekts ein eigenes, an die Struktur des SCOR-Modells angelehntes Modell erstellt wurde das InCoCo-S Reference Model (IRM; Schneider, Schönsleben und Lorenz 2008). 19 Vgl. Becker, Knackstedt und Stein 2007 (Kapitel 5); vgl. Knackstedt, Stein und Becker 2010 (Kapitel 10). 20 Vgl. Knackstedt, Stein und Becker 2010 (Kapitel 10); vgl. Knackstedt, Stein und Becker 2009 (Kapitel 9).

22 1 Exposition 7 aus.21 Neben Organisationen existieren für solche exkludierten Bereiche auch Referenzmodelle, die bereits auf eine Art und Weise spezifiziert wurden, die eine Integration in das SCOR-Modell im Sinne des Konfigurationsansatzes ausschließen.22 Hieraus leitet sich die dritte Forschungsfrage ab: FF3 Wie können Informationen anderer Referenzmodelle mit denen des SCOR-Modells verknüpft werden? In den Publikationen von Knackstedt, Stein und Becker wird eine Methode entwickelt und vorgestellt, mit denen eine solche Koppelung möglich ist.23 Sowohl die Erweiterung des SCOR- Modells im Sinne des Konfigurationsansatzes, als auch die Ermöglichung einer Kopplung des SCOR-Modells mit anderen Referenzmodellen erfordert die Erweiterung des Vorgehensmodells zur unternehmens- und Supply Chain-bezogenen SCOR-Einführung, da die Methoden bisher naturgemäß keine Berücksichtigung gefunden haben. Die Forschungsfrage lautet hier: FF4 Wie muss das Vorgehensmodell zur SCOR-Implementierung angepasst werden, um die vorgestellten Methoden zu unterstützen? Das SCC als Non-Profit-Organisation hat keine Möglichkeiten und auch nicht die Motivation, die zusätzlichen Informationen für das Referenzmodell durch den Einsatz eigener Mitarbeiter erheben zu lassen. Aus diesem Grund ist er auf die Unterstützung seiner Mitglieder angewiesen. Durch deren globale und somit sowohl räumliche als auch zeitliche Verteilung werden Methoden benötigt, die eine solche Kooperation unterstützen und die Ergebnisse, die durch die Mitglieder zur Verfügung gestellt werden, konsistent im Sinne des SCOR-Modells halten. In diesem Zusammenhang lautet die fünfte Forschungsfrage: FF5 Welche Konzepte sind erforderlich, um eine aktive, verteilte Beteiligung der Mitglieder des SCC am SCOR-Modell zu ermöglichen und dessen Konsistenz im Sinne des SCC zu sichern? Dieser Aspekt ist Gegenstand diverser Publikationen von Becker et al. und Delfmann et al. in denen Methoden vorgestellt werden, die eine sowohl sprachlich als auch modellstrukturell konsistente verteilte Modellierung ermöglichen.24 Unter der Voraussetzung, dass Teile der Weiterentwicklung des SCOR-Modells direkt an die Mitglieder übergeben würden, bestünde die Chance, 21 Vgl. Supply Chain Council 2009b, S Für eine ausführliche Begründung vgl. Abschnitt Vgl. Knackstedt, Stein und Becker 2010 (Kapitel 10); vgl. Knackstedt, Stein und Becker 2009 (Kapitel 9). 24 Vgl. Becker et al. 2009a (Kapitel 12); vgl. Delfmann et al. 2009b (Kapitel 13); vgl. Becker et al. 2010a (Kapitel 14); vgl. Delfmann et al. 2009a (Kapitel 15).

23 1 Exposition 8 die Menge an Informationen und somit den Informationsgehalt des Referenzmodells zu erhöhen. Dies führt jedoch gleichzeitig zu einer Erhöhung der Komplexität des Modells. Grundsätzlich kann diesem Problem wie oben beschrieben mit Mitteln der konfigurativen Referenzmodellierung begegnet werden. Da die Referenzmodellentwickler durch die Verteilung der Modellierung nicht mehr zeitlich und räumlich gemeinsam an dem Modell arbeiten können, eine konsistente Konfiguration aber dennoch gewährleistet sein muss, lautet die sechste Forschungsfrage: FF6 Wie können die Methoden der konfigurativen Referenzmodellierung an die Erfordernisse der verteilten Modellierung angepasst werden? Mit dieser Frage beschäftigen sich die Publikationen von Knackstedt und Stein und Becker et al.25 Die Komplexität des Ansatzes der konfigurativen Referenzmodellierung vor allem unter dem Gesichtspunkt der verteilten Modellierung sowie die Kopplung von Referenzmodellen erfordert den Einsatz von Techniken und Modellierungswerkzeugen, die eine verlässliche und fehlerfreie Modellerstellung, Modellkopplung und -konfiguration ermöglichen. Bisher sind solche Werkzeuge und Standards in der Praxis nicht verbreitet, sodass die siebte Forschungsfrage lautet: FF7 Existieren Werkzeuge und Standards, die genutzt werden können, um die aus den oben angeführten Forschungsfragen abgeleiteten Anforderungen zu unterstützen? In nahezu allen in dieser Arbeit verwendeten Publikationen wird die Anwendung von unterstützenden Softwarelösungen und Standards vorgestellt. Exklusiv eingegangen wird auf diese Problematik aber in den Veröffentlichungen von Janiesch und Stein sowie Herwig und Stein.26 Es ist das Ziel dieser Arbeit und der für diese Arbeit verwendeten Publikationen, durch die aus den Forschungsfragen entstandenen Lösungen einen Beitrag zu leisten, um der in Abschnitt 1.2 vorgestellten Problemstellung in den Forschungsbereichen Entwicklung von Referenzmodellierungssprachen (a), Entwicklung von Referenzmodellierungsmethoden (b), Entwicklung von Referenzmodellen (c) und Entwicklung von Modellierungswerkzeugen (d; siehe Abschnitt 1.1) zu begegnen. Die folgende Tabelle gibt einen Überblick über den Zusammenhang der Forschungsfragen mit den entsprechenden Bereichen der Referenzmodellierungsforschung (RefMod-Forschung); in Kapitel 3 wird auf die jeweiligen Forschungsfragen nochmals explizit Bezug genommen: 25 Vgl. Knackstedt und Stein 2007 (Kapitel 6); vgl. Becker et al (Kapitel 7). 26 Vgl. Janiesch und Stein 2007 (Kapitel 11); vgl. Herwig und Stein 2010 (Kapitel 8).

24 1 Exposition 9 Forschungsfragen Bereich der RefMod-Forschung (a) Entw. von Referenzmodellierungssprachen X (b) Entw. von Referenzmodellierungsmethoden X X X X (c) Entw. von Referenzmodellen X X (d) Entw. von Modellierungswerkzeugen X Tab. 1.1: Adressierung der Bereiche der Referenzmodellierungsforschung durch die Forschungsfragen 1.4 Wissenschaftstheoretische Positionierung Für das Verständnis der im Rahmen dieser Arbeit verwendeten Publikationen sowie die vorgelagerte Darlegung der Zusammenhänge ist es erforderlich zu explizieren, auf welche Art und Weise die Erkenntnisse im Verlauf des Forschungsprozesses erlangt wurden. Ohne eine wissenschaftstheoretische Positionierung der Arbeit besteht die Gefahr, dass implizite Prämissen des Lesers nicht hinreichend und bereits im Vorfeld adressiert werden und hierdurch ein falsches bzw. nicht intendiertes Verständnis geschaffen wird.27 Zu diesem Zweck bietet der von Becker und Niehaves vorgestellte Bezugsrahmen in Tab. 1.2 die Möglichkeit, die eigene wissenschaftstheoretische Positionierung anhand von fünf Aspekten vorzunehmen.28 Den einzelnen Aspekten dieses Bezugsrahmens sind unterschiedliche Positionen zugeordnet, die im Folgenden näher dargestellt werden Vgl. Krogstie und Sølvberg 1996, S. 208 f.; Schütte 1998, S. 8 ff.; Knackstedt 2006, S. 11; Brelage 2006, S. 7; Rieke 2008, S Vgl. Becker und Niehaves 2007; für den Morphologischen Kasten siehe Zwicky 1989; Becker und Niehaves 2007, S Vgl. ergänzend Rieke 2008; Delfmann 2006; Knackstedt 2006; Niehaves 2004; Niehaves 2005; Becker, Niehaves und Knackstedt Der von Becker und Niehaves vorgestellte Bezugsrahmen basiert auf Arbeiten von Burrell und Morgan, die die Notwendigkeit eines solchen Instruments für die Sozialwissenschaften identifizierten (Burrell und Morgan 1979, S. 1 ff.). Die hier verwendete Fassung von Becker und Niehaves (2007) abstrahiert von den sozialwissenschaftlichen Kriterien (wie der Natur der Gesellschaft), wurde jedoch um den Aspekt des Wahrheitsbegriffs erweitert. Zusätzlich wird ein deutlicher Fokus auf die Domäne der Wirtschaftsinformatik gelegt. 29 Vgl. im Folgenden auch Rieke 2008, S. 9 ff.

25 1 Exposition 10 Ontologischer Aspekt Gegenstand der Erkenntnis Die Ontologie30 wird aus dem griechischen Begriff όν für Sein abgeleitet und bezeichnet die Wissenschaft bzw. Lehre des Seienden. Sie beschäftigt sich also mit der Erforschung was ist und wie es ist.31 Im Rahmen der ontologischen Positionierung wird von dem Forscher festgelegt, was in seinem Verständnis Gegenstand der Forschung ist.32 Die folgenden drei Ausprägungen der Aspekte können unterschieden werden: Wissenschaftstheoretischer Aspekt Ontologischer Aspekt Gegenstand der Erkenntnis Epistemologischer Aspekt Verhältnis von Erkenntnis und Erkenntnisgegenstand Wahrheitsbegriff Wesen der wahren Erkenntnis Erkenntnisursprung Quelle der Erkenntnis Methodologischer Aspekt Art und Weise der Entstehung der Erkenntnis Ontologischer Realismus Epistemologischer Realismus Korrespondenztheorie der Wahrheit Ausprägung Ontologischer Idealismus Konsenstheorie der Wahrheit Kantianismus Konstruktivismus Semantische Theorie der Wahrheit Empirismus Rationalismus Kantianismus Induktivismus Deduktivismus Hermeneutik Quelle: Becker und Niehaves 2007, S Tab. 1.2: Morphologischer Kasten zur wissenschaftstheoretischen Positionierung 30 Der Begriff Ontologie wird in verschiedenen Fachrichtungen jeweils unterschiedlich verwendet. Neben der philosophischen Bedeutung des Begriffes wird in der Informatik und auch der Wirtschaftsinformatik dem Begriff der Ontologie eine andere Bedeutung zugeordnet. Gruber versteht eine Ontologie bspw. als explizite und formalsprachliche Spezifikation einer gemeinsam verwendeten Konzeptualisierung von Phänomenen der Realität (übersetzt nach Gruber 1993, S. 23). Guarino spezifiziert den Ontologiebegriff weiter: An ontology is a logical theory accounting for the intended meaning of a formal vocabulary, i. e. its ontological commitment to a particular conceptualization of the world. The intended models of a logical language using such a vocabulary are constrained by its ontological commitment. An ontology indirectly reflects this commitment (and the underlying conceptualization) by approximating these intended models. Vgl. Guarino 1998, S Vgl. von Foerster Vgl. Monod 2003.

26 1 Exposition 11 Ontologischer Realismus: Es existiert eine von menschlichen Denk- und Sprachprozessen unabhängige Realität. Forschungsgegenstände sind damit (angenommene) Realweltobjekte bzw. besitzen eine Repräsentation in der Realwelt.33 Ontologischer Idealismus: Die Welt ist ein Produkt menschlicher Wahrnehmung bzw. Vorstellung. Gegenstände existieren allein dadurch, dass Subjekte diese (in ihrer Vorstellung) konstruieren.34 Kantianismus: Kant versucht, den ontologischen Realismus und den ontologischen Idealismus zu verbinden und geht davon aus, dass sowohl Betrachtungsgegenstände ( Dinge an sich ), die unabhängig von menschlicher Wahrnehmung existieren, als auch solche, die an menschliche Wahrnehmung gebunden sind, nebeneinander existieren.35 In dieser Arbeit wird der Position des ontologischen Realismus gefolgt. Damit wird hier von einer Realwelt ausgegangen, die unabhängig vom menschlichen Bewusstsein, d. h. unabhängig von Denk- und Sprechprozessen, existiert. Im Rahmen dieser Arbeit steht die verteilte, konsistente Erweiterung von Referenzmodellen vor allem des SCOR-Modells im Mittelpunkt. Das SCOR- Modell bildet eine realweltliche Problemstellung, nämlich die Beschreibung von Supply Chains, ab. Die in Teil B vorgestellten Arbeiten sowie die Zusammenfassung in Abschnitt 3.2 bieten Methoden als Diskursobjekte zur Begegnung des realweltlichen Dilemmas der Referenzmodellierung. Epistemologischer Aspekt Verhältnis von Erkenntnis zu Erkenntnisgegenstand Der Begriff Epistemologie setzt sich aus dem grieschischen ὲπιστέµε (Erkenntnis, Wissen, Wissenschaft) und λόγος (Wissenschaft, Lehre) zusammen. Es handelt sich also um die Lehre der Erkenntnis. Die beiden folgenden Grundpositionen ermöglichen die Definition des Verständnisses über die Beziehung zwischen dem Erkenntnisgegenstand und der Erkenntnis, die ein Subjekt erworben hat. Grundsätzlich wird versucht zu erkennen, ob sich Dinge außerhalb des menschlichen Denkens und Sprechens zumindest prinzipiell objektiv identifizieren lassen.36 Epistemologischer Realismus: Der epistemologische Realismus setzt voraus, dass objektive Erkenntnis einer unabhängigen Realität möglich ist.37 Auf Basis der Möglichkeit dieser objekti- 33 Vgl. z. B. Bunge Vgl. z. B. von Foerster Vgl. Kant Vgl. Becker und Niehaves 2007, S Vgl. z. B. Losee 1972.

27 1 Exposition 12 ven Erkenntnis müssen im epistemologischen Realismus Maßnahmen existieren, die in der Lage sind, die subjektabhängigen Verzerrungen der Erkenntnis der Realität zu eliminieren. Aufgrund der mit dem spistemologischen Realismus eng verbundenen Annahme einer unabhängigen Realwelt setzt diese Position eine ontologisch-realistische Position voraus und wird im Umfeld der Wirtschaftsinformatikforschung häufig mit Positivismus gleichgesetzt.38 Konstruktivismus: Erkenntnis stellt sich im konstruktivistischen Sinne als subjektiv dar,39 was bedeutet, dass die Beziehung zwischen Erkenntnis und dem Objekt der Erkenntnis durch das erkennende Subjekt determiniert ist.40 Die Ströme des Konstruktivismus lassen sich in ihren Annahmen wiederum unterscheiden: Einerseits kann von einer durch das Subjekt interpretierten objektiven Realität ausgegangen werden,41 andererseits kann die Annahme vertreten werden, dass eine objektive Realität nicht existiert und Erkenntnis daher als privat betrachtet werden kann.42 Dem Einfluss des Subjekts auf die Erkenntnis wird in dieser Arbeit eine zentrale Rolle beigemessen. Dies äußert sich in dem Forschungsgebiet der Referenzinformationsmodellierung, in dem die Bewertung der Relevanz oder der Unwichtigkeit maßgeblich von der subjektiven Einstellung des Modellierers abhängig ist. Trotzdem sind Elemente, die in ein Referenzmodell aufgenommen werden, zumindest Abstraktionen von Bestandteilen einer Vorstellungswelt und entsprechen in diesem Sinne Phänomenen.43 Das Subjekt ist jedoch nicht in der Lage, die gesamte Realwelt zu erfassen und ist aufgrund dessen darauf angewiesen, vereinzelte Ausschnitte durch Phänomene zu erfassen und zu interpretieren. Aus wissenschaftstheoretischer Sicht wird in dieser Arbeit demzufolge eine epistemologisch konstruktivistische Position eingenommen. Diese entspricht in Verbindung mit der bereits eingenommenen ontologischen realistischen Position dem Interpretivismus. 38 Vgl. Becker und Niehaves 2007, S Vgl. Glasersfeld Vgl. Lorenzen Vgl. Burrell und Morgan 1979; Walsham 1995; Klein und Myers Dies entspricht der Position des radikalen Konstruktivismus. Vgl. hierzu z. B. Glasersfeld Vgl. Lorenz 1995b, S. 568.

28 1 Exposition 13 Wahrheitsbegriff Wesen der wahren Erkenntnis Gegenstand des Wahrheitsbegriffs ist die Frage, wie der Mensch wahre Erkenntnis erlangen bzw. wie richtiges Wissen erworben werden kann und wie die Richtigkeit verifiziert werden kann. Hierzu werden im Folgenden drei relevante Grundpositionen erläutert.44 Korrespondenztheorie der Wahrheit: Da ihrer Auffassung nach wahre Aussagen solche sind, die Fakten der wahren Welt repräsentieren,45 legt die Korrespondenztheorie der Wahrheit sowohl ontologisch als auch epistemologisch eine realistische Position zugrunde, da zum einen angenommen wird, dass eine wahre Welt existiert, zum anderen Fakten nur dann existieren können, wenn die korrespondierenden Sachverhalte eindeutig erkennbar sind. Konsenstheorie der Wahrheit: Wahrheit wird durch eine Gruppe von Subjekten definiert, die sich auf auf die Wahrheit eines Fakts einigen.46 Somit besteht die Wahrheit nur für diese Gruppe und ist ein Diskursobjekt, wenn die Gruppe oder die Erkenntnis der Subjekte sich verändert.47 Semantische Theorie der Wahrheit: Laut Tarski geht Wahrheit immer auf eine Sprache die Objektsprache zurück, in der die auf Richtigkeit zu prüfenden Aussagen getroffen werden.48 Die Objektsprache selbst ist Gegenstand einer Metasprache, die durch Regeln die Wahrheit von Aussagen der Objektsprache festlegt. Im Vergleich zur Konsenstheorie der Wahrheit ist es demnach relevant, dass sich über beides geeinigt wird Objektsprache und Metasprache. Nur wenn sämtliche Subjekte einer Gruppe im Besitz sowohl der Objektsprache als auch im Besitz der Metasprache sind,49 kann Wahrheit bestimmt werden. In Übereinstimmung mit Delfmann et al. und Rieke wird Wahrheit in Bezug auf Sprachen gemäß der semantischen Theorie der Wahrheit, in Bezug auf Gruppen von Subjekten entsprechend der Konsenstheorie der Wahrheit aufgefasst.50 Wahrheit entsteht damit innerhalb einer Sprachgemeinschaft durch Konsens, was mit einer epistemologisch interpretivistischen Positionierung verbunden ist. Für die Erstellung von (Referenz-)Modellen bedeutet dies, dass ein Modell dann 44 Vgl. Becker und Niehaves 2007, S. 203 f. 45 Vgl. Wittgenstein Vgl. z. B. Habermas 1973; Apel Vgl. Habermas Vgl. Tarski Kamlah und Lorenzen bezeichnen solche Gruppen als Sprachgemeinschaften (vgl. Kamlah und Lorenzen 1996, S. 45 ff.). 50 Vgl. Delfmann et al. 2006, S. 25.

29 1 Exposition 14 als richtig angesehen wird, wenn das Modell für den Modellersteller und den Modellnutzer als konsensbildende Sprachgemeinschaft akzeptabel ist. Für diese Arbeit ist weiterhin die semantische Theorie der Wahrheit relevant, da für die Beschreibung der in dieser Arbeit entwickelten Modellierungssprache eine Sprachaussage über eine Sprache getroffen wird. Zudem wird eine Konfiguration von Modellen des SCOR-Modells und dem SCOR-Modell selbst vorgenommen, welche in einer (oder mehreren) Modellierungssprache(n) definiert wurden. Hierdurch werden ebenfalls über mehrere Sprachebenen hinweg Sprachaussagen getroffen. In dieser Hinsicht ist die Explikation der Metasprache(n) für die Beurteilung wahrer Aussagen essenziell.51 Erkenntnisursprung Quelle der Erkenntnis Der Aspekt des Erkenntnisursprungs fokussiert die Frage nach der Quelle des fundamentalen Erkenntnisvermögens. Dieser versucht die Frage zu beantworten, woher Erkenntnis stammt. Empirismus: Erkenntnis wird über Sinneseindrücke (impressions of senses) gewonnen und kann als empirisches Wissen bezeichnet werden.52 Im Gegensatz zum Rationalismus kann das Ergebnis des Erkenntnisgewinns als a posteriori-wissen bezeichnet werden.53 Rationalismus: Die Quelle der Erkenntnis ist die Vernunft.54 Ein Objekt wird durch die Fähigkeit des Subjekts, zu Konzeptionalisieren, zum Gegenstand der Wahrnehmung. Im Gegensatz zum Empirismus kann das Ergebnis des Erkenntnisgewinns auch als a priori-wissen bezeichnet werden. Kantianismus: Laut Kant kann keine der beiden Ansichten (Empirismus vs. Rationalismus) ohne die jeweils andere existieren. Ohne ein sensorisches Element kann es keine Objekte geben und ohne Intellekt können die Ergebnisse der kognitiven Eindrücke nicht eingeordnet werden.55 Diese Arbeit beinhaltet Ergebnisse empirischer Elemente, die zur Entwicklung der vorgestellten Konzepte führten. Dies entspricht dem Gedanken des Empirismus. Die Konzepte wurden jedoch 51 Vgl. auch Delfmann et al. 2006, S Vgl. Berkeley 1963; Carnap 1999; Hume 1978; Locke Vgl. Alavi, Carlson und Brooke Vgl. z. B. Leibniz 1998; Chomsky 1965; Descartes 1986; BonJour Vgl. Kant 1998.

30 1 Exposition 15 aufgrund von kritischer Reflexion der Problemstellung entwickelt, ein Vorgehen, das dem Rationalismus anzurechnen ist. Aus dieser Sicht entspricht die grundlegende Ausrichtung dieser Arbeit der des Kantianismus. Methodologischer Aspekt Art und Weise der Entstehung von Erkenntnis Im Rahmen des methodologischen Aspekts wird die Frage beantwortet, auf welchem Wege neues Wissen hergeleitet werden kann. Induktivismus: Unter Induktion wird das Schließen vom Speziellen auf das Allgemeine verstanden.56 Induktives Schließen bezeichnet die Transformation von Aussagen spezieller (beobachteter, empirischer) Sachverhalte in universelle Gesetzmäßigkeiten auf Basis der Annahme über die Homogenität der Natur.57 Damit ist gemäß des Induktivismus die Generalisierung die Grundlage für die Herleitung neuen Wissens. Deduktivismus: Unter Deduktion wird das Schließen vom Allgemeinen auf das Individuelle verstanden.58 Hierbei ist es vorteilhaft, wenn die Schlüsse logisch gefolgert werden können. Hermeneutik: Hermeneutik (vom griechischen ηερµ ενευειν ausdrücken, interpretieren, übersetzen) addressiert das Verstehen von Sachverhalten durch humane Subjekte.59 Bei diesen Sachverhalten handelt es sich ursprünglich um das Verstehen von Texten.60 Die Grundaussage war, dass das Wissen über einen Gegenstand die Art beeinflusst, mit der ein Text über diesen Gegenstand gelesen wird. Die Informationen, die über das Lesen des Textes gewonnen werden, beeinflussen dann wieder das Verständnis über den Betrachtungsgegenstand.61 Diese Einstellung ist nicht auf Texte beschränkt und kann auf jeden beliebigen Sachverhalt übertragen werden: Die Auseinandersetzung mit dem Sachverhalt verändert das Wissen darüber, was wiederum die weitere Auseinandersetzung beeinflusst. In dieser Arbeit wurden sowohl induktive als auch deduktive Vorgehensweisen angewandt. Die Induktion wird implizit während der Arbeit an der Erweiterung des Referenzmodells angenommen, wenn von Aussagen, die aus Interviews oder Dokumentenanalysen abgeleitet werden, auf Referenzprozesse geschlossen wird, die dann in das SCOR-Modell übernommen werden. Vor 56 Vgl. Seiffert Vgl. Rott Vgl. Lorenz 1995a. 59 Vgl. Veraart und Wimmer 1995; Alvesson und Skøldberg 2000, S ; Capurro Vgl. Alvesson und Skøldberg 2000, S Vgl. Veraart und Wimmer 1995; Capurro 1986, S. 13.

31 1 Exposition 16 allem die Überführung von Modellen zu Referenzmodellen, die nicht mit der entsprechenden Intention erstellt wurden, ist induktiv. Die Anwendung eines Referenzmodells hingegen beinhaltet ein deduktives Vorgehen, da bei der Umsetzung von verallgemeinerten Informationen auf konkrete Anwendungsszenarien geschlossen wird. Gleichzeitig kann angenommen werden, dass in dieser Arbeit die Erstellung eines Referenzmodells unter62 hermeneutischen Aspekten betrachtet werden kann, da die Erkenntnisse über den Untersuchungsgegenstand während der Entwicklung die weitere Entwicklung beeinflusst haben. Vor allem im Rahmen des iterativen Design Science (DS)-Forschungsansatz, der im folgenden Abschnitt beschrieben wird, spielt der hermeneutische Ansatz eine große Rolle. In Tab. 1.3 ist die wissenschaftstheoretische Positionierung dieser Arbeit durch Markierung der relevanten Ausprägungen zusammengefasst. Wissenschaftstheoretischer Aspekt Ontologischer Aspekt Gegenstand der Erkenntnis Epistemologischer Aspekt Verhältnis von Erkenntnis und Erkenntnisgegenstand Wahrheitsbegriff Wesen der wahren Erkenntnis Erkenntnisursprung Quelle der Erkenntnis Methodologischer Aspekt Art und Weise der Entstehung der Erkenntnis Ontologischer Realismus Epistemologischer Realismus Korrespondenztheorie der Wahrheit Ausprägung Ontologischer Idealismus Konsenstheorie der Wahrheit Kantianismus Konstruktivismus Semantische Theorie der Wahrheit Empirismus Rationalismus Kantianismus Induktivismus Deduktivismus Hermeneutik Quelle: In Anlehnung an Becker und Niehaves 2007, S. 8. Tab. 1.3: Wissenschaftstheoretische Positionierung 1.5 Forschungsmethodik Obwohl der Arbeit eine interpretivistische Ausrichtung unterstellt wird, wurden sowohl sie selbst als auch verschiedene der in Teil B angeführten Veröffentlichungen in Anlehnung an das Design 62 Hierzu kann bspw. auch das Referenzvorgehensmodell zur Anwendung des SCOR-Modells gezählt werden. Vgl. Abschnitt

32 1 Exposition 17 Science Research63 entwickelt. Hevner et al. an deren Richtlinien für Design Science-Forschung sich diese Arbeit anlehnt, gehen von einer positivistischen Grundeinstellung aus, was mit Rücksicht auf Niehaves eine interpretivistische Sicht jedoch nicht ausschließt.64 Hevner et al. beschreiben Design Science als Ansatz, der darauf ausgerichtet ist, neue und innovative (IT-) Artefakte zu erstellen.65 Es geht also im Gegensatz zur Verhaltensforschung nicht um das Verstehen der Welt und deren Abläufe an sich, sondern um die Entwicklung von Innovationen (Artefakten66), die aufgrund der Analyse des aktuellen Zustands der Welt diese verbessern. Die Forschungsergebnisse müssen den existierenden Wissenskorpus erweitern also neu und nachgewiesen relevant sein. Vgl. Tab. 1.4 für die sieben von Hevner et al. aufgestellten Richtlinien und deren Begegnung in Rahmen dieser Arbeit. Tab. 1.4: Richtlinien nach Hevner et al. in Bezug auf diese Arbeit Richtlinie Bedeutung Bezug zur Arbeit Design als Artefakt Relevanz des Problems Evaluation des Designs DS-Forschung muss eine nutzbare Lösung in Form eines Konstrukts, eines Modells, einer Methode oder einer Instanziierung hervorbringen. Ziel der DS-Forschung ist die Entwicklung einer technologie-basierten Lösung für wichtige und relevante unternehmerische Probleme. Die Anwendbarkeit, Qualität und Effizienz des Artefakts muss sorgfältig durch ausgewählte Methoden demonstriert werden. In dieser Arbeit wurden verschiedene Artefakte im Sinne von Sprachen, Methoden und Werkzeugen entwickelt, die den Anforderungen des DS-Ansatzes entsprechen.67 Aufgrund der in Abschnitt 1.2 dargestellten Problemstellung kann davon ausgegangen werden, dass es sich bei dem Dilemma der Referenzmodellierung um ein wirtschaftlich relevantes Problem handelt, für das in dieser Arbeit Lösungen vorgestellt werden. Die in dieser Arbeit entwickelten Konzepte wurden zumindest prototypisch durch die Umsetzung in Werkzeugen getestet. Dies wird allerdings lediglich als erster Evaluationsschritt gesehen. Fortsetzung auf der nächsten Seite 63 Vgl. Simon Vgl. Niehaves 2007, S. 9, der sich auf Schön 1984 beruft. 65 Vgl. hierzu und auch im Folgenden Hevner et al Im Folgenden werden die Begriffe Lösung und (Forschungs-)Ergebnis synonym zu Artefakt benutzt. 67 Vgl. hierzu ausführlich die Abschnitte 1.1 und 1.2.

33 1 Exposition 18 Richtlinie Bedeutung Bezug zur Arbeit Forschungsbeitrag Sorgfalt der Forschung Design als Suchprozess Kommunikation des Ergebnisses Der Beitrag, der durch die DS-Forschung bereitgestellt wird, muss eine klare und überprüfbare Bereicherung des Forschungsbereichs, in dem das Artefakt entwickelt wurde, darstellen. DS-Forschung basiert auf der Anwendung von sorgfältigen Methoden sowohl während der Entwicklung als auch während der Evaluation des Artefakts. Die Entwicklung einer Lösung sollte einem iterativen Suchprozess folgen, während dessen Methoden des jeweiligen Forschungsumfelds benutzt werden. Hierdurch soll die Lösung stetig getestet und verbessert werden. Die Ergebnisse eines Design-Science- Forschungsprozesses müssen sowohl technisch-orientiertem Publikum, als auch management-orientiertem Publikum präsentiert werden. Die Möglichkeiten zur verteilten Erweiterung des SCOR-Modells bereichern den Bereich der Referenzmodellierungsforschung um die Übertragung und Anwendung der Methoden der konfigurativen Referenzmodellierung auf ein weiteres Referenzmodell sowie um neue Methoden zur Unterstützung der Erweiterung. Die Notwendigkeit sowie die Anforderungen an das SCOR-Modell wurden durch empirische Analysen und durch eigene, kritische Reflexion abgeleitet. Diese ist durch Erfahrungen aus Praxistätigkeiten und durch der Literatur entnommene Domänenkenntnisse gerechtfertigt. Die Artefakte wurden unter dem Aspekt der Konfigurativen Referenzmodellierung entwickelt und getestet. Für die Evaluation wird der Einsatz in der Unternehmenspraxis angestrebt. Die Ergebnisse der ersten Umfrage (Kapitel 5) wurden als Grundlage genommen, die vorgestellten Methoden zu entwickeln. Diese wurden verbessert und durch weitere Umfragen gesichert, was auch zu neuen Anforderungen und damit Lösungsentwicklungen führte. Die (Teil-)Forschungsergebnisse wurden in Form von Publikationen auf Konferenzen und in Zeitschriften beiden Publikumstypen präsentiert. Im Rahmen des Forschungsprojekts FlexNet, für das die Artefakte teilweise als Ergebnis dienten, wurden sie Publikum aus dem Unternehmensbereich präsentiert. Tab. 1.4: Richtlinien nach Hevner et al. in Bezug auf diese Arbeit

34 1 Exposition 19 Verschiedentlich wurde versucht zu definieren, worum es sich bei Lösungen bzw. Artefakten handeln kann.68 Hierbei kann March und Smiths Definition von vier Artefakttypen als sehr einflussreich angesehen werden:69 Konstrukte bieten Sprachkonzepte, die die Beschreibung eines Problems und eine entsprechende Lösung kommunizieren können. Methoden explizieren den Prozess, wie Probleme gelöst werden und geben Hinweise, wie der Lösungsraum durchsucht werden kann. In dieser Arbeit werden Wege demonstriert, die Methode der konfigurativen Referenzmodellierung auf das SCOR-Modell anzuwenden. Modelle sind das Ergebnis der Anwendung einer Methode und ermöglichen die anwendungsbezogene Darstellung eines Problems und dessen Lösungsbereichs. In dieser Arbeit werden Modelle auf eine fachkonzpetionelle Art verwendet, um Lösungsbereiche zu demonstrieren. Gleichzeit ist das erweiterte SCOR-Modell ein Artefakt im Sinne eines Forschungsgegenstandes bzw. einer Problemlösung. Instanziierungen sind technische Umsetzungen von Konstrukten, Methoden und Modellen. Für jeden in dieser Arbeit vorgestellten Forschungsbereich werden entsprechende Umsetzungen präsentiert (vgl. vor allem Abschnitt 3.3.2). Die Motivation, Anforderungen und Anregungen, die zu dieser Arbeit geführt haben, kommen aus empirischen Quellen sowie durch die Analyse existierender Methoden, die auf neue Gegebenheiten angepasst wurden. Allein durch die Erstellung der Artefakte im Sinne des Design Science-Forschungsansatzes können keine empirischen Daten erhoben werden.70 Aus diesem Grund sind vor allem zur Anforderungserhebung ergänzend die folgenden Forschungsmethoden zum Einsatz gekommen: Umfrage: Eine Umfrage ist eine Studie, die das Generalisieren der Aussagen einer Auswahl von Befragten auf eine größere Gruppe zum Gegenstand hat.71 Bei einer Umfrage werden sowohl qualitative als auch quantitative Daten erhoben, um bspw. Erwartungen oder Meinungen 68 Vgl. bspw. Benbasat und Zmud 2003; Orlikowski und Iacono 2001; R. Weber Vgl. March und Smith Zur hier gewählten Darstellung vgl. Pfeiffer 2008, S. 25. Diese vier Artefakttypen können equivalent zu den in Abschnitt 1.2 vorgestellten Forschungsergebnistypen der Referenzmodellierungsforschung gesehen werden. Insofern gilt die Aussage der Tab. 1.1 auch in Bezug auf diese Artefakttypen. 70 Ich stütze mich bei dieser Aussage und im Folgenden auf die Erkenntnis C2 von Pfeiffer: Design science research is a multi-methodological scientific process. Pfeiffer 2008, S Vgl. Creswell 2002, Pinsonneault und Kraemer 1993.

35 1 Exposition 20 von Teilnehmern zu sammeln. Häufig wird für eine Umfrage auf offene oder strukturierte Interviews oder Fragebögen zurückgegriffen, wobei entweder eine große Gruppe sehr oberflächlich (extensive research) oder eine kleine Gruppe sehr detailliert befragt werden kann (intensive research).72 In dieser Arbeit wurde eine explorative Studie im Sinne des intensive research durchgeführt, um Fachexperten in strukturierter, aber auch in offener Form zu Ihrer Auffassung in Bezug auf Erweiterungen des SCOR-Modells zu befragen.73 Dokumentenanalyse: Hierbei werden vorhandene Dokumente nicht spezifizierter Art für die Beantwortung von Forschungsfragen herangezogen und analysiert.74 Beispiele für solche Dokumente können wissenschaftliche Artikel in Fachzeitschriften, Handlungsanweisungen aus Unternehmen, persönliche Dokumente oder Präsentationen sein. Beachtet werden muss bei einer Dokumentenanalyse als Restriktion, dass ohne einen Dialog zwischen demjenigen, der das Dokument betrachtet und demjenigen, der es erstellt hat, eine semantische Lücke ist, die vom Leser durch Interpretation gedeckt werden muss.75 Zur Sicherung der ersten Forschungsfrage wurden 182 vom SCC bereitgestellte und von SCOR-Anwendern verfasste Case Studies analysiert und interpretiert.76 Das Vorgehen während der Erstellung der Publikationen sowie ein Überblick über den Aufbau dieser Arbeit wird in Abb. 1.1 dargestellt, eine Liste der verwendeten Publikationen wird im folgenden Abschnitt geben. 72 Mingers 2003, S. 237 f. 73 Diese Befragung richtete sich an FF1 und wurde in Becker, Knackstedt und Stein 2007 sowie Knackstedt, Stein und Becker 2010 publiziert. 74 Vgl. bspw. Bryman und Bell Vgl. Prior 2003, S Der Begriff Case Study kann in diesem Fall aus zwei Perspektiven betrachtet werden. Einerseits tituliert das SCC seine Datenbank von Anwenderberichten mit dem Begriff Case Study Archive (Supply Chain Council 2009c), wobei es sich nicht unbedingt um Studien der Fälle handelt (vgl. bspw. Stake 1999, S. 4). Andererseits werden diese Anwenderberichte zum Fall, wenn sie zum Studiengegenstand werden, wie im Fall der vorgenommenen Analyse (siehe Knackstedt, Stein und Becker 2010; (Kapitel 10)). Um diese Begriffsverwirrung zu vermeiden, wird im Folgenden und auch in den Publikationen der Terminus Anwenderbericht bzw. Analyse von Anwenderberichten verwendet.

36 1 Exposition 21 Kapitel in Teil A Forschungsprozess Publikation in Teil B Kap. 1 Ermittlung des Forschungsgegenstandes ECIS2007 Kap. 3.1 Anforderungserhebung ECIS2007, RefMod07,IJPE2010 Kap. 3.2 Überprüfung existierender Lösungen Implizite Anwendung in allen Publikationen Kap Adaption eines Ansatzes, der die Anforderung erfüllt GfKl2007, ECIS2008, RefMod09, IJPE2010 Kap Kap Neukonstruktion eines Ansatzes, der die Anforderung erfüllt WI2009, ER2009, EMISA2009, EMISA-J2009, Mod2010 Kap. 3.3 Konsensbasierte Validierung sowie Validierung durch exemplarische Anwendung Implizite Anwendung in allen Publikationen In Anlehnung an: Delfmann 2006, S. 29. Abb. 1.1: Vorgehen und Aufbau der Arbeit 1.6 Verwendete Publikationen Die folgenden Publikationen sind in diese kumulative Dissertation eingeflossen, wobei in der ersten Spalte der folgenden Tabelle die Publikationspunkte, in der zweiten die Zitation, in der dritten die adressierte Forschungsfrage (FF) sowie in der vierten und fünften Spalte maßgebliche Rankings angegeben werden, falls die Publikationsorgane bewertet wurden Als maßgebliche Rankings werden einerseits die JourQual2-Bewertung (JQ2; Schrader und Hennig-Thurau 2009; VHB 2008) sowie die WKWI-(Wissenschaftliche Kommission Wirtschaftsinformatik-)Bewertung von Heinzl, Schoder und Frank (Heinzl, Schoder und Frank 2008) angesehen und genutzt. Für die Einordnung des EMISA- Journals sei auf das Protokoll des WKIW-Treffens auf der WI Wien 2009 verwiesen: de/fileadmin/files/wkwi/protokoll_wien_2009.pdf, Abrufdatum A(K) entspricht einer A-Konferenz der WKWI, B(J) einem B-Journal.

37 1 Exposition 22 Tab. 1.5: Verwendete Publikationen Pkt. Nr. Zitation FF JQ2 WKWI 1/3 1 Jörg Becker, Ralf Knackstedt und Armin Stein (2007). Extending the Supply Chain Operations Reference Model: Potentials and their Tool Support. In: Proceedings of the 15 th European Conference on Information Systems (ECIS 2007). St. Gallen, Schweiz, S ; Hier: Kap. 5, S /2 2 Ralf Knackstedt und Armin Stein (2007). The Application of Taxonomies in the Context of Configurative Reference Modelling. In: Proceedings of the 31 st Annual Conference of the Gesellschaft für Klassifikation e.v. (GfKl 2007). Freiburg, S ; Hier: Kap. 6, S /4 3 Jörg Becker et al. (2008). Ontology Support For Configurative Reference Modelling. In: Proceedings of the 16 th European Conference on Information Systems (ECIS 2008). Galway, Irland, S ; Hier: Kap. 7, S /2 4 Sebastian Herwig und Armin Stein (2010). Enabling Widespread Configuration of Conceptual Models An XML Approach. In: Proceedings of the 12 th International Workshop on Reference Modelling (RefMod 2009). Berlin, Heidelberg: Springer-Verlag, S ; Hier: Kap. 8, S /3 5 Ralf Knackstedt, Armin Stein und Jörg Becker (2009). Modellierung integrierter Produktion und Dienstleistung mit dem SCOR-Modell Bestehende Ansätze und Entwicklungsperspektiven. In: Proceedings der 9. Internationalen Tagung Wirtschaftsinformatik (WI 2009). Wien, Österreich, S ; Hier: Kap. 9, S B A(K) 2, 6 2, 6 B A(K) 7 B(K) 2, 3 C A(K) Fortsetzung auf der nächsten Seite

38 1 Exposition 23 Pkt. Nr. Zitation FF JQ2 WKWI 78 6 Ralf Knackstedt, Armin Stein und Jörg Becker (2010). Advances in Reference Model based Supply Chain Design Requirements and Perspectives exemplified by the SCOR model. In: International Journal of Production Economics. Eingereicht am ; Hier: Kap. 10, S , 2, 3, 4 1/2 7 Christian Janiesch und Armin Stein (2007). Adapting Standards to Facilitate the Transition from Situational Model to Reference Model. In: Proceedings of the 10 th International Workshop on Reference Modelling (RefMod 2007). Brisbane, Australien, S ; Hier: Kap. 11, S B B(K) 1/4 8 Jörg Becker et al. (2009a). Formalizing Linguistic Conventions for Conceptual Models. In: Proceedings of the 28 th International Conference on Conceptual Modeling (ER 2009). Eingeladen zur Publikation im Data and Knowledge Engineering (DKE) Journal; Nominiert für den Best Paper Award. Gramado, Brasilien, S ; Hier: Kap. 12, S B (C) A(K) (B[J]) 1/4 9 Patrick Delfmann et al. (2009b). Supporting Distributed Conceptual Modelling through Naming Conventions A Tool-based Linguistic Approach. In: Enterprise Modelling and Information Systems Architectures 4.2, S. 3 20; Hier: Kap. 13, S /5 10 Jörg Becker et al. (2010a). Ein automatisiertes Verfahren zur Sicherstellung der konventionsgerechten Bezeichnung von Modellelementen im Rahmen der konzeptionellen Modellierung. In: Proceedings der Fachtagung Modellierung Angenommene Einreichung am Klagenfurt, Österreich; Hier: Kap. 14, S C C(J) 5 D Fortsetzung auf der nächsten Seite 78 Die Publikation wurde eingereicht, jedoch abgelehnt.

39 1 Exposition 24 Pkt. Nr. Zitation FF JQ2 WKWI 1/4 11 Patrick Delfmann et al. (2009a). Pattern Matching in Conceptual Models A Formal Multi-Modelling Language Approach. In: Proceedings of the 3 rd International Workshop on Enterprise Modelling and Information Systems Architectures (EMISA 2009). Eingeladen zur Veröffentlichung im Enterprise Modelling and Information Systems Architectures Journal. Ulm, S ; Hier: Kap. 15, S /30 Punkte 5 C B(J) Tab. 1.5: Verwendete Publikationen

40 2 Grundlagen 2.1 Informationsmodellierung Modellbegriff Informationsmodelle sind eine spezielle Klasse von Modellen, welche selbst als andere Systeme zielorientiert abbildende Systeme gesehen werden.79 In Übereinkunft mit Pfeifer wird unter einem System ein [...] sinnvoll in sich gegliedertes, geordnetes Ganzes [...] verstanden.80 Bestandteile eines Systems sind Elemente sowie deren Beziehungen untereinander, die sich von der Systemumwelt abgrenzen.81 Das in dieser Arbeit als Forschungsgegenstand verwendeten SCOR-Modell soll dem Charakter nach einem Informationsmodell entsprechen und als Hilfsmittel für die Informationssystemgestaltung eingesetzt werden können.82 Modelle werden als abstrakte Repräsentation eines realweltlichen (der Objektwelt entspringenden) Sachverhalts verstanden. Im konstruktivistischen Sinne kann ein Modell als eine Konstruktion eines Subjekts betrachtet werden.83 Ein Informationsmodell ist somit das Ergebnis einer Konstruktion eines Konstrukteurs oder einer 79 Ferstl und Sinz 2006, S. 20. Zur Diskussion zum Begriff System (abgeleitet aus dem Griechischen sýstema das Zusammengestellte, das Zusammengeordnete ) siehe bspw. Schütte 1998, S. 37 ff.; Becker und Schütte 2004, S. 30 ff.; Delfmann 2006, S. 30 f. 80 Vgl. Pfeifer 1997, S f. 81 Vgl. Ackoff 1971, S Ackoff definiert zwei Arten von Systemen: Abstrakte Systeme, bei denen sowohl Elemente als auch deren Beziehungen durch Annahmen getroffen werden (eine Einstellung, die dem ontologischen Realismus zugeordnet werden kann), und konkrete Systeme, deren Elemente und Beziehungen zumindest Repräsentationen in der Objektwelt im Sinne der Realwelt des ontologischen Idealismus besitzen. In dieser Arbeit wird dem Gedanken des Kantianismus folgend angenommen, dass Elemente und deren Beziehungen untereinander sowohl eine Entsprechung in der Realwelt haben dürfen, aber auch lediglich Gedankenkonstrukte sein können. Vgl. zu dieser Diskussion nochmals Abschnitt 1.4. Vgl. auch Baetge Die Definitionen der in dieser Arbeit verwendeten Begriffe abstrahieren von den unter Umständen geführten Metadiskussionen und verwenden diejenigen, die im Rahmen dieser Ausarbeitung als plausibel angesehen werden. Im Falle der Entscheidung für eine zur Diskussion stehende Definition wird auf die entsprechenden Alternativauffassungen verwiesen. 83 Vgl. nochmals Abschnitt 1.4 zum epistemologischen Aspekt dieser Arbeit. 25

41 2 Grundlagen 26 Gruppe von Konstrukteuren, das [...] Informationen über zu modellierende Elemente eines Systems [...] mit Hilfe einer Sprache [...] 84 umfasst.85 Die Erstellung eines Modells kann somit als Konstruktionsprozess verstanden werden, bei dem ein zu modellierender Sachverhalt der materiellen Domäne im Fall der Wirtschaftsinformatik in der Regel ein Informationssystem86 subjektiviert und in ein mentales Modell überführt wird, um anschließend mittels einer Sprache in ein konzeptionelles Modell überführt zu werden (vgl. Abb. 2.1). Hierbei besitzt im Sinne der Hermeneutik bereits existierendes Wissen des Modellerstellers über die materielle Domäne Einfluss auf das mentale, abstrahierte Modell. Bei den Sprachen, die Externe Realität Interne Modelle Modellersteller Externes Modell Konstruktion Mentales Modell Explizierung Konstruktion Berücksichtigung Existierendes Wissen Anwendung Anwendung Materielle Domäne Diskurs Modellierungssprache Domänensprache Konzeptionelles Modell Mentales Modell Interpretation Evaluation Konstruktion Existierendes Wissen Modellanwender In Anlehnung an: Pfeiffer 2008, S. 51; ursprünglich Becker und Schütte 2004, S. 66. Abb. 2.1: Modellierungsprozess 84 Becker und Schütte Es wird hier explizit von der vollständigen Definition von Becker und Schütte 2004 Abstand genommen, welche Relevanz und Zeitbezug in die Definition aufnehmen. Die Relevanz wird als subjektive Eigenschaft angenommen, die extern nicht bewertbar ist. Nach Ruhrmann ist für einen Rezipienten zwar die (subjektive) Relevanz einer Nachricht wichtig, um Aufmerksamkeit zu erregen (Ruhrmann 1994, S. 245). Wenn das Subjekt ein Modell erstellt, wird es aber zumindest für ihn eine wie auch immer geartete Relevanz besitzen, auch wenn diese nur für ihn selbst erkennbar ist, er also selbst der Rezipient ist. Der Zeitbezug wird nicht berücksichtigt, da er von dem Modellersteller bei der Modellerstellung nicht zwingend berücksichtigt worden sein muss und unter Umständen erst ex post bewertbar ist. 86 Vgl. bspw. Ferstl und Sinz 2006, S. 1; Mertens et al. 2004, S. 4; Scheer 1997, S. 1.

42 2 Grundlagen 27 für die Explizierung des Modells verwendet werden, kann es sich um (semi-)formale Modellierungssprachen, um Domänensprachen oder um eine Kombination von beidem handeln.87 Mit dieser Kenntnis ist es dem Modellanwender möglich, unter Berücksichtigung des eigenen, über die materielle Domäne verfügbaren Wissens, mit dem Modellersteller, aber auch mit anderen Modellanwendern in einen entsprechenden Diskurs über das mentale Modell zu treten. Hierbei ist ein möglichst hoher Übereinstimmungsgrad zwischen den mentalen Modellen der unterschiedlichen Beteiligten relevant, was eine gute Dokumentation des Modellerstellungsprozesses erfordert. Sowohl der Modellerstellungsprozess (die Konstruktion), als auch die Beschäftigung mit dem Modell verändern das Wissen bzw. die Vorstellung über die materielle Domäne. Die Modellerstellung muss jedoch nicht zwingend von einer einzelnen Person vorgenommen, sondern kann auch von einer Modellierungsgruppe kooperativ durchgeführt werden.88 Auch die Einbeziehung von Modellnutzern in den Konstruktionsprozess kann hilfreich sein, vor allem, wenn das Modell nicht zur eigenen Verwendung entworfen wird. Durch den Diskurs über den realweltlichen Aspekt sowie die Intention des Modells schon während der Konstruktion besteht die Möglichkeit, einen hohen Übereinstimmungsgrad der mentalen Modelle der Beteiligten zu erreichen. Das hieraus folgende konzeptionelle Modell wird so zu einem möglichst hohen Maße den Erwartungen der Modellanwender entsprechend. Hierdurch steigt zwar der Koordinationsaufwand, die Modellqualität im Sinne des gemeinsam entwickelten Verständnisses über die konzeptionellen Modelle wird aber erhöht.89 Unterstützt werden können dieser Koordinationsaufwand sowie die daraus folgende Synchronisierung des mentalen Modells durch Methoden, wie sie in Abschnitt vorgestellt und in den Publikationen der Kapitel entwickelt wurden Modellierungssprachen Um in der Lage zu sein, Informationsmodelle zu erstellen, sind Modellierungssprachen notwendig, die eine Visualisierung des mentalen in Form eines konzeptionellen Modells ermöglichen (vgl. nochmals Abb. 2.1). Nach Carnap werden Sprachen allgemein als Systeme von Zeichen und Regeln zur Verwendung der Zeichen verstanden.90 Dies lässt sich auf Modellierungssprachen übertragen, da diese als Systeme von Zeichen sowie Regeln über die Verwendung dieser Zeichen im Rahmen 87 Für eine (formale) Spezifikation dieser Thematik vgl. Pfeiffer 2008, S Im Folgenden wird der Begriff Referenzmodellersteller synonym für Gruppe von Referenzmodellerstellern genutzt. Sobald sich Aussagen ausschließlich auf einzelne Modellersteller beziehen, wird dies explizit angegeben. 89 Vgl. Frank, Strecker und Koch 2007b, S. 19. Vgl. auch nochmals die Semantische Theorie der Wahrheit (Abschnitt 1.4, S. 13), die von einer Konsensorientierung einer Gruppe unter Berücksichtigung einer gemeinsamen Objekt- und Metasprache ausgeht. 90 Vgl. Carnap 1960, S. 1. Vgl. zu diesen Ausführungen auch Delfmann 2006, S. 48 ff.

43 2 Grundlagen 28 der Erstellung von Modellen verstanden werden können. Nach Holten kann eine Modellierungssprache in einen repräsentationellen und einen konzeptionellen Sprachaspekt unterteilt werden (vgl. Abb. 2.2).91 1:n Grundlegende Komponente Methode Technik Sprache 1:1 Konzeptioneller Aspekt der Sprache Basis für... Abgeleitete Komponente Handlungsanleitung 1:n Repräsentationeller Aspekt der Sprache Abb. 2.2: Komponenten einer Technik In Anlehnung an: Holten 2000, S. 5. Der konzeptionelle Aspekt einer Sprache umfasst die Regeln und Elemente (die Grammatik) der Modellierungssprache, deren Kenntnis für die Modellierung in dieser Modellierungssprache notwendig ist. Hierbei müssen die Elemente und deren Einsatz beschrieben werden. Für die Konstruktion des konzeptionellen Aspekts einer Modellierungssprache ist es daher wichtig, dass dieser vollständig und gut dokumentiert ist. Diese Dokumentation kann in einer natürlichsprachlichen Art vorgenommen werden, damit der Modellnutzer einen höheren Übereinstimmungsgrad seines mentalen Modells mit dem des Modellerstellers erreichen kann. Grundsätzlich kann einer Sprache immer nur genau ein konzeptioneller Aspekt zugeordnet werden. Sollte dieser geändert werden, resultiert dies in einer neuen Sprache. Der repräsentationelle Aspekt einer Sprache setzt die Elemente des konzeptionellen Aspekts visuell um, indem den Elementen Symbole zugeordnet werden. Zusätzlich sollen Informationen darüber gegeben werden, wie die Verwendung der Elemente bzw. deren Anordnung zu geschehen hat. Es ist möglich, für eine Sprache mehrere Repräsentationsformen zu haben, um den verschiedenen kognitiven Anforderungen der unterschiedlichen Modellnutzer entgegen zu kommen. Wird zu einer Sprache eine entsprechende Handlungsanleitung zur Verfügung gestellt, wird diese Kombination nach Holten als Technik bezeichnet. Eine Handlungsanweisung beschreibt den Einsatz der Sprache und bietet Informationen, die über den konzeptionellen bzw. repräsentationellen Aspekt hinausgehen Vgl. Holten 1999, S Für das Beispiel der EPK könnte in einer Handlungsanweisung bspw. angegeben werden, dass nur diejenigen Aktivitäten als Funktion dargestellt werden, die wertschöpfenden Charakter haben oder die in Beziehung zum prozessprägenden Objekt stehen. Vgl. Becker und Schütte 2004, S. 107.

44 2 Grundlagen 29 Eine Reihe von in Beziehung stehenden Aufgaben, die in ihrer Gesamtheit zur Lösung eines übergeordneten Modellierungsproblems beitragen, wird als Methode bezeichnet. Innerhalb einer Methode können mehrere Modellierungstechniken verwendet werden Klassifikation von Informationsmodellen Schütte klassifiziert Informationsmodelle in verschiedene Dimensionen, die eine Einordnung einzelner Modelle ermöglichen sollen.94 Hierbei kommen unterschiedliche Realweltaspekte, Zwecke oder Formalisierungsgrade zum Tragen. In Bezug auf Informationssysteme führen Scheer und Nüttgens mit dem ARIS-Konzept (Architektur Integrierter Informationssysteme) einen Ordnungsrahmen ein, der genutzt werden kann, um den Zweckaspekt von Informationsmodellen zu klassifizieren.95 Durch diesen Ordnungsrahmen werden vier verschiedene Perspektiven auf ein Unternehmen vorgegeben: Die Organisationssicht, die Funktionssicht, die Datensicht sowie die die anderen drei Sichten integrierende Prozesssicht.96 Für jede dieser Sichten werden die drei Beschreibungsebenen Fachkonzept, DV-Konzept und Implementierung der Informationssystementwicklung97 betrachtet. Als weitere Kategorisierung wird von Schütte die Unterscheidung zwischen Spezifischem Informationsmodell und Referenz-Informationsmodell eingeführt.98 Während grundsätzlich jedes Modell, das den oben angeführten Spezifikationen entspricht, als spezifisches Informationsmodell angesehen werden kann, sind an Modelle, die als Referenzmodelle gelten sollen, zusätzliche Bedingungen gebunden. 93 Vgl. Holten 2000, S. 5; Delfmann 2006, S Schütte 1998, S Scheer und Nüttgens 2000, S Dieses Konzept ist bspw. auch im Handels-H-Modell von Becker und Schütte umgesetzt. Vgl. Becker und Schütte Vgl. für eine ausführliche Beschreibung Scheer und Hars 1992, S. 15 ff. Fachkonzeptionelle Modelle abstrahieren von informationstechnischen Details und repräsentieren rein fachliche Aspekte in strukturierter Form (vgl. Delfmann 2006, S. 42). In DV-konzeptionellen Informationsmodellen werden konkrete informationstechnische Details aufgenommen. Implementierungsmodelle sind schon mit Programm-Code vergleichbar und können von Rechnersystemen interpretiert werden. Beispiele hierfür sind ohne weiter auf die Domäne einzugehen Workflow- Modelle, die direkt in eine Workflow-Engine propagiert (deployed) werden können. Für eine grundlegende Einführung in das Workflow Management siehe bspw. Jeston und Nelis Schütte 1998, S. 64.

45 2 Grundlagen Referenzmodellierung Aus etymologischer Sicht bedeutet der Begriff Referenz Empfehlung oder Bezugnahme,99 womit der Begriff Referenz-Informationsmodell100 auf ein Modell mit Empfehlungscharakter hindeutet, auf das Bezug genommen werden kann bzw. soll.101 Bezogen auf die Frage, wann ein Modell als Referenzmodell angesehen werden kann, wird in dieser Arbeit in Übereinstimmung mit vom Brocke, Delfmann sowie Knackstedt, Stein und Becker argumentiert, dass ein Informationsmodell dann als Referenzmodell angesehen wird, wenn es (1) mit der entsprechenden Intention erstellt wurde,102 oder, angelehnt an Janiesch und Stein, (2) als spezifisches Informationsmodell zu diesem Zweck angepasst wird103 oder (3) ohne die entsprechende Intention erstellt wurde, aber verbreitet genutzt wird.104 Aus der weiterführenden Diskussion zur Charakterisierung von Referenzmodellen lassen sich vier weitere Merkmale extrahieren:105 Allgemeingültigkeit: Ein Referenzmodell sollte für verschiedene Anwendungsbezüge ableitbar sein und für diese spezifische Modelle zur Verfügung stellen. Hierfür sind verschiedene Vorgehen denkbar. Eine Möglichkeit ist, das Referenzmodell auf sehr grobgranularer Ebene zu definieren und die Spezifikation der Elemente auf dieser Ebene dem Modellnutzer zu überlassen. Eine andere, dem Ansatz der konfigurativen Referenzmodellierung nahe Möglichkeit ist die (im Sinne des Modellierers) vollständige Spezifikation der Domäne und die bedarfsgerechte Bereitstellung von Individualmodellen für die Anwender. Das Referenzmodell besteht in diesem Fall aus einer Gesamtmenge spezifizierter Teilmodelle, sodass individuelle Modelle jeweils einem solchen Teilmodell entsprechen. Dieser Ansatz entspricht im Verständnis dieser Arbeit nicht der Allgemeingültigkeit. Es wird in dieser Arbeit vor allem in Hinblick auf die Intention, ein Referenzmodell um spezifische Elemente zu erweitern von der Forderung nach Allgemeingültigkeit abgesehen. 99 Vgl. Pfeifer 1997, S Im Folgenden wird der Term Referenz-Informationsmodell der Überschrift dieses Abschnitts entsprechend mit Referenzmodell abgekürzt. 101 Vgl. Schütte 1998, S. 70; Schwegmann 1999, S. 53; Delfmann 2006, S Vgl. vom Brocke 2003, S. 34, Delfmann 2006, S. 46 und Knackstedt, Stein und Becker Vgl. Janiesch und Stein 2007 bzw. Kapitel Dieser Fall ist zumindest dem Autor nicht bekannt. 105 Vgl. hierzu bspw. Fettke und Loos 2004, S. 8 ff.; vom Brocke 2003, S. 31 ff.; Knackstedt 2006, S. 57 ff.; Raue 1999, S. 26 ff. Für eine ausführlichere Übersicht siehe Delfmann 2006, S. 46.

46 2 Grundlagen 31 Branchenbezug: Einige Autoren fordern einen konkreten Branchen- oder Geschäftsbereichbezug106 eines Referenzmodells.107 Hierdurch wird die Verwendung des Referenzmodellbegriffs nach Ansicht des Autors zu sehr eingeschränkt, da auch branchen- und geschäftsbereichübergreifende Referenzmodelle vorstellbar sind.108 Durch die Methode der konfigurativen Referenzmodellierung wird bspw. die Ergänzung von Informationen in ein Referenzmodell, die nicht in dessen direktem Fokus liegen, ermöglicht ein Ansatz, der in dieser Arbeit für das SCOR-Modell angewendet wird und von Anwendern gewünscht wird.109 Vollständigkeit: Nach Hars und Scheer ist es für ein Referenzmodell notwendig, dass es zumindest einen Kontext gibt, unter dem es ohne Anpassungen verwendet werden kann.110 Dies entspricht wiederum dem Dilemma der Referenzmodellierung (vgl. Abschnitt 1.2): Entweder das Referenzmodell wird derart generisch entwickelt, dass eine Anpassung zwingend notwendig ist, oder das Referenzmodell wird derart detailliert dargestellt, dass es aufgrund mangelnder Zielgruppen und Einsatzszenarien nicht mehr als solches anerkannt werden kann. Aus diesem Grund wird die Vollständigkeit in dieser Arbeit nicht als relevantes Kriterium erachtet. Adaptierbarkeit: In Übereinstimmung mit Delfmann wird die Notwendigkeit der methodischen Unterstützung einer Modelladaption nicht gefordert.111 Adaptionsmechanismen wie die freie Modifikation112, bei der das Modell unabhängig von einer konkreten Sprache oder Methode erweitert oder verfeinert werden kann, stehen dieser Voraussetzung entgegen. In abgeschwächter Form ist diese Forderung jedoch durchaus relevant: Eine wie auch immer geartete Adaption ohne Berücksichtigung der methodischen Unterstützung muss (im Verständnis dieser Arbeit) für ein Referenzmodell gewährleistet sein. Sollte eine methodische Unterstützung zur Verfügung stehen, erhöht dies jedoch die Wahrscheinlichkeit einer konsistenten Anpassung des Referenzmodells. 106 Vgl. bspw. Delp 2006, S Vgl. bspw. Marent 1995, S Vgl. bspw. das IRM (InCoCo-S Referenzmodell) von Montorio 2006, das als Ergänzung zum SCOR-Modell Dienstleistungsprozesse zum Gegenstand hat, aber kein unabhängiges Modell der Dienstleistungsbranche ist. 109 Vgl. Knackstedt, Stein und Becker 2010 bzw. Kapitel 10 auf S. 111 im Teil B dieser Arbeit. 110 Hars 1994, S. 15; Scheer 1998, S Vgl. Delfmann 2006, S Vgl. vom Brocke 2003, S

47 2 Grundlagen 32 Unter Einbeziehung dieser vier Forderungen und der Berücksichtigung der oben angeführten Arbeitsdefinition bleibt diese weitestgehend bestehen und wird lediglich um die Adaptierbarkeit ergänzt: Ein Referenzmodell ist ein Modell, das entweder (1) mit der Intention konstruiert wird, wiederverwendet zu werden, oder (2) aufgrund einer bewussten Entscheidung dahingehend verändert wird, dass es wiederverwendet werden kann oder (3) das ohne dass es mit dieser Intention entwickelt wurde wiederverwendet wird. In jedem Fall muss es (4) adaptierbar sein, ohne dass hierfür zwingend eine methodische Unterstützung angeboten wird. 2.3 Konfigurative Referenzmodellierung Wie bereits in den vorhergehenden Abschnitten angesprochen, dient die konfigurative Referenzmodellierung als Ausweg aus dem Dilemma der Referenzmodellierung. Erste Ansätze wurden von Schütte und Schwegmann113 vorgestellt und später vor allem von der Forschergruppe um Becker et al. weiter entwickelt.114 Das grundlegende Konzept der konfigurativen Referenzmodellierung ist das Anreichern der Referenzmodelle im besten Fall schon während deren Erstellung um Parameter, die einen (oder mehrere) konkrete Anwendungskontexte definieren.115 Ein solcher Parameter könnte für Modellerweiterungen stehen und beispielsweise im Bereich des Supply Chain Managements die Ausprägung GreenSCM116 besitzen. An relevante Modellelemente oder -teile wird dann der Parameter mit der entsprechenden Ausprägung annotiert.117 Solche Elemente müssen nicht für jeden Referenzmodellnutzer relevant sein und können durch Anwenden von Regeln und Algorithmen aus dem Referenzmodell entfernt werden.118 Die Erstellung (1) und Nutzung (2) solcher konfigurierbaren Referenzmodelle kann in eben diese Phasen ((1) und (2)) unterschieden werden, in denen jeweils der Konstrukteur (1) bzw. der Anwender (2) zum Einsatz kommt (vgl. Abb. 2.3). Zur Anpassung hat der Modellanwender die Möglichkeit, das konfigurierbare Referenzmodell zu konfigurieren und es anschließend weiter anzupassen: 113 Vgl. Schütte 1998 und Schwegmann Vgl. Becker et al. 2001; Becker et al. 2002; Becker, Delfmann und Knackstedt 2002; Becker et al. 2003; Becker, Delfmann und Knackstedt 2004; Becker et al. 2004; Rosemann, Schwegmann und Delfmann Delfmann 2006 fügt der konfigurativen Referenzmodellierung eine methodische Unterstützung hinzu. Hieran orientieren sich auch die folgenden Ausführungen. 115 Im Folgenden wird in diesem Abschnitt unter einem Referenzmodell soweit nicht explizit anders betont ein konfigurierbares verstanden. 116 Zu einer ausführlicheren Erläuterung zu GreenSCM bzw. GreenSCOR siehe Fußnote 219 auf S In diesem Beispiel: Modellerweiterung = GreenSCM. 118 Für die konkrete Umsetzung in Bezug auf das SCOR-Modell und ausführlichere Erläuterungen siehe Knackstedt, Stein und Becker 2010.

48 2 Grundlagen 33 Evaluation Modellerstellung Projektzieldefinition Weitere Anpassung Definition der Modellierungstechnik Entwicklung Projektzieldefinition Konfigurierbares Referenzmodell Suche und Auswahl Anwendung Konfiguriertes Modell Konfiguration Abb. 2.3: Phasen des Lebenszyklus eines konfigurierbaren Referenzmodells Konfiguration: Hier wählt der Referenzmodellnutzer die für ihn relevanten Konfigurationsparameterausprägungen119 aus, die vom Referenzmodellersteller in das Modell eingearbeitet wurden. Aufgrund einer Regelbasis und falls vorhanden mit Hilfe einer methodischen Unterstützung wird eine konfigurationsspezifische Modellvariante abgeleitet. Freie Modifikation: Es ist unwahrscheinlich, dass ein Referenzmodell nach der Konfiguration von dem Nutzer ohne weitere Anpassung übernommen werden kann. Die abgeleitete Modellvariante sollte aber einen besseren Ausgangspunkt für eine spezifische Anpassung geben, als das vollständige Gesamtmodell. Konfigurationsparameter werden in der Regel in Unternehmensmerkmale 120 und Perspektiven gegliedert,121 was aber einen Unternehmensbezug unbedingt voraussetzt. In dieser Arbeit wird keine Klassifikation der Konfigurationsparameter vorgenommen.122 Diejenigen, die für das SCOR-Modell vorgeschlagen werden, können bestenfalls den Perspektiven zugeordnet werden. Sie repräsentieren die Anforderungen von verschiedenen Benutzergruppen an Informationsmodelle und sind somit freier definierbar als Unternehmensmerkmale. Zusätzlich wird die Festlegung auf die Verwendung von Unternehmensmerkmalen dem unternehmensübergreifenden Charakter einer Supply Chain nicht gerecht Im Folgenden wird der Term Parameterausprägung synonym zu Konfigurationsparameterausprägung verwendet. 120 Vgl. Becker, Delfmann und Knackstedt 2002, S Vgl. Delfmann 2006, S. 53 f. 122 Es geht hierbei um die Klassifikation der Konfigurationsparameter auf Typebene. Für eine Klassifizierung im Sinne von Taxonomien auf Instanzebene siehe Abschnitt Die Identifikation und Einführung sinnvoller Kriterien für die Kategorisierung von Konfigurationsparametern für das Supply Chain Management ist eine Aufgabe, die als weiterer Forschungsbedarf gesehen werden muss. Vgl. Kapitel 4.

49 2 Grundlagen 34 Für die Konfiguration von Modellen stehen verschiedene Mechanismen zum Ausblenden bzw. Entfernen von Elementen aus dem Referenzmodell zur Verfügung. Diese führen Regeln aus, durch die festgelegt wird, welche Anpassungen ein Referenzmodell aufgrund einer konkreten Auswahl von Perspektiven, denen die entsprechenden Konfigurationsregeln zugeordnet wurden, erfährt.124 Die Mechanismen werden grundsätzlich auf einem integrierten Gesamtmodell ausgeführt, das sämtliche Informationen enthält. Als Ergebnis befinden sich lediglich die Modellelemente in der angepassten Variante, die aufgrund der Wahl der Parameterausprägungen nicht aus dem Modell entfernt wurden. Insgesamt werden acht Konfigurationsmechanismen fünf Kategorien zugeordnet:125 Modelltypselektion: In einem Referenzmodell ist es möglich, dass verschiedene Typen von Modellen vorkommen. Als anschauliches Beispiel kann das Handels-H-Modell angeführt werden,126 das die verschiedenen Modelltypen Funktionsdekompositionsdiagramm zur Beschreibung von (betriebswirtschaftlichen) Funktionen, ERM (Entity Relationship Model) zur Datenmodellierung, Organigramm zur Organisationsmodellierung sowie EPK (Ereignisgesteuerte Prozesskette) zur integrierten Gesamtdarstellung verwendet. Der Mechanismus der Modelltypselektion unterstützt die Zuordnung von Modelltypen zu Perspektiven und ermöglicht somit deren anforderungsspezifische Ausblendung. Elementtypselektion: Hierbei werden Perspektiven einzelne Elementtypen einer Modellierungssprache zugeordnet, die bei einer Konfiguration bedarfsgerecht aus dem Referenzmodell entfernt werden können. Für die Modellierungssprache EPK können so bspw. die Elementtypen Entitytyp und Anwendungssystem für die Perspektive des Organisationsgestalters ausgeblendet werden.127 Elementselektion: Im Gegensatz zur Modelltyp- und Elementtypselektion werden hierbei einzelne Instanzen von Modellelementen aus dem Modell entfernt. Dies geschieht durch die konkrete Annotation von Konfigurationsattributen und -termen an einzelne Modellelemente und die anschließende Auswertung von Regeln unter Bezugnahme auf die gewählten Parameterausprägungen. 124 Vgl. hierzu auch Delfmann 2006, S. 66 f. 125 Im Folgenden werden lediglich die Kategorien erläutert. Deren Beziehung zum SCOR-Modell werden in Abschnitt vorgestellt. Für eine ausführliche Auseinandersetzung mit den Mechanismen vgl. Delfmann 2006, S. 66 ff. 126 Vgl. Becker und Schütte Auf eine Unterscheidung der Elementselektion nach Attributen bzw. nach Termen wird in dieser Arbeit nicht eingegangen. Vgl. hierzu bspw. Delfmann 2006, S. 68.

50 2 Grundlagen 35 Bezeichnungsvariationen: Perspektivenabhängig können Geschäftsobjekte, die in den Bezeichnungen von Modellelementen vorkommen, unterschiedlich benannt sein. In diesem Fall kann der Mechanismus der Bezeichnungsvariation die Bezeichnung von Modellelementen ersetzten, bspw. den Begriff Rechnung durch Faktura. Dieser Mechanismus wird in dieser Arbeit nicht weiter berücksichtigt, bietet aber in Bezug auf die in den Kapiteln 12, 13 und 14 vorgestellten Methoden Potenzial für weiterführenden Forschungsbedarf. Darstellungsvariation: Entsprechend der Motivation für die Bezeichnungsvariation können Modellnutzer mit unterschiedlichen Kognitionstypen die Darstellung von Modellelementen verschieden aufnehmen und interpretieren. Wenn bei der Gestaltung des fachkonzeptionellen Modells auf die Anforderungen des Adressaten durch die geeignete Darstellungsform Rücksicht genommen werden kann, führt dies dazu, dass die Übertragung des fachkonzeptionellen Modells in ein mentales Modell durch Interpretation einfacher und im Sinne des gemeinsamen Verständnisses durch einen höheren Deckungsgrad der mentalen Modelle richtiger vonstattengeht. Ein einfaches Beispiel ist die Zurverfügungstellung eines EPK-Modells in schwarz / weiß, ein komplexeres Beispiel ist die Änderung der Elementform (des Shapes). Die Darstellungsvariation muss sich aber nicht nur auf Modellelemente beziehen, sondern kann auch die gesamte Modelltypologie betreffen, sodass aufgrund einer Konfiguration ein anderes Modelllayout angeboten wird. 2.4 Referenzmodellierung im Supply Chain Management Supply Chain Management Das SCOR-Modell gilt als eines der am weitesten verbreiteten Referenzinformationsmodelle im Bereich des Supply Chain Management (SCM).128 Supply Chain Management ist noch immer ein diffuser, nicht eindeutig definierter Begriff. Obwohl das Supply Chain Management nicht direkter Gegenstand dieser Arbeit ist, ist zur Einordnung des SCOR-Modells eine Begriffsdefinition notwendig. Nach J. Weber kann das Supply Chain Management als fortschrittlichste von vier Hauptsichten auf die Logistik gesehen werden.129 Dies bedingt aber, das SCM als spezielle Art der 128 Vgl. Sürie und Wagner 2008, S. 41; Kasi Vgl. J. Weber 2002, S. 4 f. J. Weber sieht den ersten Entwicklungsschritt der Logistik als material- und warenflussbezogene Dienstleistungsfunktion, den zweiten als flussbezogene Koordinationsfunktion, den dritten als Flussorientierung des Unternehmens und den vierten als Supply Chain Management bezeichnete unternehmensübergreifende Flussorientierung.

51 2 Grundlagen 36 Logistik zu betrachten, wobei in dieser Hinsicht noch andere Ansichten vertreten sind.130 In dieser Arbeit wird die Auffassung des Unionists vertreten, die besagt, dass die Logistik als Teil des Supply Chain Managements gesehen werden kann. Mentzer et al. versuchen, verschiedene vorhandene SCM-Definitionen zu klassifizieren und eine einheitliche abzuleiten.131 Im Folgenden wird der Argumentation von Mentzer et al. gefolgt. Diese definieren zunächst Supply Chain als [...] eine Menge von drei oder mehr Entitäten (Organisationen oder Individuen), die direkt an dem Material-, Dienstleistungs-, Finanz- und / oder Informationsfluss von der Quelle zum Abnehmer und umgekehrt beteiligt sind. 132 Weiter unterteilen sie diese Kette in eine direkte (1), erweiterte (2) und vollständige (3) Supply Chain,133 die vom eigenen Unternehmen aus betrachtet die nächsten Partner (1), zusätzlich sämtliche Partner der direkten Partner (2), oder alle Teilnehmer der Supply Chain berücksichtigen (3). Das SCC positioniert sein Verständnis in dieser Einordnung explizit in einer Erweiterten Supply Chain.134 Weiterhin unterscheiden Mentzer et al. die Auffassungen, dass SCM als Supply Chain-bezogene Managementphilosophie (1), als Werkzeug zur Umsetzung einer Supply Chain-bezogenen Managementphilosophie (2), oder als eine Menge von Supply Chainbezogenen Managementprozessen (3) gesehen wird. Sie charakterisieren (1) mit den folgenden drei Punkten:135 1a. SCM ist ein Systemansatz, der die Supply Chain als Ganzes sieht und den gesamten Materialfluss vom Zulieferer zum letzten Abnehmer managt. 2a. SCM ist eine strategische Ausrichtung, um durch gemeinsame Bemühungen die inner- und überbetrieblichen operationalen und strategischen Fertigkeiten zusammenzuführen und als Ganzes zu synchronisieren. 3a. SCM setzt den Fokus auf den Abnehmer, um für ihn eine einmalige und individuelle Wertschöpfung zu generieren, die in Kundenzufriedenheit mündet. 130 Vgl. Larson und Halldorsson 2004, S. 18 f. Diese unterscheiden die Einstellungen Traditionalist, Relabelling, Unionist und Intersectionist. Während der Traditionalist SCM als Teil der Logistik sieht ( logistics outside the firm ), geht es beim Relabelling um die gleiche Sache, jedoch mit einer anderen Bezeichnung. Der Unionist sieht Logistik als Teilaspekt des SCM, während der Intersectionist lediglich Schnittstellen zwischen SCM und Logistik sieht. J. Weber wird sich also als Traditionalist sehen. 131 Vgl. Mentzer et al Aus dem Englischen übersetzt. Vgl. Mentzer et al. 2001, S. 4: [...] a set of three or more entities (organizations or individuals) directly involved in the upstream and downstream flows of products, services, finances and / or information from a source to a customer. 133 Die Begriffe wurden sinngemäß aus dem Englischen übersetzt. Die dort verwendeten sind direct, extended und ultimate. Mentzer et al. 2001, S Supply Chain Council 2009b, S : It spans: all customer interactions (order entry through paid invoice), all physical material transactions (supplier s supplier to customer s customer, including equipment, supplies, spare parts, bulk product, software, etc.). 135 Mentzer et al. 2001, S. 7.

52 2 Grundlagen 37 In Bezug auf das SCOR-Modell kann davon ausgegangen werden, dass die Supply Chain (1a.) als Ganzes gesehen wird und eine strategische Ausrichtung (2a.) Grundvoraussetzung ist.136 Im Mittelpunkt des SCOR-Modells steht zwar das eigene Unternehmen (vgl. Abb. 2.4) und nicht der Abnehmer. Eine Abnehmerorientierung ist aber aus vom SCC getroffenen Aussagen erkennbar.137 Es kann dennoch unterstellt werden, dass das Produkt des SCC als Ergebnis einer Managementphilosophie gesehen wird. Um eine SCM-Philosophie umzusetzen, sind unterschiedliche Maßnahmen notwendig (2a.). Aus der Literatur wurden von Mentzer et al. folgende Schritte extrahiert:138 1b. Abgestimmtes Verhalten 2b. Gemeinsamer Informationsaustausch 3b. Gemeinsames Tragen von Risiko und Chance 4b. Kooperation 5b. Gemeinsames Ziel und gleicher Fokus bei der Kundenausrichtung 6b. Prozessintegration 7b. Zeitlich langfristig ausgelegte Partnerschaften Durch die vom SCC vorgegebene Spannweite des SCOR-Modells sowie die übergreifenden Plan- Prozesse kann vorausgesetzt, die beteiligten Unternehmen der Supply Chain unterstützen eine SCOR-Nutzung davon ausgegangen werden, dass das Verhalten der kooperierenden Teilnehmer (4b.) aufeinander abgestimmt ist (1b.). Die Struktur des SCOR-Modells setzt einen gemeinsamen Informationsaustausch (2b.) sowie die ebenfalls notwendige Prozessintegration (6b.) voraus und definiert diese. Eine unternehmensübergreifende SCOR-Umsetzung wird vermutlich nicht stattfinden, wenn keine langfristige Partnerschaft angestrebt wird (7b.). In Bezug auf (3b.) kann keine Aussage getroffen werden, es kann jedoch davon ausgegangen werden, dass Kooperationen durch die Verfolgung eines gemeinsamen Ziels entstehen (5b.). Durch die enthaltenen Prozesselemente unterstützt das SCOR-Modell die oben angegebenen Punkte und kann als Instrument zur Umsetzung der vom SCC vorgegebenen SCM-Philosophie gesehen werden. Die Elemente des SCOR-Modells selbst können zumindest als Blaupausen für Supply Chain Management-Prozesse (3a.) gelten, wenn auch nicht für alle von Mentzer et al. mit Berufung auf Grant et al. angeführ- 136 Dies kann zumindest anhand der übergeordneten Planning-Prozesstypen sowie aufgrund der oben angeführten Reichweite des SCOR-Modells interpretiert werden. Vgl. nochmals Supply Chain Council 2009b, S bzw. Abb Vgl. Supply Chain Council 2009b, S : The wide-spread use of the Model results in better customer-supplier relationships [...]. 138 Vgl. Mentzer et al. 2001, S. 8.

53 2 Grundlagen 38 ten Bereiche.139 Die abschließende, zusammenführende Definition des SCM von Mentzer et al. unter Berücksichtigung der Definition des Terms Supply Chain lautet: The systemic, strategic coordination of the traditional business functions and the tactics across these business functions within a particular company and across businesses within the supply chain, for the purposes of improving the long term performance of the individual companies and the supply chain as a whole (Mentzer et al. 2001, S. 18). Durch die unternehmensübergreifende Ausrichtung zusätzlich zur Berücksichtigung des eigenen Unternehmens, was auch das SCOR-Modell charakterisiert, sowie durch die Einbeziehung der originären Geschäftsprozesse einer Unternehmung zur Steigerung der Supply Chain Performance, wird die Definition für diese Ausarbeitung als sinnvoll angesehen Supply Chain Operations Reference-Modell Laut Poluha [...] dient [das SCOR-Modell...] zur Beschreibung der Lieferkette. Es stellt folglich ein Beschreibungsmodell [...] dar. 140 Das Supply Chain Council (SCC), von Advanced Manufacturing Research (ARM), Pittiglio, Rabin, Todd & McGrath (PRTM) sowie 54 weiteren Unternehmen gegründet, stellte das SCOR-Modell im November 1996 erstmalig vor.141 Heute (01/2010) umfasst das SCC 593 Mitgliedsorganisationen, was die Aussage bezüglich der weiteren Verbreitung unterstützt.142 Ziel des Zusammenschlusses war und ist, im Rahmen einer Not-for-Profit-Organisation eine Methodologie sowie Werkzeuge für die Evaluation und das Benchmarking von Supply Chains zu schaffen, die es Unternehmen ermöglichen sollen, [...] dramatische und schnelle Verbesserungen des Supply Chain-Prozesses herbeizuführen.143 Als Vehikel hierfür dient das hierarchisch strukturierte SCOR-Modell, das es ermöglichen soll, die eigene Supply Chain zu evaluieren (d. h. den Ist-Zustand zu erfassen), mit anderen Supply Chains zu vergleichen (Benchmarking durch Leistungsattribute (Performance- Attributes)) und durch Prozessoptimierung sowie die Anwendung von mitgelieferten Best Practices zu deren Leistungsverbesserung beizutragen (d. h. einen Soll-Zustand herzuleiten).144 Nach Stephens ist dies in Projekten, die in Nordamerika, Lateinamerika, Europa und Australien bzw. 139 Vgl. Mentzer et al. 2001, S. 10 f. (mit Berufung auf Grant et al. 1997): [...] customer relationship management, customer service management, demand management, order fulfillment, manufacturing flow management, procurement, and product development and commercialization. 140 Poluha 2005, S Vgl. Supply Chain Council 2009a. 142 Vgl. Supply Chain Council 2010b. Die Mitgliedsorganisationen teilen sich auf in Global Members (60), Members (259), SME Members (59), Academic Members (132) sowie Non Profit Members (83). 143 Supply Chain Council 2009b, S Vgl. bspw. Supply Chain Council 2008, S. 1.

54 The SCOR-model has been developed to describe the business activities associated with all phases of satisfying a customer s demand. The Model itself contains several sections and is organized around the five primary management processes of Plan, Source, Make, Deliver, and Return (shown in Figure 1). By describing supply chains using these process building blocks, the Model can be used to describe supply chains that are very simple or very complex using a common set of definitions. As a result, disparate industries can be linked to describe the depth and breadth of virtually any supply chain. The Model has been able to successfully describe and provide a basis for supply chain improvement for global 2projects Grundlagen as well as site-specific projects. 39 Plan Deliver Return Source Return Plan Make Deliver Return Source Return Make Deliver Return Source Return Plan Make Deliver Return Source Return Suppliers Supplier Supplier Internal or External Your Company Customer Internal or External Customers Customer Figure 1 - SCOR is organized around five major management processes. Quelle: Supply Chain Council 2009b, S It spans: all customer interactions (order entry through paid invoice), all physical material transactions (supplier s supplier to customer s customer, including equipment, supplies, spare parts, bulk Neuseeland product, software, mit dem etc.) SCOR-Modell and all market interactions durchgeführt (from wurden, the understanding auch gelungen.145 of aggregate Ausgangspunkt demand to the ist jeweils fulfillment die of eigene each order). Unternehmung It does not attempt im Kontext to describe der Supply every business Chain, sodass process die or activity. Verbindungen Specifically, zu the Model does not address: sales and marketing (demand generation), product development, research Zulieferern and development, (Supplier) and some und Abnehmern elements of post-delivery (Customer) customer in den Verbesserungsprozess support. mit einbezogen werden können (vgl. Abb. 2.4). Laut SCC umfasst das Modell hierbei sämtliche Interaktionen in It should be noted that the scope of the Model has changed and is anticipated to change based Bezug on Council auf member den Informationsaustausch requirements. With the mit introduction dem Kunden, of Return, den the Austausch Model was physischer extended Güter into the sowie area alle of post-delivery Interaktionen customer mit dem support Markt.146 (although Einschränkend it does not include wirdall jedoch activities angemerkt, in that area). dass nicht jeder Geschäftsprozess bzw. jede Aktivität eines Referenzprozesses im Detail erfasst werden. Explizit complexities ausgegrenzt and werden across multiple vom SCC industries. die Bereiche The Council Vertrieb, has focused Marketing, on three Produktentwicklung, process levels and does F&E As shown in Figure 2, the Model is designed and maintained to support supply chains of various (Fertigung not attempt und to prescribe Entwicklung) how a particular sowie die organization Endkundenbetreuung. should conduct Weiterhin its business werden or tailor die its systems Bereiche / information flow. Every organization that implements supply chain improvements using the SCOR-model HR will need (Human to extend Ressources), the Model, Ausbildung at least to sowie Level Qualitätssicherung 4, using organization-specific nicht näher processes, betrachtet, systems, da diese and entweder practice. implizit im Modell enthalten seien oder durch andere Organisationen, die in diesen in der Lage sein, mit den enthaltenen Elementen [...] die Tiefe und Breite prinzipiell jeder Supply Chain [...] zu beschreiben Copyright 2008 Supply Chain Council Inc. Abb. 2.4: Einflussbereich des SCOR-Modells Bereichen qualifizierter sind, abgedeckt werden können und sollten.147 Dennoch soll das Modell Bei den Elementen handelt es sich zunächst um sechs verschiedene Prozesstypen (Process Types), die sich auf der ersten Ebene des SCOR-Modells befinden (vgl. auch im Folgenden Abb. 2.5): Plan (Planen; P)149, Source (Beschaffen; S), Make (Produzieren; M) und Deliver (Vertreiben; D) sowie 145 Vgl. Stephens Vgl. auch im Folgenden Supply Chain Council 2009b, S Vgl. Supply Chain Council 2009b, S Supply Chain Council 2009b, S : [...] the depth and breadth of virtually any supply chain [...]. 149 Die Prozesstypen werden soweit eindeutig durch die ersten Buchstaben der Substantive abgekürzt.

55 Introduction The Model is silent in the areas of human resources, training, and quality assurance. Currently, it is the position of the Council that these horizontal activities are implicit in the Model and there are other highly qualified organizations that are chiefly concerned with how an organization should train, 2 Grundlagen retain, organize, and conduct their quality programs. Just as the Council recognized the requirements for 40 marketing and sales in commercial organizations, the Council is not minimizing the importance of these activities, but they are currently out of scope for SCOR. Level Schematic Comments Supply-Chain Operations Reference Model # Description 1 Top Level (Process Types) 2 Configuration Level (Process Categories) 3 Process Element Level (Decompose Processes) P1.1 Identify, Prioritize, and Aggregate Supply-Chain Requirements P1.2 Identify, Assess, and Aggregate Supply-Chain Requirements P1.3 Balance Production Resources with Supply- Chain Requirements Plan Source Make Deliver Return P1.4 Establish and Return Communicate Supply-Chain Plans Level 1 defines the scope and content for the Supply-Chain Operations Reference Model. Here the basis of competition performance targets are set. A company s supply-chain can be configured-to-order at Level 2 from core process categories. Companies implement their operations strategy through the configuration they choose for their supply-chain. Level 3 defines a company s ability to compete successfully in its chosen markets, and consists of: Process element definitions Process element information inputs, and outputs Process performance metrics Best practices, where applicable System capabilities required to support best practices Systems/tools Not in Scope 4 Implementation Level (Decompose Process Elements) Companies implement specific supply-chain management practices at this level. Level 4 defines practices to achieve competitive advantage and to adapt to changing business conditions. Figure 2 - SCOR is a hierarchical model with specific boundaries in regard to scope. Abb. 2.5: Ebenen des SCOR-Modells Quelle: Supply Chain Council 2009b, S Copyright 2008 Supply Chain Council Inc. Return Source (Behandlung von Rücklieferungen beschaffter Ware; RS) und Return Deliver (Behandlung zurückgesendeter, gelieferte Ware; RD).150 Jeder der Prozesstypen wird auf der zweiten Modellebene durch Prozesskategorien (Process Categories) in kontextspezifische Anwendungsbereiche unterteilt. Der Produktionsprozess an dem sich sämtliche Prozesse des Modells orientieren151 wird in Lagerproduktion (Make to Stock; M1)152, Auftragsfertigung (Make to Order; M2) oder 150 Für die Übersetzung der Prozesstypen vgl. Bolstorff, Rosenbaum und Poluha 2008, S. 19 und Holten und Melchert 2002, S Vgl. Supply Chain Council 2009b, S : The Model focuses on three environments, Make-to-Stock, Make-to- Order, and Engineer-to-Order. 152 Die Zahl hinter der Prozesstypenabkürzung definiert die Ausprägung.

56 Steps to Create a Geographic Map: 2 Grundlagen Create geographic context (a.k.a. the map) Individualfertigung153 (Engineer to Order; M3) unterteilt und ermöglicht eine anforderungsspezifische Auswahl und Anwendung, um z. B. eine geographische Karte der Supply Chain darzustellen 2. Draw and name your customers on the map a. Identify the level 2 processes (vgl. Abb. 2.6). Die Prozesskategorien können wiederum in drei Arten unterschieden werden: Einerseits b. List jene, the level die dem 2 processes Plan-Prozesstyp in the customer zugeordnet on your sind map(plan-prozesskategorien, beispielsweise 3. P1) Beginning sowie jene, with die your den customers, restlichen repeat Prozesskategorien this for every node (S, on M, the D, map: RS, RD; beispielsweise M1) zugeordnet a. Identify sind all (Execution-Prozesskategorien); supplying nodes (where does material andererseits come wurden from) für jeden Prozesstyp zusätzlicheb. Prozesskategorien Draw and name these eingeführt, supplying dienodes eine grundsätzlich on the map unterstützende Funktion haben, um Daten c. für Identify die jeweiligen the level 2 Prozesstypen processes vor- und aufzubereiten sowie diese zu managen (Enable- Prozesskategorien)154. d. list these in the node Während on your der map Supply Chain-Modellierung müssen implizit für jede verwendetee. Execution-Prozesskategorie Draw the material flows (arrows die korrespondierenden connecting the nodes) Plan- und Enable-Prozesskategorien hinzugefügt 4. Repeat until werden. you have Im Einzelnen included werden all your suppliers/nodes neben dem bereits erwähnten Make die Prozesstypen und beinhalteten Prozesskategorien wie folgt definiert und hierarchisiert:155 Example: HQ P1, P2, D2, S2 Retail, Inc S1, P2 Battery Supplier D1, P1, P4 Drive Supplier D1, P1, P4 MP3 Factory P3, S1, M1, D1 Quelle: Supply Chain Council 2008, S. 18. Abb. 2.6: Anwendung von Prozesskategorien zur Modellierung einer Supply Chain 153 Alternative Begriffe sind konstruktionsorientierte Einzelfertigung (Holten und Melchert 2002, S. 12), Auftragsentwicklung bzw. Spezialanforderung (Poluha 2005, S. 87). 154 Vgl. Supply Chain Council 2008, S. 9; Supply Chain Council 2009b, S ; Holten und Melchert 2002, S. 212 f. 155 Der Make-Prozesstyp wird aufgrund der obigen Erläuterung nicht erneut aufgeführt. 18 SCOR Overview

57 2 Grundlagen 42 Plan: Dem Plan wird eine organisatorische Bedeutung zugerechnet, da dieser Prozesstyp die strategische Planung und Überwachung der gesamten betrachteten Supply Chain umfasst und mit den entsprechenden Plans der Supply Chain-Partner abgeglichen werden soll.156 Aufgespalten wird der Plan in die Prozesskategorien P2: Plan Source, P3: Plan Make, P4: Plan Deliver, P5: Plan Return und P1: Plan Supply Chain, welche die einzelnen Planungsprozesse für die jeweiligen Execution-Bereiche enthalten.157 Source: Dieser Prozesstyp umfasst die Prozesskategorien S1: Source Stocked Product, S2: Source Make-to-Order Product und S3: Source Engineer-to-Order Product. Diese bilden die verschiedenen Arten der Materialbeschaffung ab, abhängig davon, ob die Ware von einem Anbieter bezogen wird, der diese auf Lager bereithält (S1), oder ob sie von ihm noch erzeugt (S2) bzw. entwickelt (S3) werden muss, bevor sie geliefert werden kann. Die Anfrage für eine Bestellung kommt in der Regel aus einem Make- oder einem Deliver-Prozess.158 Deliver: Die Unterteilung in die verschiedenen Prozesskategorien orientiert sich wiederum daran, ob das Produkt bei einer Kundenanfrage auf Lager liegt (D1: Deliver Stocked Product) oder ob es den Make- (D2: Deliver Make-to-Order Product) bzw. Engineer-Prozess (D3: Deliver Engineer-to-Order Product) noch durchlaufen muss.159 Eine weitere, in der Version 7 des SCOR-Modells eingeführte Prozesskategorie behandelt die Auslieferung an den Handel (D4: Deliver Retail Product). Return: Um die Abwicklung der Rücknahme oder Rücklieferung von entweder defekten (S/DR1: Return Defective Product), zu reparierenden (S/DR2: Return MRO Product) oder überzähligen (S/DR3: Return Excess Product) Produkten zu unterstützen, wurde in Version 5 des SCOR- Modells der Return-Prozesstyp eingeführt.160 Dieser existiert sowohl auf Zulieferer- als auch auf Abnehmerseite. Auf der dritten Ebene werden die Prozesskategorien weiter in Elementarprozesse (Activities) verfeinert, die durch Informationsflüsse zu Prozessmodellen verknüpft sind. Jedes Element ist über einen eindeutigen Bezeichner identifizierbar Vgl. Supply Chain Council 2009b, S ; Holten und Melchert 2002, S. 217 f. 157 Vgl. Bolstorff und Rosenbaum 2003, S. 93 f. 158 Vgl. Bolstorff und Rosenbaum 2003, S. 89 f. 159 Vgl. Bolstorff und Rosenbaum 2003, S. 91 f. 160 Vgl. Supply Chain Council 2009b, S ; Bolstorff und Rosenbaum 2003, S. 91 ff. 161 M2.3 steht so bspw. für die Aktivität Produce and Test in der Make-to-Order-Prozesskategorie. Ihr vorgelagert ist die Aktivität M2.2 (Issue Sourced / In-Process Product), ihr nachgelagert die Aktivität M2.4 (Package). Vgl. Supply Chain Council 2009b, S

58 2 Grundlagen 43 Page 6 of 6 Supply-Chain Council Comprehensive Benchmarks Report Grundsätzlich sind jedem SCOR-Prozesselement fünf Leistungsattribute (Performance Attributes) zugeordnet, die über Metriken (Metrics) ein Benchmarking ermöglichen.162 Die Leistungsattribute unterscheiden sich dahingehend, ob sie für Kunden wahrnehmbar sind (Customer-Facing163) oder Parity, nur intern Advantage, bewertet werden Superior können (Internal-Facing164).165 Zum Vergleich der Kennzahlen bieten kommerzielle Anbieter entsprechende Datensammlungen an oder werten die Unternehmensdaten als Dienstleistung aus (vgl. Abb. 2.7).166 Attribute Metric Company Parity Advantage Superior Sample Size Parity Gap Req Gap Reliability Perfect Order Fulfillment 98.0% 92.0% 96.0% 98.0% Responsiveness Order Fulfillment Cycle Time 14 days 10 days 6 days 2 days 17 8 days Flexibility Ups. Supply Chain Flexibility 62 days 80 days 62 days 40 days Cost Supply Chain Mgmt Cost 10.1% 10.8% 10.4% 10.2% Assets Cash-to-Cash Cycle Time 22 days 45 days 30 days 20 days Abb. 2.7: Beispiel eines SCOR-Benchmarks Quelle: Supply Chain Council 2007, S. 5. Das vollständige Vorgehensmodell zur Anwendung des SCOR-Modells wird vom SCC nicht im Referenzmodell mitgeliefert vielmehr wird lediglich ein grober Überblick über einen möglichen Ablauf eines SCOR-Projekts in der Informationsbroschüre gegeben.167 Die Hinweise beschränken Copyright APQC All rights reserved. CONFIDENTIAL benchmarking provided by: sich dabei auf mögliche Anwendungsszenarien168 sowie mögliche Modelltypen, die unter Verwendung der Prozesskategorien erstellt werden können. Hierbei handelt es sich jeweils um abstrakte Darstellungen der Supply Chain aus unterschiedlichen Perspektiven und in unterschiedlichen Granularitäten. Das Business Scope Diagram (BSD) stellt logische und geografische Entitäten der betrachteten Supply Chain und deren Material- und Informationsflüsse dar gebündelt nach Zulieferer, eigenem Unternehmen sowie Abnehmer. Hierbei handelt es sich noch nicht um eine SCOR- 162 Die einzige Ausnahme betrifft die Ebene 1, auf der die Performance-Attribute keinem konkreten Elementtyp zugewiesen sind. Vgl. Supply Chain Council 2009b, S Hierzu zählen die Leistungsattribute Supply Chain-Reliability (-Zuverlässigkeit), -Responsiveness (Reaktionsfähigkeit) und -Agility (Agilität, ehemals Flexibility, Flexibilität. Die Umbenennung wurde vorgenommen, um Verwirrungen mit Metriken, die das Wort Flexibility enthalten, zu vermeiden. Vgl. Supply Chain Council 2009b, S ). 164 Hierzu zählen die Leistungsattribute Supply-Chain-Costs (-Kosten) und -Assets (-Vermögen). 165 Vgl. Supply Chain Council 2009b, S Vgl. Supply Chain Council 2007; Supply Chain Council 2010a. 167 Vgl. im Folgenden Supply Chain Council 2008, S. 15 ff. 168 Aufgeführt werden hier, erweiternd zu den oben angeführten Anwendungsszenarien (Business Process Reengineering, Benchmarking, Best Practices Analysis), bspw. Strategieentwicklung, Mergers & Acquisition, Zerschlagungen von Unternehmen, Standardisierung, Hinweise für Start-Up-Unternehmen sowie das Prozess-Outsourcing. Vgl. Supply Chain Council 2008, S. 16.

59 2 Grundlagen 44 spezifische Modellierung. Für die Geographic Map werden die im BSD definierten Partizipanten der Supply Chain auf einer Landkarte verteilt und durch die ihnen entsprechenden Execution- Prozesskategorien verfeinert (vgl. nochmals Abb. 2.6). Für das SCOR Thread Diagram werden die einzelnen Prozesskategorien, die auch für die Karte verwendet wurden, um Plan-Prozesskategorien erweitert und von ihrer geografischen Lage in eine ablauforientierte Darstellung überführt. SCOR Process Models (Workflows) dienen dann zur Darstellung der Verbindung einzelner Aktivitäten auf der dritten Ebene des SCOR-Modells unter Einbeziehung der Organisationseinheit, welche die entsprechende Aktivität ausprägt. Für eine ausführliche Beratung zum Einsatz des SCOR-Modell wird auf entsprechende Seminare des SCC oder von Partnerunternehmen hingewiesen. In ihrem Buch Spitzenleistungen im Supply Chain Management. Ein Praxishandbuch zur Optimierung mit SCOR erläutern Bolstorff, Rosenbaum und Poluha sehr detailliert die Anwendung von SCOR an einem Beispielunternehmen.169 Aufgrund der bisherigen Einführung und Strukturierung des SCOR-Modells kann es mit Bezug auf Abschnitt 2.2 aufgrund der folgenden Aspekte als Referenzmodell im Sinne dieser Arbeit bezeichnet werden: Modell: Das SCOR-Modell stellt eine abstrakte Repräsentation eines realweltlichen Sachverhalts dar. Gegenstand der Objektwelt sind Prozesse, Kennzahlen, Performance-Attribute und Metriken, die im Bereich des Supply Chain Managements zur Beschreibung von Supply Chains genutzt werden können. In dieser Hinsicht ist das SCOR-Modell ein legitimes Modell im Sinne dieser Arbeit. Informationsmodell: Das SCOR-Modell ist ein Modell, welches das Ergebnis einer Konstruktion einer Gruppe von Konstrukteuren dem SCC darstellt und Informationen über die Elemente des Systems Supply Chain Management mit Hilfe einer (vom SCC nicht formal spezifizierten) Sprache und einer Domänensprache beschreibt. Im Sinne von Schütte bzw. Scheer können die im SCOR-Modell enthaltenen Teilmodelle und Modellelemente als fachkonzeptionelle Beschreibungen von Teilen der Supply Chain gesehen werden.170 In Bezug auf die Anwendungszwecke ist das SCC explizit: Business Process Reengineering Benchmarking Best Practices Analysis Process Reference Model.171 Somit ist das SCOR- Modell auch als Informationmodell im Sinne dieser Arbeit anzusehen. 169 Vgl. Bolstorff, Rosenbaum und Poluha Vgl. Schütte 1998; Scheer Vgl. Figure 3 in Supply Chain Council 2009b, S

60 2 Grundlagen 45 Referenzmodell: Obwohl das SCOR-Modell den Begriff Reference bereits im Namen trägt, ist eine Einordnung in die in Begriffswelt dieser Arbeit notwendig. Der Definition aus Abschnitt 2.2 folgend ist es für ein Referenzmodell hinreichend, wenn es mit der Intention, wiederverwendet zu werden (1) konstruiert wurde und (4) adaptierbar ist. Diese hinreichenden Bedingungen werden durch das SCOR-Modell erfüllt, da es mit der expliziten Aussage entwickelt wurde, jedwede Supply-Chain abzubilden (1)172, weil es Prozessbausteine zur Verfügung stellt, aus denen zur Beschreibung der Supply Chain ausgewählt werden kann (4) sowie unterhalb der dritten Ebene frei adaptierbar ist (4). Zusätzlich besitzt es einen Branchenbezug, was bspw. dem Verständnis von Delp oder Marent entgegen kommt. Vollständigkeit wird dem Modell nicht unterstellt, was für die Charakterisierung als Referenzmodell aber auch nicht notwendig ist.173 Weiterhin ermöglicht gerade der subjektive Mangel an Elementen eine mögliche Erweiterung. Das SCOR-Modell ist also auch als Referenzmodell im Sinne dieser Arbeit anzusehen Supply Chain Operations Reference-Metamodell Ein sprachorientiertes Metamodell M2 ist ein Modell, mit dem die Syntax einer Modellierungssprache S1 beschrieben wird, die dazu verwendet wurde, ein Modell M1 zu beschreiben.174 Weiterhin kann durch dieses Metamodell jeder durch S1 beschreibbare Realweltgegenstand abgebildet werden. Um das SCOR-Modell formal zu beschreiben, wird ein Metamodell benötigt, das in der Lage ist, sämtliche Elemente und Beziehungen, die im SCOR-Modell hinterlegt sind, abzubilden. Eine formale Beschreibung des Modells ist die Grundvoraussetzung, um die in Abschnitt 2.3 beschriebenen Konfigurationsmechanismen darauf anzuwenden. Zur Beschreibung des SCOR-Metamodells wurde die Modellierungssprache ERM (Entity Relationship Model)175 in ihrer erweiterten Form176 verwendet (vgl. Abb. 2.8). Dieses Metamodell stellt den Ist-Zustand des SCOR-Modells in Version 9.0 dar. Obwohl bereits (nicht vom SCC zur Verfügung gestellte) Metamodelle des SCOR-Modells existieren,177 wurde einer Neukonstruktion der Vorzug gegeben, da Vegettia et al. sowie Stefanovic, Majstorovic und Stefanovic die Anforderungen der Konfiguration nicht berücksichtigen. Die Elemente des SCOR-Modells können anhand des Metamodells folgendermaßen spezifiziert werden: 172 Vgl. wieder Supply Chain Council 2009b, S Vgl. nochmals Abschnitt Vgl. Strahringer 1996, S. 24 ff.; Holten 1999, S. 13 ff.; Delfmann 2006, S. 49 ff. 175 Vgl. Chen Vgl. Scheer Vgl. Vegettia et al. 2005; Stefanovic, Majstorovic und Stefanovic 2006.

61 2 Grundlagen 46 Prozesselement D,T Prozesstyp (1:n) (1:n) PK-Bedingung PE-PA-Assoziation (1:n) Performance- Attribut (0:n) (0:n) (1:1) (0:n) Prozesskategorie D,T Plan-PK (1:n) (0:n) Berechnungsvorschrift PE-PA-Metrik- Assoziation (1:n) (0:n) Metrik (0:n) (1:1) EP-Order (0:n) (0:n) (1:1) Execute-PK Enable-PK (1:1) (1:1) (1:n) Legende (0:n) (0:n) (0:n) Elementarprozess (0:n) Entitytyp Uminterpretierter Relationshiptyp Output Input Relationshiptyp Attribut (0:n) (0:n) Austauschobjekt (0:n) (min:max)-kardinalität D,T Spezialisierung/ Generalisierung Disjunkt, Total Best Practice (0:n) Abb. 2.8: Metamodell des SCOR-Modells Prozesselement: Auf Metamodell-Ebene ist zunächst jedes Element, das Prozesse darstellt oder kapselt, ein Prozesselement. Dieses kann spezialisiert werden auf die Elemente Prozesstyp (Ebene 1), Prozesskategorie (Ebene 2) und Elementarprozess (Ebene 3). Die Generalisierung der Prozesstypen ist darin begründet, dass jedes der drei in einer Beziehung zu Performance- Attributen steht. Hierbei ist jedem Prozesselement, unabhängig von der Ebene, mindestens ein Performance-Attribut zugeordnet,178 es können aber auch mehrere sein. Im derzeitigen Stand können maximal fünf Performance-Attribute zugeordnet werden (also alle),179 eine Ausweitung ist aber vor allem vor dem Hintergrund dieser Arbeit denkbar. Performance-Attribut: In der Version 9 des SCOR-Modells existieren fünf Performance-Attribute, die mindestens einem, aber auch beliebig vielen Prozesselementen zugeordnet sein 178 Vgl. bspw. P4.3, Balance Delivery Resources and Capabilities with Delivery Requirements (Supply Chain Council 2009b, S ). Zugeordnet bedeutet, dass es in dem Dokument des SCOR-Modells nicht den Wert None Identified enthält. 179 Vgl. bspw. M1.7, Waste Disposal (Supply Chain Council 2009b, S ).

62 2 Grundlagen 47 können. Die Zuordnung eines Prozesselementes zu einem Performance-Attribut180 (PE-PA- Assoziation) kann mit einer Metrik bewertet werden. Metrik: Eine Metrik kann auf eine, aber auch auf mehrere PE-PA-Zuordnungen angewendet werden.181 Eine Metrik kann, muss aber nicht in die Berechnung von anderen Metriken eingehen (Berechnungsvorschrift).182 Prozesstyp: Einem Prozesstyp (bspw. P1) sind immer mindestens eine, in der Regel aber mehrere Prozesskategorien untergeordnet. Sie bieten damit eine organisatorische Kapselung der hierarchisch untergeordneten Prozesskategorien. Prozesskategorien: Diese Elementtypen sind immer exakt einem Prozesstypen zugeordnet, was dem hierarchischen Charakter des SCOR-Modells entspricht. Prozesskategorien könnten nochmals in Plan-, Execution- und Enable-Prozesskategorien unterteilt werden, was in diesem Modell nicht berücksichtigt wurde. Aus dieser Argumentation heraus erschließt sich aber die PK-Bedingung, die besagt, dass jede Execution-Prozesskategorie in der Regel eine Plan- und eine Enable-Prozesskategorie benötigt. Prozesskategorien können, müssen aber keine Best Practices zugeordnet bekommen. Die Beziehung Prozesskategorie-EP-Order wird unter Elementarprozess erläutert. Elementarprozess: Auf der dritten Ebene bilden diese Modellelemente die feingranularste Modellebene. Zwischen Elementarprozessen können, müssen aber keine Austauschobjekte gewechselt werden. Sie müssen keine, können aber mehrere Best Practices zugeordnet bekommen. Die Reihenfolge der Elementarprozesse im Prozessmodell wird über die EP- Order festgelegt. In ihr wird eine Vorgänger- / Nachfolger-Beziehung abgebildet. Eine konkrete EP-Order repräsentiert dann das Prozessmodell einer Prozesskategorie auf der dritten Ebene. Dieses Metamodell erlaubt das konsistente Verändern des SCOR-Modells,183 indem nachvollzogen werden kann, welche Interdependenzen zwischen Elementen herrschen, wenn eines hinzugefügt oder entfernt werden soll. Hierdurch ist es auch möglich, die Elemente des SCOR-Modells als 180 Die Zuordnung eines Performance-Attributs zu einem Prozesselement ist bspw. die Supply Chain Responsiveness des Plan Supply Chain P1-Prozesstypen. Vgl. Supply Chain Council 2009b, S Eine Metrik, die im SCOR-Modell nicht verwendet wird, wird nicht in das Modell aufgenommen, was die (1:n)- Kardinalität erklärt. 182 Vgl. bspw. die Ebene-2-Metrik RL.2.4 Perfect Condition, die in die Berechnung der Ebene-1-Metrik RL.1.1 Perfect Order Fulfillment eingeht. Vgl. Supply Chain Council 2009b, S Vgl. Abschnitt 3.2.1, bzw. Kapitel 5 und 10.

63 2 Grundlagen 48 Elementtypen einer Modellierungssprache zur Modellierung von Supply Chains zu nutzen, wenn das Metamodell in einer Software umgesetzt wird.

64 3 Erweiterung des Supply Chain Operations Reference-Modells 3.1 Erhebung von Anforderungen Explorative Umfrage Aus der Annahme heraus, dass es für das SCOR-Modell sinnvoll sein könnte, von Anwendern motivierte Erweiterungen zu berücksichtigen, wurde 2007 eine explorative Umfrage über den Bedarf und die Implikationen von Erweiterungen durchgeführt.184 Die Auswahl der Teilnehmer erfolgte zunächst aufgrund ihrer Kenntnis des SCOR-Modells. Sie wurden entweder durch persönliche Bekanntschaft, ihrer Mitgliedschaft im SCC oder anhand entsprechender Hinweise im Geschäftsnetzwerk XING185 kontaktiert. Insgesamt wurden 20 Interviews mit vorwiegend deutschen Teilnehmern geführt, die zum Zeitpunkt des Interviews in den Bereichen Hochschule (6 Teilnehmer), Dienstleistung und Beratung (4 Teilnehmer), Elektrotechnik (5 Teilnehmer) oder Pharma / Chemie / Medizin (5 Teilnehmer) tätig waren. Die Teilnehmer der Interviews wurden in einem ersten qualitativen Teil zunächst offen befragt, welche Probleme sie mit dem SCOR-Modell (damals Version 8) assoziieren und anschließend, welche Anforderungen sie an die zukünftige Entwicklung des SCOR-Modells stellen würden. Weiter wurden die Teilnehmer gefragt, ob sie eine Reduzierung des SCOR-Modells für sinnvoll erachten und wenn ja, welche Teile reduziert werden sollten. Im letzten Teil der qualitativen Befragung wurden die Partizipanten aufgefordert, Wege zu nennen, wie das SCOR-Modell in Zukunft weiterentwickelt werden könne. Ein Ergebnis der offenen Befragung war die Erkenntnis, dass das Modell teilweise bereits so, wie es sich zum damaligen Zeitpunkt darstellte, als zu komplex angesehen wurde und nur schwer verständlich sei. In Bezug auf Anforderungen an die Weiterentwicklung sowie potenzielle Erweiterungen wurde häufig der Wunsch nach industrie- oder unternehmenstypspezifischen Modellvarianten sowie die Forderung nach detaillierteren Prozessmodellen auf der dritten Ebene ECIS Siehe hierzu ausführlich Becker, Knackstedt und Stein 2007 (Kapitel 5) vormals OpenBC. 49

65 3 Erweiterung des Supply Chain Operations Reference-Modells 50 geäußert. Auch die vom SCC explizit ausgeschlossenen Geschäftsbereiche wurden teilweise als integrationswürdig angesehen. Weiterhin wurde der Wunsch geäußert, SCOR ein ausführlicheres Vorgehensmodell beizulegen sowie die Anwendung der Referenz besser durch Anwendungssoftware zu unterstützen. In einer zweiten, ebenfalls qualitativ gestalteten offenen Fragerunde, wurden die Teilnehmer gefragt, ob sie sich vorstellen können, was für Implikationen die Implementierung ihrer Erweiterungsvorschläge für das SCOR-Modell haben könnten, vor allem, ob das SCOR-Modell mit den angeregten Erweiterungen noch nutzbar sei. Mehr als die Hälfte der Teilnehmer war der Überzeugung, dass dies der Fall sei. Sie schränkten allerdings ein, dass die Erweiterungen nur dann sinnvoll seien, wenn eine Konfiguration des Modells möglich ist, welche Erweiterungen ausschließlich für die Anwender im Modell belassen, die dies auch wünschen. Die anschließende Frage, ob die Bereitstellung von spezifischen Modellvarianten wünschenswert sei, wurde vom Großteil bejaht. Die abschließende Frage, ob ein Software-Werkzeug für die Verwendung des SCOR-Modells sinnvoll sei, wurde von allen außer einem Befragten bejaht, wobei bezüglich der Möglichkeit einer Realisierung Skepsis herrschte. In Abb. 3.1 wird das Ergebnis der Umfrage, gegliedert in Dimensionen, Bereich und Subbereiche dargestellt. Metriken Entfernen von Inkonsistenzen Legende: Bezeichnung Prozesskategorien Qualitätssicherung Dimension Bereich Subbereich Objekte der Variantenbildung Varianten Entwicklungsperspektiven Erweiterungen Integration von Dienstleistungspartnern Kontexte für die Variantenbildung Forderung nach Detaillierung Industriespezifische Modellvarianten Tool-Support Detaillierung der 3. Ebene Modellanwendungsspezifische Varianten Detaillierte Dokumentation der Berechnung von Metriken Abb. 3.1: Ergebnisse der explorativen Umfrage

66 3 Erweiterung des Supply Chain Operations Reference-Modells Analyse von Anwenderberichten Um die Forderungen nach Erweiterungen weiter zu belegen, wurde 2009 eine Analyse von Anwenderberichten, die von Nutzern des SCOR-Modells bereitgestellt wurden, durchgeführt.186 Die umfangreichste, dem Autor bekannte Sammlung von SCOR-bezogenen Anwenderberichten sind die SCOR Archives187, in denen sich derzeit (Stand: 01/2010) 182 unterschiedliche Berichte befinden. In einem ersten Schritt wurden zur Klassifizierung die Ersteller der Berichte dem NAICS (North American Industry Classification System) entsprechend codiert. Der Ursprung der Berichte gestaltete sich wie folgt: 71 entstammen dem produzierenden Gewerbe, 41 dem Dienstleistungsgewerbe, 21 der öffentlichen Verwaltung, 16 dem IT-Sektor und 15 dem Ausbildungsbereich. Die restlichen Berichte verteilen sich auf die Bereiche Energie, Land- und Forstwirtschaft, Bergbau, Handel, Logistik und Lagerung sowie weitere Dienstleistungen. 10 Berichte konnten keinem Bereich zugeordnet werden (siehe Abb. 3.2). IJPE Anzahl Fallstudien gesamt nicht identifizierbar Land- und Forstwirtschaft (11) Bergbau (21) Energie (22) Produktion (31-33) Handel (42) Logistik und Lagerung (43) IT-Sektor (51) Dienstleistung (54) Ausbildung (61) Andere Dienstleistungen (81) Öffentliche Verwaltung (92) Abb. 3.2: Klassifizierung der Anwenderberichte nach NAICS Nach der Klassifizierung der Anbieter wurden die Berichte dahingehend untersucht, ob Kritik zu bestehenden Elementen oder Anregungen für Erweiterungen enthalten waren. War dies der Fall, wurde versucht, diese mittels des aus der explorativen Studie entstandenen Frameworks zu klassifizieren (vgl. nochmals Abb. 3.1). Von den 182 analysierten Berichten wurde in 58 Hinweise auf Mängel oder Erweiterungspotenziale des Modells gegeben. Da nicht alle Anregungen in das vorgegebene Schema passten, wurde dieses sukzessive erweitert und aktualisiert. Bereiche der explorativen Umfrage, die in der Berichtsanalyse nicht angesprochen wurden, wurden entfernt. Die abgeleiteten Kritikpunkte lassen sich wie folgt zusammenfassen (siehe Abb. 3.3): 186 Siehe hierzu ausführlich Knackstedt, Stein und Becker 2010 (Kapitel 10). 187 Supply Chain Council 2009c.

67 3 Erweiterung des Supply Chain Operations Reference-Modells 52 Variierte Kennzahlen (3; 3,2%) [RV1] SCOR ist zu allgemein (2; 2,1%) [RV2] Eigenes, von SCOR abgeleitetes Modell (9; 9,5%) [RV3] Entfernen von Inkonsistenzen (2; 2,1%) [RQ1] Qualitätssicherung (3; 3,2%) [RQ] Einsatz formaler Modellierungssprachen (1; 1,1%) [RQ2] Forderung nach Vorgehensmodell (3; 3,2%) [RE1.1] Eigene Erstellung e. Vorgehensmodells (10; 10,5%) [RE1.2] Vorgehensmodell zur SCOR-Anwendung (13; 13,7%) [RE1] Legende: Bezeichnung (Anzahl Nennungen; Prozent. Nennungen) [Kurzform] Dimension Bereich Subbereich Erweiterte Kennzahlen (9; 9,5%) [RE2] Forderungen nach Varianten von SCOR (8; 8,4%) [RV4] Varianten (22; 23,2%) [RV] Kritik am SCOR- Modell (95; 100%) Erweiterungen (46; 48,4%) [RE] Integration von Kollaboration (11; 11,6%) [RE3] Industriespezifische Modellvarianten (6; 6,3%) [RV4.1] Tool-Support (24; 25,3%) [RT] Forderung nach Detaillierung (7; 7,4%) [RE5] Integration weiterer Unternehmensbereiche (6; 6,3%) [RE4] Kulturell angepasste Modellvarianten (1; 1,1%) [RV4.2] Sprachspezifische Modellvarianten (1; 1,1%) [RV4.3] Integration des 4. Levels (2; 2,1%) [RE5.1] Abb. 3.3: Ergebnisse der Berichtsanalyse Tool-Support RT: Die Analyse der Berichte deutet darauf hin, dass die Unterstützung bei der Modellierung mit SCOR durch Software-Werkzeuge eine wichtige Hilfestellung ist. Derzeit wird vom SCC selbst kein Produkt angeboten, es existieren jedoch Lösungen von Drittanbietern. Bekanntere Werkzeuge sind hierbei e-scor von gensym188, ARIS EasySCOR189, BOC ADOlog190, Xelocity Process Wizard191 und das Tibco Business Studio192. Es ist zu vermuten, dass die Werkzeuge den Bereitstellern der Berichte nicht bekannt waren, oder dass sie den spezifischen Anforderungen nicht gerecht wurden. Für eine grundsätzliche Unterstützung der Modellierung sollten sie aber geeignet sein. Qualitätssicherung RQ: Die Dimension Qualitätssicherung kann in die Bereiche Entfernen von Inkonsistenzen und Einsatz formaler Modellierungssprachen unterteilt werden. Noch in der Version 7 des SCOR-Modells waren oftmals Verknüpfungen zwischen den Elementen auf der zweiten und dritten Ebene nicht konsistent, was auf die papierbasierte Modellierung und Bereitstellung des Modells zurückgeführt werden kann.193 Zur Erstellung der 188 Vgl. gensym Vgl. IDS Scheer Vgl. BOC-Group Vgl. Xelocity Vgl. TIBCO Software Inc In der Version 7 des SCOR-Modells kam es bspw. noch vor, dass der Prozesstyp P4 einen Output nach P1 verzeichnet hat, dieser jedoch in P1 nicht registriert wurde. In der Version 9 gibt es ebenfalls Inkonsistenzen, bspw. im Elementarprozess SR1.3, in dem die Supply Chain Costs in zwei verschiedenen Schreibweisen vorkommen.

68 3 Erweiterung des Supply Chain Operations Reference-Modells 53 Ebene-3-Modelle für die Version 9 des SCOR-Modells wurde ARIS verwendet, wodurch die Wahrscheinlichkeit des Auftretens von Inkonsistenzen zumindest reduziert wurde.194 Beide Bereiche können durch den Einsatz von bspw. den oben angeführten Werkzeugen adressiert werden. Varianten RV: In den untersuchten Anwenderberichten konnten vier unterschiedliche, die Bereitstellung spezifischer Varianten betreffende Bereiche identifiziert werden. Variierte Kennzahlen [RV1] sehen vor, dass für einzelne Anwender die Berechnungsformel der KPI nicht dem unternehmenseigenen und evtl. auch nicht dem branchentypischen Vorgehen entspricht. Dieser Bereich ähnelt [RV4], der ähnliche Ansprüche, diese jedoch auf Prozessebene erhebt. Zusätzlich wurde konkretisiert, dass für spezifische Industrien standardisierten Vorgehen wie die vom SCC vorgeschlagenen nicht anwendbar seien [RV4.1]. Explizit für den asiatischen Bereich wurde eine kulturell angepasste Modellvariante gefordert [RV4.2], für Südamerika eine spanischsprachige Variante [RV4.3]. Konkrete Hinweise zu notwendigen Anpassungen, die nicht einem der Bereiche aus [RV4] zuzuordnen waren, wurden in [RV3] gesammelt. Schließlich wurden diverse Modelle vorgestellt, welche die Struktur des SCOR-Modells verwendeten, um ein eigenes, projektspezifisches Referenzmodell zu erstellen [RV3]. Erweiterungen RE: Die vom SCC im Rahmen des SCOR-Modells zur Verfügung gestellten Informationen zu dessen Anwendung werden in den Berichten als nicht ausreichend angesehen [RE1]. Dies leitet sich zum einen aus der expliziten Forderung danach ab [RE1.1], zum anderen aus der Tatsache, dass eigene Vorgehensmodelle präsentiert wurden, die von den kommerziell erhältlichen (wie bspw. die von Bolstorff und Rosenbaum oder Bolstorff, Rosenbaum und Poluha) abweichen. Im Gegensatz zu [RV1] wurde im Rahmen von [RE2] nicht die Änderung existierender Kennzahlen, sondern die Einführung zusätzlicher gefordert. Obwohl der Informationsaustausch zwischen den einzelnen Elementen des SCOR-Modells dokumentiert ist, wird kritisiert, dass auf den Prozess der Kollaboration zwischen den Beteiligten einer Supply Chain nicht ausreichend eingegangen wird [RE3]. Auch die bereits in der explorativen Studie motivierte Integration weiterer Unternehmensbereiche auch solcher, die vom SCC explizit ausgeschlossen wurden findet sich in der Analyse der Berichte Dies ist für die derzeitige Verbreitungsform per Papier (bzw. PDF) irrelevant, in Bezug auf das SCOR-Metamodell entspräche dies aber einem neuen Performance-Attribut-Typen. Vgl. Supply Chain Council 2009b, S Vgl. Supply Chain Council 2009b, S f.

69 3 Erweiterung des Supply Chain Operations Reference-Modells 54 wieder [RE4]. Zusätzlich wurde eine weitere Detaillierung [RE5] der Prozesse, explizit auch auf die vierte Ebene [RE5.1], gefordert Auswertung der Anforderungen Die aus den Interviews und der Dokumentenanalyse abgeleiteten Anforderungen an Erweiterungen des SCOR-Modells widersprechen den Aussagen des SCC, der behauptet, dass das SCOR- Modell nicht verändert werden muss, um jedwede Supply Chain abzubilden.195 Es ist nicht möglich, durch reines Uminterpretieren der SCOR-Modellelemente bspw. die Erstellung einer Dienstleistung abzubilden. Vor dem Hintergrund der wachsenden Relevanz des Dienstleistungssektors und damit einhergehend der hybriden Wertschöpfung196 also des integrierten Angebots eines physischen Produktes in Kombination mit einer Dienstleistung erscheint die Integration von Dienstleistung in das SCOR-Modell relevant. Es sind derzeit jedoch keine Möglichkeiten vorgesehen, Modellelementen einzelne Metriken oder Best Practices197 hinzuzufügen. Zur Sicherung der Ableitungen aus den Analysen wurde nochmals eine Literatursichtung vorgenommen, in der Publikationen identifiziert wurden, in denen ebenfalls Lücken im SCOR-Modell adressiert wurden. Ellram, Tate und Billington sowie Baltacioglu et al. schlagen zu diesem Zwecke vor, ganze Elemente mit den entsprechenden Verknüpfungen zu integrieren,198 Montorio sowie de Waart und Kemper fügen auf der ersten Ebene die zusätzlichen Prozesstypen Adapt, Build und Operate sowie Disposition and Repair ein.199 Neben den oben angeführten und von Praktikern geforderten Anforderungen existieren weitere, nicht mit Dienstleistungen im Zusammenhang stehende Erweiterungen, die in der wissenschaftlichen Literatur formuliert wurden. Stefanovic, Majstorovic und Stefanovic schlagen bspw. die Integration von Initiativen wie ISO 9000 und Lean and Six Sigma vor.200 Vegettia et al. erweitern SCOR im Bereich der Informationslogistik und definieren zusätzliche Daten- und Informationsflüsse.201 Die Integration von Kennzahlen, Best Practices und Metriken, die von Cash und Wilkerson vorgeschlagen wurden und einem ökologischen Leitbild folgen,202 sind in der letzten Entwicklungsiteration in die aktuelle Version 9 als GreenSCOR-Elemente 195 Vgl. nochmals Supply Chain Council 2009b, S Vgl. Stille 2003, S. 196 f.; Engelhardt, Kleinaltenkamp und Reckenfelderbäumer 1993, S. 395 f. 197 Hierbei kann es sich bspw. um solche handeln, die lediglich für Dienstleistungen relevant sind. 198 Vgl. Ellram, Tate und Billington 2004; Baltacioglu et al Vgl. Montorio 2006; de Waart und Kemper Vgl. Stefanovic, Majstorovic und Stefanovic 2006, S Vgl. Vegettia et al Vgl. Cash und Wilkerson 2003.

70 3 Erweiterung des Supply Chain Operations Reference-Modells 55 übernommen worden.203 Huang und Keskar präsentieren zusätzliche Performance-Attribute, Prozesskategorien und Metriken, die eine bessere Bewertung von Zulieferern ermöglichen sollen.204 Die Erweiterung von Best Practices um Hinweise auf unterstützende Software-Lösungen wird von Morciniec und Yearworth vorgeschlagen.205 In Bezug auf die Simulation von Supply Chains schlagen Fayez, Rabelo und Mollaghasemi Ontologien vor, die eine Vergleichbarkeit von Simulationen ermöglichen sollen.206 In Bezug auf die Anforderungen an Erweiterungen lässt sich hieraus die folgende Proposition ableiten: (1) Es werden spezifische, anwendungskontextbezogene Elemente für das SCOR-Modell benötigt. In diesem Fall würde das SCOR-Modell von einem Konfigurationsansatz profitieren, in welchem dem Modellersteller die Möglichkeit gegeben wird, unterschiedliche Varianten zu beschreiben und der Modellnutzer die für ihn relevante Variante ableiten kann, ohne die Komplexität des SCOR-Modells zu erhöhen. Durch dieses Vorgehen wird den Anforderungen [RV1], [RE2] und [RV4] begegnet. Da eine Erweiterung im oben angesprochenen Sinne auch das Hinzufügen von Ebene-1-Prozesstypen umfasst, können auch detaillierte Modelle [RE5] angeboten werden, was eine spezifischere Gestaltung des SCOR-Modells ermöglicht [RV2]. Eine weitere Forderung der Anwender ist die Integration von zusätzlichen Unternehmensbereichen in das SCOR-Modell. Sowohl in der Literatur, als auch in der Praxis werden Fälle beschrieben, in denen das SCOR-Modell nicht durch einzelne Elemente erweitert, sondern als Vorgabe verwendet wurde, um ein ähnlich strukturiertes Modell mit den entsprechenden Anforderungen zu erstellen. Im Rahmen des EU-Projekts Innovation, Coordination and Collaboration in Service Driven Manufacturing Networks (InCoCo-S) entstand so das eigenständige IRM (InCoCo-S Reference Model), in dem Dienstleistungsprozesse und ihre Zusammenhänge beschrieben werden. In Węcel, Zalech und Jakubowski 2003 wird das Knowledge Supply Chain Management Model (KSCM) im Stile von SCOR vorgestellt, das explizit mit der Intention, mit SCOR verbunden zu werden, entwickelt wurde. Selbst das Supply Chain Council folgt diesem Ansatz, indem er mit der Design Chain Operations Reference (DCOR)207 und der Customer Chain Operation Reference (CCOR)208 zwei strukturgleiche Modelle anbietet. 203 Vgl. Supply Chain Council 2009b, S Vgl. Huang und Keskar Vgl. Morciniec und Yearworth Vgl. Fayez, Rabelo und Mollaghasemi Vgl. Supply Chain Council Bei dem DCOR-Modell handelt es sich um sich um eine Reihe von Prozessen, die die Entwicklung von Produktinnovationen zu Produktdefinitionen begleiten. Vgl. Hunsche Vgl. Supply Chain Council Die Customer Chain wird vom SCC definiert als eine Sammlung von Geschäftsaktivitäten, die die Aufgabe haben, Aufträge aus dem Erstkontakt mit dem (dann noch potenziellen) Kunden zu generieren. Vgl. Supply Chain Council 2004, S. 3.

71 3 Erweiterung des Supply Chain Operations Reference-Modells 56 Dies führt zu der zweiten Proposition: (2) In Bezug auf die Erweiterung durch Inhalte, die unter Umständen in anderen Referenzmodellen bereits vorhanden sind, sollte die Verknüpfung des SCOR-Modells mit solchen Referenzmodellen unterstützt werden [RV3]. Durch die Verknüpfung mit entsprechenden Referenzmodellen können zusätzliche Branchenmodelle gekoppelt [RV4.1]209, aber auch funktionale Bereiche angebunden werden [RE4]. Durch eine Koordinationsschicht, die zwischen den jeweiligen Referenzmodellen gebildet wird, kann sowohl dem Wunsch nach Unterstützung der Kooperation [RE3], als auch dem Wunsch nach spezifischeren Modellvarianten [RV2] begegnet werden. Die Analyse der Anwenderberichte ergab ebenfalls, dass eine ausführliche Anleitung zur Implementierung des SCOR-Modells in Projekten vermisst wird, obwohl das SCC Seminare anbietet210 und das Standardwerk von Bolstorff, Rosenbaum und Poluha verfügbar ist.211 Auch wenn diese Angebote nicht Teil des SCOR-Modells selbst sind, motiviert dies noch keinen Handlungsbedarf, da zumindest die Publikation parallel zum Modell bezogen werden kann. Es ist dennoch notwendig, auf die Zurverfügungstellung einer Handlungsanweisung einzugehen, da sich unter der Voraussetzung, dass die oben angeführten Methoden Verwendung finden, das Vorgehensmodell zur Implementierung von SCOR stark verändern wird. Dies führt zur Formulierung der dritten sowie der vierten Proposition: (3) Die Anwendung des Konfigurations- oder des Kopplungsansatzes erfordert die Anpassung des vorhandenen Vorgehensmodells zur SCOR-Implementierung. (4) Obwohl die vorhandenen Modellierungswerkzeuge teilweise in der Lage sind, das SCOR-Modell, so wie es ist, abzubilden und damit die entsprechenden Supply Chain-Modelle zu erzeugen, müssen für den Fall, dass die oben motivierten Ansätze realisiert werden, zusätzliche Funktionalitäten implementiert werden, die derzeit noch nicht erforderlich sind. Im folgenden Abschnitt wird auf die Umsetzung der angeführten Propositionen durch vorhandene oder im Rahmen der Erstellung dieser kumulativen Dissertation entwickelten Methoden eingegangen. 209 So könnten beispielsweise Elemente des Handels-H-Modells, ein Ordnungsrahmen und Referenzmodell für Handelsunternehmen (Becker und Schütte 2007), mit den Elementen der dritten Ebene des SCOR-Modells verknüpft werden. 210 Vgl. Supply Chain Council 2010c. 211 Bolstorff, Rosenbaum und Poluha 2008.

72 3 Erweiterung des Supply Chain Operations Reference-Modells Konzepte zur Erweiterung des SCOR-Modells Konfiguration des SCOR-Modells Adaption des Ansatzes für das SCOR-Modell Für die Konfiguration des SCOR-Modells wird der Ansatz von Becker, Delfmann und Knackstedt genutzt.212 Dieser ermöglicht die kontextspezifische Modellierung von Modellelementen sowie die anschließende kontextspezifische Anpassung des Modells durch den Modellnutzer. Hierzu ist es notwendig, zunächst Regeln zu spezifizieren, die bestimmen, welche Modellelemente für eine bestimmte Modellvariante Gültigkeit besitzen und welche entfernt werden (1). Anschließend werden die SCOR-Modellelemente bestimmt, für die eine Entfernung aus dem Modell in Frage kommt (2). Letztlich müssen Algorithmen ablaufen, die sicherstellen, dass sich das reduzierte Modell in einem konsistenten Zustand befindet.213 Für die Diskussion der Fragen wird das Metamodell des konfigurierbaren SCOR-Modells aus Abb. 3.4 vorausgesetzt, wofür das in Abschnitt 2.4 eingeführte SCOR-Metamodell als Vorlage dient.214 Dieses Metamodell ist um Elemente erweitert, die in den Anwenderberichten als wünschenswert genannt wurden (wie bspw. Spezifizierungen auf der vierten Ebene), sowie um Konfigurationsattribute, die an konfigurierbare Modellelemente annotiert werden können (vgl. Abb. 3.4). Ad (1): Im Sinne des Konfigurationsansatzes nach Becker, Delfmann und Knackstedt 2007 werden Konfigurationsregeln, die entscheiden, welche Elemente im Modell verbleiben, durch Konfigurationsterme215 realisiert. Die Terme bestehen aus Konfigurationsparametern, die verwendet werden können, um den unternehmens- oder geschäftsartspezifischen Gültigkeitsbereich von Modellelementen zu definieren. Ein Element verbleibt nur dann im Modell, wenn es entweder keine Parameter annotiert hat216, oder wenn die Parameter, die für die Konfiguration des Modells gewählt wurden, mit den annotierten übereinstimmen. Aufgrund der Nachfrage nach 212 Vgl. Becker, Delfmann und Knackstedt Die Diskussion, die zur Entscheidung für die Verwendung dieses Ansatzes geführt hat, befindet sich in Knackstedt, Stein und Becker Vgl. Delfmann Da Lücken im Modell, die durch das Entfernen von Elementen entstehen, die Semantik des Modells stören, müssen diese zumindest durch Nachziehen von Kanten geschlossen werden. Wenn das Informationsmodell auf Grundlage eines Metamodells erstellt wurde, ist die syntaktische Entsprechung mit dem Metamodell sicherzustellen. 214 Siehe Abb. 2.8, Seite Diese Konfigurationsterme folgen einer Grammatik, die in Backus-Naur-Form definiert wurde. Vgl. zur Backus- Naur-Form Ryan, Collins und O'Neill Ein Element, das nicht mit einem Konfigurationsterm versehen wurde, ist für jede Modellvariante relevant und verbleibt somit immer im Modell.

73 3 Erweiterung des Supply Chain Operations Reference-Modells 58 Prozesselement (PE) D,T Prozesstyp (1:n) (1:n) Konf.-Term PC-Condition PE-PA-Relation (0:n) (1:n) Performance- Attribut (PA) (0:n) (0:n) Prozesskategorie (PK) (1:1) (0:n) D,T Plan-PK (1:n) PE-PA-Metrik- Relation (1:n) (0:n) Metrik Konf.-Term (0:n) Berechnung Level 4 Prozess- Modell (L4PM) Konf.-Term Konf.-Term (1:n) EP-L4PM- Relation Konf.-Term EP-Reihenfolge (0:n) (0:n) (0:n) (0:n) (1:1) (0:n) Konf.-Term (1:1) Elementarprozess (EP) (0:n) Execute-PK Enable-PK (1:1) (1:1) (1:n) Legende: Output Konf.-Term Input Entitytyp Uminterpretierter Relationshipttyp (0:n) (0:n) Austauschobjekt (0:n) Relationshiptyp Attribut Best Practice (0:n) (min:max)-kardinalität D,T Spezialisierung/ Generalisierung (Disjunkt, Total) Konf.-Term Abb. 3.4: SCOR-Metamodell für die Konfiguration zusätzlichen industriespezifischen Varianten des SCOR-Modells217 bietet es sich beispielsweise an, einen Konfigurationsparameter Industriezweig einzuführen, der die Ausprägungen Pharma, Automotive, Dienstleistung, Chemie etc. umfassen kann. Einzelne Parameter können über logische Operatoren zu komplexeren Strukturen zusammengefasst werden, was z. B. den folgenden Term ermöglicht: ((Industriezweig = Automotive) OR (Industriezweig = Chemie)) AND (Produktart = Investitionsobjekt). Diese Terme sind den booleschen Operationen entsprechend zu wahr oder falsch auswertbar. Ein mit diesem Term versehenes Element bleibt somit im Modell, wenn während der Konfiguration entweder der Industriezweig Automotive oder Chemie gewählt wurde, und gleichzeitig die Ausprägung Investitionsobjekt gewählt wird. Ad (2): Die im letzten Abschnitt vorgestellte Dokumentenanalyse bietet Hinweise darauf, welche Elemente bzw. Teile des SCOR-Modells konfigurierbar sein müssen, um die Anforderungen der 217 Vgl. nochmals Abschnitt

74 3 Erweiterung des Supply Chain Operations Reference-Modells 59 Anwender erfüllen zu können. Tab. 3.1 beinhaltet in der zweiten Spalte für das jeweilige Element die Motivation für die Berücksichtigung bei der Konfiguration. Ad (3): Wird das SCOR-Modell dem Metamodell von Abb. 3.4 entsprechend konfigurativ erstellt bzw. konfigurierbar gemacht, kann durch die Ausführung von Algorithmen der Methode der konfigurativen Referenzmodellierung das Modell kontextspezifisch aufbereitet werden. Diese Algorithmen determinieren, welche Implikationen das Entfernen von Elementen auf andere im Modell enthaltenen Elemente hat. Wie sich die Algorithmen für die jeweiligen Modellelemente verhalten müssen, ist in der dritten Spalte von Tab. 3.1 beschrieben. Grundsätzlich orientiert sich diese Regelung an den Kardinalitäten, die im Metamodell annotiert sind. Bei (0:n) sind in der Regel keine weiteren Maßnahmen nötig. Ist ein Element jedoch abhängig von einem anderen, müssen diese aufgedeckt und berücksichtigt werden. Zusätzlich zu diesen Regeln ist eine abschließende Konsistenzsicherung notwendig. Tab. 3.1: Design-Aspekte der Konfiguration des SCOR-Modells Modellelement Motivation für die Konfiguration Algorithmische Behandlung Elementarprozess (EP) Grundlegendes, konstituierendes Element der dritten Ebene. EP-Order Entspricht dem Modell einer Prozesskategorie. EP können in Abhängigkeit ihres Anwendungskontextes ein- bzw. ausgeblendet werden. Ein Beispiel hierfür ist die Sterilisierung von produzierten Waren, was für viele Produktionstypen nicht berücksichtigt werden muss, im Bereich der Herstellung klinischer Geräte aber unbedingt notwendig ist. Es soll möglich sein, für bestimmte Prozesskategorien unterschiedliche wieder kontextspezifische Ebene-3-Modelle zu hinterlegen. Hierfür müssen die Kanten und unter Umständen auch die Elementarprozesse geändert werden. Ein Elementarprozess wird entfernt, wenn der annotierte Konfigurationsterm zu falsch ausgewertet wird. Alle Inputs und Outputs, Metriken und Best Practices, die mit dem EP in Verbindung stehen, werden ebenfalls entfernt. Die entstehenden Lücken müssen konsistent überbrückt werden. Wird ein Elementarprozess an keiner anderen Stelle des Modells wiederverwendet, kann er komplett aus dem Modell entfernt werden. Fortsetzung auf der nächsten Seite

75 3 Erweiterung des Supply Chain Operations Reference-Modells 60 Modellelement Motivation für die Konfiguration Algorithmische Behandlung EP-Order (fortgesetzt) Prozesskategorie Prozessbaustein auf der zweiten Ebene zur Modellierung der Supply Chain. Prozesstyp Aggregiert untergeordnete Prozesskategorien. EP-Level-4- Prozessmodell- Relation Bietet unternehmensoder projektspezifische Verfeinerungen von Elementarprozessen. Es werden bei der Konfiguration wiederum diejenigen Elemente, Kanten und Fragmente entfernt, bei denen der annotierte Konfigurationsterm zu falsch ausgewertet wird. Die Auswahl der Prozesskategorien ist abhängig vom Geschäftsmodell des zu modellierenden Standortes. Wenn in der gesamten Supply Chain kein Engineer-to- Order (M3) realisiert wird, können die im Zusammenhang stehenden Prozessbausteine ebenfalls aus dem Referenzmodell entfernt werden. Für den Fall, dass zusätzliche, spezifische Bausteine in das Modell eingefügt wurden, können diese bspw. für eine Standardvariante entfernt werden. Das nachträgliche Einführen des Prozesstypen Return in das SCOR-Modell deutet darauf hin, dass grundsätzlich auch auf dieser Ebene die Möglichkeit bestehen soll, dem Referenzmodell Elemente hinzuzufügen. Für spezifische Anforderungen können detaillierte Modelle auf der vierten Ebene hinterlegt werden, die nach Bedarf ein- oder ausgeblendet werden. An den Prozess der Sterilisierung von Produkten können bspw. in verschiedenen Branchen unterschiedliche Anforderungen gestellt werden.218 Das Löschen einer Prozesskategorie führt zum Entfernen aller EP-Orders, assoziierter Modelle niedrigerer Ebenen, Informationsflüsse, Metriken und Best Practices aus dem Referenzmodell, die nicht in anderen Prozesskategorien verwendet werden. Das Löschen eines Prozesstypen führt dazu, dass alle assoziierten Prozesskategorien ebenfalls gelöscht werden. Beim Löschen der Prozesskategorien wird iterativ wie oben beschrieben vorgegangen. Beim Löschen einer EP-Level-4-Prozessmodell-Relation wird das verbundene Modell von der Aktivität auf der dritten Ebene getrennt und steht an dieser Stelle nicht mehr zur Verfügung. Sollte es nicht noch an einer anderen Stelle referenziert sein, wird es vollständig aus dem Referenzmodell entfernt. Fortsetzung auf der nächsten Seite 218 Vgl. z. B. Supply Chain Council 2009b, S In der Aktivität M2.4 wird auf einen optionalen, für bestimmte Industrien aber obligatorischen Sterilisierungsprozess beim Verpacken der Ware hingewiesen: Within certain industries, packaging may include cleaning or sterilization.

76 3 Erweiterung des Supply Chain Operations Reference-Modells 61 Modellelement Motivation für die Konfiguration Algorithmische Behandlung Best Practice Gibt Hinweise über bekannte Verfahren der Durchführung von durch Elemente beschriebenen Prozessen. Metrik Ermöglicht das Bewerten eines Elements. Performance- Attribute Ermöglichen das Benchmarking von Prozessen Best Practices können kontextabhängig sowohl Prozesskategorien als auch Elementarprozessen zugewiesen werden. Diese müssen aber nicht für jede Ausprägung des Elements relevant sein, so dass sie in diesem Fall aus dem Modell entfernt werden können. Ein Beispiel hierfür ist eine Best Practice für Sicherheitsvorgaben, die für die Arzneimittelindustrie Gültigkeit besitzt, jedoch für die Automobilbranche irrelevant ist. Die Art der Metrik ist abhängig vom Anwendungskontext des Modells. Neben reinen Kosten- oder Verbrauchsanalysen können auch ökologische Aspekte als Metrik abgebildet werden. Solche Metriken müssen den Anforderungen entsprechend eingeführt werden. Neben den fünf vorhandenen Performance-Attributen können ähnlich den Metriken weitere, kontextspezifische eingeführt werden. Das Löschen einer Best Practice führt zur Entfernung von allen Beziehungen zu Elementen, denen sie zugewiesen wurde. Das Löschen einer Metrik führt dazu, dass alle Metriken, in deren Berechnung die Metrik eingeht, ebenfalls gelöscht werden. Als Ausnahme sollte vorgesehen werden, dass Metriken, in welche die betrachtete Metrik lediglich additiv eingeht, nicht gelöscht werden. Das Löschen eines Performance-Attributes führt zum Löschen aller annotierten Metriken. Dies kann dazu führen, dass weitere Metriken im Sinne des oben beschriebenen Algorithmus gelöscht werden müssen. Tab. 3.1: Design-Aspekte der Konfiguration des SCOR-Modells Anwendung der Konfiguration Im folgenden Beispiel wird die EP-Order also das Prozessmodell einer Prozesskategorie der Prozesskategorie M1 (Make-to-Stock) konfiguriert und somit kontextabhängig angepasst (vgl. Abb. 3.5). Der Prozess wurde um den Elementarprozess Sterilization (M1.4a) erweitert, was im Originalmodell bisher lediglich implizit in M1.4 vermerkt ist und nicht expliziert wurde, da es sich um ein (nicht näher spezifiziertes) Branchenspezifikum handelt. In diesem Beispiel wird unterstellt, dass die Sterilisierung von Produkten für die Pharmaindustrie wichtig ist, weshalb es mit dem Term Industry branch (Pharmaceutical) versehen wurde.

77 3 Erweiterung des Supply Chain Operations Reference-Modells 62 Konfigurierbares SCOR-Modell (Auszug) Best Practices Information Feedback M1.2, M1.3, M1.4a, M1.4, M1.5, M1.6, M2.2, M2.3, M2.4, M2.5, M2.6, M3.3, M3.4, M3.5, M3.5, M3.6, M3.7 Reduce Non-Value Added Paperwork While Still Measuring Process Metrics Paperless Production Control Performance- Attribute Reliability Costs Sustainability Performance- Attribute Reliability... Asset Management Sustainability Metrik Warranty Costs... Beschreibung / Definition % packaging material that is recyclable/reusable, Model extension (Green) Scrap packaging expense, % packaging material that is biodegradable, Model extension (Green) Cost to Package Electronic data collection of completion Electronic dispatch of operations Standard of Personnel Education Model extension (Green) Make to Stock (M1) Schedule Production Activities (M1.1) Issue Material (M1.2) Produce and Test (M1.3) A Sterilization (M1.4a) Package (M1.4) Stage Product (M1.5) Release Product to Deliver (M1.6) A Waste Disposal (M1.7) Process Categories Make to Stock (M1) Make to Order (M2) Engineer to Order (M3) Information Feedback M1.1, M2.1, M3.2 Information Feedback M1.1, M2.1, M3.2 Industry branch (Pharmaceutical) NOT Individuality (Standard) Information Feedback M1.1, M2.1, M3.2 Information Feedback M1.1, M2.1, M3.2 Information Feedback M1.1, M2.1, M3.2 Information Feedback M1.1, M2.1, M3.2 Finished Product Release D1.8, D2.9, D4.2 Legende: Elementarprozess (EP) A EP-Order Austauschobjekt (Input/Output) Konfigurationsterm Abb. 3.5: Konfigurierbarer Ebene-3-Prozess Da das Element mit einem Konfigurationsparameter versehen wurde, verbleibt es lediglich dann im Modell, wenn der Modellanwender sich für diesen entscheidet. In jedem anderen Fall (keine Auswahl von Konfigurationsparametern, Auswahl anderer Konfigurationsparameter) wird das Element entfernt. Sollte es bspw. auch für die Chemiebranche im Modell verbleiben, müsste es um dieses Spezifikum erweitert werden: (Industry branch = Pharmaceutical) OR (Industry branch = Chemical). Dem folgenden Elementarprozess M1.4a wurden den Vorgaben entsprechend ebenfalls

78 3 Erweiterung des Supply Chain Operations Reference-Modells 63 Best Practices, Metriken und Informationsflüsse hinzugefügt, die bei einer Konfiguration ebenfalls entfernt werden müssen. Einige der Metriken des Originalelement M1.4 sind lediglich für die Betrachtung einer Grünen Supply Chain relevant, weshalb sie mit der Konfigurationsparameterausprägung Green des Performance-Attributes Model extension versehen wurden.219 Dieser Parameter erlaubt modulare Erweiterungen des SCOR-Modells, die nicht zwingend domänenspezifisch sein müssen.220 Wiederum ist es so, dass die Metrik nur dann im Modell enthalten bleibt, wenn der Nutzer sich für den entsprechenden Parameter entscheidet. Zusätzlich zu den Metriken können Performance-Attribute ergänzt werden, die spezielle Bewertungs- / bzw. Benchmarkingperspektiven ermöglichen. In Verbindung mit den oben eingeführten grünen Kennzahlen ist es sinnvoll, ein entsprechendes Performance-Attribut Sustainability zu definieren, das für die grüne Perspektive steht und entsprechend attribuiert wird. Sustainability sollen Kennzahlen zugeordnet werden, die sich mit der Nachhaltigkeit der Supply Chain befassen. Eine mögliche Metrik in diesem Bereich ist Ausbildungsniveau der Mitarbeiter, mit dem die Nachhaltigkeit des Sozialen bewertet werden kann. Unternehmen, die keine Individualproduktion (Make-to-Order) durchführen, sondern lediglich auf Lager produzieren, werden vermutlich keine Verwendung für Individualentwicklungen (Engineer-to-Order) haben. Aus diesem Grund wurde M1 mit dem Konfigurationsparameter NOT Individuality (Standard) versehen, sodass es bei Auswahl einer anderen Individualität als Standard entfernt wird. Entsprechend dem Algorithmus aus Tab. 3.1 für Prozesskategorien müssen bei einer entsprechenden Konfiguration wiederum sämtliche verbundenen Elemente entfernt werden.221 Auf diese Art kann das gesamte Modell erweitert und mit kontextspezifischen Elementen versehen werden. Die Auswirkung einer Konfiguration ist in Abb. 3.6 dargestellt. Es wird für das 219 Das Supply Chain Council versteht unter GreenSCOR environmental programs. Supply Chain Council 2009b, S Nach Beamon bedeutet der Weg zu einer grünen Supply Chain : [...] a move towards sustainability, achieved through vast reductions in resource use and waste generation, and a move away from one-time use and product disposal. Beamon 1999, S Srivastava fasst die Diskussion um Green Supply Chain Management (GrSCM) in einem entsprechenden Literatur-Review folgendermaßen zusammen: Adding the "green"component to supply-chain management involves addressing the influence and relationships between supply-chain management and the natural environment. Srivastava 2007, S. 54. Hier wird GrSCM als Unterkategorie von Nachhaltigkeit verstanden, was die drei Bereiche Umwelt, Wirtschaft und Soziales umfasst. 220 Technisch unterscheidet sich dieser Parameter nicht von anderen. Semantisch ist es jedoch sinnvoll, durch eine geeignete Sprachwahl Klarheit zu schaffen, wofür ein bereits vorhandener Konfigurationsparameter genutzt wird. Vgl. für die sprachliche Synchronisierung bei der Modellierung Abschnitt In dem vorgestellten Beispiel ist eine Konfigurationsparameterausprägung Engineer to Order denkbar. Grundsätzlich sollte jede Prozesskategorie auf diesem Abstraktionsniveau aus technischen und algorithmischen Überlegungen heraus einen eigenen Konfigurationsparameter annotiert bekommen. Hierdurch wird dem vom SCC angeführten Konzept der Konfigurierbarkeit des SCOR-Modells Rechnung getragen. Supply Chain Council 2009b, S : A company s supply-chain can be " configured-to-order" at Level 2 from core process categories. Companies implement their operations strategy through the configuration they choose for their supply-chain.

79 3 Erweiterung des Supply Chain Operations Reference-Modells 64 Konfiguriertes SCOR-Modell für: Industry branch = White goods, Model extension = None, Individuality = Standard (Auszug) Information Feedback M1.2, M1.3, M1.4, M1.5, M1.6, M2.2, M2.3, M2.4, M2.5, M2.6 Make to Stock (M1) Schedule Production Activities (M1.1) Process Categories Make to Stock (M1) Make to Order (M2) Issue Material (M1.2) Information Feedback M1.1, M2.1 Performance Attribute Reliability Costs Metrik Warranty Costs... Scrap packaging expense, Cost to Package Produce and Test (M1.3) A Information Feedback M1.1, M2.1 Package (M1.4) Information Feedback M1.1, M2.1 Stage Product (M1.5) Information Feedback M1.1, M2.1 Performance- Attribute Reliability... Asset Management Release Product to Deliver (M1.6) A Waste Disposal (M1.7) Information Feedback M1.1, M2.1 Finished Product Release D1.8, D2.9, D4.2 Legende: Elementarprozess (EP) A EP-Order Austauschobjekt (Input/Output) Konfigurationsterm Abb. 3.6: Konfigurierter Ebene-3-Prozess folgende Beispiel angenommen, dass durch den Modellnutzer die folgenden Konfigurationsparameterausprägungen gewählt wurden: Industry branch = White goods, Model extension = None und Individuality = Standard. Da die Pharmaindustrie nicht als Ausprägung gewählt wurde, werden das Element M1.4a sowie alle verbundenen entfernt. Da weiter keine Individualproduktion bzw. -entwicklung gewählt wurde, werden auch die Prozesskategorie M3 sowie alle angehängten Elemente entfernt. Hierzu zählen auch die Informationsflüsse, die zwischen den Elementen bestanden. In diesem Fall muss ein Algorithmus gewährleisten, dass alternative Verbindungen erzeugt werden. Da keine Modellerweiterung gewählt wurde, werden die Informationen über

80 3 Erweiterung des Supply Chain Operations Reference-Modells 65 GreenSCOR (Performance-Attribute Sustainability, die annotierten Metriken sowie die zwei Metriken aus dem Bereich Cost ) aus dem Modell entfernt. Als Ergebnis steht eine SCOR-Modell-Variante, die keine Informationen mehr enthält, die für einen spezifischen Anwendungskontext relevant sind. Weiterhin ist erkennbar, dass auf Prozesskategorieniveau ein konsistentes Prozessmodell erstellt werden konnte, das abgesehen von der fehlenden M3-Prozesskategorie dem Originalmodell entspricht und (zumindest für den Modellnutzer) keine sichtbare zusätzliche Komplexität besitzt. Verwendung von Taxonomien GfKl07 Evaluation Modellerstellung Projektzieldefinition Weitere Anpassung Definition der Modellierungstechnik Entwicklung Es ist notwendig zu wissen, welche Konfigurationsparameter und welche entsprechenden Konfigurationsparameterausprägungen für das SCOR-Modell existieren. Zu diesem Zweck ist es sinnvoll, eine Taxonomie zu erstellen, die sämtliche Konfigurationsparameter und deren Ausprägungen enthält. Dies kann unabhängig vom verwendeten Referenzmodell in verschiedenen Phasen des Lebenszyklus eines konfigurierbaren Referenzmodells zur Anwendung kommen222 und sowohl bei der Modellerstellung bzw. -entwicklung als auch bei der Modellanwendung und -anpassung unterstützen (vgl. Abb. 3.7). Taxonomien, die Supply Chains charakterisieren und so als initiale Orientierung dienen können, existieren bereits rudimentär.223 Problematisch ist jedoch, dass deren Erstellung nicht mit der Maßgabe stattgefunden hat, die Auswirkung der Konfiguration unter Zuhilfenahme der Parameter auf ein Modell darzustellen. Aus diesem Grund ist es fragwürdig, ob alle für eine Konfiguration re- Projektzieldefinition Konfigurierbares Referenzmodell Suche und Auswahl Anwendung Konfiguriertes Modell Konfiguration Abb. 3.7: Ausgewählte Phasen des Lebenszyklus eines konfigurierbaren Referenzmodells 222 Vgl. nochmals Abschnitt Vgl. Wang, Huang und Dismukes 2004.

81 3 Erweiterung des Supply Chain Operations Reference-Modells 66 levanten Ausprägungen berücksichtigt wurden und ob die Granularität der Parameter ausreichend ist. Weiterhin ist es sinnvoll, Konfigurationsparameter wie Modellerweiterung einzuführen,224 die von einer existenten Taxonomie nicht abgedeckt werden können, da sie modellspezifisch sind. Bezogen auf Abb. 3.7 kann diese Taxonomie in vier Phasen des Prozesses zum Einsatz kommen und diese unterstützen. Im ersten Schritt, der Projektzieldefinition, müssen sich die Entwickler des Referenzmodells darauf einigen, welche Informationen sie für ihr Projekt aufnehmen bzw. nicht berücksichtigen möchten. Für ein erstes Begriffsverständnis haben sich Morphologische Kästen bewährt, die eine strukturierte Problemlösungssuche aufgrund von identifizierten zu diesem Zeitpunkt möglicherweise relevanten Aspekten und deren Ausprägungen ermöglichen. Im Diskurs können sich die Beteiligten entscheiden, auf welche Ausprägungen sie sich einigen. Ein Morphologischer Kasten, der bei der Klassifizierung von Handelsunternehmen unterstützen könnte, ist in Abb. 3.8 dargestellt. Welche Modellierungstechnik (Phase 2) eingesetzt werden soll, ist für Taxonomien irrelevant sie sind sprachunabhängig und existieren parallel zu Modellierungsprojekten. Bei der Characteristic Business level Retail Business Trading Level Horizontal cooperation Vertical Cooperation Contact orientation Sales contact form Beneficiary Range extend Pricing policy Purchase initiation through Logistics handling Third-party business Retailer Inland trade Characteristic form Wholesaler Foreign trade Retailers Wholesalers Other cooperation Retail and wholesale Wholesale and industrial companies Retail and industry companies Retail, wholesale and Industrial companies Stationary Itinerant Mail Order Sales person Self-service Catalog Vending Machine Wide and deep range Visit to store Investment goods trade Active Letter/fax By the customer (collect) Pooled payment business Wide and shallow range Promotion business Narrow and deep range Consumer goods trade Passive Service business Narrow and shallow range Telephone (call center) Internet Push (e.g., Clubs) By the retailer/intermediary Through the internet (for (delivery) digital products) Abb. 3.8: Morphologischer Kasten für Konfigurationsparameter der Domäne Handel 224 Siehe oben: Bei der Modellerweiterung green handelt es sich um ein optionales Modul, das nicht notwendigerweise im Referenzmodell integriert sein muss.

82 3 Erweiterung des Supply Chain Operations Reference-Modells 67 Modellerstellung (Phase 3) ist darauf zu achten, dass nur Elemente in das Referenzmodell integriert werden, die für Kontexte bestimmt sind, auf die sich zuvor geeinigt wurde.225 Das SCOR-Modell ist bereits ausführlich spezifiziert, sodass die ersten beiden Phasen außer Acht gelassen werden können, die dritte Phase aber weiter berücksichtigt werden muss. Die Evaluation des Modells (Phase 4) benötigt nicht explizit die Taxonomie, sie kann jedoch herangezogen werden, um zu validieren, dass tatsächlich alle relevanten Perspektiven integriert und alle irrelevanten exkludiert wurden. Für den Fall, dass ein Referenzmodell nicht den ersten Phasen entsprechend auf die Konfiguration vorbereitet wurde wie zum Beispiel das SCOR-Modell, ist es zur Qualitätssicherung sinnvoll, diese vierte Phase einzubeziehen. Als Ergebnis steht zum Abschluss der vierten Phase ein konfigurierbares Referenzmodell, dessen Parameter sich konsistent in dem Modell wiederfinden und in der Anwendungsphase eine entsprechende Konfiguration ermöglichen. Dieses kann vom Referenzmodellanwender unabhängig von der Entwicklung verwendet werden. Bei der Suche und Auswahl eines geeigneten Referenzmodells kann eine veröffentlichte Taxonomie hilfreich sein, um die Eignung des Modells für die ursprüngliche Projektzieldefinition des Anwenders zu überprüfen. Bei der Konfiguration muss der Anwender schließlich aus den gegebenen die benötigten Konfigurationsparameterausprägungen für die Erstellung einer angepassten Modellvariante auswählen. Unter Umständen kann das konfigurierte Modell noch weiter konfiguriert werden, wenn bspw. eine Modellvariante erzeugt wurde, die ODER-Bedingungen einschließt. Verwendung von Ontologien Während durch Taxonomien die Möglichkeit besteht, bspw. Klassen von Referenzmodellen oder eine Strukturierung von Konfigurationsparametern und Ausprägungen zu erstellen, kann mit Hilfe von Ontologien definiert werden, wie Konfigurationsparameter und deren Ausprägungen untereinander in Verbindung stehen (vgl. Abb. 3.9).226 Als grundlegende Beziehungen werden (1) ist-instanz-von (is-instance-of ), (2) excludes (schließt aus) und (3) impliziert (implicates) vorgeschlagen. Jede Parameterausprägung ist grundsätzlich mit dem entsprechenden Parameter über eine Instanz-Beziehung verbunden (1). In Bezug auf das SCOR-Modell kann angenommen werden, dass im Bereich der Lagerproduktion eine Konfiguration des Modells in Abhängigkeit der Nachfrage (Konfigurationsparameter: demand) vorgenommen wird. Die Produktion von Saisonartikeln und die entsprechende Nachfrage (demand = seasonal) für Produktionsstoffe unterscheidet sich von der ECIS08 IJPE 225 Vgl. als Beispiel nochmals Abb. 3.8: Von allen möglichen Ausprägungen werden lediglich jene berücksichtigt, die grau schattiert wurden. 226 Siehe hierzu ausführlich Becker et al (Kapitel 7).

83 3 Erweiterung des Supply Chain Operations Reference-Modells 68 Sales contact form Contact orientation Vending machine Catalog Self-service Sales person Mail order Itinerant Stationary Excludes Implicates Implicates Implicates Investment goods trade Consumer goods trade Visit to store Letter/fax/ Internet Telephone (call center) Push (e.g., clubs) Beneficiary Purchase initiation through Concepts... Characteristic Relations Is-instance-of Retail and wholesale Vertical cooperation Excludes Retail and industrial companies... Parameter Implicates Excludes Excludes Excludes Excludes Wholesale and industrial companies Excludes Excludes Retail, wholesale and industrial companies Abb. 3.9: Beispielontologie in Anlehnung an den Morphologischen Kasten aus Abb. 3.8 ganzjährigen Produktion (demand = regular) von Massenartikeln (2).227 Wenn das Referenzmodell nicht derart konfiguriert werden soll, dass beide Möglichkeiten enthalten bleiben, ist die Annahme eines gegenseitigen Ausschlusses der Parameterausprägungen vertretbar. In diesem Fall handelt es sich um Konfigurationsparameterausprägungen des selben Konfigurationsparameters (demand). Weiterhin können Beziehungen auch zwischen Parameterausprägungen über Konfigurationsparameter hinweg existieren: Wird für den Konfigurationsparameter Type of Business die Ausprägung Engineer to Order gewählt, wird vermutlich die Ausprägung Sales Agent für den Parameter Distribution Channel geeignet sein, da Auftragsentwicklungen aufgrund der Komplexität des Produktes eher über das direkte Gespräch als bspw. über das Internet initiiert werden (3).228 Die Regeln der Ontologie müssen durch eine Geschäftslogik evaluiert werden, die somit eine konsistente 227 Vgl. bspw. Vörös 1999, S. 195; Rajaram und Tang 2001, S. 582 f. 228 Vgl. Schuh 1999, S. 177.

84 3 Erweiterung des Supply Chain Operations Reference-Modells 69 Konfiguration unter Berücksichtigung der Abhängigkeit von Konfigurationsparametern und deren Ausprägungen ermöglicht.229 Die Auswertung der Regeln gestaltet sich in den unterschiedlichen Phasen des Lebenszyklus verschieden. Während der Projektzieldefinition ist es zunächst wichtig, alle abhängigen Parameter zu identifizieren und zu berücksichtigen. Im Rahmen der Referenzmodellerstellung ist die Berücksichtigung aller Regeln erforderlich, um die Konsistenz des integrierten Gesamtmodells sicher zu stellen. Während der Konfigurationsphase müssen wiederum sämtliche wechselseitigen Abhängigkeiten berücksichtigt werden, wobei Ausschlüsse lediglich dann zu berücksichtigen sind, wenn nicht eine Modellvariante zur weiteren Konfiguration erzeugt werden soll. Zusammenfassung der Möglichkeiten der Konfiguration Der Konfigurationsansatz nach Becker, Delfmann und Knackstedt lässt sich auf das SCOR-Modell entsprechend den aus den Anwendungsberichten abgeleiteten Anforderungen230 anwenden. Ohne die Komplexität für den Modellnutzer zu steigern, können wesentlich spezifischere Modelle aus dem integrierten Gesamtmodell erstellt werden, wenn dieses um einzelne Elemente erweitert und entsprechend attribuiert wurde. Die Verwendung von Taxonomien und Ontologien zur Klassifikation und Verbindung der Konfigurationsparameter bzw. ihrer Ausprägung stellt die konsistente Konfiguration des SCOR-Modells sicher, ohne dass sich gegenseitig ausschließende Informationen im Modell enthalten bleiben oder abhängige Elemente nicht mitgeliefert werden. Methoden, die eine einheitliche Erweiterung des SCOR-Modells auf syntaktischer Ebene sicherstellen, werden in Abschnitt vorgestellt. Für eine konsistente Nutzung und Durchführung des Konfigurationsansatzes ist zusätzlich die Unterstützung durch Software-Werkzeuge hilfreich. Auf diese Unterstützung wird in Abschnitt eingegangen Kopplung des SCOR-Modells Es existieren bereits Referenzmodelle für unterschiedliche betriebswirtschaftliche Kontexte,231 für die der Aufwand, sämtliche enthaltenen Informationen in das SCOR-Modell zu übertragen, entweder zu hoch ist oder von den Entwicklern keine Unterstützung finden wird, da durch sie eine entsprechende Reputation erlangt wurde.232 Einige dieser Referenzmodelle sind, ähnlich dem SCOR-Modell, auf verschiedenen Ebenen spezifiziert. Als Beispiele hierfür können die ebenfalls WI09 IJPE 229 Für eine Formalisierung der Regeln siehe Becker et al Vgl. nochmals Abschnitt Vgl. Fettke und Loos 2003, S. 45 f.; Fettke Vgl. nochmals Proposition 2 auf S. 56.

85 3 Erweiterung des Supply Chain Operations Reference-Modells 70 vom SCC zur Verfügung gestellten DCOR- und CCOR-Modelle sowie das abgespaltene VRM (Value Reference Model)233, aber auch das Handels-H-Modell von Becker und Schütte234 oder das Y-CIM-Modell von Scheer235 angeführt werden. Das SCC hat bei der Erstellung der Modelle Introducing the Design-Chain berücksichtigt, dass sie an das SCOR-Modell gekoppelt werden, ohne jedoch auf die Umsetzung einzugehen (vgl. Abb. 3.10). Supplier processes Product/Portfolio Management MCOR Product Design DCOR Supply Chain SCOR Sales & Support CCOR Customer processes Quelle: Hunsche 2006, S. 4. The collection of processes that translate ideas for Abb. 3.10: Vorstellung des SCC der CCOR/DCOR/SCOR-Integration products into product definitions such as recipes, BOMs, Um Informationen, work die instructions, solchen Modellen enthalten workflow sind, mit dem and SCOR-Modell develops koppelnor zu können, re-uses werdenthe Koordinationsblöcke processesvorgeschlagen, and infrastructure die bspw. den Datenaustausch for selling, und / oder fulfillment and support of the product. den Prozessablauf zwischen den jeweiligen Modellelementen regeln.236 Eine Referenzbibliothek solcher Bausteine bietet Elemente, die aufgrund standardisierter Schnittstellen das Weiterleiten und die Verarbeitung von Daten zwischen den Referenzmodellen ermöglichen und nicht Teil des SCOR-Modells sind.237 Neben der Aufgabe der Datenkoordination können eigene Prozessmodelle DCOR 1.0 Introduction Training hinterlegt werden, die wiederum den Ablauf der Kooperation definieren. Zur Umsetzung müssen für jedes zu koppelnde Referenzmodell diejenigen Modellelemente ausgewählt werden, zwischen denen eine Interaktion notwendig ist, um sie dann über einen Referenzprozessbaustein miteinander Vgl. Value Chain Group Vgl. Becker und Schütte Vgl. Scheer Vgl. Scheer, Theling und Loos 2002, S Dieser Ansatz entstammt dem vom BMBF geförderten Forschungsprojekt FlexNet (Flexible Informationssystem- Architekturen für hybride Wertschöpfungsnetzwerke; BMBF-Förderzeichen 01FD0629). In diesem Projekt werden für die hybride Wertschöpfung standardisierte Koordinationsblöcke entwickelt, die zwischen Anwendungssystemen des Produzenten und des kooperierenden Dienstleisters geschaltet werden. Vgl. bspw. Beverungen, Knackstedt und Müller 2008.

86 3 Erweiterung des Supply Chain Operations Reference-Modells 71 zu verbinden. Hierzu müssen auf Seiten der Modelle sowohl geforderte als auch angebotene Inputund Output-Daten spezifiziert und mit den Bausteinen abgeglichen werden (vgl. im Folgenden Abb. 3.11). SCOR IRM Bibliothek von Referenzmodellen SCOR DCOR CCOR IRM Y-CIM Handels-H-Modell Ebene 1 Ebene 2 Ebene 3 Source (S) Deliver Stocked Product (D1) Deliver Make-to- Stock Product (D2) Plan (P) Make (M) Deliver Engineer- to-order- Product (D3) Request for Quote (RFQ)/Request for Proposal (RFP) Contract Status ED.3 Customer address Data D3.2 Completed Proposal D3.2 Purchase History ED.3 Credit History D2.2, ED.3 Shipping Preferences (Customer) ED.3 Return (R) Deliver (D) Deliver Retail Product (D4) Enable Deliver (ED) Obtain and Respond to RFQ/RFP (D3.1)... Ebene 3 Ebene 2 Ebene 1 Adapt Services (A) Adapt Logistics (A1) Adapt Maintenance (A2) Customer Service Requirements Selected Services Service Adapt Plan Historical Quotations Build Services (B) Adapt Retrofit (A3) Adapt Packaging (A4) Operate Services (O) Configure &... Adapt Services... (A2.2) Service Offer Adapt Quality Control (A5) Coordination of... (C...) Kopplungsebene Data of product components = SCOR D3.1 (Completed Proposal) Data of service components = IRM A2.2 (Service Offer) Coordination of Offering (C1) Model of Product-service bundle = SCOR D3.1 (Completed Proposal), IRM A2.2 (Service Offer)... Data of product components Data of service components Coordination of Offering (C1) Model of Productservice bundle Bibliothek von Koordinationsbausteinen Data of product components Data of service components Model of Product-Service bundle C1.1 Model of Product-Service bundle C1.1 Assessment Protocol C1.2 Model of Product-Service bundle C1.1 Develop alternative product-service bundles (C1.1) Assess alternative product-service bundles (C1.2) Choose productservice bundle (C1.3) Report productservice bundle (C1.4) Model of Product-service bundle C1.2, C1.3, C1.4 Model of Product-service bundle C1.2 Assessment Protocol C1.3 Model of Product-service bundle Coordination of Offering (C1) Abb. 3.11: Beispiel der Anwendung des Kopplungsansatzes Für das bereits angeführte IRM galt das SCOR-Modell explizit als Vorbild und eignet sich somit im Besonderen zur Illustration der Kopplung. In dem folgenden Beispiel wird davon ausgegangen, dass ein Produzent mit einem Dienstleiter kooperiert, um ein Hybrides Produkt zu erzeugen. Beispiele solcher Produkte sind Kraftfahrzeuge, die gemeinsam mit einer Versicherung, Wartung oder einem Leasingplan verkauft werden.238 Grundsätzlich müssen sich die Partner 238 Für weitere Beispiele hybrider Produkte vgl. bspw. Knackstedt, Pöppelbuß und Winkelmann 2008, S. 235 f.

87 3 Erweiterung des Supply Chain Operations Reference-Modells 72 bei der Erstellung eines hybriden Produktes auf eine geeignete Kombination aus Produkt und Dienstleistung einigen.239 An diesem Punkt setzt das Beispiel ein. Voraussetzung ist, dass sich die Unternehmen dazu entscheiden, auf Referenzmodelle zurück zu greifen. Für Produzenten eignet sich in dieser Hinsicht das SCOR-Modell, für den Dienstleister das IRM, da es gerade zum Zweck der Dienstleistungsabbildung entwickelt wurde. Aus einer Liste koppelbarer Referenzmodelle werden die zu koppelnden ausgewählt, wobei es sich bei diesem Ansatz nicht zwangsläufig um eine Kombination von Referenzmodellen mit dem SCOR-Modell handeln muss. Der Ansatz ist generisch und somit auch mit anderen, Funktionen und Prozesse abbildenden Referenzmodellen anwendbar. Für die Kopplung werden zunächst diejenigen Elemente gewählt, die einer Kopplung bedürfen in diesem Fall der Elementarprozess D3.1: Obtain and Respond to RFQ/RFP des SCOR-Modells und der Elementarprozess A2.2 Configure & Adapt Services des IRM. Gerade bei der sehr individuellen Erzeugung von hybriden Produkten dürfte sich die Deliver Engineeredto-Order Product -Prozesskategorie am besten eignen. In Abbildung 3.11 sind die (für diesen Fall relevanten) eingehenden und ausgehenden Daten mit den jeweiligen Quellen (soweit identifizierbar) angeführt.240 Aus einer Bibliothek von Koordinationsbausteinen (links unten) wird ein geeigneter, standardisierter Prozessbaustein ausgewählt (in diesem Fall C1: Coordination of Offering ) und entsprechend mit Inputs und Outputs versehen. Die Elementarprozesse des Prozessbausteins selbst können wieder einer Struktur entsprechen, die dem des SCOR-Modells auf der dritten Ebene entspricht. In diesem Fall wird der Prozessbaustein C1 verwendet, um in Abstimmung mit dem Dienstleister ein geeignetes Produktmodell für die RFQ-/ RFP-Daten aus dem SCOR-Modell zu definieren, evaluieren, auszusuchen und dieses zur weiteren Verwendung an die Parteien zu übermitteln. Dies geschieht einerseits als Completed Proposal für das SCOR-Modell, andererseits als Service Offer für das IRM. Im Rahmen des FlexNet-Projekts wurden bereits zumindest für die Hybride Wertschöpfung eine Reihe standardisierter Prozessobjekte entwickelt, deren Veröffentlichung als PAS (Publicly Available Specification) angestoßen wurde.241 Diese können als Ausgangspunkt für die Kopplung von Referenzmodellen, die für eine Kooperation von Produzent und Dienstleister geeignet sind, genutzt werden. Hierfür wurden neben Prozessen auch Dokumente spezifiziert, die ein standardisiertes Vokabular sowie implementierte Schnittstellenbeschreibungen beinhalten. Für 239 Vgl. Knackstedt et al Ein RFQ bzw. RFP kommt von einem Partner außerhalb des eigenen Prozesses. Da sich der Partner nicht zwingend ebenfalls an der Systematik von SCOR orientieren muss, ist kein konkreter Elementarprozess definiert. Für das Weiterreichen der Informationen innerhalb des Prozesses werden die Ziel-Elementarprozesse (ED3, D2.2 und D3.2) aber angegeben. 241 Vgl. DIN 2010.

88 3 Erweiterung des Supply Chain Operations Reference-Modells 73 die Kopplung von Modellen bzw. die Erstellung neuer Kopplungsbausteine ist die Unterstützung durch Software-Werkzeuge hilfreich. Auf diese Unterstützung wird in Abschnitt eingegangen Anpassung des Vorgehensmodells zur SCOR-Einführung Unter Berücksichtigung der in den Abschnitten und vorgestellten Ansätze kann die Anwendung des SCOR-Modells in der Art, wie Bolstorff, Rosenbaum und Poluha sie vorstellen, nicht weiter Bestand zu haben.242 Aus diesem Grund wird ein optionales243, erweitertes Vorgehensmodell vorgeschlagen (vgl. Abb. 3.12). Nachdem die organisatorischen Vorbereitungen zur Einführung eines SCOR-Projektes getroffen wurden, wird eine weitere Adaptionsphase durchlaufen. In dieser wird zunächst analysiert, ob die Einbeziehung von Funktionsbereichen, die nicht durch das SCOR-Modell unterstützt werden, erwünscht ist. Sollte dies der Fall sein, muss die Frage beantwortet werden, ob Referenzmodelle existieren, die einen solchen Bereich abdecken und ob eine Kopplung dieser möglich und nutzenstiftend ist. Bei der Auswahl geeigneter Referenzmodelle können Referenzmodellkataloge wie der von Fettke und Loos oder der Open Model Initiative verwendet werden.244 Auch für unternehmensinterne Modelle kann eine Eignung zur Darstellung von Verfeinerungen von Prozessen der dritten Ebene überprüft werden. In der Konfigurationsphase werden die geeigneten und benötigten Konfigurationsparameter sowie deren Ausprägung festgelegt, die Konfigurationsterme ausgewertet und jedes Modell, das konfigurierbar ist, den Regeln entsprechend angepasst.245 Die konfigurierten Modelle können dann bereits dem Projektteam zur Verfügung gestellt werden, sofern nicht Kopplungen oder weitere Anpassungen im Sinne der Adaptionstechniken Aggregation, Instanziierung, Spezialisierung oder freie Modifikation246 vorgenommen werden sollen. Abschließend müssen die relevanten Modellelemente der zu koppelnden Referenzmodelle identifiziert und die geeigneten Kooperationsbausteine ausgewählt werden. Für den Fall, dass sich geeignete Bausteine in der Bibliothek befinden, ist zu überprüfen, ob sie ohne Anpassung übernommen werden können oder den Gegebenheiten angeglichen werden müssen. IJPE GfKl07 ECIS Vgl. Proposition 3, S. 56; vgl. Bolstorff und Rosenbaum 2003; Bolstorff, Rosenbaum und Poluha Trotz der oben vorgestellten Erweiterungsmechanismen ist es weiterhin möglich, eine Standardvariante zu pflegen, die dem Stand des grundlegenden SCOR-Modells entspricht. Zu diesem Zweck muss lediglich ein Konfigurationsparameter Standardmodell eingeführt werden, der ausschließlich an diejenigen Modellelemente annotiert wird, die das dem SCC als Referenz entsprechende Modell konstituieren. Somit besitzt das herkömmliche Vorgehensmodell weiterhin seine Daseinsberechtigung. Für den Fall, dass nicht die Standardvariante gewählt wird, ist das optionale, angepasste Vorgehensmodell notwendig. 244 Vgl. Fettke und Loos 2003; The Open Model Initiative Es ist nicht auszuschließen, dass sich unter den im Referenzmodellkatalog befindlichen Modellen auch solche finden, die ebenfalls konfigurierbar sind. 246 Vgl. vom Brocke 2003; Becker, Delfmann und Knackstedt 2004; Knackstedt 2006; Delfmann 2006.

89 3 Erweiterung des Supply Chain Operations Reference-Modells 74 Teamauswahl Metriken definieren Vorbereitung Lückenanalyse erstellen Wettbewerbslage analysieren Bedarf an Zusatzmodellen feststellen Suche nach Zusatzmodellen Identifikation von Zusatzmodellen Auswahl von Zusatzmodellen Bewerten von Zusatzmodellen Legende Adaptation Festlegen von Konfiguationsparameterausprägungen Logische Auswertung von Konfigurationstermen Konfiguration Konfigurierte Modelle zur Verfügung stellen Anpassung der Modelle gemäß Konfigurationsregeln Original-Vorgehen nach Bolstorff und Rosenbaum (2003) Adaptation As-Is-Materialfluss modellieren Anforderungen an To-Be-Modelle identifizieren Materialfluss abbilden Opportunitätsanalyse erstellen To-Be-Materialfluss modellieren Aggregation Instanziierung Sonstige Modell- Adaption Sonstige Anpassung Spezialisierung Neue Vorgehensphase To-Be-Modelle anpassen To-Be- Prozess- und Informationsfluss finalisieren Prozess- und Informationsfluss abbilden As-Is-Prozess- und Informationsfluss erstellen Implementierung vorbereiten Kooperationsbedarf feststellen Kooperationsbaustein suchen Kopplung der Einzelmodelle Kooperationsbaustein integrieren Kooperationsbaustein auswählen oder neu konstruieren Zusätzliche Schritte in der neuen Vorgehensphase Abb. 3.12: An die Ansätze angepasstes Vorgehensmodell Für den Fall, dass kein geeigneter Kopplungsbaustein identifiziert werden kann, ist die Entwicklung eines neuen notwendig. Hierbei können Software-Artefakte zum Einsatz kommen, die eine entsprechende Generierung ermöglichen (vgl. Abschnitt 3.3.2) Kollaborative Modellerweiterung Ein erweitertes SCOR-Modell zu erstellen erfordert die Erhebung von Daten, Prozessen und organisationalen Gegebenheiten von vielen Teilnehmern. Hier ist die Frage zu stellen, woher diese Informationen kommen, da das SCC als Non-Profit-Organisation keine Mitarbeiter zur Verfügung stellen kann, die die benötigten Inhalte erheben können. Das Einarbeiten von Erweiterungsvorschlägen, wie sie in Anwenderberichten des SCC dokumentiert sind, erfordert ein hohes Maß an Personalaufwand und ist durch die Struktur des SCC nicht realisierbar.247 Aus diesem Grund 247 Vgl. Hypothese 1 von Frank, Strecker und Koch; Frank, Strecker und Koch 2007a, S. 20.

90 3 Erweiterung des Supply Chain Operations Reference-Modells 75 wird die Erweiterung im Sinne des Open Model-Ansatzes248 vorgeschlagen, der es den Teilnehmer des Council ermöglicht, proaktiv im Sinne der Open Source-Bewegung an der Erweiterung des SCOR-Modells mitzuwirken. Durch ihr gemeinsames Interesse am Gegenstand des SCOR-Modells besteht die Möglichkeit, dass sie, durch eine intrinsische Motivation angeleitet, die Erweiterung des SCOR-Modells vorantreiben.249 Hierfür müssen die Barrieren für eine Beteiligung sehr niedrig gehalten werden und die Effekte, die eine Beteiligung mit sich führt, erkennbar sein.250 Auf Seiten des SCC ist es wichtig, dass Modelle und Erweiterungen, die durch die Mitglieder in das SCOR- Modell eingebracht werden, konsistent zu den vorhandenen Modellen und der gemeinsamen Vorstellung sind. Dies betrifft vor allen Dingen die Kernelemente des SCOR-Modells (Prozesskategorien, Best Practices, Metriken und Perfomance Attribute), deren Struktur zumindest dem Metamodell des SCOR-Modells entsprechend sein müssen. Erweiterungen, die auf der vierten Ebene hinzugefügt werden, können vom Modelltyp her zwar vielfältig sein müssen also nicht zwangsläufig dem SCOR-Metamodell entsprechen, eine gemeinsame, vom SCC vorgegebene Sprache kann sich aber als nützlich erweisen, um ein kongruentes Verständnis des Modells zu bewahren.251 Da bei einer Umsetzung des oben angeführten Übertragens der Entwicklungstätigkeit auf die SCC-Mitglieder keine zeitliche und räumliche Nähe der Entwickler mehr herrscht, sind diese Voraussetzungen nicht bzw. nur schwer zu gewährleisten.252 Aus diesem Grund werden zwei Methoden vorgeschlagen, die nicht nur eine syntaktisch korrekte Erstellung von Elementen und Modellen im Sinne eines Metamodells erlauben, sondern auch die sprachlich einheitliche (verteilte) Modellierung unterstützen und erlauben, Strukturen in Modellen zu identifizieren, die bspw. auf Redundanzen oder Fehler hinweisen können. Linguistische Ansätze Empirische Studien belegen, dass selbst bei der individuellen Modellierung von konzeptionellen Modellen einzelner Personen, vor allem aber bei der räumlich und zeitlich verteilten Modellie- rung, Namens- und Typkonflikte häufig zu beobachtende Fehler bzw. Uneindeutigkeiten sind.253 ER09 EMISA 248 Vgl. Frank, Strecker und Koch 2007a. 249 Vgl. Ljungberg 2000, S. 208: An open source project is a loosely coupled community kept together by strong common values[...]. Vgl. auch Stewart und Gosain 2006, S. 292 f. 250 Vgl. Lerner und Tirole 2002, S. 212 ff.; Frank, Strecker und Koch 2007b, S. 12 f., abgeleitet aus Rossi und Bonaccorsi Vgl. hierzu auch Abschnitt sowie Janiesch und Stein 2007 (Kapitel 11). 252 Vgl. Hadar und Soffer 2006; Lawrence und Barker 2001; Batini, Lenzerini und Navathe Vgl. Hadar und Soffer 2006.

91 3 Erweiterung des Supply Chain Operations Reference-Modells 76 Hierbei handelt es sich vor allem um Synonyme254, unnötige Metainformationen255, ungeeignete Auswahl von Elementtypen256, inkonsistente Verwendung von Phrasenstrukturen257, Verwendung nicht eindeutiger Bezeichnungen258 sowie Rechtschreibfehler.259 Unter der Voraussetzung, dass die Erweiterung des SCOR-Modells verteilt durch seine Mitglieder stattfindet, deren Modellierungserfahrung sich vermutlich stark unterscheidet, ist es wichtig, die oben beschriebenen Fehler möglichst schon während des Modellierungsprozesses zu minimieren, um im Anschluss vergleichbare und in das Gesamtmodell integrierbare Modelle bzw. Modellbausteine zu erlangen. Bereits bestehende Ansätze können strukturbezogen eingeteilt werden in solche, die entweder einzelne Terme oder komplexere Phrasen adressieren, und zeitpunktbezogen in solche, die entweder vor dem Modellierungsprozess (ex-ante) oder danach (ex-post) zum Einsatz kommen. Die entwickelte Methode unterscheidet sich hiervon, indem sie den Modellierer während des Modellierungsprozesses begleitet und unterstützt. Vor allem für Prozessmodelle, in denen die Bezeichnungen (im Gegensatz zu bspw. Datenmodellen) aus komplexeren Phrasen bestehen, ist diese Methode geeignet, jedoch nicht darauf begrenzt. Mit Blick auf das SCOR-Modell lässt sich feststellen, dass zumindest auf den Ebenen zwei und drei komplexere Strukturen für die Bezeichnung der Modellelemente verwendet werden.260 Zur Unterstützung bei der Modellierung wird ein Framework vorgeschlagen, das vorschreibt, wie aus Teilen der natürlichsprachlichen Grammatik261 und festdefinierten Namenskonventionen262 eine modellierungsprojektbezogene Grammatik abgeleitet wird. Es ist für die Modellierung wichtig, dass der Modellierer durch die Überprüfung der Elementbezeichnungen nicht von seiner ER Hierbei kann es sich um tatsächliche Begriffe, aber auch um Abkürzungen handeln. Ein Beispiel für ein Synonym ist die Verwendung des unspezifischen Begriffs Rechnung an einer Stelle und die Verwendung des spezifischeren Begriffs Kreditorenrechnung an einer anderen. 255 Syntaktisch sowie semantisch wird beispielsweise das Ende eines Prozesses bei der Verwendung der Methode der Ereignisgesteuerten Prozesskette (EPK) durch das letzte, abschließende Ereignis determiniert. Hierbei konnte jedoch beobachtet werden, dass die Bezeichnungen der Elemente zum Teil noch um Informationen wie Ende des Prozesses ergänzt wurden. 256 In EPK-Modellen wurden Ereignisse gefunden, die mit Auftrag ist zu versenden bezeichnet wurden, was dem Typ Funktion entspricht. 257 Obwohl in Projekten zum Teil Bezeichnungskonventionen schriftlich vorlagen, wurden unterschiedliche Satzstrukturen verwendet. Beispiel (aus dem Englischen übersetzt): Überprüfe, ob Beschreibung notwendig ist vs. Überprüfe Notwendigkeit der Beschreibung. 258 Dieser Fehler tritt auf, wenn bspw. in Funktionen der EPK oder in Aktivitäten von BPMN (Business Process Management Notation) Tätigkeiten mit und verknüpft werden. Beispiel (aus dem Englischen übersetzt): Füge Ergänzungen ein und versende abschließende Version. 259 Für eine Klassifizierung von üblichen Bezeichnungsfehlern vgl. Delfmann, Herwig und Lis 2009, S. 182 ff. 260 Source Stocked Product (S1) entspricht beispielsweise schon dem Fall <Nomen> <Adjektiv> <Nomen>. 261 Diese besteht aus einem natürlichsprachlichen Lexikon (dem Sprachschatz ) und einer natürlichsprachlichen Syntax. 262 Diese bestehen aus einem Domänenthesaurus und Phrasenstrukturkonventionen.

92 3 Erweiterung des Supply Chain Operations Reference-Modells 77 eigentlichen Aufgabe dem Erstellen des Modells abgelenkt wird, um eine möglichst maximale Konzentration auf den Modellerstellungsprozess zu gewährleisten. Die Systeme, die hierfür genutzt werden, müssen schnell reagieren und möglichst in Echtzeit ein valides Ergebnis präsentieren. Hierfür wurde eine Analyse der Funktionalitäten von verfügbaren Parsern, die Struktur und Therme einer Phrase ausgeben, durchgeführt und der geeignetste der Stanford Parser ausgewählt. Für die Umsetzung des Konzepts müssen bereits im Vorfeld der Modellierung ein Vokabular festgelegt sowie valide Phrasenstrukturen definiert werden, welche während des Modellierungsprozesses durch einen Algorithmus zur Validierung genutzt werden. Auf Basis der Wortarten werden alle weiteren Aktivitäten durchgeführt, die dazu führen, dass der Modellierer im besten Fall ohne Rückmeldung des Systems modellieren kann. Auf die externen Systeme muss lediglich dann zurückgegriffen werden, wenn das Wort weder im natürlichsprachlichen, noch im Domänenlexikon zu finden ist, Wörter in einer Phrase überzählig sind und unter Umständen entfernt werden müssen oder wenn Synonyme identifiziert wurden, die nicht eindeutig bestimmt wurden. Berücksichtigt wird auch die Neuaufnahme von Wörtern in das Domänenlexikon während des Modellierungsprozesses. Hierdurch kann eine dynamische Erweiterung umgesetzt werden, wenn die neuen Begriffe von einem Expertengremium validiert und freigeschaltet, oder aber mit den entsprechenden Synonymen versehen werden. Für die Umsetzung der automatisierten Überwachung der Richtlinien ist eine Werkzeugunterstützung unumgänglich. Eine prototypische Umsetzung wird in Abschnitt vorgestellt. EMISAJ Mod10 Modellstrukturbezogene Ansätze Modellierungswerkzeuge greifen zur Sicherung der syntaktischen Korrektheit von mit ihrer Hilfe erstellten Modellen auf das Konstrukt des Metamodells263 für die jeweilige Sprache zurück und grenzen sich hiermit von Zeichenwerkzeugen ab.264 Durch ihren Einsatz wird die Wahrscheinlichkeit des Auftretens von syntaktischen Fehlern in Modellen zumindest reduziert, ganz auszuschließen sind sie jedoch nicht. Aus diesem Grund ist es sinnvoll, Methoden einzuführen, die in der Lage sind, solche syntaktischen Fehler in Informationsmodellen zu identifizieren. Bei der verteilten Erstellung von Modellen, wie es im Zuge der global verteilt stattfindenden Erweiterung des SCOR-Modells der Fall wäre, kann es vorkommen, dass verschiedene Nutzer ähnliche Realweltaspekte doppelt modellieren. Hierfür ist es wünschenswert, dass solche strukturellen Ähnlichkeiten identifizierbar sind, und eine Konsolidierung der Modelle ermöglicht sowie 263 Vgl. nochmals Abschnitt Vgl. Karagiannis und Kühn 2002, S. 193 f.

93 3 Erweiterung des Supply Chain Operations Reference-Modells 78 vereinfacht wird. Auch bei der Modellierung disjunkter Sachverhalte, die anschließend in ein konsolidiertes Gesamtmodell überführt werden sollen, kann die automatische Identifikation von Schnittstellen dazu beitragen, den Integrationsvorgang zu beschleunigen. Vor allem im Bereich der Datenmodellierung kann es hilfreich sein, eindeutige Strukturen vorzugeben, deren Einhaltung ein gemeinsames Verständnis des Betrachtungsgegenstandes ermöglicht (vgl. Abb. 3.13). A ABC-ZuO B A AB-ZuO B C ABC-ZuO C Abb. 3.13: Unterschiedliche Modellierung des gleichen Sachverhalts in ERM (Bsp.) Die in Abb dargestellten ER-Modelle können von zwei unterschiedlichen Modellierern erzeugt worden sein, die trotz einer gemeinsamen Modellierungssprache und einer gemeinsamen Domänensprache aufgrund ihres unterschiedlichen mentalen Modells zu zwei unterschiedlichen konzeptionellen Modellen gelangt sind. Solchen Fällen kann nicht mit den in Abschnitt beschriebenen Konzepten begegnet werden. Obwohl verschiedene Ansätze zur Lösung dieser Problematik bestehen, sind diese in der Regel domänen- oder modellierungssprachenbezogen,265 weshalb im Rahmen der Veröffentlichungen dieser Arbeit ein generischer, von der Modellierungssprache unabhängiger Ansatz entwickelt und vorgestellt wurde. Der Ansatz besteht darin, Modelle als Menge von Elementen im Sinne der Mengenlehre zu betrachten und auf diesen Operationen zu definieren, die in der Lage sind, Strukturen zu identifizieren. Die betrachteten Elemente lassen sich grundsätzlich in Knoten und Kanten unterscheiden. Mit diesen atomaren Elementen können dann Mengen (z. B. ein Element und eine verbundene Kante) sowie Mengen von Mengen erstellt werden (z. B. mehrere mit Kanten verbundene Elemente). Operationen, die auf diesen Mengen arbeiten, können Strukturen definieren, die dann in vorhandenen Modellen gesucht werden können. Das Ergebnis einer Strukturmustersuche ist dann wieder eine Menge aus (gefundenen) Strukturen, die selbst wiederum aus Mengen von Elementen besteht (vgl. Abb. 3.14). Über logische Operationen wie das Bilden von Vereinigungsmengen oder Teilmengen können die Ergebnismengen wiederum zielgerichtet beschnitten werden. Die bisher EMISA 265 Vgl. die Literaturanalyse in Delfmann et al. 2009b.

94 3 Erweiterung des Supply Chain Operations Reference-Modells 79 Strukturdefinition Strukturmustersuche Menge von gefundenen Strukturmustern Gefundene Strukturmuster (Menge von Elementen) Abb. 3.14: Elemente, Mengen, Strukturdefinitionen und Strukturen als notwendig identifizierten Operationen wurden in der Publikation von Delfmann et al. formal spezifiziert. Die Ergebnismenge kann zur Visualisierung an ein Modellierungswerkzeug übergeben werden, das die Elemente, die Teil einer Struktur sind, farblich markiert und so die Korrektur von Fehlern oder die Zusammenführung von Modellen vereinfacht Unterstützung durch Werkzeuge Verwendung von Standards Vorausgesetzt, dass die oben vorgeschlagenen Konzepte für die verteilte Erweiterung des SCOR- Modells eingesetzt werden, muss geklärt werden, ob es sich bei den von Anwendern zur Verfügung gestellten Modellen um neu erstellte oder um solche, die aus bestehenden abgeleitet wurden, handelt. Wie im Abschnitt 2.2 angeführt wurde, ist nicht jedes situativ erstellte Modell geeignet, als (Teil von einem) Referenzmodell zu dienen. Aus diesem Grund ist es sinnvoll und notwendig, bei der Übermittlung dieser Modelle an eine zentrale Einrichtung, wie bspw. an das SCC, Standards zu nutzen und einzuhalten, um die Integration in das Referenzmodell zunächst zu ermöglichen und weiter zu erleichtern. Bei Standards handelt es sich um Spezifikationen zur Kommunikation oder zum Vorgehen, auf die sich eine Gruppe geeinigt hat.267 Durch die Dokumentation der Spezifikation sind Möglichkeiten gegeben, Anwender in ihren Tätigkeiten oder ihrer Kommunikation zu leiten und so die Durchführungs- und Kommunikationsqualität zu verbessern. Insgesamt werden von Janiesch RefMod7 266 Vgl. Delfmann et al. 2009a (Kapitel 15). 267 Vgl. David und Greenstein 1990; Fomin, Keil und Lyytinen 2003.

95 3 Erweiterung des Supply Chain Operations Reference-Modells 80 und Stein drei zu standardisierende Bereiche vorgeschlagen, die in Bezug auf die Erweiterung des SCOR-Modells von Vorteil sein können:268 Notationen: Neben Modellierungssprachen wie EPK, UML oder Aktivitätsdiagrammen ist BMPN eine recht junge Modellierungssprache269, die allerdings Beachtung bei der Object Management Group (OMG), die als einflussreiches Standardisierungsgremium bekannt ist, gefunden hat. BPMN ermöglicht durch verschiedene Sätze von Modellelementen eine abstrakte Modellierung auf fachkonzeptioneller Ebene, aber auch eine detaillierte Modellierung, die unter gewissen Umständen270 eine Überführung in die Business Process Execution Language (BPEL) erlaubt. Neben dem Vorteil der Bekanntheit der Sprache können Modelle, die in BPEL vorliegen, auf Workflow Engines zur Prozessunterstützung ausgeführt zu werden. Außerdem wird BPMN von Unternehmen gefördert, die auch Mitglieder des SCC sind, was die Akzeptanz unter den Anwendern erhöhen sollte.271 Terminologie: Die in Abschnitt vorgestellten Ansätze begleiten den Modellierer bei der Erstellung von Informationsmodellen und stellen sicher, dass sie eine einheitliche Sprache verwenden. Hierfür wird die UBL (Universal Business Language) vorgeschlagen, die von der OASIS (Organization for the Advancement of Structured Information Standards) entwickelt wurde. Die Mitglieder in diesem Konsortium überschneiden sich wieder stark mit denen des SCC, was einen hohen Akzeptanzgrad schaffen sollte. Dadurch, dass UBL der einzige von UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) akkreditierte XML-Ansatz zur Beschreibung von Geschäftsdokumenten ist, sollte die Akzeptanz auch außerhalb des SCC gewährleistet und als Teil der für die verteilte Modellierung des SCOR-Modells zur Verfügung gestellten Terminologie geeignet sein. Vorgehensmodelle: Die in UBL angebotenen Vorgehensmodelle bilden eine Grundmenge an Interaktionsvorgaben für den Austausch von Geschäftsdokumenten, was einerseits für das SCOR-Modell an sich hilfreich sein kann, da die Definition des Informationsaustauschs einer 268 Vgl. im Folgenden Janiesch und Stein BPMN 1.0 wurde im Mai 2004 erstmalig präsentiert. Vgl. BPMI 2010a. 270 Der Formalisierungsgrad von BPMN reicht noch nicht vollständig an die Anforderungen ausführbarer Aktivitäten heran. In der Version 2.0 soll ein entsprechendes Metamodell hinterlegt werden, das eine automatisierte Überführung ermöglicht: Another goal, but no less important, is to ensure that XML (Extended Markup Language) languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation. OMG 2009, S Vgl. BPMI 2010b für die Unterstützer von BPMN; vgl. Supply Chain Council 2010b für die Mitglieder des SCC: In beiden Bereichen sind bspw. die Unternehmen IBM, IDS-Scheer, Fujitsu, SAP oder Tibco zu finden.

96 3 Erweiterung des Supply Chain Operations Reference-Modells 81 der Hauptbestandteile ist, andererseits können diese Kooperationsvorgaben als Blaupause für die Kooperationsbausteine des Kopplungsansatzes dienen.272 Diese drei Standards können in einem Framework zusammengefasst werden, das einen Überblick über deren Verwendung im Rahmen der Überführung von situativen Modellen in Referenzmodelle gibt (vgl. Abb. 3.15). Durch Umsetzung dieses Vorgehens ist es möglich, Modelle, die in Einzelprojekten erstellt wurden, zumindest in eine Form zu überführen, sodass sie für die Modellintegration bestmöglich vorbereitet ist. Wird bspw. eine einheitliche Modellierungssprache verwendet, kann der in Abschnitt vorgestellte Ansatz zur Strukturmustersuche einfacher angewendet werden. Als Problem stellt sich derzeit aber die noch mangelnde Unterstützung der konfigurativen Referenzmodellierung auf Seiten der Software-Hersteller dar.273 Die Annotation von Konfigurationsparametern und deren Ausprägungen an Modellelementen sowie das anschließende Konfigurieren wird methodisch von keiner bekannten Lösung unterstützt.274 Aus diesem Grund eignet sich als Alternative zur werkzeuginternen Konfiguration besonders ein standardisiertes Austauschformat, das Modelle aus verbreiteten Modellierungswerkzeugen aufnimmt und an eine externe Konfigurationslösung übermittelt. Diese Möglichkeit besteht, weil eine Vielzahl von Modellierungswerkzeugen in der Lage sind, ihre Modelle in einem zumeist proprietären XML-Format zu exportieren (vgl. RefMod9 Unternehmerische Herausforderung Modellierungsstandards z. B. BPMN, EPK, ERM, Petri-Netze, UML,... Standardisierte Terminologie z. B. UBL, OAGIS, UCM, ISO- Codelisten,... Business Vorgehensstandards Semantics Standards z. e.g., B. ITIL, UBL, ISO OAGIS, 9000, UCM, UBL/OAGIS,... ISO code lists... Erkennen des Kontexts Auswahl des Modellierungsstand ards Auswahl der standardisierten Terminologie Auswahl von standardisierten Vorgehensmodellen Situatives, aber übertragbares Modell Referenzmodell Abb. 3.15: Vorgehen zur Verwendung von Standards 272 Vgl. Abschnitt Vgl. Delfmann und Knackstedt Verschiedene Anwendungen erlauben zwar die Annotation von Attributen an Modellelemente, die Unterstützung der in Abschnitt 2.3 vorgestellten Mechanismen ist jedoch nicht gegeben.

97 3 Erweiterung des Supply Chain Operations Reference-Modells 82?ML-Export?ML-Import ?ML Transformation Transformation?ML CML CML-Import Konfigurationswerkzeug Modellierungswerkzeug 5 CML CML-Export 4 Abb. 3.16: Ablauf der Konfiguration, Austausch der XML-Dateien Abb. 3.16: (1)).275 Diese Fähigkeit kann genutzt werden, um mittels Techniken wie XSLT (Extensible Stylesheet Language Transformation) die werkzeugspezifische Datei in ein standardisiertes Format zu überführen (2).276 Dieses kann anschließend von einer externen Lösung konfiguriert (3) und wieder exportiert (4) werden. Anschließend wird die konfigurierte Datei per XSLT in das ursprüngliche Format zurück transformiert (5) und kann in dem jeweiligen Modellierungswerkzeug weiterverwendet werden (6). Die Formate, in denen bekannte Modellierungswerkzeuge ihre Modelle exportieren, sind dahingehend optimiert, einen möglichst einfachen Austausch zwischen verschiedenen Installationen der Programme zu ermöglichen, nicht jedoch auf einen möglichst offenen Austausch. Bei dem Entwurf des CML-Schemas muss berücksichtigt werden, dass bei einer Modellserialisierung zum Zwecke der Konfiguration die Informationen, die von dem originären Werkzeug übermittelt werden, an Stellen stehen, die den Konfigurationsprozess vereinfachen (vgl. Abb. 3.17).277 Die Piktogramme der mittleren Spalte stehen stellvertretend für die in Abschnitt 2.3 vorgestellten und hier erweiterten Konfigurationsmechanismen Modelltypselektion (1), Modellselektion (2), Elementtypselektion (3) und Elementselektion (4). Die Modelltypen werden in dem vorgestellten CML-Schema explizit pro Modell gespeichert (ModType), sodass bei einer Konfiguration der Knoten mit allen Subknoten gelöscht werden kann (1). Modellelemente sind immer dem Modell untergeordnet, in dem sie modelliert wurden, sodass beim Entfernen des Modell-Knotens auch alle beinhalteten Elemente entfernt werden. Bei der Modellselektion (2) werden einzelne Modelle aufgrund ihrer Zuweisung von Parameterausprägungen entfernt (ConfigTerm), die sich auf der gleichen Schema-Ebene befinden, wie die Informationen über den Modelltyp. Entsprechend der Modelltypselektion werden wieder alle untergeordneten Elemente 275 Vgl. Herwig und Stein Die Abkürzung CML steht für Configurable Markup Language. 277 Für die Platzierung der Elemente wurde auf die XML Schema Design Principles zurückgegriffen, die unter anderem einen zweckorientierten Aufbau der Schema-Datei vorsehen.

98 3 Erweiterung des Supply Chain Operations Reference-Modells 83 Modellierungswerkzeug Procurement Process Stocktaking Warehouse [EPC] Warehouse [Functiontree] Warehouse Organization [eerm] Transfer [EPC] Rearrangement [EPC] X V Unlabeled [XOR] Unlabeled [AND] Outlet is Subsidiary [Event] Outlet is Warehouse [Event] Warehouser [Role]... Determine Stock [Function] Determine Storage Area [Function] Distribution Process Konf.-Mech. X X X X XML-Darstellung DefinitionArea Definition DefType= EPC_FCT DefID= ID1 DefLabel= Determine Storage Area Definition DefType= EPC_Role DefID= ID2 DefLabel= Warehouser ModelArea Model ModType= eerm ModID= Mod1 ModLabel ModLabelValue= Warehouse Organization Model ModType= EPC ModID= Mod2 ModLabel ModLabelValue= Transfer ConfigTerm CTValue="transaction type = warehouse business OR third-party deal" Model ModType= EPC ModID= Mod3 ModLabel ModLabelValue= Rearrangement Occurrence DefRef= ID2 OccID= Occ2 Occurrence DefRef= ID1 OccID= Occ1 ConfigAttribute CAParam="Execution Type" CAValue="manual" Abb. 3.17: Referenzmodell vs. XML-Repräsentation entfernt. Bei der Elementtypselektion (3) werden sämtliche Elemente eines bestimmten Typs aus dem Modell gelöscht. Der Typ kann anhand der Beziehung zur Definition des Elements bestimmt werden.278 Entsprechend der Modellselektion werden bei der Elementselektion (4) diejenigen Modellelemente gelöscht, die eine entsprechende Parameterausprägung zugewiesen bekommen haben. Durch die hierarchische Speicherung der Modellelemente und die sinnvolle Positionierung der Konfigurationsattribute innerhalb der XML-Datei ist somit eine einfache, aber konsistente Konfiguration möglich. Die Zurverfügungstellung von sogenannten MiscAreas279 ermöglicht zusätzlich ein Durchreichen von werkzeugspezifischen Daten, die unverändert zurückgeliefert werden,280 sodass der Ansatz für beliebige Werkzeuge mit der Möglichkeit zum Export und der Möglichkeit zur Annotation von Attributen an Modellelemente nutzbar ist. Für das SCC bedeutet dies, dass grundsätzlich Modelle von Werkzeugen verschiedener Hersteller eingereicht werden können. Für den Fall, dass bei der Modellerstellung zusätzlich auf die in den Abschnitten und vorgeschlagenen Konzepte Rücksicht genommen wird, ist es möglich, räumlich und zeitlich verteilt für das SCOR-Modell geeignete Modelle zu erstellen, die einerseits konfigurierbar sind, andererseits aber aufgrund ihrer gegenseitig konsistenten Struktur einfach in 278 Der vorgestellte Ansatz unterstützt das Definitions- und Ausprägungskonzept. Vgl. Delfmann 2006, S MiscArea steht als Abkürzung für Miscellaneous Area, also ein XML-Bereich, in dem verschiedene oder sonstige Informationen zwischengespeichert werden. 280 Bei diesen Daten kann es sich bspw. um Metadaten in Bezug auf das exportierte Modell, den Ersteller des Modells oder die Uhrzeit der Erstellung handeln.

99 3 Erweiterung des Supply Chain Operations Reference-Modells 84 das SCOR-Modell aufzunehmen sein sollten. Dies setzt voraus, dass das SCOR-Modell in einem die Konzepte unterstützenden Format vorliegt Verwendung von Modellierungswerkzeugen Für alle in dieser Arbeit vorgestellten Konzepte wurden am Lehrstuhl für Wirtschaftsinformatik und Informationsmanagement des Instituts für Wirtschaftsinformatik der Westfälischen Wilhelms-Universität Münster im Rahmen der BMBF-Forschungsprojekte RefMod06 (Förderzeichen 01ISC05A) und FlexNet sowie im Rahmen von Projektseminaren Prototypen entwickelt, die ihre Durchführbarkeit demonstrieren und als erster Evaluationsschritt des Design Science- Prozesses gezählt werden können. Der größte Teil der Konzepte wird von dem auf Microsoft Visio aufsetzenden Meta-Modellierungswerkzeug [εm] umgesetzt,281 das während der letzten vier Jahre ( ) entwickelt wurde. Die Entscheidung, eine eigene Modellierungsumgebung zu realisieren, entstammte der Tatsache, dass vorhandene, verbreitete Modellierungswerkzeuge nicht in der Lage sind, die Anforderungen der Konfiguration ohne zusätzliche Implementierung zu erfüllen.282 Ein Forschungsprototyp, der im Rahmen des Forschungsprojekts RefMod06 für die Software ARIS der IDS-Scheer AG implementiert wurde, war speziell für dieses Produkt ausgelegt, was eine Verbreitung vor allem im Bereich kleiner und mittlerer Unternehmen (KMU) aufgrund des Preises des ARIS Toolsets ausschloss. Dieses Werkzeug unterstützt die in Abschnitt geforderte und Abschnitt vorgeschlagene verteilte Modellierung durch eine Client- / Server-Architektur, sodass Modelle auf einem zentralen Server bearbeitet und gespeichert werden. Durch seine Fähigkeit als Meta-Modellierungswerkzeug können beliebige Modellierungssprachen angelegt werden, sodass die erstellten Modelle der Sprachsyntax entsprechend konsistent sind und die Erstellung von Modellen auf der vierten Ebene des SCOR-Modells mit beliebigen Modellierungssprachen ermöglicht wird. Weiterhin ist [εm] mit definierten Schnittstellen entwickelt worden, die das Hinzufügen von Plugins ermöglichen. Trotz der Metamodellierungsfähigkeiten war das System jedoch nicht in der Lage, den Besonderheiten der Modellierung mit SCOR zu genügen (vgl. Abb. 3.18). Der hervorgehobene Bereich des SCOR-Metamodells entspricht der Verbindung von Prozesskategorien (PK) zu den hinterlegten Prozessmodellen der dritten Ebene. Eine beliebige, untereinander verbundene Menge von Elementarprozessen ergibt in seiner Anordnung eine EP-Reihenfolge, die einem Prozessmodell entspricht. Jeder Prozesskategorie, mit der im Sinne von SCOR modelliert wird, ist demzufolge 281 Zur Konzeption, dem Meta-Metamodell sowie der Architektur von [εm] vgl. Delfmann et al. 2008a. 282 Vgl. nochmals Abschnitt

100 element E) D,T Prozesstyp (1:n) (1:n) 3 Erweiterung des Supply Chain Operations Reference-Modells 85 Konf.-Term PC-Condition Relation (0:n) (1:n) Performance- Attribut (PA) (0:n) (0:n) Prozesskategorie (PK) (1:1) (0:n) -Metriction Konf.-Term (1:1) Berechnung Konf.-Term Konf.-Term (1:n) trik (0:n) (0:n) Konf.-Term EP-Reihenfolge (0:n) (1:1) (0:n).-Term Level 4 Prozess- Modell (L4PM) (1:n) EP-L4PM- Relation (0:n) (0:n) (0:n) Elementarprozess (EP) (0:n) : titytype tionshiptyp ax)-kardinalität Output Uminterpretierter Relationshipttyp D,T (0:n) Austauschobjekt dass beim Platzieren einer Prozesskategorie (0:n) auf der Modellierungsoberfläche (0:n) ein Prozessmodell Attribut auf der dritten Ebene ausgeprägt und (0:n) hinterlegt werden muss. Dieses Modell der dritten Ebene Best Practice Spezialisierung/ Generalisierung (Disjunkt, Total) Abb. 3.18: Ausschnitt aus dem SCOR-Metamodell Konf.-Term Konf.-Term genau ein Prozessmodell zugeordnet und umgekehrt. Für die Modellerstellung bedeutet das, muss bereits auf der Typebene des Elementtypen Prozesskategorie definiert werden, was eine Vermischung der Typ- und Instanzebene darstellt. In [εm] selbst ist dies nicht abbildbar. Aus diesem Grund wurde im Rahmen einer Masterarbeit das [εm]-meta-metamodell durch ein Plugin erweitert, um eine Modellierung in der vom SCC vorgegebenen Notation zu ermöglichen (vgl. Abb. 3.19).283 Hierdurch ist auch das automatische Hinterlegen von Prozessen der dritten Ebene sowie die fallweise Anpassung möglich.284 Für die Modellierung werden, wie in den Beispielen des SCC demonstriert, die Elemente der zweiten Ebene verwendet, um auf einem Arbeitsblatt die Supply Chain abzubilden.285 Es ist anzumerken, dass jedes Element des SCOR-Metamodells durch einen Elementtyp in [εm] abgebildet wird, womit sämtliche Modelloperationen nicht nur auf Prozesselemente, sondern auch auf Metriken, Best Practices und Performance-Attributen durchgeführt werden können. In Abb ist mittig die fiktive Unternehmung minidust dargestellt, die auf der linken und rechten Seite jeweils ihre Zulieferer und Abnehmer positioniert hat. Für jedes Element, das sich auf der Arbeitsfläche Input 283 Die Masterarbeit wurde von Herrn Marcel Heddier verfasst. 284 In einem zur Beschreibung der Supply Chain entwickelten SCOR-Modell können die verschiedenen Prozesskategorien mehrmals erscheinen, wenn ein Unternehmen bspw. mehrere Produktionsstätten besitzt, die auf Lager produzieren. In diesem Fall sollen die Prozessmodelle auf der dritten und den darunter liegenden Ebenen unabhängig voneinander angepasst werden können. 285 Vgl. bspw. nochmals Abb. 2.6 bzw. Supply Chain Council 2008, S. 18.

101 3 Erweiterung des Supply Chain Operations Reference-Modells 86 Abb. 3.19: Beispiel eines SCOR-Modells [εm] befindet, wurde eine Verfeinerung auf die dritte SCOR-Ebene hinterlegt. Weiterhin existieren für jedes Prozesselement die dem Metamodell entsprechenden Beschreibungen, Datenein- und -ausgänge, Performance-Attribute, Metriken und Best Practices (vgl. Abb. 3.20). Abb. 3.20: Analyse der Modellelemente in [εm]

102 3 Erweiterung des Supply Chain Operations Reference-Modells 87 Es werden immer nur diejenigen Inputs und Outputs angezeigt, die auch tatsächlich instanziiert wurden.286 Gleiches gilt auch für die Performance-Attribute. Aufgrund der Realisierung des SCOR-Metamodells ist es zudem möglich, die Sprache zu erweitern und z. B. neue Metriken oder Performance-Attribute, die lediglich für bestimmte Perspektiven relevant sind, einzupflegen. Weiterhin ist es hierdurch möglich, auf der vierten Ebene detaillierte Prozessmodelle in beliebigen Modellierungssprachen zu hinterlegen und diese perspektivenabhängig ein- oder auszublenden. Durch ein weiteres Plugin werden die linguistischen Konzepte, wie in Abschnitt und den Kapiteln 12 bis 14 vorgestellt, für [εm] umgesetzt. Diese ermöglichen dem Vorgehensmodell von Becker et al. folgend287 die Definition von Begriffen und Phrasenstrukturen, um sprachlich konsistente Modelle zu erzeugen (vgl. Abb. 3.21). Das Plugin ist nicht auf eine Modellierungssprache begrenzt und kann somit für das SCOR-Modell auf allen Ebenen verwendet werden. Das Befüllen des Thesaurus ist eine Administrationsaufgabe, die jedoch eine Verwendung von bestehenden Lexika ermöglicht. Hierdurch können bspw. die Sprachkonventionen der UBL in [εm] zur Verfügung gestellt werden. Diese Funktionalitäten wurden in den Publikationen von Becker et al. 2009a, Delfmann et al. 2009b und Becker et al. 2010a vorgestellt und über den Publikationszeitraum weiterentwickelt. Abb. 3.21: Umsetzung der Sprachkonventionen in [εm] 286 Vgl. bspw. den Elementarprozess M2.2, Issue Sourced/ In-Process Product (Supply Chain Council 2009b, S ): Als Informationseingänge sind jeweils die Inventory Availability aus S1.4, S2.4 und S3.6 vermerkt. In einer Supply Chain, die kein Source Engineer-to-Order ausprägt, ist der Informationsfluss von S3.6 nach M2.2 irrelevant und wird an dieser Stelle nicht benötigt. 287 Vgl. Becker et al. 2010a (Kapitel 14).

103 3 Erweiterung des Supply Chain Operations Reference-Modells 88 Durch die Funktionalität eines zusätzlichen Plugins ist [εm] in der Lage, eine Strukturmustersuche auf bestehenden Modellen durchzuführen. Hiermit können die Anforderungen aus Abschnitt umgesetzt werden (vgl. Abb. 3.22; vgl. auch Delfmann et al. 2009b). Zu diesem Zweck müssen die Strukturen zunächst formal definiert werden, wofür ein grafischer Editor zur Verfügung steht, der die Formalisierung als Baum realisiert. Zur Erstellung der Struktur stehen sämtliche benötigten Elemente, Operationen und Verbundoperationen zur Verfügung.288 In dem Beispiel aus Abb wird innerhalb eines EPK-Modells nach Ereignissen gesucht, denen entgegen dem Metamodell der EPK eine Entscheidungskompetenz eingeräumt wurde. Dies wird durch ein auf das Ereignis folgendes XOR und eine daran anschließende Funktion identifiziert. Das Ergebnis wird in Modellen, in denen die entsprechende Struktur identifiziert wurde, farblich markiert. Das Plugin ist nicht auf eine Sprache und auch nicht auf ein Modell festgelegt. Vielmehr Navigation Modeling Language Editor Perspective Editor Administration Shape Management Plug-in Manager Edit Save Select Connect Zoom in Zoom out Width Page Show shapes Print Connection points Grid Page setup Pattern: Model selection: Matches: Close Model New search Model Selection Model Modeling View Modeling Environment Pattern Matching [em] Structural Pattern Matching Pattern selection Search Language: EPC Language: EPC Language: EPC Language: EPC Search Cancel Connection Abb. 3.22: Anwendung des Pattern-Plugins in [εm] 288 Vgl. Delfmann et al. 2009a (Kapitel 15).

104 3 Erweiterung des Supply Chain Operations Reference-Modells 89 können sämtliche Modelle einer Sprache, für die eine Struktur definiert wurde, durchsucht werden. Hierdurch kann die Modellqualität durch die Identifizierung typischer struktureller Fehler erhöht, und Strukturen, die sich zur Modellintegration unterschiedlicher Modelle eignen, erkannt werden. Für das SCOR-Modell bedeutet dies, dass bei einer verteilten Modellierung mit mehreren Nutzern einerseits die Konsistenz der Modelle gewahrt bleibt, andererseits die Erweiterung in konsolidierten Modellen resultieren kann, die ähnliche Realweltobjekte darstellen. Letztlich ist [εm] in der Lage, Modellelemente mit Attributen zu versehen und Modelle in ein proprietäres XML-Format zu exportieren, sodass eine Konfiguration durch ein externes Werkzeug, wie sie in Abschnitt vorgestellt wurde, möglich ist. Für diesen Schritt wurde wiederum in einem Projektseminar das Konfigurationsprogramm adapt(x) entwickelt, das den oben beschriebenen Prozess der externen Konfiguration unterstützt (vgl. Abb. 3.23). Sowohl für ARIS von der IDS- Scheer AG also auch für das Exportformat von Microsoft Visio wurden XSLT-Dateien entwickelt, die eine Überführung der jeweiligen AML- und VSD-Datei in CML und zurück ermöglicht. In adapt(x) selbst werden Konfigurationsregeln angelegt, denen dann die entsprechenden Konfigurationsmechanismen zuzuordnen sind. Anschließend können die Konfigurationsregeln wiederum Abb. 3.23: Screenshot: Konfiguration mit adapt(x)

105 3 Erweiterung des Supply Chain Operations Reference-Modells 90 Perspektiven oder, für den Fall dass dies vorgesehen ist, Unternehmensmerkmalen zugeordnet werden. Das Modell wird dann durch die Auswahl der gewünschten Unternehmensmerkmale und Perspektiven konfiguriert. Der Prozess wird hierbei dokumentiert, sodass ein Adaptions- Controlling möglich ist.289 Die in den Attributen gespeicherten Konfigurationsparameter und deren Ausprägungen werden von der Software in einer Datenbank gespeichert, sodass die Erstellung von Dependenzen zwischen den Einträgen hergestellt werden können. Werden diese typisiert, können Taxonomien und Ontologien für Konfigurationsparameter und Konfigurationsparameterausprägungen im Sinne der Abschnitte und realisiert werden. Für die Unterstützung des Kopplungsansatzes wurde im Rahmen des BMBF-Forschungsprojekts FlexNet die Lösung FlexNet Architect entwickelt,290 dessen originärer Gegenstand [...] eine webbasierte Anwendung zur Modellierung hybrider Wertschöpfungsnetzwerke darstellt.291 Obwohl die ursprüngliche Intention der Software die Kopplung von Funktionsbereichen von Produzenten und Dienstleistern durch standardisierte Bausteine ist, kann die Software verwendet werden, um Modellelemente von Referenzmodellen darzustellen und grafisch über Bausteine im Sinne des Abschnitts zu verknüpfen. 289 Hierbei handelt es sich um die Analyse aufgrund von gewählten Unternehmensmerkmalen und Perspektiven entfernter Modellelemente. Dies kann darüber Aufschluss geben, welche Modellbereiche für welche Nutzer relevant sind Informationen, die für die Weiterentwicklung des jeweilige Modells geeignet sind. 290 Vgl. European Research Center for Information Systems 2010a. 291 Vgl. European Research Center for Information Systems 2010b.

106 4 Zusammenfassung und weiterführender Forschungsbedarf 4.1 Diskussion der Forschungsfragen Durch die in dieser Arbeit verwendeten Publikationen können die aus der Problemstellung der Arbeit abgeleiteten Forschungsfragen beantwortet werden. Die entwickelten Konzepte können nicht nur bei der verteilten Entwicklung des SCOR-Modells unterstützend wirken, sondern erweitern domänen- und modellunabhängig den Artefaktbestand der Referenzmodellierungsforschung. Ausgangspunkt für die Entwicklung der Konzepte war die Vermutung, dass sich das Supply Chain Council mit dem von ihm entwickelten Supply Chain Operations Reference-Modell in dem in der Wirtschaftsinformatikforschung bekannten Dilemma der Referenzmodellierung befindet. Um diese Vermutung zu stützen, wurden unterschiedliche empirische Verfahren verwendet, um die erste Forschungsfrage (FF) zu beantworten (FA): FF1 Ist es wie vom SCC propagiert möglich, mit dem SCOR-Modell, wie es sich derzeit darstellt, jede Supply Chain den Anforderungen der Anwender entsprechend darzustellen? In Publikation 1 (Kapitel 5 Becker, Knackstedt und Stein 2007) wurde sowohl eine explorative Umfrage unter Nutzern des SCOR-Modells sowie eine Literaturanalyse von Beiträgen verschiedener Wirtschaftsinformatik-Konferenzen der letzten Jahre durchgeführt. Zusätzlich wurden 53 der 163 zu diesem Zeitpunkt vom SCC zur Verfügung gestellten Anwenderberichte ausgewertet. Diese erste Analyse von Anwenderberichten wurde in Publikation 5 (Kapitel 10 Knackstedt, Stein und Becker 2010) auf die vollständige Anzahl von derzeit (01/2010) 182 erhöht. Die Erhebungen ergaben folgende Antwort auf die erste Forschungsfrage: FA1 Es ist festzustellen, dass das SCOR-Modell in seinem originären Zustand nicht in der Lage ist, jede Supply Chain den Anforderungen der Anwender entsprechend darzustellen. Um die Anforderungen der Anwender bedienen zu können, müssen die von ihnen gewünschten Erweiterungen in das SCOR-Modell eingearbeitet werden. Das Supply Chain Council steht diesem 91

107 4 Zusammenfassung und weiterführender Forschungsbedarf 92 Vorgehen skeptisch gegenüber, da eine höhere Detaillierung das Modell einerseits unübersichtlicher macht und andererseits den Kreis der potenziellen Anwender verkleinert. Aus diesem Grund lautete die zweite Forschungsfrage: FF2 Können die Methoden der konfigurativen Referenzmodellierung sinnvoll auf das SCOR- Modell angewendet werden, um einen von Anwendern gewünschten höheren Spezifizierungsgrad zu erreichen, ohne jedoch den Adressatenkreis einzuschränken? In den Publikationen 5 (Kapitel 9 Knackstedt, Stein und Becker 2009) und 6 (Kapitel 10 Knackstedt, Stein und Becker 2010) wurde die Übertragung der Konzepte der konfigurativen Referenzmodellierung auf das SCOR-Modell vorgestellt, die auf einem Metamodell beruhen, das eine konsistente Konfiguration erlaubt. Durch die Konfiguration kann das SCOR-Modell bei erweitertem Umfang zielgruppenspezifischer angepasst werden. Der erweiterte Umfang ermöglicht vermutlich eine Ausdehnung des Adressatenkreises. Die Publikationen 2 (Kapitel 6 Knackstedt und Stein 2007) und 3 (Kapitel 7 Becker et al. 2008) fügen ergänzende Konzepte hinzu. FA2 Die Methoden der konfigurativen Referenzmodellierung können sinnvoll auf das SCOR- Modell angewendet werden, sodass durch die Erweiterung um zusätzliche Elemente ein größerer Adressatenkreis angesprochen werden kann und gleichzeitig durch die Konfiguration zielgruppenspezifische Varianten gebildet werden können. Das SCC argumentiert in seinen Veröffentlichungen, dass verschiedene Unternehmens- oder SCM-Bereiche explizit nicht in das SCOR-Modell aufgenommen werden, da für diese andere, kompetentere Institutionen existieren. Tatsächlich gibt es verschiedene Referenzmodelle, die für solche Bereiche geeignet sind. Eine gemeinsame Nutzung in Verbindung mit dem SCOR-Modell könnte sich als vorteilhaft erweisen, sodass die dritte Forschungsfrage lautete: FF3 Wie können Informationen anderer Referenzmodelle mit denen des SCOR-Modells verknüpft werden? In den Publikationen 5 (Kapitel 9 Knackstedt, Stein und Becker 2009) und 6 (Kapitel 10 Knackstedt, Stein und Becker 2010) wurde ein Konzept vorgestellt, wie existierende, im groben Schema des SCOR-Modells verfügbare Referenzmodelle (bspw. DCOR, CCOR oder IRM) gekoppelt werden können. Dieses beruht auf der Verwendung von Koordinationsbausteinen, die zwischen den jeweiligen Modellelementen positioniert werden und so die Informationsflüsse und Abläufe regeln.

108 4 Zusammenfassung und weiterführender Forschungsbedarf 93 FA3 Durch den Einsatz von Koordinationsbausteinen zwischen geeigneten Elementen der Referenzmodelle können diese miteinander gekoppelt werden. Durch die Kopplung können die Modelle gemeinsam genutzt werden. Das SCC gibt selbst wenig Informationen über den Anwendungsprozess des SCOR-Modells. Diese werden in der Hauptsache durch Seminare oder bspw. das von Bolstorff, Rosenbaum und Poluha veröffentlichte Buch Spitzenleistungen im Supply Chain Management. Ein Praxishandbuch zur Optimierung mit SCOR vermittelt (Bolstorff, Rosenbaum und Poluha 2008). Hierbei werden naturgemäß die in dieser Arbeit vorgestellten Konzepte nicht berücksichtigt, sodass das Vorgehensmodell zur Anwendung des SCOR-Modells angepasst werden muss. Somit lautete die vierte Forschungsfrage: FF4 Wie muss das Vorgehensmodell zur SCOR-Implementierung angepasst werden, um die vorgestellten Methoden zu unterstützen? In Publikation 6 (Kapitel 10 Knackstedt, Stein und Becker 2010) wurde ein Konzept vorgestellt, wie das Vorgehensmodell in Bezug auf die Anwendung von Konfigurations- und Kopplungsmechanismen angepasst werden muss. FA4 Vor der eigentlichen Einführung des SCOR-Modells in einem Unternehmen müssen weitere Referenzmodelle identifiziert werden, die für eine Kopplung in Frage kommen. Zusätzlich müssen die Konfigurationsparameter und deren Ausprägungen gewählt werden, um das SCOR-Modell projektspezifisch zu konfigurieren. Das SCC selbst wird nicht in der Lage sein, die zusätzlich benötigten, von den Mitgliedern geforderten Informationen zu erheben und in das Referenzmodell einzuarbeiten. Aus diesem Grund müssen Konzepte zur Verfügung gestellt werden, die die Qualität der durch die Benutzer eingestellten Informationen sicherstellt. Hieraus leitete sich die fünfte Forschungsfrage ab: FF5 Welche Konzepte sind erforderlich, um eine aktive, verteilte Beteiligung der Mitglieder des SCC am SCOR-Modell zu ermöglichen und dessen Konsistenz im Sinne des SCC zu sichern? In den Publikationen 8 11 (Kapitel 12 15; Becker et al. 2009a; Delfmann et al. 2009b; Becker et al. 2010a; Delfmann et al. 2009a) wurden Verfahren vorgestellt, wie die syntaktische und sprachliche Vereinheitlichung von verteilt entwickelten Modellen unterstützt werden kann sowie zu gestalten und durchzuführen ist.

109 4 Zusammenfassung und weiterführender Forschungsbedarf 94 FA5 Die in dieser Arbeit vorgestellten Konzepte gewährleisten bei verteilt erstellten Modellen die Konsistenz der Sprache sowie die der Modellstruktur, um die Vergleichbarkeit der Modelle zu gewährleisten. Die Konfiguration von Referenzmodellen setzt Kenntnisse über die hinterlegten Konfigurationsparameter und deren Konfigurationsparameterausprägungen voraus. Es kann vorkommen und ist auch wahrscheinlich, dass zwischen den Parametern und deren Ausprägungen Abhängigkeiten bestehen. Bei der verteilten Entwicklung und Nutzung konfigurierbarer Modelle muss hierauf Rücksicht genommen werden, sodass die sechste Forschungsfrage lautet: FF6 Wie können die Methoden der konfigurativen Referenzmodellierung an die Erfordernisse der verteilten Modellierung angepasst werden? Im einfachsten Fall kann es sich bei den Abhängigkeiten um ist Instanz von-, ist abhängig vonoder schließt aus-beziehungen handeln. Diese Abhängigkeiten können in Form von Taxonomien und / oder Ontologien abgebildet werden, sodass der Nutzer bei der Auswahl der Parameter automatisch geführt wird und keine Ausprägungen wählen kann, die zu einem inkonsistenten Modell führen. Diese Konzepte wurden in den Publikationen 2 (Kapitel 6; Knackstedt und Stein 2007) und 3 (Kapitel 7; Becker et al. 2008) entwickelt und vorgestellt. FA6 Damit eine konsistente Konfiguration auch ohne Kenntnis von Abhängigkeiten zwischen den Konfigurationsparametern und deren Ausprägungen stattfinden kann, müssen diese über Taxonomien bzw. Ontologien expliziert und unter Umständen für die entsprechenden Software-Werkzeuge verfügbar gemacht werden. Die vorgestellten Konzepte erfordern zumindest den Einsatz von Modellierungswerkzeugen, die eine Konfiguration im Sinne der hier vorgestellten Methoden unterstützen. Weiterhin müssen Techniken genutzt werden, die geeignet sind, integrationswürdige und -fähige Informationen, die bei SCC-Mitgliedern vorliegen, als Bestandteile des SCOR-Modells zu integrieren. Somit lautet die siebte Forschungsfrage: FF7 Existieren Werkzeuge und Standards, die genutzt werden können, um die aus den oben angeführten Forschungsfragen abgeleiteten Anforderungen zu unterstützen? Die in den Publikationen zur Veranschaulichung verwendeten Werkzeuge unterstützen die Konzepte, die in dieser Arbeit entwickelt wurden. Grundsätzlich wird ein Modellierungswerkzeug benötigt, das in der Lage ist, das verteilte Arbeiten an Modellen zu ermöglichen. Weiterhin müssen die in den Kapiteln vorgestellten Konzepte unterstützt werden. Dies wird durch das

110 4 Zusammenfassung und weiterführender Forschungsbedarf 95 Metamodellierungswerkzeug [εm] geboten, das in den folgenden Publikationen zur Illustration verwendet wird: Becker et al. 2009a; Delfmann et al. 2009b; Becker et al. 2010a; Delfmann et al. 2009a. Wenn kein eigenes Programm zur Konfiguration verfügbar ist, kann durch den Export von konfigurierbaren Modellen eine Konfiguration in einem externen Werkzeug vorgenommen werden, wie es in Abschnitt vorgestellt und in Publikation 4 zur Evaluation verwendet wurde. In Publikation 7 (Kapitel 11; Janiesch und Stein 2007) wurde ein Vorgehensmodell vorgestellt, das die Berücksichtigung von verschiedenen Standards bei der Überführung von einem situativen Modell zu einem Referenzmodell(-bestandteil) berücksichtigt. Hierdurch, und durch die Berücksichtigung der in den Kapiteln vorgestellten Konzepten kann davon ausgegangen werden, dass die Akzeptanz der Modelle bei anderen Anwendern erhöht wird. FA7 Es existieren Werkzeuge, die zu diesem Zweck entwickelt wurden, sowie Standards, die die aus den oben angeführten Forschungsfragen abgeleiteten Anforderungen unterstützen. 4.2 Weiterer Forschungs- und Handlungsbedarf Die Ergebnisse dieser Arbeit bietet Konzepte, die zur Unterstützung der Erweiterung des SCOR- Modells genutzt werden können. In Bezug auf die Konzepte der Konfiguration ist vor allem die Erstellung einer möglichst vollständigen Definition von Konfigurationsparameter und deren Ausprägungen im Bereich des SCM im Allgemeinen und in Bezug auf das SCOR-Modell im Speziellen. Folgenden Fragestellungen können in diesem Zusammenhang von Bedeutung sein: Welche Typen von Supply Chains, die für das SCOR-Modell relevant sind, existieren? Welche Konfigurationsparameter und welche Konfigurationsparameterausprägungen charakterisieren diese Typen? Bestehen zwischen den Konfigurationsparametern und deren Ausprägungen Abhängigkeiten? Existieren neben den ist abhängig von- bzw. schließt aus-bedingungen noch weitere Abhängigkeitstypen? Durch welche Elemente und Beziehungen kann eine SCM-Ontologie definiert werden? Die Beantwortung dieser Fragen, deren Behandlung durch empirische Methoden wie Interviews und Umfragen erfolgen sollte, ermöglicht eine klarere Taxonomie von Supply Chains und eine detailliertere Charakterisierung. Weiterhin können bestehende konfigurierbare Modelle noch spezifischer auf konkrete Anwendungskontexte vorbereitet werden. Vorausgesetzt, dass das SCC die Konzepte umsetzt, ist zu untersuchen, welche Anreizsysteme für den Wissensträger innerhalb einer Unternehmung bestehen, sich an der Entwicklung eines

111 4 Zusammenfassung und weiterführender Forschungsbedarf 96 Referenzmodells zu beteiligen. Eine Vielzahl von Forschungsfragen auf diesem Gebiet wurde bereits von den Initiatoren der Open Model Initiative formuliert.292 Durch die Strukturanalogie der parallel vom SCC entwickelten CCOR- und DCOR-Modelle können einerseits Wege gesucht werden, wie die Methoden der konfigurativen Referenzmodellierung auf diese angewendet, und ob sie aufgrund des nahezu mit dem SCOR-Metamodell identischen Metamodells mit den in dieser Arbeit vorgestellten Konzepten erweitert werden können. Andererseits bieten sie aus den gleichen Gründen eine gute Voraussetzung, den Kopplungsansatz prototypisch umzusetzen. Weiter bieten sich in Bezug auf den Kopplungsansatz aus betriebswirtschaftlicher Sicht Potenziale zur Definition von Kopplungsbausteinen, die zwischen dem SCOR-Modell und anderen Modellen eingesetzt werden können. Hierbei können Methoden der Koordinationstheorie293 zur Beschreibung von Koordinationsmechanismen (Informations- und Datenaustausch), die zur Kopplung zweier Bausteine und der Definition des koordinierenden Bausteins benötigt werden, zum Einsatz kommen. Weiterhin ist zu fragen, welche Referenzmodelle von Unternehmen derzeit eingesetzt werden, um eine Priorisierung der für die Kopplung in Frage kommenden zu erreichen. Im Bereich der Durchsetzung von Bezeichnungskonventionen ist zu untersuchen, welche Effekte das Vorschreiben der Bezeichnungen auf den Modellierer hat, unter der Voraussetzung und Annahme, dass Modellierung als kreativer Akt gesehen werden kann, der möglichst wenig gestört werden soll.294 Weiterhin ist zu überlegen, wie die vorgestellten Konzepte in Bezug auf den Konfigurationsmechanismus der Bezeichnungsvariation genutzt werden können, um bspw. ein auf die Unternehmensterminologie angepasstes SCOR-Modell zu konfigurieren. Der Aufbau von Strukturmustern setzt derzeit gute Kenntnisse der Mengenlehre sowie ausgeprägtes formales Verständnis voraus. Für die Erstellung von Strukturmustern werden also Wege gesucht, die diese Aufgabe vereinfachen und bspw. durch grafische Unterstützung wie z. B. das Modellieren des Musters unterstützen. In dieser Arbeit wurden verschiedene Werkzeuge vorgestellt, die jeweils einzelne Konzepte umsetzen. Eine gegenseitige Verknüpfung ist zwar möglich, eine Integration wäre aber wünschenswert. Dies bedeutet, dass die Ergebnisse der oben motivierten weiterführenden Forschungsfragen in eine einzelne Lösung integriert werden, die sämtliche Konzepte unterstützt. 292 Vgl. Frank, Strecker und Koch 2007b. 293 Vgl. Crowston, Rubleske und Howison 2006; Malone et al Unter Umständen befindet der Modellierer sich bei dieser Tätigkeit in einem Flow. Vgl. bspw. Snyder und López 2005, S. 90 f.; Csíkszentmihályi 1991.

112 Teil B

113 Dagobert Duck Johann BB Dagobert Duck Johann Dagobert Duck BB Dagobert Duck Wer sind diese Rüpel, die in mein Privatkontor eindringen, ohne jede Voranmeldung? Die Arbeiter von der BB. Sie wollen den alten Telefonapparat gegen ein neues Modell auswechseln. So ist s. Wir installieren Ihnen anstelle Ihres alten Gerümpels den modernsten Apparat, den s gibt! Wie??? Halt! Keiner rührt mir meinen guten alten Apparat an! Schließlich dient er mir seit dem Jahre 1907[...]. Nie würde ich mich von ihm trennen! [...] Die liefern Ihnen das Ding gratis per Werbegeschenk! Gratis? Bestimmt! Welche Farbe darf s denn sein? Rot? Elfenbein? Vergoldet? Vergoldet! Vergoldet! Ich glaube, ich komme mit der BB ins Geschäft! Walt Disneys Lustiges Taschenbuch 19, Neuauflage, S. 17 f.

114