Bachelorarbeit. für die Prüfung zum. Bachelor of Science. des Studiengangs Wirtschaftsinformatik Software-Engineering. an der

Transkript

1 Bachelorarbeit für die Prüfung zum Bachelor of Science des Studiengangs Wirtschaftsinformatik Software-Engineering an der Dualen Hochschule Baden-Württemberg Lörrach Frederik Frey 14. September 2015 Kurs Ausbildungsfirma Betreuer der Ausbildungsfirma Wissenschaftlicher Betreuer WWI12a Endress+Hauser InfoServe GmbH+Co. KG, Weil am Rhein Frau Christine Eichkorn Herr Prof. Gerhard Staib

2 Ehrenwörtliche Erklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit mit dem Thema selbstständig und ohne Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer anderen Prüfung noch nicht vorgelegt worden. Weil am Rhein, 11. September 2015 Frederik Frey Hinweis zum Umfang der Arbeit Der Textteil der vorliegenden Arbeit - beginnend mit der Einleitung bis ausschließlich Quellenverzeichnis - umfasst 60 Seiten. I

3 Freigabe der Arbeit Die vorliegende Arbeit wurde durch das Ausbildungsunternehmen Endress+Hauser InfoServe GmbH+Co. KG, Weil am Rhein inhaltlich geprüft und zur Vorlage an der DHBW Lörrach, Studiengang Wirtschaftsinformatik Software- Engineering, freigegeben. Weil am Rhein, 11. September 2015 Christine Eichkorn II

4 Abstract Jeder hat ihn schon einmal bedient und seine Funktionen zu schätzen gewusst. Ob beim Autokauf oder der Zusammenstellung der neuen Küche: ein Konfigurator. Ein Konfigurator bietet die Möglichkeit mit wenigen Klicks von einer Vorstellung zu einem fertig modellierten Produkt zu gelangen. Er soll bei der Wahl der richtigen Konfiguration unterstützen und als Ergebnis eine vollkommen eindeutige Spezifikation präsentieren, auf deren Basis die Produktion sofort beginnen kann. Als global agierender Anbieter für Messgeräte setzt sich Endress+Hauser intensiv mit der Konfiguration von Produkten auseinander. In den letzten Jahren wurden dabei große Fortschritte erzielt und mit dem Release des neuen Endress+Hauser Konfigurators 6.0 ist nun eine Version verfügbar, die den SAP Konfigurator, der die letzten Jahre hauptsächlich genutzt wurde, abgelöst hat. Trotzdem wird das SAP System weiter genutzt, da es komplexe Berechnungen, aufbauend auf dem eingepflegten Beziehungswissen, erlaubt. Nur so kann die Produzierbarkeit der Produkte gewährleistet werden. Das Ziel dieser Arbeit ist, dieses Beziehungswissen auch im Endress+Hauser Konfigurator nutzen zu können. Als IT-Dienstleister der Endress+Hauser Gruppe ist es die Aufgabe von Endress+Hauser InfoServe eine Lösung für diese Problematik zu finden. Nun soll betrachtet werden, in wie weit es möglich ist, das bereits im SAP vorhandene Wissen in den Endress+Hauser Konfigurator 6.0 zu integrieren. Ein erster Test verlief erfolgreich, denn es war möglich aus dem Endress+Hauser Konfigurator 6.0 eine Validierung der aktuellen Konfiguration mit Hilfe des SAP Beziehungswissen durchzuführen. Somit ist es nun möglich, bereits während der Konfiguration eines Produkts die technische Umsetzbarkeit zu überprüfen. III

5 Inhaltsverzeichnis Ehrenwörtliche Erklärung Hinweis zum Umfang der Arbeit Freigabe der Arbeit Abstract Inhaltsverzeichnis Abkürzungsverzeichnis Tabellenverzeichnis Abbildungsverzeichnis I I II III IV VI VII VIII 1 Variantenkonfiguration Die Komplexitäten Die Herausforderungen Das Bestreben Der Ablauf 4 2 Stammdaten Endress+Hauser Endress+Hauser Product Center Endress+Hauser Sales Center Endress+Hauser InfoServe Der Endress+Hauser Konfigurator Varianten Definition des Variantenbegriffs Varianten und Standard Variantenkonfiguration Beziehungswissen Methoden Experteninterview Risikoanalyse 22 IV

6 2.6.3 Aufwandsschätzung Business Process Model and Notation Netzplantechnik 27 3 Der Wandel Vergangenheit der Zukunft Optimierungspotenzial Zukunft der Vergangenheit 37 4 Evaluation Allgemeines Ansätze Ansatz Eins Ansatz Zwei Ansatz Drei Ansatz Vier Aufwandsschätzung Ansatz Eins Ansatz Zwei Ansatz Drei Ansatz Vier Auswahl 48 5 Das Projekt Projektablauf Entwicklung Der neue Ablauf 54 6 Zurück in die Zukunft Vergangenheit Zukunft 58 Quellenverzeichnis Anhang IX XIII V

7 Abkürzungsverzeichnis CER CRM ERP FAZ FEZ FP GP PEA SAZ SEZ SBO TSP WBS Common Equipment Record Customer Relationship Management Enterprise Resource Planning Frühste Anfang Zeit Frühste Ende Zeit Freier Puffer Gesamtpuffer Project Engineering Assisten Späteste Anfang Zeit Späteste Ende Zeit SAP Business One Technisches Sonderprodukt Work Breakdown Structure VI

8 Tabellenverzeichnis Tabelle 1: Top 10 Automobilhersteller auf dem deutschen Markt, nach Anzahl der Modellvarianten... 1 Tabelle 2 - Aufwandsberechnung Ansatz Tabelle 3 - Risikobewertung Ansatz Tabelle 4 - Aufwandsschätzung Ansatz Tabelle 5 - Risikobewertung Ansatz Tabelle 6 - Legende Netzplan VII

9 Abbildungsverzeichnis Abbildung 1 - Endress+Hauser Konfigurator Abbildung 2 - Prinzipielles Vorgehen bei der Variantenkonfiguration Abbildung 3 Beispiel für einen gerichteten, endlichen und kreisfreien Graphen Abbildung 4 - Ausgangsstatus einer Produktkonfiguration Abbildung 5 - Spezifizierung von frei wählbaren Merkmalswerten Abbildung 6 - Fehlerhafte Konfiguration Abbildung 7 - Vollständige Konfiguration Abbildung 8 - Bestellprozess via Online Shop Abbildung 9 - Omnigrad M TR Abbildung 10 - Aufruf eines SAP Funktionsbausteins aus dem E+H Konfigurator Abbildung 11 - Netzplan zum Projektablauf Abbildung 12 - Validierung der Konfiguration durch SAP Beziehungswissen Abbildung 13 - Technischer Ablauf der Konfiguration Abbildung 14 - Neuer Bestellprozess via Online Shop Abbildung 15 - Ausschnitt des grafischen Konfigurators des Automobilherstellers Tesla Abbildung 16 - Idee des mobilen Endress+Hauser Konfigurators VIII

10 1 Variantenkonfiguration 1.1 Die Komplexitäten Die Vielfältigkeit von Produkten und deren Fertigung exakt nach Kundenwunsch sollte in jedem produzierenden Unternehmen gegeben sein. In der folgenden Tabelle ist zu sehen, dass Produkte nicht nur in verschiedene Modelle eingeteilt werden, sondern dass von jedem Modell auch noch zahlreiche Modellvarianten existieren und umgesetzt werden. Das heißt, der Kunde entscheidet sich für ein Modell und hat anschließend die Möglichkeit aus verschiedensten Modellvarianten auszuwählen. Diese Vielfalt ist es, die es dem Hersteller ermöglicht individuell auf Kundenwünsche einzugehen. Allerdings bringt diese Vielfalt auch einige Herausforderungen mit sich. Beispielsweise fallen Anfertigungen von Spezialteilen an, da die meisten Modellvarianten nicht auf Lager gehalten sondern In-Time produziert oder eingekauft werden. Dieses Konzept sorgt für die hohe Priorität der guten Kommunikation zwischen Vertrieb, Einkauf, Produktion und Logistik. Modelle Modellvarianten Ø Varianten je Modell BMW Volkswagen Opel Audi Mercedes Ford Skoda Volvo Seat Citroen Tabelle 1: Top 10 Automobilhersteller auf dem deutschen Markt, nach Anzahl der Modellvarianten 1 1 Eigendarstellung nach, (MeinAuto.de & JATO, 2013) 1

11 Eine weitere Schwierigkeit sind die sich gegenseitig ausschließenden Modellvarianten. In Bezug auf Tabelle 1 bedeutet dies, dass beispielsweise ein Cabriolet nicht mit einem Schiebedach kombiniert werden kann. Trotzdem sind Cabriolet und Schiebedach beide Varianten der Kategorie Fahrzeugart bzw. Dach. Wird Beispielhaft der Prozess der Autokäufe im Jahr 2015 analysiert, so fällt auf, dass der Kunde nur in einen kleinen Teil des Fertigungsprozesses involviert ist und zwar indem er selbstständig die Konfiguration seines Produktes übernimmt. Dies geschieht mit Hilfe eines Konfigurators, der meist auf der Website des Verkäufers zur Verfügung gestellt wird. Hier werden nacheinander Modell und Ausführungen ausgewählt und an die Kundenwünsche angepasst. Die Auswahl der Modellvarianten liegt hierbei alleine beim Kunden, der meistens nicht über die sich gegenseitig ausschließenden Varianten informiert ist. Diese Information sollte daher, genauso wie eventuelle Lieferverzögerungen bei bestimmen Variantenkombinationen, vom Konfigurator bereitgestellt und dem Kunden transparent dargestellt werden. Außerdem ist es für den Kunden hilfreich, sollte die von ihm gewünschte Kombination nicht umsetzbar sein, wenn der Konfigurator alternative Vorschläge zur Verfügung stellen würde. Gemäß einer Umfrage auf der Website eines repräsentativen Autohändlers wird die Möglichkeit zur komplett eigenständigen Konfiguration eines Autos mit 14% als sehr wichtig eingestuft. 2 Hat sich der Kunde nun für eine Konfiguration entschieden, wird diese dem Autohändler übermittelt. Dieser überprüft nun die Konfiguration und spezifiziert mit Hilfe eines weiteren Konfigurators die Details, die der Kunde nicht anlegen konnte. Als global agierender Anbieter von Messgeräten ist auch Endress+Hauser auch im Bereich der Konfiguration aktiv. So haben Kunden die Möglichkeit die gewünschten Produkte vor der Bestellung individuell zu konfigurieren. Dieser Konfigurator, der im Online Shop verfügbar ist, wird außerdem noch für den Vertrieb und in der Reparatur eingesetzt. 2 Vgl. (Capgemini, 2010) 2

12 1.2 Die Herausforderungen Mit fast konfigurierbaren Produkten 3 hat Endress+Hauser eine große Produktpalette. Diese Produkte besitzen insgesamt Merkmale 4, welchen in der Summe Merkmalswerte zugeordnet sind. Im Durschnitt hat ein Produkt etwa neun Merkmale mit jeweils sechs Ausführungen. Damit ergeben sich mögliche Kombinationen 5 für ein Produkt. Wird diese Zahl aufsummiert, ergeben sich mehr als vier Milliarden Kombinationsmöglichkeiten 6 für alle Endress+Hauser Produkte, abzüglich der festgelegten Ausschlüsse. Bei den dargestellten Zahlen handelt es sich um Durchschnittswerte für alle Produkte der Endress+Hauser Gruppe. Um diese umfangreiche Produktlandschaft zu überblicken hat Endress+Hauser InfoServe den vorhandenen SAP Konfigurator mit einer Eigenentwicklung abgelöst. Dabei werden alle Informationen aufgearbeitet und der Kunde hat anschließend die Möglichkeit, sein gewünschtes Produkt zu bestellen. Als Datenbasis nutzt der Endress+Hauser Konfigurator die SAP Datenbanktabellen, welche er durch Webservices erhält. Wird nun ein Ausschluss entdeckt, wird dieser im Konfigurator als nicht selektierbar gekennzeichnet. Zum aktuellen Zeitpunkt nutzt der Endress+Hauser Konfigurator Endress+Hauser eigene SAP Tabellen zur Überprüfung der gewählten Konfiguration. Geplant ist eine Validierung der im Endress+Hauser Konfigurator gepflegten Konfiguration gegen das Beziehungswissen, das im SAP gepflegt wurde. Es geht dabei nicht um eine Nachentwicklung der SAP Logik, sondern ausschließlich um eine Validierung über eine Schnittstelle zum SAP. 1.3 Das Bestreben Als IT-Dienstleister für die Endress+Hauser Gruppe hat es sich Endress+Hauser InfoServe als Ziel gesetzt, eine einheitliche Konfiguration für alle Endress+Hauser 3 Vgl. (Eichkorn, 2015) 4 Vgl. (Eichkorn, 2015) 5 Vgl. (Eichkorn, 2015) 6 Vgl. (Eichkorn, 2015) 3

13 Produkte zu ermöglichen. Die so erstellten Konfigurationen sollen bereits im SC auf ihre technische Umsetzbarkeit überprüft werden können. Um dies zu erreichen, soll in einem ersten Schritt eine Machbarkeitsprüfung durchgeführt werden, um zu testen, ob das bereits vorhandene Beziehungswissen in den Endress+Hauser Konfigurator eingebettet werden kann. Anhand eines Beispiels soll getestet werden, inwiefern eine Kommunikation zwischen Endress+Hauser Konfigurator und SAP Beziehungswissen möglich ist. In dieser Arbeit soll geklärt werden, welche Änderungen am momentan verwendeten Endress+Hauser Konfigurator vorgenommen werden müssen, um ihn an die gegebenen Bedingungen anzupassen. Im Rahmen dieser Untersuchung wird auch geklärt werden, mit welchem Aufwand und mit welchen Schwierigkeiten diese Änderungen verbunden sind und welche Alternativen denkbar wären. Sollten Aufwand und eventuell auftretende Schwierigkeiten als gering eingeschätzt werden, so wird der Konfigurator entsprechend den ermittelten Änderungen angepasst oder ein Modell zu diesen Änderungen erstellt werden. 1.4 Der Ablauf Nachdem zuerst die Komplexitäten, Herausforderungen und das Bestreben der Variantenkonfiguration in Zusammenhang mit diesem Projekt erläutert wurden, folgen nun die Grundlagen, die zum besseren Verständnis der Arbeit beitragen sollen. Diese Grundlagen beginnen mit einer Übersicht über die Endress+Hauser Gruppe mit ihren Untereinheiten Product Center, Sales Center und InfoServe, um den Leser darzustellen, in welchem Umfeld das Projekt erarbeitet wurde. Der Endress+Hauser Konfigurator 6.0, welcher der Gegenstand dieser Arbeit ist, wird nachfolgend beschrieben. Nun folgen Begriffserläuterungen und Definitionen zum Thema Varianten und Standard. Diese Begriffe klar festzulegen und einzugrenzen ist unabdingbar für den weiteren Verlauf der Arbeit, da auf ihnen die Abschnitte Variantenkonfiguration und Beziehungswissen aufbauen. 4

14 Um die Grundlagen abzuschließen werden die Methoden, die zur Erstellung der Arbeit verwendet wurden, aufgezählt und beschrieben. Dazu gehören Experteninterview, Risikoanalyse, Aufwandsschätzung und Business Process Model and Notation. Der aktuelle Stand bezüglich des Systems aus Endress+Hauser Konfigurator und SAP Beziehungswissen wird anschließend in Form der Ist-Analyse dargestellt und analysiert, um im Anschluss die damit einhergehenden Probleme und das daraus resultierende Soll-Konzept vorzustellen. Mit welchen Ansätzen dieses umgesetzt werden kann und welche Vor- und Nachteile die jeweiligen Ansätze mit sich bringen, wird nun in einer Übersicht dargestellt. Nach der Auswahl eines Ansatzes wird dieser im Entwicklungsteil der Arbeit theoretisch umgesetzt und ein Projektplan erstellt. Das letzte Kapitel fasst die oben genannten Schritte zusammen und zieht Schlüsse, um dann einen Ausblick zu wagen. 5

15 Stammdaten 2 Stammdaten 2.1 Endress+Hauser Die Endress+Hauser Gruppe wurde 1953 gegründet und hat ihren Hauptsitz in Reinach. 7 Die mehr als Mitarbeiter verteilen sich auf Standorte in 46 Ländern, wobei der Umsatz der Gruppe bei etwa 2 Milliarden Euro liegt. 8 Heute gehört Endress+Hauser mit der hohen Vielfalt der verschiedenen Automatisierungslösungen und Dienstleistungen zu den weltweit führenden Automatisierungsanbietern. 9 Unterstützt wird dieses Netzwerk vom Vertrieb, den Sales Centern (SC), und der Produktion, den Product Center (PC), sowie durch firmeneigene Support Unternehmen zu denen auch InfoServe gehört Endress+Hauser Product Center In den PCs werden die Endress+Hauser Messgeräte entwickelt und produziert. Dieser Produktionsverlauf beinhaltet zudem Forschung, Automatisierung und die Trennung nach den einzelnen Arbeitsgebieten. 10 Eines der Endress+Hauser PCs, das PC Wetzer, stellt das Kompetenzzentrum für Temperaturmesstechnik, Systemkomponenten und Energielösungen dar. Diese und folgende Informationen nutzen als Quelle die Firmenpräsentation des PC Wetzers. 11 Der Fokus in Bezug auf die industrielle Anwendung liegt bei der Lebensmittel-, Chemie-, Petrochemie-, Grundstoff-, Metall- und Life Science Industrie. Zudem werden Wasser und Abwasser, Öl und Gas sowie erneuerbare Energien beliefert. Die Produkte werden exakt nach Kundenwunsch produziert und montiert. Das PC Wetzer zählt 652 Mitarbeiter und Mitarbeiterinnen und wuchs um sieben Prozent im vergangenen Jahr. 7 Vgl. (Endress+Hauser, 2015), S Vgl. (Endress+Hauser Gruppe, 2014) 9 Vgl. (Endress+Hauser, 2015), S Vgl. (Endress+Hauser, 2015) 11 Vgl. (Endress+Hauser Wetzer, 2014), F. 1 6

16 Stammdaten Neue Innovationen sind beispielsweise das hygienische Thermometer oder der Prozessanzeiger. Neben der Herstellung der oben genannten Techniken ist die Kalibrierung der Geräte ein weiterer Kernprozess des PC Wetzer Endress+Hauser Sales Center In den SCs werden die Endress+Hauser Messgeräte, Dienstleistungen, Softwareprodukte und Automatisierungslösungen verkauft. 12 Um einen ständigen Austausch zwischen SC und PC zu ermöglichen, sind beide Organisationseinheiten eng verbunden Endress+Hauser InfoServe Um die oben beschriebenen Kernprozesse in der Endress+Hauser Gruppe zu unterstützen, bietet Endress+Hauser InfoServe die entsprechende IT Infrastruktur und Anwendungslandschaft. 14 Die Unterstützung der Geschäftsprozesse in den PCs und SCs erfolgt über die Wartung und den Ausbau der SAP Struktur, über die Betreuung der lokalen sowie globalen Netzwerke 15, über das Betreiben eines Notfallrechenzentrums sowie eines Global Helpdesks und über das Bereitstellen von integrierten Anwendungen und (Backup-)Lösungen. 16 Neben der Unterstützung der firmeninternen Prozesse beteiligt sich InfoServe auch an den IT Lösungen für die Endkunden der Endress+Hauser Gruppe Der Endress+Hauser Konfigurator 6.0 Wer ein neues Auto kaufen möchte, stellt sich seinen Traumwagen online per Mausklick zusammen. Genauso funktioniert es mit Endress+Hauser Produkten: Der Endress+Hauser Konfigurator ermöglicht die kundenspezifische Konfiguration der Messgeräte. Welche Materialien können für welches Gerät verwendet werden? Welche Flanschanschlüsse stehen für ein bestimmtes Gerät zur Verfügung? Der 12 Vgl. (Endress+Hauser Messtechnik GmbH, 2015), S Vgl. (Endress+Hauser Messtechnik GmbH, 2015), S Vgl. (Endress+Hauser InfoServe, 2015), S Vgl. (Endress+Hauser InfoServe, 2015), S Vgl. (Endress+Hauser InfoServe, 2015), S Vgl. (Endress+Hauser InfoServe, 2015), S. 1 7

17 Stammdaten Konfigurator gestaltet jedes Produkt genau nach den Bedürfnissen des Kunden. Gleichzeitig führt das Tool eine Plausibilitätsprüfung durch und stellt damit sicher, dass Endress+Hauser das konfigurierte Messgerät tatsächlich produzieren kann. Der Endress+Hauser Konfigurator ist in vielen Prozessen der Firmengruppe im Einsatz, zum Beispiel im Vertrieb, im Service oder im Marketing. Rund Aufrufe gibt es wöchentlich. Mit dem Update auf die Version 6, in Abbildung 1 zu sehen, wird der bisher implementierte Endress+Hauser Konfigurator 5.5 für die ganze Gruppe abgelöst. Die Bedienung des Konfigurators wurde in der neuen Version deutlich vereinfacht. Dies geschah zum Beispiel durch eine erweiterte Suchfunktion und das Ausblenden nicht wählbarer Optionen. Auch die hohe Stabilität, eine deutlich bessere Fehlertoleranz aus Sicht des Nutzers und das neue Design machen das Tool für die Nutzer attraktiv. Der Konfigurator ist für unterschiedliche Systeme und Prozesse optimiert, damit läuft er überall reibungslos: im SAP ERP System, Common Equipment Record (CER), SAP Customer Relationship Management (CRM), SAP Business One (SBO), Online Shop und Project Engineering Assistant (PEA). Die ebenfalls ganz neu spezifizierte Integration der technischen Sonderprodukte (TSP) sorgt dafür, dass auch diese vollständig auf Plausibilität geprüft werden. Bereits 2012 hatte InfoServe gemeinsam mit den Schlüsselanwendern des Konfigurators damit begonnen die Anforderungen für die neue Version zusammenzutragen. Im Oktober 2014 starteten Schulungen und Tests in den Product Centern der Firmengruppe, für die die Einführung inzwischen abgeschlossen ist. Seit September 2015 ist der neue Endress+Hauser Konfigurator 6.0 flächendeckend im Einsatz. 8

18 Stammdaten Abbildung 1 - Endress+Hauser Konfigurator Der vereinfachte Ablauf bei einer Konfiguration ist wie folgt: Nach der Auswahl der spezifischen Konfiguration für das Produkt wechselt der Konfigurator zurück in die entsprechende Umgebung, aus welcher er aufgerufen wurde zurück. Anschließend wird dann zum Beispiel der Bestellvorgang fortgesetzt. 2.3 Varianten Definition des Variantenbegriffs Wird nach einer Definition für Varianten gesucht, so gibt es verschiedene Quellen, die unterschiedliche Definitionen liefern. So definiert bereits der Duden die Variante als eine leicht veränderte Form von etwas und das Deutsche Institut für Normung beschreibt Varianten als Gegenstände ähnlicher Form und/oder Funktion mit einem in der Regel hohen Anteil identischer Gruppen oder Teile 19. Dieser Definition legten bereits schon Bräutigam 20, Kaiser 21, Korreck 22, Lingnau 23 und Menge 24 ihre Theorien zu 18 Screenshot des Endress+Hauser Konfigurators (Deutsches Institut, 2002), S Vgl. (Bräutigam, 2004), S Vgl. Kaiser, 1995, S Vgl. (Korreck, 2002), S Vgl. (Lingnau, 1994), S. 23 9

19 Stammdaten Grunde. Demnach sind Varianten also Objekte, die auf der einen Seite ähnlich zueinander sind auf der anderen Seite aber mehr oder weniger deutliche Unterschiede aufweisen können. Da die oben aufgeführten Definitionen noch unscharf erscheinen, sollen im Folgenden, der Argumentationslinie von Boysen 25 folgend, zwei Leitfragen beantwortet werden, um im Anschluss eine schlüssige Definition des Variationsbegriffs aufstellen zu können. Die erste zu klärende Frage ist die nach der Art der Vergleichskriterien. Wodurch unterscheiden sich die einzelnen Objekte oder Varianten? Hier werden Merkmale benötigt, welche die Produkte charakterisieren. Wird der Variantendefinition nach Lingnau gefolgt, so entstehen Varianten bei Ähnlichkeiten in Bezug auf mindestens eines der Merkmale Geometrie, Material oder Technologie 26 oder durch eine verschiedene Anzahl der Teilkomponenten 27. Bei näherer Betrachtung fällt auf, dass diese Merkmale nicht ausreichend sind um alle möglichen Produkte und Varianten zu beschreiben. So lassen sich verschiedene Lebensmittelvarianten durch ganz andere Merkmale beschreiben, als beispielsweise Varianten eines Autos. Ein Aufzählen aller als möglich erscheinenden Produktmerkmale ist wenig sinnvoll, weshalb je nach Objekt eine Aufzählung von relevanten Merkmalen festgelegt wird. Welche Merkmale relevant sind wird objektbezogen und subjektiv bewertet. Die zweite zu bearbeitende Frage befasst sich mit dem Ausmaß der Verschiedenheit. Wie stark unterscheiden oder ähneln sich die Objekte? Wird der Anweisung von Gembrys, Heina und Rosenberg vertraut, so findet eine Feststellung des Verschiedenheitsausmaßes anhand der Ausprägung der einzelnen Merkmale statt. 28 Im Gegensatz dazu stellen Bongulieme, Kohlhase und Rapp 29 einen Bezug zu übergeordneten Eigenschaften her. Diese Eigenschaften werden durch Merkmale und Ausprägungen beschrieben 30, wobei Merkmale nur als solche gezählt 24 Vgl. (Menge, 2001), S Vgl. (Boysen, 2005), S Vgl. (Lingnau, 1994), S Vgl. (Deutsches Institut, 2002), S Vgl. (Gembrys, 1998), S.5; (Heina, 1999), S.5 sowie (Rosenberg, 1996), Sp Vgl. (Bongulielmi, 2003), S. 65 ; (Rapp, 1999), S. 26 sowie (Kohlhase, 1997), S Vgl. (Rapp, 1999), S

20 Stammdaten werden, wenn sie eine Unterscheidung der Einheiten ermöglichen. Mit Eigenschaft ist folglich im weiteren Verlauf dieser Arbeit die Ausprägung eines relevanten Merkmals gemeint. Wichtig zu erwähnen in Bezug auf das Ausmaß der Verschiedenheit ist, dass es sich bei zu großer Ähnlichkeit der Produktvarianten nicht mehr um verschiedene Produktvarianten innerhalb der gleichen Produktart handelt. 31 Eine Produktart erfasst alle Varianten eines Produkts. Folglich können Produktvarianten nur relativ zu ihrer Produktart existieren. 32 Ein möglicher Definitionsansatz für den Begriff der Variante wäre also der folgende: Alle Produkte der gleichen Produktvariante weisen die gleiche Ausprägung aller relevanten Produktmerkmale auf. Verschiedene Produktvarianten bilden zusammen eine Produktart. Diese Einteilung erfolgt sowohl subjektiv als auch relativ aus Sicht des Betrachters. Es ist nur dann zweckmäßig von einer Variante zu sprechen, wenn innerhalb der gleichen Produktart noch mindestens eine weitere Variante vorhanden ist Varianten und Standard Nach der Definition des Vereins Deutscher Ingenieure (VDI) muss für die Definition einer Variante eine Grundausführung gegeben sein. 33 Diese sogenannte Grundausführung einer Variante wird im Folgenden als Standard bezeichnet. Für den Begriff Standard gibt es, wie auch für den Begriff der Variante, verschiedene Definitionen. So wird der Standard bereits im Duden als was als mustergültig und modelhaft angesehen wird und nach dem sich anderes richtet beschrieben. Im Gabler Marketing Lexikon ist ein Standard auf die durchschnittlichen Erwartungen der Nachfrager ausgerichtet. 34 Auch hier bedarf es der Klärung einiger Fragen bevor eine Definition für den Standardbegriff gegeben werden kann. 31 Vgl. (Kohlhase, 1997), S Vgl. (Souren, 1996), S Vgl. (Verein Deutscher Ingenieure, 1978), S (Bruhn & Homburg, 2004), S

21 Stammdaten Zunächst müssen die Gründe für Standards erläutert werden. Hier sind zum einen die historischen Gründe anzuführen. Wenn beispielsweise in einer Firma über lange Zeit hinweg nur eine Produktvariante innerhalb einer Produktart existierte, so wird diese Variante als Standard gesetzt und alle weiteren Varianten bleiben normale Produktvarianten innerhalb der Produktart. Ein ähnlicher Effekt entsteht durch verschiedene Absatzmengen bzw. Umsätze der einzelnen Produktvarianten. Häufig wird die Variante als Standard beschrieben, die eine deutlich größerer Absatzmenge 35 oder einen deutlich höheren Umsatz aufweist, als alle anderen Varianten. Manchmal wird dem Käufer auch zur Vereinfachung der Verkaufstransaktion ein Standard angeboten auf Grundlage dessen der Kunde seine Produktvariante festlegen kann. Ein Beispiel ist der Kauf eines Autos, bei dem das Standardmodell an die Wünsche des Kunden angepasst wird. Standards entstehen also nicht zufällig, sondern werden von den Unternehmern als Norm vorgegeben. Ein weiterer Punkt der in Bezug auf Standards diskutiert werden muss, ist die Relation zwischen Standard und Variante. Die begriffliche Abhängigkeit wird deutlich, sobald die Definitionen von Caesar: Der Standard stellt den stückzahlstärksten Umfang innerhalb eines Variantenspektrums dar 36 und Bartuschat: Varianten als eine Abweichung vom Standard 37 betrachtet werden. Hier besteht ein klares Abgrenzungsproblem, inwiefern der Standard, da Teil eines Variantenspektrums, selbst eine Variante ist oder ob Varianten neben Standards als Abweichungen von ebendiesem existieren. In der Praxis ist es meist wenig sinnvoll, ein Standardprodukt aus einer Produktart zu identifizieren, da es meist nicht ausreichend Gründe für eine explizite Unterscheidung zwischen Standard und Variante gibt. Deshalb wird der Begriff des Standards nicht in die Definition der 35 (Korreck, 2002), S. 57 (Korreck verwendet den Begriff Basisprodukt anstelle von Standard) 36 (Caesar, 1991), S (Bartuschat, 1995), S. 6 12

22 Stammdaten Produktvariante aufgenommen sondern lediglich die Möglichkeit genannt ein Standardprodukt als musterhaften Vertreter innerhalb eines Variantenspektrums zu identifizieren. 2.4 Variantenkonfiguration Um das Prinzip der Variantenkonfiguration zu veranschaulichen wird diese im folgenden Kapitel als untergeordnetes Prinzip der Produktkonfiguration dargestellt. Als Quelle wird, wenn nicht anders angegeben Variantenkonfiguration mit SAP 38 von Uwe Bluhmöhr, Manfred Münch und Marin Ukalovic genutzt. Die Konfiguration beschränkt sich nicht nur auf Produkte sondern ist in vielen Systemen präsent. Als Konfigurationsaufgabe wird die Herausforderung eine für den Anwender individuell passende Einstellung zu finden, indem verschiedene Parameter eingestellt werden, verstanden. Beispiele für eine solche Konfigurationsaufgabe ist das Schneidern eines Maßanzugs, der passgenau auf die Wünsche des Kunden zugeschnitten ist oder der Kauf eines Autos, bei dem sich der Anwender für eine bestimmte Farbe, Ausstattung, etc. entscheiden muss. Ein stark vereinfachtes Beispiel ist das einer Schachtel, bei dem verschiedene Farben und Volumen gewählt werden können. Konfigurationsaufgaben können also in vielen verschiedenen Bereichen vertreten sein. In manchen Fällen (z.b. Autokauf, Maßanzug oder Schachtel) wird das Produkt nach den Kundenwünschen spezifiziert und die verschiedenen Parameter werden angepasst. Bei dieser Produktspezifikation geht es um die Festlegung aller an ein Produkt gestellten Anforderungen, also um die das Produkt auszeichnenden Eigenschaften, die bei dessen Bereitstellung zu beachten sind. Die Produkteigenschaften werden beispielsweise in graphischer oder textueller Form mit den spezifischen Parametern dargestellt. Werden nur einige Parameter angepasst, während andere gleich bleiben und es sich ansonsten um das gleiche Produkt handelt, so liegt, wie schon im Kapitel 2.3 erläutert, eine Produktvariante vor. Wird nun die Konfigurationsaufgabe in Zusammenhang mit der Produktkonfiguration gebracht, so entsteht daraus die folgende Definition der Produktkonfiguration: Eine 38 (Blumöhr, et al., 2013) 13

23 Stammdaten Konfigurationsaufgabe, die sich mit der Spezifikation von Produkten befasst, von denen verschiedene Varianten existieren. Bei einer Produktkonfiguration wird meist wie folgt vorgegangen: Nach dem Festlegen der Parametermenge werden die Parameterwerte definiert. Anschließend werden die Werte festgelegt, die die individuelle Produkterscheinung charakterisieren. Soll die Produktkonfiguration automatisiert werden, kommt ein sogenannter Konfigurator zum Einsatz: Also eine Software, die die Variantenkonfiguration unterstützt und dabei nach folgenden Arbeitsschritten vorgeht: Im ersten modellierenden Schritt findet eine formale Festlegung der Parameter statt: Die Erstellung eines Konfigurationsmodells. Darauf aufbauend findet die aktive Konfiguration statt, bei der die Parameterwerte entsprechend den Anwenderwünschen ausgewählt werden. Dieser Schritt der aktiven Konfiguration wird auch interaktive Konfiguration genannt. Ist der konfigurierende Schritt abgeschlossen, so startet der dritte und letzte Schritt, bei dem die ausgewählten Werte abgespeichert und eventuell graphisch dargestellt werden. Das so erhaltene Erscheinungsbild des Produktes wird als Konfigurationsergebnis bezeichnet. Abbildung 2 - Prinzipielles Vorgehen bei der Variantenkonfiguration 39 Konkret bedeutet dieser Ablauf am Beispiel des oben bereits angeschnittenen Schachtelbeispiels, dass der modellierende Schritt der ist, bei dem das konfigurierbare Produkt Schachtel in einer der Farben verfügbar sein soll. Die Werte des Merkmals Farbe werden als rot, gelb oder grün festgelegt. In der aktiven Konfiguration entscheidet sich der Anwender nun für die Farbe rot. Das Ergebnis der Konfiguration wird nun gespeichert und dem Anwender wird unter Umständen ein Bild der roten Schachtel präsentiert. 39 (Blumöhr, et al., 2013) S

24 Stammdaten Das Merkmal, als ein elementarer Konfigurationsbaustein, ist eine wichtige Variable der Konfigurationsaufgabe. Es beschreibt, dem Schachtelbeispiel folgend, die Produktoptionen, wie zum Beispiel die Farbe der Schachtel. Der Merkmalswert beschreibt die Ausprägung des Merkmals, am Beispiel der Schachtelfarbe hat das Merkmal den Wert rot. Als Werte können aber auch Längen-, Gewichts- oder Materialangaben dienen. Zwischen einzelnen Merkmalen können Abhängigkeiten auftreten. So hängt das Schachtelvolumen unter anderem von den Werten der Seitenlängen ab. Diese Abhängigkeiten werden in den Konfigurationsregeln beschrieben. Ein guter Konfigurator zeichnet sich durch eine effektive und problemgerechte Formulierung dieser Regeln aus. Auf Abhängigkeiten wird im folgenden Kapitel dieser Arbeit genauer eingegangen. Ein weiterer Teilaspekt der Produktkonfiguration ist der der Mass Customization. Dieser Ausdruck setzt sich aus den englischen Begriffen Mass Production und individual Customization zusammen. Der Begriff soll den enormen Aufwand einer formalen Modellierung mit der hohen Verbreitung von konfigurierbaren Produkten rechtfertigen. Durch die ausreichend häufige Lösung einer Konfigurationsaufgabe wird damit die formale Modellierung lohnend. Neben diesem Häufigkeitsaspekt spricht oft auch die hohe technische Komplexität mancher Produkte für die Investition in eine formale Modellierung. Auch wird so die Automatisierung von betriebswirtschaftlichen Produkten, wie zum Beispiel das Ermitteln des Verkaufspreises vereinfacht. Ein System kann strukturell mit der Komponentenstruktur beschrieben werden. Die Komponenten wiederum können durch eine Aufteilung des Systems in Teilsysteme strukturiert werden. Eine Stückliste wirkt hier in Bezug auf die Komponentenstrukturen beschreibend. Die Stückliste ist wegen ihrer Wichtigkeit in der Produktherstellung ein elementares Ziel der Produktkonfiguration. 15

25 Stammdaten Es existieren zwei Unterklassen der Stückliste. Zum einen die konfigurierbare Stückliste, die alle denkbaren Komponenten umfasst. Diese wurden zerlegt, weshalb einige Komponenten nur unter bestimmten Bedingungen Teil der Liste sind. Eine andere Variante der Stückliste ist die Maximalstückliste, in der alle möglichen Komponenten aufgeführt und fest ausgeprägt sind. Eine Maximalstückliste der farbvariierten Schachtel würde neben der Position Schachtel auch alle denkbaren Farben und die Bedingungen unter welchen sie gewählt werden, enthalten. Wünscht der Anwender eine Komponente, die nicht auf der Stückliste präsent ist, können zu einer Maximalstückliste manuell oder automatisiert weitere Komponenten hinzugefügt werden, wie zum Beispiel die Position rote Schleife, die ergänzend auf die Stückliste geschrieben wird. Die so generierte Stückliste wird als Teil des Konfigurationsergebnisses gespeichert. Bei dynamischer Instanziierung handelt es sich um eine alternative zur Stückliste. Es handelt sich dabei nicht um ein Modell, bei der alle Komponenten im Vorhinein auf einer Liste festgehalten werden sondern bei dem einzelnen Komponenten in einem dynamischen Prozess auch noch während der aktiven Konfiguration hinzugefügt werden können. Ein sinnvoller Einsatz wäre beispielsweise, wenn bei der Schachtel zusätzlich, an die äußere Schachtelform angepasste Fächer eingebaut werden sollen. Anstatt vorher alle Fächer in der Maximalstückliste zu planen, werden die Fächer im Laufe der Konfiguration passend zur äußeren Schachtelform hinzugefügt. Der Arbeitsplan legt den Fertigungsablauf des Produktes durch Aufteilung in parallele oder alternative Arbeitsvorgänge fest. Analog zu den Stücklisten existieren ebenfalls Maximal- oder konfigurierbare Arbeitspläne. 2.5 Beziehungswissen Die Informationen über Beziehungswissen, die in diesem Kapitel vorgestellt werden, basieren auf Uwe Blumöhrs Buch Variantenkonfiguration mit SAP (Blumöhr, et al., 2013) S

26 Stammdaten Allgemeiner Überblick über Beziehungswissen Das Beziehungswissen hat zwei Aufgaben zu erfüllen. Zum einen die Unterstützung der Konfiguration der Bewertungsoberfläche, beispielsweise bei einem Kundenauftrag. Dabei muss das Konfigurationsergebnis vollständig und in sich schlüssig sein. Das Beziehungswissen wird genutzt, um Bewertungen zu setzen und zu berechnen, sowie zum Anbieten von Vorschlagswerten. Idealerweise werden verbotene Bewertungskombinationen in der Oberfläche nicht angeboten. Der zweite Anwendungsbereich ist die Auflösung von Stücklisten und Arbeitsplänen entsprechend der Konfiguration. Dabei wird das Beziehungswissen genutzt, um überflüssige Elemente von Maximalstückliste und -arbeitsplan zu Löschen und eventuelle Änderungen an den übrigen Elementen vorzunehmen. Vier Arten von Beziehungen sollen im Folgenden erläutert werden: Vor- und Auswahlbedingungen sowie Prozeduren und Constraints. Merkmalsabhängigkeiten werden über Vorbedingungen dargestellt. Theoretisch kann jedes Merkmal jeden der vorher definierten Werte annehmen, unabhängig von den Werten der anderen Merkmale. Die Elemente einer Maximalstückliste oder eines Maximalarbeitsplans, die nicht mit einer Auswahlbedingung gekennzeichnet werden, werden in die aufgelöste Stückliste bzw. den aufgelösten Arbeitsplan übernommen. Diese Elemente werden Gleichteile genannt. Elemente, die mit einer Auswahlbedingung gekennzeichnet sind, werden Variantenteile genannt. Das Element wird nur dann übernommen, wenn die Auswahlbedingung erfüllt wird. Auswahlbedingungen können beispielsweise zu Positionen der Stückliste, Folgenzuordnungen im Arbeitsplan, Fertigungshilfsmitteln im Arbeitsplan oder Vorgängen im Arbeitsplan zugeordnet sein. Die Auswahlbedingungen sind auch dann von Bedeutung, wenn ein Merkmal nur unter gewissen Bedingungen ein Muss-Merkmal und ansonsten ein Kann-Merkmal sein soll. Prozeduren bieten eine Möglichkeit zum Festlegen der Merkmalswerte und zum Lesen von aktuellen Wertsetzungen. Nach dem Konfigurationsstart werden die 17

27 Stammdaten Prozeduren exakt einmal nach einer vorgegebenen Reihenfolge abgearbeitet. Soll ein Elementdetail geändert werden, so muss es klar der Prozedur zugeordnet sein. Auch die Bewertung von Merkmalen erfolgt durch Prozeduren. Hierbei werden zwischen zwei Herangehensweisen an die Wertsetzung unterschieden. Die harte Wertsetzung verbietet es Benutzern und Constraints Werte zu löschen oder zu überschreiben. Der einzige Fall, bei dem eine Wertsetzung überschrieben werden darf, ist wenn eine Prozedur die vorhergehende überschreibt. Der gültige Wert ist jeweils der, der von der letzten Prozedur gesetzt wurde. Sogenannte dynamische Vorschlagswerte werden hingegen von der weichen Wertsetzung zugelassen. Die Werte sind konfigurationsunabhängig und die Wertsetzung hängt ab von den bereits erfolgten Merkmalsbewertungen. Eine Prozedur kann dem Konfigurationsmodell, Merkmal oder Merkmalswert zugeordnet werden. Ersteres ist favorisiert, da daraus eine Kontrolle über die Abarbeitungsreihenfolge folgt. Die gleiche Funktionalität wie die Prozeduren haben die Constraints. Sie sind wichtig in der mehrstufigen Konfiguration da eine Darstellung der Objektabhängigkeiten ermöglicht wird. Außerdem bieten Constraints Auswertungen von Variantentabellen, -funktionen und Beziehungswissen an und die Einschränkung der Merkmalswertevorräte. Bezüglich der Abarbeitungsreihenfolge sind keine Einstellungen erforderlich. Die verschiedenen Constraints werden in sogenannten Constraint- und Beziehungsnetzen gesammelt, in denen eine Zuordnung ausschließlich nach Konfigurationsprofil stattfindet. Im Unterschied zu anderen bereits genannten Bedingungen leisten Constraints keinen Beitrag zur Stücklisten- und Arbeitsplanauflösung. 18

28 Stammdaten Einordnung der Beziehungsarten in prozeduales und deklaratives Beziehungswissen Es existieren drei Arten von Beziehungswissen, die die verschiedenen Herangehensweisen an den Konfigurator beschreiben. Das Ergebnis des deklarative Beziehungswissens, zu dem auch Constraints und zu gewissen Teilen Aktionen gehören, hängt nur von den Ausgangsbedingungen ab. Der Zeitpunkt, zu dem die Abarbeitung stattfindet und die Reihenfolge in der dies geschieht sind dabei nicht relevant. Der Aufbau der Syntax gibt keinerlei Informationen über die Abarbeitung, allein die Beschreibungen der Bedingungen können aus der Syntax herausgelesen werden. Das prozedurale Beziehungswissen arbeitet die Prozeduren hingegen zeitabhängig ab. Eine Zuordnung kann im Vorhinein festgelegt werden. Ein Vorteil des prozeduralen Beziehungswissens ist die Möglichkeit von sukzessiven Berechnungen und Vorschlagswertsetzungen. Semideklaratives Beziehungswissen vereint Eigenschaften von deklarativem und prozeduralem Beziehungswissen. Die Syntax ist dabei rein deklarativ und macht keine Vorgaben bezüglich der Abarbeitung. Die Auswertung erfolgt allerdings prozedural und arbeitet die Vor- und Auswahlbedingungen zeitabhängig ab. Globaler und lokaler Charakter von Beziehungswissen Neben der prozeduralen und deklarativen Einteilung des Beziehungswissens, welche im vorhergehenden Abschnitt erläutert wurde, existiert auch noch die Aufteilung in lokales und globales Wissen. Beim lokalen Beziehungswissen erfolgt eine rein numerische, interne Nummernvergabe. Die Prozeduren werden so beispielsweise Prozedur 389, Prozedur 390, Prozedur 391, usw. benannt. Eine Freigabe erfolgt automatisch. Das Anlegen, Ändern und Löschen der Prozeduren wird aus der Zuordnung abgeleitet, welche fest mit dem Beziehungswissen verknüpft ist. Lokales Beziehungswissen ist nur genau einmal einsetzbar, und zwar an genau dem Punkt, an dem es erstellt wurde. Im Gegensatz dazu steht das globale Beziehungswissen, welches wiederverwendbar und unbegrenzt oft einsetzbar ist. Das globale Beziehungswissen folgt einer nicht- 19

29 Stammdaten numerischen, externen Nummernvergabe, sodass die Prozeduren beispielsweise PROZ_AB3, PROZ_3CD, usw. benannt werden. Die Freigabe erfolgt manuell und nicht automatisch. Statusänderungen beeinflussen die Zuordnung ebenso wenig, wie das Anlegen von Kurztexten. Für die Pflege ist hier allerdings eine eigene Transaktion von Nöten. Das Anlegen des globalen Beziehungswissens kann, sofern es sich nicht um Constraint-Netze handelt, aus der Zuordnung heraus erfolgen. Aufgrund der besseren Performance durch die Möglichkeit der Mehrfachverwendung durch Mehrfachzuordnung und aufgrund der deutlich einfacheren Auswertung wird häufig das globale Beziehungswissen für die Variantenkonfiguration empfohlen. Der Status des lokalen sowie des globalen Beziehungswissens kann nur dann Freigegeben sein, wenn die Syntax vorhanden und fehlerfrei ist. Liegt eine fehlerhafte Syntax vor, kann diese zwar gespeichert werden, das Beziehungswissen wird in diesem Fall allerdings den Status Gesperrt erhalten. Beziehungswissen bei Variantenkonfiguration und in der Klassifizierung Sowohl bei der Klassifizierung als auch bei der Variantenkonfiguration kann Beziehungswissen nutzbringend eingesetzt werden. Bei Ersterem wird das Wissen, Vor- und Auswahlbedingungen sowie Prozeduren, Merkmalen, Merkmalswerten oder Klassen zugeordnet. Beziehungswissen, das an Klassen(-knoten) angefügt wird, ist nur in der Klassifizierung aktiv. Beziehungswissen und ihre Ausführungsreihenfolge In der Konfiguration der Bewertungsoberfläche sind alle Arten von Beziehungswissen nutzbar. Der Zeitpunkt der Abarbeitung kann im Konfigurationsprofil festgelegt werden. Ein Standardvorgehen ist es, die Abarbeitung nach jedem Bildwechsel und bei jeder Datenfreigabe, die durch die Entertaste erfolgt, erfolgen zu lassen. Alternative Einstellungen erlauben eine Abarbeitung auf Anfrage. Zu Sicherstellung des deklarativen Charakters sind Constraints ständig aktiv. Jede Änderung führt damit zu einer Constraintabarbeitung. Die Abarbeitung von Beziehungswissen ist fest vorgegeben und findet folgendermaßen statt: 20

30 Stammdaten Im ersten Abarbeitungsschritt werden die Werte, die durch Prozeduren gesetzt wurden, zurückgesetzt. Falls sich dadurch Änderungen an Constraintbedingungen ergeben, werden nun diese abgearbeitet. Der nächste Schritt ist die Abarbeitung und einmalige Auswertung der Prozeduren. Die Auswertung erfolgt in einer festen Reihenfolge beginnend mit dem Konfigurationsprofil. Hier wird die Reihenfolge über die sogenannte Sortierung definiert. Als nächstes werden die Bewertungsmerkmale abgearbeitet. Innerhalb der Merkmale kann hier zwar eine Reihenfolge vorgegeben werden, die Abarbeitungsreihenfolge der Merkmale ist allerdings nicht variabel. Bei der nun folgenden Abarbeitung der Vorbedingungen hat die Reihenfolge keine Auswirkung auf Prozeduren und Constraints. Der letzte Schritt, die Abarbeitung der Auswahlbedingungen, hat keine Reihenfolge und keine Auswirkung auf Prozeduren und Constraints. Eine Stücklisten- und Arbeitsplanauflösung ist ausschließlich bei Auswahlbedingungen und Prozeduren möglich, wobei die Auswahlbedingungen vor den Prozeduren ausgewertet werden. Die Abarbeitungsreihenfolge unterscheidet sich bei Endress+Hauser grundlegend von der im SAP, da durch den Einsatz des Endress+Hauser Konfigurator 6.0 dort das gepflegte Beziehungswissen ausschließlich einmal aufgerufen wird. Allerdings bezieht der Endress+Hauser Konfigurator kein Beziehungswissen aus dem SAP. 21

31 Stammdaten 2.6 Methoden Experteninterview Das Experteninterview ist zwar als Methode der Organisationsforschung definiert 41 bildet hier aber eine Ausnahme, da Methoden in der Regel nicht nach dem Gegenüber benannt werden, sondern nach dem Verfahren, mit dem Informationen erlangt werden. Trotzdem ist das Experteninterview, wie auch das leitfadengestützte Interview, eine Unterklasse des Interviews und kann so verwendet werden Risikoanalyse Unter einem Risiko oder einer Risikosituation wird in der Regel der Eintritt eines unerwünschten Ereignisses verstanden. Da eine Risikoanalyse meist sehr komplex ist, wird im Folgenden eine vereinfachte Form aus Risikomanagement für IT-Projekte 42 erläutert. Ein Ereignis tritt mit einer gewissen Wahrscheinlichkeit ein und verursacht einen gewissen Schaden. Daher kann das betriebswirtschaftliche Risiko gut durch den Betriebsschaden beschrieben werden. Um diesen Risikoschaden zu bestimmen müssen Eintrittswahrscheinlichkeiten und Schadensbetrag herangezogen werden. Innerhalb von Projekten können unterschiedliche Einzelrisiken auftreten. Der Risikoschaden für ein Risiko berechnet sich wie folgt: Dabei steht für den dem Einzelrisiko zugeordneten Schadensbetrag und für die zugehörige Eintrittswahrscheinlichkeit. Um den für das Projektmanagement relevanten Gesamtrisikoschaden aufsummiert werden: berechnen zu können, müssen alle Einzelrisikoschäden Damit diese Formel zutreffend ist, müssen die Einzelrisiken unabhängig voneinander sein. Dies kann bei einer Projektorganisation als gegeben betrachtet werden. Für die Bestimmung von Risikoschäden in der Praxis müssen empirische Methoden zur 41 Vgl. (Kühl, 2009), S Vgl. (Wack, 2006) S

32 Stammdaten Bestimmung des Schadenswertes und der Eintrittswahrscheinlichkeit herangezogen werden. Der Risikoschaden ist dabei entweder eine deterministische Größe, das heißt, der Wert ist bereits durch Vorbedingungen festgelegt, oder eine stochastische Größe, wenn der Schaden nur geschätzt werden kann. Auch bei der Eintrittswahrscheinlichkeit handelt es sich offensichtlich um eine stochastische Größe, deren Wert nur empirisch, z.b. durch Rückgreifen auf frühere, vergleichbare Projektdaten oder durch Heranziehen von Experteninterviews, bestimmt werden kann. Da hier leicht Schätzfehler auftreten können, enthält die so angegebene Eintrittswahrscheinlichkeit eine stochastische Abweichung von der tatsächlichen Wahrscheinlichkeit. Um diese Abweichung auszugleichen, können Mittelwerte oder Streuungen ermittelt werden Aufwandsschätzung In diesem Abschnitt sollen grundlegende Techniken, die ein frühes Abschätzen des Entwicklungsaufwandes ermöglichen, erläutert werden. Im späteren Projektverlauf können diese Techniken auch für eine präzisere Schätzung verwendet werden. Das Ziel ist es, den Gesamtaufwand abzuschätzen, indem das Projekt in seine Teilaktivitäten zerlegt wird, welche alle Tätigkeiten enthalten, die im Verlauf des Projektes ausgeführt werden müssen. Neben dieser Kenntnis aller Teilaktivitäten muss auch eine gewisse Erfahrung vorhanden sein, welche Tätigkeit wie viel Zeit in Anspruch nehmen wird. Da der schwierigste Teil der Aufwandsschätzung darin besteht, die Arbeit der einzelnen Teammitglieder zu koordinieren, wird im Folgenden die sogenannte Netzplantechnik eingeführt. 43 Diese Technik beschreibt den Vorgang, bei der zuerst das Projekt in seine voneinander abhängigen Teilaktivitäten zerlegt wird, um dann für jede Komponente den Aufwand zu schätzen. Die Summe der Teilaufwände ergibt den Gesamtaufwand. Eine solche Schätzung ist deshalb genauer als eine Gesamtschätzung, weil der Aufwand für die Teilaktivitäten statistisch gesehen genauso oft über- wie unterschätzt wird und somit im Durchschnitt korrekt ist. Sobald alle voneinander abhängigen Teilaktivitäten ermittelt wurden, werden sie in einem sogenannten Netzplan nebeneinander angeordnet. Aus diesem Plan kann dann, in Form des sogenannten kritischen Pfades, 43 Vgl. (Mangold, 2009) 23

33 Stammdaten die minimale Projektdauer ermittelt werden. Zur Ermittlung der Teilaktivitäten existieren verschiedene Modelle. Das Wasserfallmodell unterteilt das Projekt in die folgenden Phasen: Die Anforderungsanalyse gefolgt von Softwareentwurf, -implementierung und Testen. Da dieses Modell aber keine ausreichend exakte Unterteilung zur Erstellung des Netzplans und zur Aufwandsschätzung bietet, wird meist die Work Breakdown Structure verwendet. Die WBS unterteilt das Projekt zuerst in 25 Teilaktivitäten nach Jones 44 und führt anschließend noch Unteraktivitäten ein, so dass das Projekt am Ende in ungefähr Teilaktivitäten unterteilt ist. Charakteristisch für diese Methode zur Aufwandsschätzung ist also, dass es sich dabei um ein lineares bottom-up Vefahren handelt, bei dem die Gesamtaufwandsschätzung aus der Aufwandschätzung für die Teilaktivitäten hervorgeht. Neben dem hier beschriebenen bottom-up Verfahren existieren auch top-down Methoden, bei denen zuerst der Gesamtaufwand geschätzt wird um daraus auf den Aufwand für die Teilaktivitäten zu schließen Business Process Model and Notation Nach Heinrich Seidlmeier 45 wird der im Folgenden vorgestellte Standard zur graphischen Darstellung und Modellierung von Prozessen. Die Abkürzung BPMN ist aus dem Englischen abgeleitet und steht für Business Process Model and Notation. BPMN stellt einen Prozess, ein Fluss oder eine Abfolge von Aktivitäten mit dem Zweck der Erledigung einer Aufgabe dar. Diese Aktivitäten reichen hierbei vom Arbeitsplatz bis hin zur Unternehmensebene. Die Darstellung erfolgt über graphische Diagramme, die aus fest definierten Elementen bestehen. Unterschieden wird zwischen den sogenannten inner- und überbetrieblichen Prozessen. Erstere werden in der BPMN Sprache kurz als Prozess bezeichnet und werden über eine zentrale organisatorische Einheit oder Software gesteuert. Wegen dieser zentralen Steuerung hat sich der Begriff Orchestrierung etabliert. Innerbetriebliche Prozesse werden weiterhin in private Prozesse, welche alle relevanten Daten enthalten, und öffentliche Prozesse, welche nur die auch extern 44 Vgl. (Jones, 2008) 45 Vgl. (Seidlmeier, 2015), S

34 Stammdaten einsehbaren Elemente enthalten, gegliedert. Die überbetrieblichen Prozesse überschreiten, im Vergleich zu den innerbetrieblichen, die Unternehmensgrenzen. Hier liegt keine zentrale Steuerung vor, vielmehr muss jeder zum Prozess beitragende Akteur selbstständig wissen, welche Aufgaben zu welchem Zeitpunkt erledigt werden müssen. Die Koordination erfolgt über Nachrichtenaustausch. Folgend aus dieser dezentralen Steuerung hat sich die Bezeichnung Choreograph durchgesetzt. Zur graphischen Darstellung der hier erläuterten Prozesse existieren vier verschiedene Diagrammtypen, die aus über 100 verschiedenen Elementen des BPMN zusammengesetzt sind. Die wichtigsten Elemente, unterteilt in fünf Kategorien, sollen im Folgenden erläutert werden: Flussobjekte definieren das Prozessverhalten. Zu Flussobjekten zählen Aktivitäten, die der Repräsentation der Prozessschritte dienen. Es gibt zahlreiche Varianten der Aktivitäten, wie zum Beispiel Task, User Task und Send Task. Ereignisse, die die Prozesszustände repräsentieren und Gateways, die den Prozessverlauf über das UND und das ex- und inklusive ODER steuern, zählen ebenfalls zu den Flussobjekten. Die Kategorie der Daten bzw. Datenobjekte lässt sich mit drei Elementen nahezu vollständig beschreiben. Hierzu gehören die Dateninput, -output und -speicherobjekte. Zur Verbindung der Daten- und Flussobjekte dienen die Verbindungsobjekte. Durch sie entstehen Sequenzflüsse zur Verknüpfung von Aktivitäten, Nachrichtenflüsse zum Übermitteln von prozessrelevanten Daten, Assoziationen und Datenassoziationen zur Verknüpfung von Kommentaren und Artefakten. Die Schwimmbahnen organisieren die beschriebenen Elemente in Gruppen, die als Pools und Lanes bezeichnet werden. Diese können sowohl vertikal als auch horizontal angeordnet sein. Ein Pool kann beispielsweise eine Abteilung repräsentieren, der die alleinige Prozessorganisation unterliegt, kann aber auch zur Modellierung eines IT-Systems verwendet werden und dient dem besseren Verständnis des Gesamtprozesses. Die Bahnen unterteilen den Pool und enthalten den eigentlichen Prozessverlauf. Artefakte konnotieren die Objekte und sind dabei nicht relevant für den Prozessablauf. Beispiele sind Anmerkungen oder Gruppierungen. 25

35 Stammdaten Zusätzlich zu diesen Basiselementen gibt es noch die erweiterten Elemente, wie zum Beispiel eine Unterteilung in Start-, Zwischen- und Endereignisse. Diese Elemente werden in den vier Diagrammtypen, die nun beschrieben werden, verwendet. Das Geschäftsprozessdiagramm oder auch nur das Prozessdiagramm zeigt unternehmensinterne Prozesse mit Fokus auf den Arbeitsfluss. Es besteht eine Ähnlichkeit zu den sogenannten Flussdiagrammen, allerdings bieten die Prozessdiagramme mehr Ausdrucksmöglichkeiten. Prozessdiagramme benötigen immer maximal einen Pool. Dagegen haben Choreographiediagramme generell gar keine Pools. Sie zeigen den Informations- und Nachrichtenaustausch bei überbetrieblichem Fluss zwischen prozessbeteiligten Partnern an. Der Prozessverlauf wird mit den oben beschriebenen Prozesselementen dargestellt. Diese beiden Diagrammtypen werden in Kollaborationsdiagrammen vereinigt, sodass sowohl die überbetriebliche Zusammenarbeit in Pools und Bahnen dargestellt wird, sowie die Verbindung der Elemente in benachbarten Polls über den Nachrichtenfluss. Theoretisch können bei diesem Diagrammtyp einige Pools komplett leer bleiben und trotzdem verbunden werden. Der vierte Diagrammtyp, der in diesem Kapitel beschrieben werden soll ist das Konversationsdiagramm, das einen Überblick über den Nachrichtenaustausch zwischen Geschäftspartnern geben soll. Es gibt keine Auskunft über die verschiedenen Verarbeitungsschritte. Um eine inhaltliche und strukturelle Korrektheit sowie die Vollständigkeit und Konsistenz bewerten zu können, gibt es einige Modellierungsregeln. Die 39 Regeln zur methodischen Korrektheit können in die folgenden Kategorien eingeteilt werden 46 : Sequenzfluss, Start- und Endereignis, angeheftetes Ereignis, sendendes oder empfangendes Zwischenereignis, Nachrichtenfluss, Gateway und Prozess. Weitere 27 Regeln zur strukturellen Korrektheit betreffen die Bereiche Beschriftungen, Nachrichtenfluss, Endereignis und das Aufklappen eines Unterprozesses. 46 Vgl. (B, 2012) S

36 Stammdaten Netzplantechnik Der Begriff der Netzplantechnik, welcher in diesem Kapitel auf Basis des gleichnamigen Werks von Dirk Nossten 47 erläutert werden soll, beinhaltet viele Modelle, die die Projektplanung und -umsetzung unterstützen sollen. Die theoretische Grundlage hierfür ist die aus der Mengenlehre stammende Graphentheorie, die eine Menge von Kanten und Knoten in Form eines Knotengraphen untersucht. Ein Beispiel hierfür ist die nachfolgende Abbildung. Abbildung 3 Beispiel für einen gerichteten, endlichen und kreisfreien Graphen 48 Welche Form für die Knoten gewählt wird ist dabei nicht relevant. Bei einem Knotengraph verbinden Kanten in Form von Pfeilen zwei Knoten miteinander. Jeder Knoten ist durch mindestens eine Kante mit einem anderen verbunden. Jeder Kante ist ein Wert zugeordnet. Durch diese Kanten und Knoten können alle Vorgänge, Ereignisse und Anordnungsbeziehungen innerhalb eines Projektes dargestellt werden. Vorgänge beanspruchen dabei Zeit, Ereignisse kennzeichnen bestimmte Zeitpunkte und Anordnungsbeziehungen legen die Abhängigkeiten und Reihenfolgen zwischen den Vorgängen und Ereignissen fest. In dieser Arbeit werden die sogenannten vorgangsorientierten Knotennetzpläne verwendet, bei denen Ereignisse vernachlässigt werden und Vorgänge als Knoten dargestellt werden. Ein Beispiel für einen solchen Netzplan kann Abbildung 11 herangezogen werden. Die Anordnungsbeziehungen zwischen den verschiedenen Vorgängen werden durch Pfeile dargestellt. So können verschiedenste Abhängigkeiten dargestellt werden. Beispielsweise, wenn die abgeschlossene Ausführung eines Vorganges Bedingung für 47 Vgl. (Noosten, 2013) 48 (Noosten, 2013) Abb

37 Stammdaten mehrere nachfolgende Vorgänge ist oder mehrere Vorgänge Bedingung für einen einzigen nachfolgenden Vorgang. Es wird zwischen vier Möglichkeiten für Abhängigkeiten zwischen Vorgängen unterschieden. Die Normalfolge, die auch als Ende-Anfang -Beziehung bezeichnet werden kann, beschreibt den Fall, in dem das Beenden eines Vorganges Bedingung für den Anfang des nachfolgenden Vorgangs ist. Im Graph geht dementsprechend der Pfeil vom Vorgangsende zum Vorgangsanfang. Analog gibt es ebenfalls Anfang-Anfang -, Ende-Ende - und Anfang-Ende -Beziehungen. Ein Minimalabstand zwischen zwei Vorgängen ist die Zeitspanne, die mindestens eingehalten werden sollte. Sie darf überschritten werden. Dahingegen darf die Zeit des Maximalabstandes zwischen zwei Vorgängen nicht überschritten werden. Um die verschiedenen Zeitpunkte zu berechnen gibt es Rechenregeln, abhängig von der Art der Anordnungsbeziehungen. Im Folgenden werden die Methoden zur Zeitpunktsberechnung für Normalfolgen erläutert. Der erste Schritt ist es dabei die Dauer der Vorgänge in die Knoten zu schreiben und die Abstände an die Pfeile. Bei der Vorwärtsrechnung wird nun beginnend beim Startvorgang jeweils der frühste mögliche Anfangs- und Endzeitpunkt berechnet. Dabei gilt:. steht dabei für den frühesten möglichen Anfangszeitpunkt, für den frühesten möglichen Endzeitpunkt und für den minimalen Zeitabstand zwischen beiden Vorgängen. Bei mehreren Vorgängen wird mit der jeweils höchsten Summe gerechnet. Die Rückwärtsrechnung geht von dem bereits berechneten Endzeitpunkt des Zielvorganges, also des letzten Vorganges, aus. Davon ausgehend werden durch Subtraktion nun die spätesten möglichen Anfangs- (SAZ) und Endzeitpunkte (SEZ) berechnet. Bei mehreren Vorgängen gilt die niedrigste Differenz. Kritische Vorgänge sind diese, bei denen FAZ und SAZ zusammenfallen. Solche Vorgänge liegen auf dem kritischen Weg durch den Netzplan. Alle Vorgänge, die nicht 28

38 Stammdaten auf diesem Weg liegen haben eine Pufferzeit. Die Gesamtpufferzeit berechnet: wird wie folgt. Ist im Netzplan ein Maximalabstand angegeben, so wird dieser bei der Berechnung zunächst vernachlässigt und erst nach Abschluss der Berechnung wird geprüft, ob für die Maximalabstände die möglichen Zeitpunkte für Vorgänger und Nachfolger im Widerspruch stehen. Für eine genauere Berechnung der Pufferzeiten muss zunächst zwischen drei für diese Arbeit relevanten Pufferzeiten unterschieden werden: die Gesamtpufferzeit freie Pufferzeit und die unabhängige Pufferzeit., die Erstere beschreibt die Zeitspanne zwischen frühestem und spätestem Endzeitpunkt und wird, wie bereits erwähnt folgendermaßen berechnet:. Die freie Pufferzeit beschreibt die Zeitspanne, um die ein Vorgang von seinem FAZ verschoben werden kann, ohne, dass Einfluss auf den FAZ des Nachfolgers genommen wird. Für Normalfolgen gilt: Für Vorgänge in der Reihenfolge dann dann. Die Zeitspanne, um die ein Vorgang verschoben werden kann, wenn alle Vorgänger zum spätesten Zeitpunkt starten und alle Nachfolger zum frühesten, wird unabhängige Pufferzeit genannt. Dabei gilt:. Um die Zeitpunkte FAZ und SAZ zu berechnen können die folgenden Formeln herangezogen werden: und Die Dauer des Vorgangs ist in enthalten. 29

39 Der Wandel 3 Der Wandel 3.1 Vergangenheit der Zukunft Als IT-Dienstleister für die Endress+Hauser Gruppe, ist es die Aufgabe von Endress+Hauser InfoServe die Systeme, die für den Produkt Lifecycle Prozess relevant sind, hoch verfügbar und performant zur Verfügung zu stellen. Dabei ist durch die Jahre des Bestehens eine Struktur entstanden, die für den Bestell- und Produktionsprozess sehr ausschlaggebend ist. So gibt es für einen örtlichen Zusammenschluss von SCs, zum Beispiel alle SCs aus Europa oder alle SCs aus Afrika, eine SAP Installation. Des Weiteren hat jedes PC eine eigene SAP Umgebung, in welcher es seine Produkte anlegen und die Produktion organisieren kann. Dies hat den großen Vorteil, dass zum Beispiel Updates am System immer in der entsprechenden Nacht durchgeführt werden können, da durch die geographische Trennung die Arbeitszeiten variieren und so keine Produktions- oder Verkaufsprozesse gestört werden. In Bezug auf die Konfiguration von Produkten übernehmen die SCs eine übergeordnete Rolle, indem sie auf Produktebene konfigurieren. Sie betrachten dabei die für den Kunden relevanten Bauteile und Ausführungen und senden die Bestellung nach Abschluss in das SAP System des PCs, welches das Produkt produziert. Im PC werden aus der Konfiguration des SCs weitere Merkmale, die für die Produktion relevant sind, abgeleitet. Dies geschieht über SAP Beziehungswissen auf Konfigurationsprofil- oder Merkmalsebene. In Abbildung 8 ist der gesamte Bestellprozess an einem Beispiel dargestellt. Es handelt sich dabei um einen Kunden, der über den Online Shop ein neues Produkt bestellen möchte. Er besucht nun also den Online Shop und wählt die gewünschten Basisprodukte und die entsprechende Menge aus. Anschließend wird er automatisch zum Endress+Hauser Konfigurator 6.0 weiter geleitet, in welchem er die Konfiguration seiner ausgewählten Produkte vornimmt. 30

40 Der Wandel Mit dem Start des Endress+Hauser Konfigurator 6.0 werden alle benötigten Informationen über das Produkt und seine Abhängigkeiten geladen. Im Folgenden ist auf fünf Abbildungen zu sehen, wie die Konfiguration voran schreitet. In der nachfolgenden Abbildung ist der Ausgangsstatus des zu konfigurierenden Produkts zu sehen. Auf der linken Seite sind die Merkmale zu sehen, welche konfiguriert werden müssen. Durch die rote Markierung am linken Bildrand ist ersichtlich, dass dieses Merkmal noch nicht konfiguriert wurde, was aber noch vor dem Absenden geschehen muss. In der rechten Spalte sind die auswählbaren Merkmalswerte zu sehen. Die grau ausgebleichten Optionen sind ausgeschlossene oder deaktivierte Merkmalswerte. Mit der Auswahl eines validen Merkmalwertes springt der Konfigurator direkt in die Auswahl für das nächste Merkmal. Abbildung 4 - Ausgangsstatus einer Produktkonfiguration 49 In der nächsten Abbildung ist eine weiter fortgeschrittene Konfiguration zu sehen. Die bereits spezifizierten Merkmale werden grün hinterlegt und der Merkmalswert wird unter dem Namen des Merkmals sichtbar. Im Fall des aktuell ausgewählten Merkmals wurde eine frei spezifizierbarer Merkmalswert ausgewählt und der Wert Screenshot des Endress+Hauser Konfigurators

41 Der Wandel eingetragen. Dies ist ein valider Wert, da er innerhalb des Bereichs 110 bis 4000 liegt. Abbildung 5 - Spezifizierung von frei wählbaren Merkmalswerten 50 Fällt dem Kunden bei der Spezifizierung eines Merkmals ein, dass er ein grau hinterlegtes, also ausgeschlossenes Merkmal wählen möchte, wird ihm angezeigt, welche anderen Merkmale die Wahl dieses Merkmalswertes verhindern. Er hat somit die Möglichkeit, in der Konfiguration ein für ihn optimales Gerät zu konfigurieren. 50 Screenshot des Endress+Hauser Konfigurators

42 Der Wandel Abbildung 6 - Fehlerhafte Konfiguration 51 In der nachstehenden Abbildung ist die vollständige Konfiguration zu sehen, welche nun durch das Betätigen des Übernehmen Knopfes zurück an das entsprechende System gesendet wird. Abbildung 7 - Vollständige Konfiguration Screenshot des Endress+Hauser Konfigurators

43 Der Wandel Ist dies geschehen, sendet der Kunde die Bestellung ab und erstellt somit eine Bestellung im SAP System des für ihn relevanten SCs. Das SC überprüft die Bestellung auf mögliche Fehler bei der Übertragung und fügt, für diese Arbeit eher nebensächliche, Bestandteile, wie zum Beispiel Konditionen, zu dem Auftrag hinzu. Ist dies geschehen, wird ein Produktionsauftrag im PC, welches dieses Produkt produziert, erstellt. Das PC leitet nun mit Hilfe des Beziehungswissens, das in ihrem SAP System hinterlegt ist, die endgültige Konfiguration für ihre Produktion ab. Dadurch werden die Arbeitspläne und Stücklisten auf die Bestellung angepasst. Bevor das Produkt in die Produktion geht, wird es von Mitarbeitern des PCs auf die technische Umsetzbarkeit überprüft. Wird eine Einschränkung festgestellt, wird diese dem Kunden mitgeteilt und die nötigen Änderungen an seiner Konfiguration werden ihm erklärt. Sobald sich der Kunde für eine umsetzbare Konfiguration entschieden hat, kann die Produktion beginnen. Der Prozess wird mit der Fertigstellung des Produkts beendet. 52 Screenshot des Endress+Hauser Konfigurators

44 Der Wandel Abbildung 8 - Bestellprozess via Online Shop Eigendarstellung nach (Eichkorn, 2015) 35

45 Der Wandel Der in Abbildung 8 dargestellte Prozess bedarf manueller Eingriffe, wie zum Beispiel für die Validierung der Konfiguration der Produkte. Dort werden, von dem für das Produkt verantwortliche PC, die Ausschlüsse mithilfe Transaktion im SAP gepflegt. Auf diese Ausschlüsse kann der Endress+Hauser Konfigurator 6.0 zugreifen und somit ausschließlich valide Konfigurationen zulassen. Einige Ausschlüsse lassen sich in dieser Transaktion allerdings nicht umsetzen, was die bereits erwähnte Prüfung der technischen Umsetzbarkeit nötig macht. Wird zum Beispiel bei einer Konfiguration eine frei wählbare Länge für einen Temperatursensor gewählt, ist diese vom PC manuell zu validieren. Dabei müssen die Mitarbeiter manuell berechnen, ob zum Beispiel eine maximale Länge für ein bestimmtes Bauteil überschritten wurde. Zusätzlich zum Online Shop gibt es einige weitere Möglichkeiten, wie ein Kunde von Endress+Hauser ein Produkt bestellen und anschließend konfigurieren kann. Eine davon ist der Offline Konfigurator, welcher einmal im Jahr von den Sales Centern an die Kunden verschickt wird. Es handelt sich dabei um eine DVD mit den aktuellen Produkten, die dazugehörigen wichtigen Informationen, Ausschlüsse und einem Berechnungstool, das es ermöglicht, die variablen Längen im oben beschriebenen Problem zu berechnen und somit zu validieren. Nach der Konfiguration exportiert der Kunde eine XML Datei und lädt diese im Online Shop hoch und kann anschließend die Bestellung wie gewohnt durchführen. 3.2 Optimierungspotenzial Der im vorherigen Kapitel dargestellte Prozess hat einige Möglichkeiten zur Optimierung. Eines der größten Probleme ist, dass der Kunde während der Konfiguration seines Produkts im Endress+Hauser Konfigurator 6.0 angeblich weiß, dass seine Konfiguration valide ist, aber es kann passieren, dass nach der Bestellung das Product Center darüber informieren muss, dass die Konfiguration doch nicht umsetzbar ist. Der Grund dafür ist, dass im Endress+Hauser Konfigurator 6.0 keine Möglichkeit besteht, Werte miteinander zu verrechnen und somit neue Abhängigkeiten zwischen Werten von freien Merkmalsfeldern zu definieren. 36

46 Der Wandel Ein weiteres Problem ist der hohe Zeitaufwand für das PC, falls es zu einem Problem bei der Validierung kommt. Die Konfiguration der Produkte kann bei einigen Kunden oft bis zu mehreren Wochen dauern. Eine unerwartete Änderung kann den kompletten Prozess erneut anstoßen, was wiederum zum Stillstand der Produktion für die gesamte Bestellung führt. Somit kann ein vereinbarter Liefertermin womöglich nicht mehr eingehalten werden. 3.3 Zukunft der Vergangenheit Im Gespräch mit den Produktmanagern des PC Wetzers 54, welches nachfolgend beispielhaft für alle PCs der Endress+Hauser Gruppe steht, und den Verantwortlichen des Endress+Hauser Konfigurators hat sich ergeben, dass dem Kunden in Zukunft direkt bei der Konfiguration mitgeteilt werden soll, falls er eine Konfiguration gewählt hat, die so im PC nicht umsetzbar ist. Mit Hilfe des SAP Beziehungswissens, welches das PC für seine Produkte pflegt, ist es möglich, den Prozess der Validierung, welcher zum aktuellen Zeitpunkt erst kurz vor der Produktion stattfindet, bereits vor Abschluss der Konfiguration durchzuführen. Dies ist möglich, da im SAP Beziehungswissen das Rechnen mit Variablen möglich ist und da das PC das entsprechende Knowhow hat, um die dafür benötigten Formeln zu erstellen. Die Problematik der Längenberechnung ist hierbei nur beispielhaft zu sehen, genauso wäre es möglich eine frei auswählbare Kalibrierungstemperatur von den Materialien abhängig zu machen. Im Gespräch 56 wurde ebenso definiert, dass bei gleichwertigen Ansätzen derjenige, welcher das geringste Risiko und alles in allem wirtschaftlich am sinnvollsten ist, umgesetzt werden soll. 54 Vgl. (Diemer, 2015) 55 Vgl. (Lauke, 2015) 56 Vgl. (Lauke, 2015) 37

47 Evaluation 4 Evaluation 4.1 Allgemeines Um den eigentlichen Grund für dieses Projekt noch einmal in Erinnerung zu rufen, wird nachfolgend ein anschauliches Beispiel beschrieben. Wird vom Kunden zum Beispiel ein Endress+Hauser Temperaturmessgerät wie in der nachfolgenden Abbildung bestellt, bei welchem ein frei spezifizierbarer Merkmalswert für das Merkmal Länge des Halsrohr gewählt wurde, kann der Fall eintreten, dass das Messgerät für den Kunden trotz valider Konfiguration nicht einsatzfähig ist. Der Grund für diese Nicht-Einsetzbarkeit kann in diesem Fall beispielsweise die zu hohe Temperatur des zu messenden Mediums sein. Da das Medium einen Wärmgradient in seiner Umgebung verursacht, kann bei zu kurzer Halsrohrlänge die Temperatur um das Gehäuse herum für die enthaltene Elektronik zu hoch sein. In diesem Fall muss der Kunde einen höheren Wert für die Sensorlänge eingeben. 38

48 Evaluation Gehäuse Anschlusskopf Halsrohr Prozessanschluss Schutzrohr Abbildung 9 - Omnigrad M TR Endress+Hauser Mitarbeiter Portal Engine 39

49 Evaluation Dieses Wissen ist allerdings nicht im Konfigurator verfügbar, da die dafür nötigen Berechnungen nicht abbildbar sind. Dort ist es ausschließlich möglich in einer Tabelle mögliche Kombinationen von Merkmalswerten zu hinterlegen, welche anschließend im Konfigurator genutzt werden, um die Konfiguration zu validieren. Dabei ist es nicht möglich Merkmalswerte miteinander zu verrechnen und daraus Ausschlüsse abzuleiten. Im Folgenden werden vier Ansätze zur Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator 6.0 dargestellt und deren Aufwand anhand von Erfahrungswerten abgeschätzt. Abschließend wird anhand der nachfolgenden Kriterien 58 eine Entscheidung getroffen, welcher der Ansätze umgesetzt werden soll. Die detaillierte technische Umsetzung wird im nächsten Kapitel beschrieben. Die wichtigste Anforderung ist, dass in einem Projekt, mit definiertem Anfangs- und Endtermin, eine Lösung entwickelt wird, welche das vom PC hinterlegte Beziehungswissen im SAP System zur Validierung von Konfigurationen im Endress+Hauser Konfigurator 6.0 nutzen zu können. 4.2 Ansätze Ansatz Eins Als erster Ansatz wird die Beauftragung eines externen Dienstleisters in Betracht gezogen. Beim Kontaktieren von mehreren, für SAP Erweiterungen bekannten Entwicklerhäusern, wurde schnell klar, dass es sich bei der Nutzung von SAP Beziehungswissen in einem externen Konfigurator um eine Anforderung handelt, mit der noch niemand Erfahrungen gesammelt hat. Nach den thematischen Gesprächen mit mehreren Entwicklungshäusern konnte niemand die Anforderungen aus dem vorherigen Kapitel erfüllen. Zusätzlich wurde angezweifelt, ob die Beauftragung einer externen Firma aus wirtschaftlicher Sicht sinnvoll ist, da Endress+Hauser InfoServe theoretisch die Möglichkeiten hätte, das Projekt umzusetzen Vgl. (Lauke, 2015) 59 Vgl. (Lauke, 2015) 40

50 Evaluation Ansatz Zwei Als zweiter Ansatz soll der Versuch, das SAP Beziehungswissen nach zu entwickeln, dargestellt werden. Auch wenn dieser Ansatz bereits im Kapitel, das die Zielsetzung der Arbeit behandelt, ausgeschlossen wurde, wird er an dieser Stelle der Vollständigkeit halber kurz erläutert. Das SAP Beziehungswissen, welches die PCs pflegen können, hat die Möglichkeit hoch komplexe Rechnungen und Gleichungssysteme zu lösen und daraus mögliche Kombinationen für Konfigurationen auszuschließen oder zu verändern. Zum aktuellen Zeitpunkt ist dies im Endress+Hauser Konfigurator 6.0 nicht möglich. Dort ist es ausschließlich möglich in einer Tabelle mögliche Kombinationen von Merkmalswerten zu hinterlegen, welche anschließend im Konfigurator genutzt werden, um die Konfiguration zu validieren. Das Abbilden von komplexen Gleichungen ist in dieser Tabelle nicht möglich. Daher wäre es nötig, die Gleichungen und Rechnungen in einem SAP Funktionsbaustein, welcher aus dem Konfigurator aufgerufen werden kann, zu entwickeln. Wie in der nachfolgenden Abbildung zu sehen ist, wird aus dem Endress+Hauser Konfigurator in diesem Fall ein Webservice aufgerufen, welcher das Ergebnis der in dem Funktionsbaustein abgelaufenen Berechnung zurückgibt. 41

51 Evaluation Abbildung 10 - Aufruf eines SAP Funktionsbausteins aus dem E+H Konfigurator Das Wissen ist in diesem Modell doppelt vorhanden, nämlich im SAP Beziehungswissen und im SAP Funktionsbaustein Ansatz Drei Der dritte Ansatz basiert darauf, das SAP Beziehungswissen, welches bereits von den PCs gepflegt wurde, per Webservice aus dem Endress+Hauser Konfigurator 6.0 zu validieren. 60 Eigendarstellung 42

52 Evaluation Ansatz Vier Der vierte Ansatz basiert auf der gleichen Idee wie Ansatz drei, allerdings wird in diesem Fall ein schon seit langer Zeit integrierter externer Mitarbeiter von Endress+Hauser InfoServe mit einbezogen, welcher die Entwicklung an ausgewählten Stellen unterstützen soll. 4.3 Aufwandsschätzung Ansatz Eins An dieser Stelle ist keine Aufwandsschätzung für Ansatz eins möglich, da keiner der kontaktierten Dienstleister eine fertig entwickelte Lösung für die Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator 6.0 gefunden wurde. Sobald sich eine neue Möglichkeit bietet, ist geplant, diese zu evaluieren Ansatz Zwei Der für den zweiten Ansatz benötigte Aufwand ist ein Wiederkehrender, da mit jedem neuen Produkt der PCs womöglich auch Bedarf für einen neuen Webservice und für einen neuen SAP Funktionsbaustein besteht. Zusätzlich muss es eine Pflegemaske geben, in welcher hinterlegt werden kann, welcher Webservice zu welchem Produkt und Merkmalswert gehört. Wird von einem Aufwand von zwei Personentagen für die Weiterentwicklung des Webservices, der Neuentwicklung des SAP Funktionsbausteins und der Eintragung in die Pflegetabelle ausgegangen, bedarf es bei circa einem neuen Produkt im Jahr 61 zwei Personentagen. Vernachlässigt wird in dieser Rechnung der einmalige Aufwand von zwei Personentagen, welche nötig wären um die Pflegemaske und die entsprechende Tabelle für die Zuordnung der Produkte, Merkmale und Merkmalswerte zum jeweiligen Webservice zu speichern. Wird dies mit einem Stundensatz von 100 verrechnet, werden jährliche Kosten von 200 benötigt um bereits gepflegtes Wissen erneut zu entwickeln und zur Verfügung zu stellen. 61 Vgl. (Diemer, 2015) 43

53 Evaluation Ansatz Drei In der Tabelle 2 eine Übersicht über die Berechnung zu sehen, welche für diesen Ansatz genutzt wurde. Für den dritten Ansatz ist die Annahme, dass für die Vorarbeit, das heißt die genaue technische Überprüfung und Analyse der Machbarkeit, circa 40 Stunden von einem InfoServe Mitarbeiter beansprucht werden. Des Weiteren werden für die detaillierte Modellierung des Prozesses vier Personen von InfoServe, eine Person vom PC Wetzer und eine Person vom SC Deutschland für circa acht Stunden benötigt. Um das Beziehungswissen im Endress+Hauser Konfigurator einsetzen zu können, muss es zuvor im SAP eingepflegt werden. Meist ist dies schon der Fall, es wird also hier davon ausgegangen, dass nur circa zehn neue Produkte eingepflegt werden müssen. Für jedes Produkt werden, abhängig von der Art des Produktes, etwa zwei Stunden benötigt. Für den Endress+Hauser Konfigurator ist es wichtig zu wissen, ob das aktuell behandelte Produkt durch SAP Beziehungswissen validiert werden muss. Um dies zu gewährleisten, muss eine Pflegeoberfläche zur Verfügung gestellt werden, was alles in allem 12 Stunden Arbeit für InfoServe bedeutet. Nach der Pflege ist es anschließend nötig die Daten aus der zentralen Datenbank in alle SAP Systeme zu verteilen, damit diese in allen SAP Systemen konsistent sind. Für diesen Vorgang werden vier Stunden benötigt. Ebenso muss das PC Wetzer die zehn neuen Produkte einpflegen, was je Produkt zehn Minuten Aufwand bedeutet. Zusätzlich zur Pflege muss auch ein Webservice programmiert werden, der überprüft, ob eine Validierung über das SAP Beziehungswissen nötig ist. Dafür werden weitere 12 Stunden Aufwand für InfoServe geschätzt. Der nächste Schritt ist die Anpassung der Benutzeroberfläche im Endress+Hauser Konfigurator. Dort arbeitet Endress+Hauser InfoServe schon lange mit einem externen Partner zusammen, der für diese Arbeit circa 12 Stunden Arbeit benötigt. Das InfoServe Team benötigt dafür weitere sechs Stunden. An dieser Stelle besteht Bedarf für einen Webservice zum Aufrufen des Beziehungswissens. Dieser soll überprüfen, ob die jeweilige Konfiguration valide ist und im PC produziert werden kann. 44

54 Evaluation Die Implementierung des Webservices bedeutet 24 Stunden Aufwand für InfoServe. Zum Abschluss muss die Applikation und ihre Neuerungen getestet werden. Dabei sind 40 Stunden für InfoServe, 32 Stunden für das PC Wetzer und 12 Stunden für das SC Deutschland vorgesehen. Alles in allem wird noch ein Aufwand für die Projektplanung und -steuerung eingeplant. In diesem Fall wird mit einem Aufwand von zehn Prozent des Gesamtaufwands gerechnet. Dies entspricht circa 28 Stunden Aufwand, den InfoServe als Leiter des Projektes tragen muss. Zusammen ist somit ein Aufwand von circa 38 Personentagen nötig, um das Projekt umzusetzen. Beschreibung Faktor IS Fatkor PC Faktor SC Faktor OIO Aufwand Summe IS Summe PC Summe SC Summe OIO Gesamt Vorarbeit 1, Modellierung Prozess 4,00 1,00 1, Pflege Beziehungswissen 10, Pflegeoberfläche ob Bezw da 1, Pflege Tabelle ob Bezw da 10, Webserve ob Bezw da 1, Verteilung 1, Anpassung UI 1,00 2, Webservice Bezw 1, Testing 3,33 2,67 1, Doku überarbeiten 1, Projektmanagement (10%) Stunden Tage Stundensatz 100,00 100,00 100,00 100,00 Betrag , , , , ,33 Tabelle 2 - Aufwandsberechnung Ansatz 3 Um ein Projekt in dieser Größenordnung umzusetzen, bedarf es zusätzlich einer Risikoanalyse, die anschließend eine mögliche Abweichung von dem in der Schätzung eingeplanten Aufwand angibt. In der nachfolgenden Tabelle ist die Berechnung für die Risiken ersichtlich, eine Erläuterung erfolgt anschließend. 45

55 Evaluation Beschreibung Zusatz Risiko Prozent Risiko Puffer Vorarbeit 20 20% 4 Modellierung Prozess 48 30% 14,4 Pflege Beziehungswissen 2 25% 0,5 Pflegeoberfläche ob Bezw da 1 25% 0,3 Pflege Tabelle ob Bezw da 0 25% 0,04 Webserve ob Bezw da 1 25% 0,3 Verteilung 0 25% 0,1 Anpassung UI 2 25% 0,45 Webservice Bezw 2 25% 0,6 Testing Doku überarbeiten Projektmanagement (10%) Stunden 21 Tage 41,0 Tabelle 3 - Risikobewertung Ansatz 3 Ein Risiko ist, das die Vorarbeit des InfoServe Mitarbeiters nicht zu dem gewünschten Erfolg kommt, und daher nach den 40 Stunden keinerlei Grundlage vorhanden ist, auf der das eigentliche Projekt aufbauen kann. Die Auswirkung wäre der Abbruch des Projekts oder eine weitere Investition von Zeit, um die Vorarbeit zufriedenstellend abzuschließen. Die Eintrittswahrscheinlichkeit des Risikos, weitere 20 Stunden für diese Tätigkeit zu beanspruchen, liegt bei 20%. Somit liegt der Risikoschaden für dieses Einzelrisiko bei vier Stunden. Bei weiterer Betrachtung der Arbeitsschritte ist ein weiteres Risiko bei der Modellierung des Prozesses zu erkennen. Dabei sind drei unterschiedliche Parteien beteiligt, die alle ihre Meinung vertreten. Die Eintrittswahrscheinlichkeit, dass weitere 8 Stunden pro Person nötig sein werden liegt dabei bei 30%. Der Risikoschaden liegt somit bei 14,4 Stunden. Bei allen Entwicklungsaufgaben gibt es das Risiko, dass die Umsetzung in der geplanten Form nicht möglich ist. Daher ist die Eintrittswahrscheinlichkeit, dass weitere zehn Prozent der bereits aufgewendeten Zeit zusätzlich benötigt werden, bei 25%. In der Summe werden somit 2,2 Stunden Risikoschaden berücksichtigt. Für das Testen und die Überarbeitung der Dokumentation ist kein Risiko zu vermerken, da dort auf vorgefertigte und erprobe Abläufe zurückgegriffen werden kann. In Summe hat dieses Projekt einen Risikoschaden von 21 Stunden. Werden diese auf die 308 Stunden addiert, welche aus der Schätzung entstanden sind, wird eine Summe 46

56 Evaluation von 239 Stunden, was 41 Personentagen entspricht. Dies würde bei einem Stundensatz von je 100 Projektkosten in Höhe von circa bedeuten Ansatz Vier Der Aufwand für Ansatz vier variiert ein wenig von Ansatz drei, da der externe Mitarbeiter die Vorarbeit übernehmen könnte. Dadurch muss er Teil des Teams sein, welches den Prozess modelliert. Ebenso kann er die Pflegeoberfläche für das PC, in welcher eingetragen werden kann, welches Beziehungswissen für den Endress+Hauser Konfigurator relevant ist, übernehmen. Die Webservices zum Überprüfen, ob Beziehungswissen vorhanden ist, und zum Ausführen des Beziehungswissens, können ebenso von dem externen Mitarbeiter übernommen werden. Zum Abschluss ist es des Weiteren möglich, die Dokumentationsanpassung von ihm erledigen zu lassen. Da ein externer Mitarbeiter meistens mit mehr Projektmanagementaufwand verbunden ist, und die Risiken sich an manchen Stellen verändern folgt nachfolgend die Auflistung der Modifizierungen und die erneute Berechnung des Aufwandes in der nachfolgenden Tabelle: Durch die Erhöhung des Projektmanagementzeitaufwands von zehn Prozent auf 15% erweitert sich der Aufwand auf 41 Stunden. Bezüglich der Risiken ist ein Anstieg der Eintrittswahrscheinlichkeit von 20% auf 40% bei der Aufwendung von zusätzlichen 20 Stunden realistisch. Somit besteht ein Risikoschaden von 8 Stunden. Beschreibung Faktor IS Faktor Extern Fatkor PC Faktor SC Faktor OIO Aufwand Summe IS Summe Extern Summe PC Summe SC Summe OIO Gesamt Vorarbeit 1, Modellierung Prozess 3,00 1,00 1,00 1, Pflege Beziehungswissen 10, Pflegeoberfläche ob Bezw da 1, Pflege Tabelle ob Bezw da 10, Webserve ob Bezw da 1, Verteilung 1, Anpassung UI 1,00 2, Webservice Bezw 1, Testing 3,33 2,67 1, Doku überarbeiten 1, Projektmanagement (15%) Stunden Tage Gesamtkosten 100,00 125,00 100,00 100,00 100,00 Betrag , , , , , ,67 Tabelle 4 - Aufwandsschätzung Ansatz 4 Anschließend ist eine Anpassung der Risiken nötig. Daher folgen die Tabelle der Berechnung und die Erläuterung. 47

57 Evaluation Beschreibung Zusatz Risiko Intern Zusatz Risiko Extern Prozent Risiko Puffer Intern Puffer Extern Vorarbeit 20 40% 0 8 Modellierung Prozess % 14 2,8 Pflege Beziehungswissen 2 25% 0,5 0 Pflegeoberfläche ob Bezw da 1 25% 0 0,3 Pflege Tabelle ob Bezw da 0 25% 0,04 0 Webserve ob Bezw da 1 25% 0 0,3 Verteilung 0 25% 0 0 Anpassung UI 2 25% 0,45 0 Webservice Bezw 2 25% 0 0,6 Testing Doku überarbeiten Projektmanagement (15%) Stunden Tage 1,9 1,5 Zusatzkosten 1.499, ,00 Tabelle 5 - Risikobewertung Ansatz 4 Durch die Teilnahme eines externen Mitarbeiters erhöht sich bei der Prozessmodellierung das Risiko auf Grund der Möglichkeit der ungenauen Vorbereitung um fünf Prozentpunkte. Dadurch erhöht sich der Risikoschaden auf 16,8 Stunden. Wird nun die Summe der benötigten Stunden für diesen Ansatz betrachtet, so ist ersichtlich, dass 349 Stunden Arbeit fällig sind, was 43,3 Personentagen entspricht. Unter Berücksichtigung, dass der externe Mitarbeiter mit einem Stundensatz von 125 arbeitet, ist somit ein Betrag von circa nötig, um dieses Projekt zu finanzieren. 4.4 Auswahl Werden die Anforderungen betrachtet, kommen ausschließlich Ansatz drei und vier in Frage, da Ansatz eins keine funktionierende Lösung bieten konnte. Des Weiteren kann Ansatz zwei nicht in einem definierten Anfangs- und Endtermin abgewickelt werden sondern bedarf dauerhafter Betreuung durch Endress+Hauser InfoServe. Des Weiteren ist eine Diskrepanz der Gesamtkosten der Ansätze drei und vier von zu erkennen. Dadurch hat Ansatz drei eine bessere Ausgangslage und werden zusätzlich noch die Eintrittswahrscheinlichkeiten der Risiken bei Ansatz drei und vier betrachtet, fallen diese bei Ansatz drei wesentlich geringer aus. 48

58 Das Projekt 5 Das Projekt 5.1 Projektablauf Um den Ablauf des Projektes anschaulich darzustellen ist in Abbildung 11 ein Netzplan zu sehen, welcher die einzelnen Aufgaben und ihre Abarbeitungsreihenfolge darstellt. In diesem Kapitel wird davon ausgegangen, dass die Aufwandsschätzung aus dem vorherigen Kapitel korrekt ist und keine Risiken eintreten. Ebenso werden weitere Aufwände wie Datenpflege im laufenden Betrieb nicht mit berechnet, da diese für dieses Projekt nicht relevant ist und zum aktuellen Zeitpunkt auch schon von den PCs ausgeführt wird. Somit ist die Datenpflege durch das Projekt von keiner Veränderung betroffen. Die im Folgenden beschriebenen Vorgänge sind in der Abbildung 11 graphisch dargestellt. Zur Erläuterung der Abbildung folgt eine Legende. FAZ FEZ Nr. Name D GP FP SAZ SEZ Tabelle 6 - Legende Netzplan Die nachfolgende Umsetzung des Ansatzes geschah in einer Sandbox Umgebung eines SAP Systems, um so die Realität bestmöglich abbilden zu können. Dabei wurde ausschließlich ein Produkt betrachtet, welches mit der Problematik die bereits in Kapitel Vier erläutert wurde, behaftet ist. Beginnend mit der Vorarbeit startet das Projekt mit der Arbeit eines Experten im SAP Umfeld, um die nötigen Informationen für Vorgang zwei zu sammeln. In diesem wird der neue Prozess, durch den Einsatz des SAP Beziehungswissens, im Endress+Hauser Konfigurator 6.0 definiert. Da Vorgang zwei auf Vorgang eins aufbaut, und bei nicht Einhalten der geplanten Zeit für Vorgang eins Vorgang zwei zeitlich nach hinten verschoben würde, ist dies der Beginn des kritischen Pfades. Nach der Modellierung des Prozesses folgen fünf parallele Vorgänge, 49

59 Das Projekt welche alle von unterschiedlichen Personen bearbeitet werden und nicht aufeinander aufbauen. Ebenso wurde in Vorgang zwei genau definiert, welche Schnittstellen und Anpassungen an der Benutzeroberfläche vorgenommen werden müssen, damit die Parallelisierung ohne Schwierigkeiten durchführbar ist. In Vorgang drei und dem darauf folgenden Vorgang werden zuerst die Tabellen, welche zur Pflege der Information, ob zu diesem Produkt ein Beziehungswissen vorhanden ist, erstellt und anschließend die dazugehörigen Pflegeoberflächen. In Vorgang fünf wird der entsprechende Webservice entwickelt, der zur Nutzung der soeben erstellten Tabelle genutzt wird. In Vorgang sechs wird vom PC Wetzer das Beziehungswissen für die Produkte gepflegt und auf seine Richtigkeit geprüft. In den Vorgängen sieben und acht werden die Anpassungen an der Benutzeroberfläche zuerst von interner und anschließend von externer Seite bearbeitet. In Vorgang neun wird das Kernstück dieses Projektes entwickelt: Der Webservice zur Validierung der Konfiguration durch das SAP Beziehungswissen. Auf Vorgang neun folgen erneut drei parallele Vorgänge. In diesen werden von unterschiedlichen Personengruppen die angepassten Änderungen getestet. Darauf folgt noch die Anpassung der Dokumentation in Vorgang 13. Wird der kritische Pfad dieses Netzplans betrachtet, ist zu sehen, dass ausschließlich fünf Vorgänge Spielraum in ihrem Umsetzungszeitraum besitzen. Dies ist kein Problem, da die Aufgaben auf dem kritischen Pfad alle von InfoServe Mitarbeitern bearbeitet werden, die sehr eng miteinander zusammen arbeiten, was mögliche Verzögerungen ausgleichen kann und dadurch die Einhaltung des Endtermins sichern kann. 50

60 Das Projekt Abbildung 11 - Netzplan zum Projektablauf 51

61 Das Projekt 5.2 Entwicklung Durch die Vorgabe, das vorhandene SAP Beziehungswissen zu nutzen, war es nötig, eine Ansatzstelle im vorhandenen SAP Programm zu finden, welche genutzt werden kann, um das SAP Beziehungswissen aufzurufen. Die Suche nach dieser Ansatzstelle erwies sich als schwieriger als gedacht und eine detaillierte Beschreibung würde den Rahmen dieser Arbeit sprengen. Stark vereinfacht wird eine Konfiguration im SAP Konfigurator simuliert, in welchem das SAP Beziehungswissen abgearbeitet wird. Das Finden dieser Stelle implizierte den Abschluss der Vorarbeit und die Modellierung des Prozesses konnte beginnen. Als Produkt eines Meetings mit den Verantwortlichen des bisherigen Konfigurationsprozesses ergab sich der im nachfolgenden Kapitel sichtbare Prozess. Im Unterschied zum bisherigen Ablauf des Bestellprozesses wird dabei bereits während der Konfiguration validiert, ob die gewählte Konfiguration des Kunden technisch umsetzbar ist. Da nun bekannt ist, an welcher Stelle der Konfiguration eine Validierung stattfinden soll, ist es die Aufgabe des PC Wetzers die gewünschten Produkte mit dem nötigen Beziehungswissen auszustatten, um eine solche Validierung zu ermöglichen. In den meisten Fällen war dieses Wissen schon vorhanden, da es bereits zur Ableitung der Konfiguration aus der Bestellung des SCs genutzt wird. Allerdings ist es nötig, es auch im SAP System der SCs zur Verfügung zu stellen, da sonst eine Validierung im Online- Shop nicht möglich wäre. In einem weiteren Schritt wurde eine Pflegeoberfläche im SAP geschaffen, in der das PC Wetzer für das Beziehungswissen von jedem einzelnen Produkt hinterlegen kann, welches Wissen zur Validierung genutzt werden soll. Für diese Pflegeoberfläche ist eine Verteilung der gepflegten Daten notwendig, da sonst Konfigurationen nicht durchgängig valide sind. Ansonsten könnte es zu Laufzeitfehlern während der Validierung kommen, da auf nicht vorhandene Daten referenziert wird. Der nächste Schritt war die Anpassung des Webservices, der alle notwendigen Daten zu einem für die Konfiguration ausgewählten Produkt zur Verfügung stellt. Dieser Webservice musste um die Information, ob es Beziehungswissen zum Validieren gibt oder nicht, erweitert werden. Dafür bedurfte es einer Strukturerweiterung des 52

62 Das Projekt Webservices, damit weitere Parameter übergeben werden können und einer Erweiterung der XML Struktur und die eigentliche Anpassung am Webservice. Anhand dieser Vorgaben wurde die Oberfläche, wie in der folgenden Abbildung zu sehen ist, angepasst. Dabei ist es nötig, einen Validierungsknopf anzuzeigen, falls Beziehungswissen vorhanden ist. Dieser Knopf ruft den Webservice zur Validierung auf und soll anschließend anzeigen, ob die Validierung erfolgreich war, also ob die Konfiguration valide ist und das Produkt der Bestellung hinzugefügt werden kann, oder ob die Konfiguration fehlerhaft ist und somit eine Anpassung nötig ist. Abbildung 12 - Validierung der Konfiguration durch SAP Beziehungswissen 62 Der für diesen Schritt nötige Webservice bedarf einer neuen Request und Response Struktur mit dementsprechenden XML Dateien, der Entwicklung des Webservices und eines Testprogramms. Letzteres ist vorgeschrieben, um den Webservice im Produktivsystem von Endress+Hauser einsetzen zu dürfen. Die Vorgabe ist, dass das Testprogramm, welches alle neu implementierten Funktionen testet, mindestens einmal erfolgreich durchlaufen werden muss, bevor eine Verteilung in das Produktivsystem möglich ist. Diese Aktivierung ist aus Sicherheitsgründen nur durch wenige Personen möglich, da bei Übertragung von fehlerhafter Software 62 Screenshot des Endress+Hauser Konfigurators 6.0 mit kleinen Veränderungen 53

63 Das Projekt beispielsweise der Endress+Hauser Konfigurator nicht mehr verfügbar sein könnte. Dies könnte dazu führen, dass keine neuen Bestellungen mehr möglich sind und somit das Kerngeschäft von Endress+Hauser stark beeinträchtigt sein könnte. Daher ist das Testen der entwickelten Applikation notwendig. Endress+Hauser InfoServe nutzt dafür ein Tool, mit welchem Testfälle definiert werden können, welche von unabhängigen Testern durchgeführt werden. Zum Schluss ist eine Anpassung der Dokumentationen nötig, welche die Konfiguration betreffen, da bei weiteren Anpassungen oder Optimierungen auf diese zurückgegriffen wird. 5.3 Der neue Ablauf In der folgenden Abbildung ist der neue Bestellprozess dargestellt. Der größte Unterschied ist die Verschiebung der Prüfung auf technische Umsetzbarkeit der Konfiguration von der manuellen Arbeit in die automatisierte Arbeit des Endress+Hauser Konfigurators 6.0. Somit erhält der Kunde direkt Feedback, wenn die ausgewählte Konfiguration technisch nicht umsetzbar ist. Stark vereinfacht wird, wie in der nachfolgenden Abbildung sichtbar ist, unabhängig vom System, aus welchem der Endress+Hauser Konfigurator 6.0 aufgerufen wird, immer der gleiche Prozess durchlaufen. Mit dem Aufruf werden einige Basisinformationen wie das Produkt und die zu konfigurierende Stückzahl mit übergeben. Anschließend ruft der Konfigurator mehrere Webservices auf, welche alle Informationen für die Konfiguration laden. Nun ist es möglich, ohne weiteren Aufruf von Webservices die komplette Konfiguration durchzuführen. Neu hinzugekommen ist nun, dass am Ende der Konfiguration die Validierung über das SAP Beziehungswissen möglich ist. Sobald dies geschehen ist, ist die Konfiguration valide und wird als item.xml zurück an das rufende System gegeben um dort weiter verarbeitet zu werden. 54

64 Das Projekt SHOP PEA ERP CRM Product Item.xml E+H Configurator Version 6 Basic Configuration Tagging New TSP Alternative Measurement Rucksack Rucksack Validation SAP Dep. Validation Ident Web Services Basic Conf. MData TAG MData TSP MData Rucksack MData Corresponding ERP System Rucksack Valid. SAP Depen -dency Valid. Ident Inquiry PMD Pricing Engine Deliv. Time Engine Abbildung 13 - Technischer Ablauf der Konfiguration 63 Durch die Anpassung des Prozesses ist es zudem möglich, im PC keine erneute Prüfung durchzuführen, was für das PC eine enorme Zeitersparnis bedeutet, da die Produktverantwortlichen nicht bei jeder Konfiguration, welche ein technisches Problem beinhaltet, erneut Kontakt mit dem Kunden aufnehmen müssen. Alles in allem wird somit die manuelle Arbeit automatisiert. 63 Eigendarstellung 55

65 Das Projekt Abbildung 14 - Neuer Bestellprozess via Online Shop Eigendarstellung nach (Frey, 2015) 56

66 Zurück in die Zukunft 6 Zurück in die Zukunft 6.1 Vergangenheit Zusammenfassend wird erneut die Ausgangssituation betrachtet, in welcher nach einer Konfiguration des Kunden das Sales Center die Bestellung überprüft und anschließend an das verantwortliche Product Center weiter geleitet hat, welches auf Basis der kundenspezifischen eine technische Konfiguration abgeleitet hat. Mit dieser technischen Konfiguration war es möglich, mit Hilfe des SAP Beziehungswissens zu analysieren, ob die Konfiguration umsetzbar ist oder nicht. Wird die Idee, diesen Schritt der Validierung bereits während der Konfiguration zu durchlaufen, nur oberflächlich betrachtet, erscheint sie banal. Wird allerdings dieses Thema genauer beleuchtet, spielen einige wichtige und komplexen Systeme und Bausteine der SAP- und Endress+Hauser Welt eine wichtige Rolle, welche alle bedacht werden müssen. Eine der anspruchsvollsten Aufgaben war es, eine Schnittstelle für den Webservice zu finden, welcher aus dem Konfigurator aufgerufen werden kann um das SAP Beziehungswissen aufzurufen, zu finden. Eine weitere Herausforderung war ebenso, dass es nicht ohne Probleme möglich war eine Konfiguration aus dem Endress+Hauser Konfigurator 6.0 ohne Probleme in einem SAP System des Sales Center zu validieren, da dort einige Daten nicht vorhanden waren, die für diesen Vorgang nötig gewesen wären. Die Lösung für dieses Problem war die Pflege der Daten in einer bereits vorhandenen zentralen Datenbank und anschließende Verteilung in die SAP Systeme der Sales Center und Product Center. Alle weiteren Schritte waren für die Umsetzung kein großes Hindernis mehr, da dies Tätigkeiten waren, welche bereits bei der Entwicklung des Konfigurators bereits einige Male von Endress+Hauser InfoServe umgesetzt wurden. 57

67 Zurück in die Zukunft Mit der Integration des SAP Beziehungswissens in den SAP Konfigurator hat der Kunde nun die Gewissheit, dass sein Produkt keine technischen Schwierigkeiten bei der Umsetzung aufweisen wird. Es ist natürlich nicht auszuschließen, dass bei der Pflege durch die Product Center Fehler gemacht werden und dadurch das in der Konfiguration abgebildete Produkt in Realität nicht umgesetzt werden kann. Da das gesamte Projekt ausschließlich in einer Sandbox Umgebung und mit stark eingeschränktem Umfang der Produkte umgesetzt und getestet wurde ist nicht garantiert, dass bei einer Umsetzung in den Produktivsystemen der Endress+Hauser Gruppe keine Probleme auftreten. Des Weiteren ist fraglich, ob das Projekt für die komplette Endress+Hauser Gruppe überhaupt umgesetzt wird, da zum aktuellen Zeitpunkt nur ein Product Center daraus einen Vorteil ziehen könnte. Da allerdings alle Product Center für ein Gruppenprojekt dieser Größe finanzielle Mittel zur Verfügung stellen müssten, ist eine Umsetzung nicht realistisch. Alles in Allem ist es möglich das SAP Beziehungswissen in die Eigenentwicklung, den Endress+Hauser Konfigurator 6.0, zu integrieren. Es bedarf allerdings einer genauen Betrachtung der Vorteile für die Product Center, die Sales Center und natürlich den Kunden um den mit der Entwicklung verbundenen Aufwand zu rechtfertigen. 6.2 Zukunft Im Folgenden werden einige als realistisch betrachtete Ereignisse, welche den Endress+Hauser Konfigurator 6.0 und allgemein die Produktvielfalt betreffen, beschrieben. Ebenso wird betrachtet, welche Faktoren zu einer drastischen Veränderung im Konfigurationsumfeld beitragen könnten. Als eines der nächsten Projekte bei Endress+Hauser InfoServe könnte somit zum Beispiel die Erweiterung des Konfigurators mit grafischen Elementen sein. Es könnte sich dabei um technische Zeichnungen oder auch eine grafische Ansicht des aktuell konfigurierten Produkts, wie es zum Beispiel im Konfigurator in der folgenden Abbildung des Automobilherstellers Tesla der Fall ist, handeln. 58

68 Zurück in die Zukunft Abbildung 15 - Ausschnitt des grafischen Konfigurators des Automobilherstellers Tesla 65 Der Kunde hat somit die Möglichkeit, die Änderung seiner Konfiguration direkt an seinem Produkt zu sehen, und kann dieses auf seine bisherigen Produkte abstimmen oder sich manche Besonderheiten besser vorstellen. Des Weiteren könnte es vorstellbar sein, dass es bald eine neue Version des Offline Konfigurators geben wird. Die aktuell veröffentlichte Version wird einmal im Jahr per DVD verschickt und enthält somit nur die zu diesem Zeitpunkt aktuellen Produkte, Preise, Ausschlüsse und vieles mehr. Allerdings werden im Laufe des Jahres sehr oft Anpassungen an den Preisen oder den Ausschlüssen vorgenommen, was somit beim Bestellen der im Offline Konfigurator erstellten Konfiguration, zu Problemen führen kann, da sich ein Preis für ein Produkt verändert hat oder ein neuer Ausschluss auf ein Merkmal oder eine Merkmalswertkombination erstellt wurde. Eine mögliche Umsetzung wäre dabei, eine installierbare Version des Endress+Hauser Konfigurators 6.0 zu entwickeln, welcher als Fundament eine lokale Datenbasis nutzt. Diese Datenbasis kann lokal auf dem Rechner gespeichert werden, um so eine erfolgreiche Konfiguration auch ohne Internetzugang zu gewährleisten. 65 Screenshot von (Tesla, 2015) 59

69 Zurück in die Zukunft Als IT-Dienstleister für die Endress+Hauser Gruppe ist es, wie bereits erwähnt, die Aufgabe von Endress+Hauser InfoServe neue Trends, welche für Endress+Hauser einen Vorteil gegenüber der Konkurrenz bringen, zu erkennen und auf diese aufzuspringen. Einer dieser Trends ist die intensivierte Nutzung von mobilen Endgeräten. Diese werden in der gesamten Endress+Hauser Gruppe bereits genutzt. Eine mögliche Idee wäre daher, für Vertriebs- oder Servicemitarbeiter eine Installation des Endress+Hauser Konfigurators auf einem Tablet vorzunehmen. Dies hätte den Vorteil, dass der Kunde vor Ort sehen könnte, welche Konfiguration für sein Produkt möglich ist oder nicht und der Vertriebsmitarbeiter ihm sofort mögliche Fragen beantworten könnte. Wie in der nachfolgenden Abbildung zu sehen ist, könnte der aktuelle Konfigurator vom Design sehr gut verwendet werden. Ebenso wie bei der auf dem Computer installierbaren offline Version, sollte auch diese Version keine dauerhafte Internetverbindung voraussetzen. Abbildung 16 - Idee des mobilen Endress+Hauser Konfigurators Eigendarstellung mit Screenshot des aktuellen Endress+Hauser Konfigurators 6.0 und dem Apple ipad 60