Universität Passau Fakultät für Informatik und Mathematik. Lehrstuhl für Mathematik Schwerpunkt Digitale Bildverarbeitung. Prof. Dr.

Größe: px
Ab Seite anzeigen:

Download "Universität Passau Fakultät für Informatik und Mathematik. Lehrstuhl für Mathematik Schwerpunkt Digitale Bildverarbeitung. Prof. Dr."

Transkript

1 Universität Passau Fakultät für Informatik und Mathematik Lehrstuhl für Mathematik Schwerpunkt Digitale Bildverarbeitung Prof. Dr. Tomas Sauer Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) Konzept eines zentralen Fertigungsdaten-Management-Systems Florian Bürchner Studienfach Informatik Erstprüfer Prof. Dr. Tomas Sauer Zweitprüfer Prof. Dr. Ilia Polian Matrikelnummer Datum 7. Mai 2014

2

3 Danksagung Zunächst möchte ich mich bei all denjenigen bedanken, die mich während der Anfertigung dieser Masterarbeit unterstützt und motiviert haben. Ganz besonders gilt dieser Dank Prof. Dr. Tomas Sauer, der den Kontakt zur ZF Friedrichshafen AG für mich bereits im Rahmen eines Praktikums und nun auch für diese Abschlussarbeit hergestellt hat und Dr. Werner Schnitzlein, der seitens der ZF dieses interessante Thema ermöglicht hat und sich für eine Kooperation zwischen Universität und Unternehmen einsetzt. Weiterhin bedanke ich mich bei Prof. Dr. Ilia Polian, der sich als Zweitprüfer zur Verfügung gestellt hat. Ebenfalls bedanken möchte ich mich bei meinem Betreuer Dipl.-Inf. Joseph Mandic für seine ausgiebige Unterstützung und seine konstruktive Kritik, die mich oft auf den richtigen Kurs zurückgebracht hat. Weiterhin danke ich Dipl.-Ing. Ralf Kleinschmidt ohne dessen Hilfe und Bemühungen in etlichen Diskussionen diese Arbeit nicht zustande gekommen wäre. Auch M. Eng. Patrick Peter danke ich, dass er mir stets mit Rat und Tat zur Seite stand und immer ein offenes Ohr für mich hatte. Außerdem bedanke ich mich bei B. Eng. Alex Nowitschkow, der immer für mich ansprechbar war und mich mit guten Ideen unterstützt hat. Nicht zuletzt gebührt meiner Familie großer Dank, insbesondere meinen Eltern, die mir mein Studium ermöglicht und mich in all meinen Entscheidungen unterstützt haben. 3

4 4

5 Inhaltsverzeichnis Abkürzungsverzeichnis 7 1. Einleitung Problemstellung Motivation Zielsetzung Abgrenzung Überblick Systemlandschaft PLM Strategie Applikationen im FDO Bereich Übersicht Axalant FATool SAP EdgeCAM ProE/CREO Schnittstellen Grundlagen Systemanalyse Standards Architektur Frameworks Anforderungsanalyse Methoden Modellierung Ist Zustand Übersicht Status Quo Aufbau Datenbank Schnittstelle Interaktive Rückgabe Transferdaten

6 Inhaltsverzeichnis 4.3. Schwachstellen im Ist Zustand Zusammenfassung Soll Konzept Szenario Bestehendes Soll Konzept Übersicht Lastenheft Schwachstellen Bewertung Erweitertes Soll Konzept Erweiterungen im Lastenheft Schwachstellen des Ist Zustands Schwachstellen des Soll Zustands Zusammenfassung Umsetzung Problemstellung Ansatz Implementierung Synchronisation von Materialien Parsen der Transfer Queue Suche nach Dokumentstämmen Überprüfen der Wiedervorlage Verifikation Fazit 123 Anhang 124 Tabellenverzeichnis 143 Abbildungsverzeichnis 145 Literaturverzeichnis 147 6

7 Abkürzungsverzeichnis BLD Bildkennung BOM Bill of materials BTL Bauteil CAD Computer Aided Design CAE Computer Aided Engineering CAM Computer Aided Manufacturing DMZ Demilitarized Zone DNC Distributed Numerical Control ERP Enterprise Ressource Planning FDM Fabric Data Management FDO Fertigungsdatenorganisation FHM Fertigungshilfsmittel KWZ Komplettwerkzeug PDM Product Data Management PDO Produktdatenorganisation PLM Product Lifecycle Management SMID Sachmerkmal ID SML Sachmerkmalleiste WKZ Werkzeuge

8 Abkürzungsverzeichnis 8

9 1. Einleitung Die Frage nach der optimalen IT Struktur im Cloud Zeitalter stellt Unternehmen heutzutage vor große Herausforderungen. Der Wunsch interne Daten weltweit und standortunabhängig zur Verfügung zu stellen wirft die Frage auf, ob periphere Systeme wie die IT Landschaft besser zentral organisiert oder als verteilte Ressourcen verwaltet werden sollen. Der Grund für eine Neuausrichtung sind oftmals neue Anforderungen an alte Systeme, die teilweise eine Anpassung der IT Architektur des gesamten Unternehmens nach sich ziehen. Dabei sind diese Anpassungen unumgänglich, um neue Technologien und Lösungen nutzen zu können und somit die Wettbewerbsfähigkeit zu wahren. Auch die Zentralisierung bringt eine Reihe von Vorteilen gegenüber verteilten, dezentralen Systemen mit sich. Neben der Möglichkeit an allen Standorten auf zuverlässige und aktuelle Daten und Dokumente zuzugreifen, was durch einen konsistenten und einheitlichen Datenbestand sichergestellt wird, können neue Standorte auch leichter in die schon bestehende IT Landschaft integriert werden. Doch die Zentralisierung wirft auch neue Fragen auf wie Zugriffskontrollen, die Konfliktbehandlung oder die Performanz beim Zugriff. Für die Zentralisierung eines bestehenden Systems sind mehrere Architekturmodelle denkbar, die abhängig von bestimmten Qualitätsfaktoren mehr oder weniger geeignet sind. Diese Faktoren beziehen sich auf technische Anforderungen wie die Qualität der Netzanbindung der verschiedenen Standorte, die Zugriffsmethoden auf einzelne Dateien oder logische Faktoren wie Zugriffsberechtigungen. Den vorgestellten Architekturen ist allen ein Master System übergeordnet, das in regelmäßigen zeitlichen Intervallen Kenntnis über alle im Netz existierenden Daten hat. Abbildung 1.1.: Direktzugriff auf den Master Server Das bekannteste Modell der Zentralisierung stellt der Direktzugriff dar, wie er in Abbildung 1.1 dargestellt ist. Hierbei greifen entfernte Standorte direkt auf den Master Server 9

10 1. Einleitung zu, was zum Vorteil hat, dass viele Probleme, wie sie durch vollständig verteilte Systeme entstehen, wegfallen. Die Zugriffsberechtigungen können leichter umgesetzt werden und der Freigabestatus sowie Änderungen an Dateien stehen immer zuverlässig und aktuell zur Verfügung. Der entscheidende Aspekt bei diesem Modell ist aber dennoch die Datenübertragungsrate zwischen den Standorten, da die entsprechenden Dateien oft sehr groß sind und dies inakzeptable Zugriffszeiten nach sich ziehen kann. Abbildung 1.2.: Replikation der Dateien auf den Slave Eine mögliche Lösung für dieses Problem wäre die Trennung von den eigentlichen Dateien und deren Meta Daten, sodass ausschließlich die Dateien auf die verschiedenen Standorte repliziert werden, die Meta Daten aber zentral gehalten und über das Netz abgerufen werden. In einem solchen hybriden System, wie es in Abbildung 1.2 zu sehen ist, sind die Zugriffszeiten auf Dateien deutlich verbessert. Dennoch müssen die Dateien auf die dezentralen Server der einzelnen Standorte repliziert werden und bei Änderungen auch wieder mit dem Master Server abgeglichen werden. Da dies durch die großen Datenmengen nur in bestimmten zeitlichen Abständen möglich ist, kann es sein, dass Dateien und die zugehörigen Meta Daten zeitweise inkonsistent vorliegen. Abbildung 1.3.: Replikation der Dateien inklusive der Meta Daten auf den Slave Eine weitere Möglichkeit ist die Replikation, wie sie in Abbildung 1.3 dargestellt ist. Hierbei handelt es sich bei den dezentralen Servern der einzelnen Standorte um eine komplette Kopie des Master Servers inklusive der Meta Daten. Dadurch ergibt sich nun auch ein asynchroner Abgleich, der Konflikte nach sich ziehen kann, wenn Dateien und damit die zugehörigen Meta Daten auf verschiedenen Systemen gleichzeitig verändert werden. Bei großen Dateien und gleichzeitig schlechter Netzanbindung kann dieses Modell den Zugriff auf Daten erleichtern, schafft aber dadurch auch die typischen Probleme, wie sie bei verteilten Systemen auftreten. [ES09] 10

11 1.1. Problemstellung In dieser Arbeit soll das aktuelle Architekturmodell der Fertigungsdaten Management Software FATool für die ZF Friedrichshafen AG analysiert werden und weitere konzeptionelle Modelle entwickelt werden, die eine Zentralisierung berücksichtigen Problemstellung Eine unternehmensweit zentrale Ausrichtung der Fertigungsdaten Management Software FATool ist das Thema dieser Arbeit. Ein Konzept über den Soll Zustand ist bereits vorhanden, wobei durch den hohen Detailgrad der Beschreibung beim Leser bereits tiefe Einsichten in das System gefordert sind und damit keine Transparenz vermittelt werden kann. Die aufgeschlüsselten Anwendungsfälle beschreiben bisher nur die Anforderungen an das System, reflektieren aber nicht die Probleme, die in der Praxis auftreten können. Vor diesem Hintergrund muss neben einer detaillierten Dokumentation auch eine exakte Analyse durchgeführt werden, die untersucht, ob bereits im Ist Zustand bestehende Probleme durch das neue Konzept gelöst werden können oder dadurch neue Probleme hervorgerufen werden. In Anbetracht der gefunden Schwachstellen soll ein eigenes Konzept zur Zentralisierung erarbeitet werden, das Lösungsansätze für die bekannten Probleme bietet. Die Suche nach Lösungen für Anforderungen an den Ist Zustand stellt einen weiteren wichtigen Punkt im Prozess der Zentralisierung dar. Dabei handelt es sich um Probleme, die bereits bekannt sind, aber bisher nicht gelöst werden konnten. Es ist offensichtlich, dass solche Schwachstellen vor der eigentlichen Zentralisierung gelöst werden müssen, denn Anforderungen an die Systeme, die im Ist Zustand nicht funktionieren, werden auch im Soll Zustand nicht funktionieren können Motivation Der bedeutendste Punkt der Zentralisierung ist die konzernweite Nutzung aller produktionsrelevanten Daten. Da produzierende Betriebe meist eine große Menge an Objekten in ihrem Materialstamm verwalten, ist es von enormer Bedeutung vor der Entwicklung eines neuen, aktuell erforderlichen Teils zu wissen, ob ein solches an einem anderen Standort schon existiert. Die Entwicklung neuer Materialien ist aufwendig, denn sie müssen entworfen, gezeichnet und im PDM System mit Teilestamm und Stückliste angelegt werden. Deshalb ist es nicht nur kostengünstiger, sondern auch zeitsparender, bereits existierende Teile wieder zu verwenden, als eine Neuentwicklung zu veranlassen. Ein weiterer positiver Nebeneffekt der zentralen Verwaltung ist, dass alle Benutzer auf einen einheitlichen Datenbestand zurückgreifen können. Des Weiteren wird die Anbindung neuer Standorte an das zentralisierte System vereinfacht, da die Architektur nicht mehr entscheidend verändert werden muss. 11

12 1. Einleitung 1.3. Zielsetzung Mit der vorliegenden Arbeit soll ein Beitrag geleistet werden, um den Prozess der Zentralisierung zu unterstützen und nachhaltig zu verbessern. Im Einzelnen werden dabei folgende Ziele verfolgt: Dokumentation des Ist Zustands und des bereits existierenden Soll Konzepts für spätere Supportaufgaben Analyse der bestehenden Konzepte anhand wissenschaftlicher Kriterien und Identifizierung eventueller Schwachstellen Bereitstellen eines eigenen Soll Konzepts unter Berücksichtigung der aufgedeckten Schwachstellen mit entsprechenden Lösungsansätzen Erarbeitung von technischen Lösungen der Schwachstellen des Ist Zustands für einen reibungslosen Betrieb des zentralisierten Konzepts Durch die gewonnenen Erkenntnisse werden Empfehlungen für die Umsetzung der Zentralisierung ausgesprochen. Während die Analyse der bestehenden Systeme rein konzeptionell durchgeführt wird, soll für eine der gefundenen Anforderungen eine Lösung erarbeitet und diese im Anschluss implementiert und validiert werden Abgrenzung Untersuchungsgegenstand dieser Arbeit ist die Zentralisierung der FDM Software FATool. Dieser Prozess betrifft verschiedene Bereiche, zum Einen die Applikation selbst, zum Anderen die Umstellung bzw. Vorbereitung der Systeme und Schnittstellen innerhalb des ZF Konzerns. Während der innere Aufbau von FATool aufgrund des geschlossenen Quellcodes als Black Box zu betrachten ist, liegt die Verantwortung für die Vorbereitung der systemeigenen Strukturen innerhalb der ZF Friedrichshafen AG. Aus diesem Grund beschäftigt sich diese Arbeit mit der Analyse der vorhandenen Konzepte und eigenen Konzeptvorschlägen. Es wird jedoch kein Leitfaden geliefert der die Zentralisierung im Detail beschreibt. Dies erfordert eine enge Zusammenarbeit mit dem Software Hersteller und ist nicht als ein Ein Mann Projekt zu verstehen. Vielmehr soll diese Arbeit einen Baustein im Prozess der Zentralisierung darstellen. Bei den Schnittstellen wird aus Gründen der Komplexität nur die Axa2FASys Schnittstelle betrachtet. Andere Schnittstellen werden nur funktional beschrieben. 12

13 1.5. Überblick 1.5. Überblick Die Gliederung der Arbeit ist darauf ausgelegt beim Leser ein Verständnis über die Gesamtproblematik der Zentralisierung des FDM Systems mit denen im ZF Konzern eingesetzten Systeme zu entwickeln. Die beteiligten System werden exemplarisch am Standort Passau aufgezeigt. Daraufhin werden die notwendigen theoretischen und wissenschaftlichen Grundlagen erarbeitet und im Anschluss bei der Analyse und Konzeption angewendet. In Kapitel 2 soll zunächst ein Überblick über alle Systeme gegeben werden, die in Beziehung zu FATool stehen. Des Weiteren sollen die Schnittstellen zwischen diesen Systemen und FATool beschrieben werden. Das Kapitel 3 stellt den Theorieteil dieser Arbeit dar und soll die nötigen Grundlagen für eine Analyse und Bewertung von Software Architekturen schaffen. Darauf aufbauend wird in Kapitel 4 der Ist Zustand dokumentiert und analysiert und anschließend seine Schwachstellen ausgearbeitet. In Kapitel 5 wird das bereits bestehende Soll Konzept analysiert und ein eigenes Konzept erarbeitet, das die bereits herausgestellten Schwachstellen beseitigt. Kapitel 6 beinhaltet einen Lösungsansatz für eine der zuvor analysierten Anforderungen. Es umfasst außerdem deren Implementierung und Validierung. In Kapitel 7 wird abschließend ein Fazit abgegeben, in dem der Fortschritt im Hinblick auf den Beginn der Arbeit beleuchtet wird und ein Ausblick auf zukünftige Aufgabenfelder der Zentralisierung gegeben werden. 13

14 1. Einleitung 14

15 2. Systemlandschaft Die ZF Friedrichshafen AG ist ein weltweit agierendes Unternehmen mit Mitarbeitern in 26 Ländern mit 121 Produktionsgesellschaften. Im Jahr 2011 wurde der Konzern neu strukturiert und besteht seither aus den vier Divisionen Antriebstechnik, Fahrwerkstechnik, Nutzfahrzeugtechnik und Industrietechnik. Die Geschäftsfelder der Divisionen können Abbildung 2.1 entnommen werden. Des Weiteren besteht das Gemeinschaftsprojekt ZF Lenksysteme GmbH, an dem die ZF Friedrichshafen AG und die Robert Bosch GmbH jeweils zur Hälfte beteiligt sind. [ZF12b] Aktionäre: 93,8 % Zeppelin-Stiftung und 6,2 % Dr. Jürgen und Irmgard Ulderup Stiftung Antriebstechnik Fahrwerktechnik Nutzfahrzeugtechnik Industrietechnik Lenksysteme* Automatgetriebe Handschaltgetriebe / Doppelkupplungsgetriebe Achsgetriebe Antriebsmodule Gusstechnologie Achssysteme Fahrwerkkomponenten Gummi & Kunststoff Dämpfungsmodule Lkw- und Van- Antriebstechnik Bus-Antriebstechnik Nkw-Achssysteme Nkw-Fahrwerkmodule Nkw-Dämpfertechnologie Arbeitsmaschinensysteme Prüfsysteme Sonder-Antriebstechnik Marine-Antriebstechnik Luftfahrt-Antriebstechnik Windkraft-Antriebstechnik Pkw-Lenksysteme Nkw-Lenksysteme Pkw-Lenksäulen Global Aftermarket Nkw-Antriebsstrangmodule * ZF Lenksysteme GmbH ist ein Gemeinschaftsunternehmen, an dem die ZF Friedrichshafen AG und die Robert Bosch GmbH jeweils zu 50 % beteiligt sind. Stand: Mai Abbildung 2.1.: Strukturierung des ZF Konzerns [ZF12b] Als Global Player hat der ZF Konzern auch hohe Anforderungen an seine IT Systeme. Die Globalisierung fordert die Verfügbarkeit von Daten unabhängig von Standorten und setzt voraus, dass während aller Phasen des Produktlebenszyklus ein gemeinsamer Zugriff auf alle für das Produkt relevanten Informationen gegeben ist. ([ES09], S. 18) Nachfolgend werden für die weitere Arbeit wichtige Begriffe definiert. Im Anschluss werden die verschiedenen Systeme am Standort Passau erklärt, die in dieser Strukturierung in vielen anderen ZF Standorten eingesetzt werden. Des Weiteren werden auch die Kommunikationskanäle zwischen den einzelnen Systemen beschrieben. 15

16 2. Systemlandschaft 2.1. PLM Strategie Für Unternehmen, die in einem globalen Umfeld agieren, ist es Voraussetzung dynamisch auf sich wandelnde Märkte zu reagieren, um ihre Wettbewerbsfähigkeit zu wahren. Dieser Markt fordert eine ständige Verbesserung der Durchlaufzeiten von Produkten, reduzierte Kosten über den gesamten Produktlebenszyklus, zunehmende Absicherung bezüglich der Produkthaftung und den daraus abgeleiteten Regeln für das Qualitätsmanagement. Abbildung 2.2.: Phasen im Produktlebenszyklus [Bau06] Daraus ergeben sich neue Anforderungen an den Produktentstehungsprozess, der aus der Produktentwicklung und der Entwicklung von Fertigungstechnologien besteht. Der Produktentstehungsprozess umfasst die komplette Planung und Entwicklung von Produkten und ihren zugehörigen Betriebsmitteln, Ressourcen, Fertigungs und Montageprozessen, deren Herstellung sowie Nutzung, Betrieb und Recycling. In Abbildung 2.2 sind die einzelnen Phasen des Lebenszyklus mit ihren zugeordneten Tätigkeiten abgebildet. [ES09] Dies bedeutet für die IT, alle betroffenen Bereiche wie Mensch, Daten und Prozesse zu verknüpfen, um die Produkt und Prozesskomplexität beherrschen zu können. Die hierfür eingesetzte Strategie heißt Product Lifecycle Management (PLM), das durch die Konsolidierung verschiedener Systeme eine Informationsstrategie definiert, die für jedes Unternehmen speziell und damit einzigartig ist. Durch eine vollständig vernetzte Unternehmenswelt ermöglicht das PLM eine unternehmensübergreifende Arbeitsteilung, um Produkte zu entwickeln, zu produzieren, zu unterstützen oder schließlich wieder vom Markt zu nehmen. Der Stellenwert der PLM Strategie wird deutlich, wenn man bedenkt, dass die Neuentwicklung eines Kraftfahrzeugs in Europa und den USA vor zwanzig Jahren rund sechs bis sieben Jahre dauerte, während es heute nur noch zwei bis drei Jahre sind. [Sen09] Die Hauptaufgabe besteht in der Verwaltung aller Informationen, die am Lebenszyklus eines Produktes beteiligt sind, um eine bessere Kontrolle über die Teilprozesse zu erhal- 16

17 2.1. PLM Strategie ten und dadurch eine transparente Aufstellung über Aufwände und Erträge ermitteln zu können. Die Vorteile, die sich daraus ergeben, sind im Einzelnen: Time-to-Market reduzieren Zeit- und Kostenreduktion Qualitätsverbesserung der Produkte Erhöhung der Innovation Um diese Ziele zu erreichen werden IT Lösungen verwendet, die die virtuelle Produktentstehung unterstützen. Eine wesentliche Rolle spielen dabei die sogenannten Autorensysteme, wie Computer Aided Design (CAD) mit dem die funktionalen und geometrischen Grundlagen des Produkts erarbeitet werden, Computer Aided Manufacturing (CAM), das zur Steuerung von Fertigungs und Montagemaschinen dient und Computer Aided Engineering (CAE) mit dessen Hilfe die Technologien zur Simulation und Berechnung zur Verfügung gestellt werden. [ES09] Ein ganz wesentlicher Bestandteil eines vollständigen PLM Konzepts ist ein Enterprise Ressource Planning (ERP) System, das die verfügbaren Ressourcen für den betrieblichen Ablauf optimiert. So lassen sich Ressourcen wie Kapital, Betriebsmittel und Personal steuern, kontrollieren und koordinieren. Den Kern einer jeden PLM Strategie bildet jedoch das Product Data Management (PDM) System, das die zentrale Lösung für den Produktentstehungsprozess darstellt. Die ersten PDM Systeme dienten zur Dokumentverwaltung und sind aus der Problematik heraus gewachsen die zunehmende Anzahl an CAD Dokumenten zusammen mit den gescannten Papierdokumenten zu verwalten. Schnell wurden die PDM Systeme auch an die Produktstruktur angebunden, was die Einführung von unternehmensweit harmonisierten Stammdaten und Stücklistenstrukturen zur Folge hatte. Deshalb bildeten PDM Systeme den Grundstein des heutigen PLM Konzepts und sind daher als der administrative Backbone 1 zu sehen. PLM ist aber nicht nur ein Baukasten aus verschiedenen Softwarelösungen, die gebündelt eingesetzt werden, sondern vielmehr eine integrierte Philosophie und Vorgehensweise mit einer ganzheitlichen Behandlung und Beeinflussung des Produktlebens. Das heißt, PLM kann nicht als einmalige Aufgabe gesehen werden, da es aufgrund der Integrationsfähigkeit ein Dauerzustand ist. Der ständige Zuwachs an 2D und 3D Daten, sowie abgeänderte Prozesse und neue Anforderungen an das Management von Fertigungsdaten innerhalb des ZF Konzerns, machten es erforderlich zwischen Produktdaten und Fertigungsdaten zu unterscheiden. Während die Produktdatenorganisation (PDO) alle Dokumente und Objekte für die Entwicklung eines Produktes verwaltet, werden bei der Fertigungsdatenorganisation (FDO) alle Daten verwaltet, die für die Herstellung des Produktes relevant sind. Dazu zählen unter anderem die Fertigungshilfsmittel (FHM), die als Unterkategorie der Betriebsmittel einzuordnen sind, allerdings nicht an einen bestimmten Ort gebunden sind. Im Gegensatz 1 Ein Backbone als Teil eines Computernetzwerkes verbindet mehrere Netzwerke miteinander und stellt so die Möglichkeit zum Informationsaustausch zur Verfügung. 17

18 2. Systemlandschaft zu Maschinen sind Werkzeuge (WKZ), Spannmittel und Vorrichtungen für Maschinen, aber auch die NC-Programme zur Steuerung der Maschinen als typische FHM zu benennen. Wie in Abbildung 2.3 zu sehen ist, beginnt die PDO weit früher als die FDO, da die FDO um die Produkte herum arbeitet und damit für die Produktion relevant ist. Dies bedeutet konkret, falls sich am Produkt etwas ändert, so ändern sich auch die entsprechenden Betriebsmittel der Fertigung. Obwohl die Administrationsprozesse unterschiedliche Bereiche abdecken, werden sie beide durch das standardisierte PDM System verwaltet. Sie basieren also auf einer einheitlichen Datenbank, aber stellen unterschiedliche Sichten auf das gleiche System zur Verfügung, sodass durch diese Sichten die spezifischen Management Prozesse repräsentiert werden. Abbildung 2.3.: Eingliederung des PDO und FDO Prozesses [ZF12a] Die Stammdaten und Dokumenttypen werden gleich verwaltet, dennoch gibt es einige Unterschiede in den Prozessen, die in Tabelle 2.1 dargestellt sind. PDO Prozess Komplexes Statusnetz (ca. 70 Level) Viele Prozessschritte (>300 Übergänge) Viele Verantwortlichkeiten Änderungsmanagement Komplexe Stücklisten Lange Entwicklungszyklen FDO Prozess Einfaches Statusnetz (7 Levels) Wenige Prozessschritte (30 Übergänge) Wenige Verantwortlichkeiten Kein Änderungsmanagement Einfache Stücklisten (FHM) Kurze Entwicklungszyklen Tabelle 2.1.: Gegenüberstellung von PDO und FDO [ZF12a] Die Vorteile, die sich aus der Trennung dieser Prozesse ergeben, sind: Erhöhte Prozesssicherheit durch weniger Management Aufwand Fehlerminimierung und schnellere Verfügbarkeit Kosten und Bestandsreduktion Systeme, die sich mit der Verwaltung und Organisation der Fertigungsdaten befassen, heißen Fabric Data Management (FDM) Systeme. 18

19 2.2. Applikationen im FDO Bereich 2.2. Applikationen im FDO Bereich Im Folgenden werden die bisher vorgestellten Systeme konkret benannt und ihre Aufgaben und Einsatzgebiete erläutert. Außerdem werden Interaktionen zwischen den Systemen gesondert dargestellt Übersicht In Abbildung 2.4 ist eine eingeschränkte Sicht auf die am Standort Passau eingesetzten IT Systeme gegeben. Diese Übersicht erhebt keinen Anspruch auf Vollständigkeit und soll lediglich die Beziehungen zwischen den Systemen genauer darstellen. Andere Sichtweisen auf die verwendeten Systeme sind möglich, jedoch für diese Arbeit nicht relevant. Abbildung 2.4.: IT Systeme im FDO Bereiche am Standort Passau [Pet12] Das Herzstück stellt das globale PDM System Axalant dar, das ortsunabhängig und unternehmensübergreifend zur Verfügung steht. Hier sind alle Daten abgelegt, die entweder der PDO oder FDO zugeordnet sind, sodass alle Softwaresysteme entweder direkt oder indirekt durch andere Systeme mit Axalant in Verbindung stehen. Im Mittelpunkt dieser Arbeit steht das FDM System FATool, das ebenfalls eng mit Axalant verknüpft 19

20 2. Systemlandschaft ist. FATool wird ebenfalls direkt aus der Produktion heraus genutzt und besitzt außerdem eine direkte Schnittstelle zum ERP System SAP, dem CAD System ProE/CREO und der CAM Anwendung EdgeCAM. Mit NC-Simul ist es möglich das Bewegungsprofil der Maschine anhand der NC-Programme, die von EdgeCAM geliefert werden, zu simulieren. PartSolutions bietet normgerechte Beschreibungen von Einzelteilen in Form von 3D-Modellen, die vor allem von den CAD Systemen verwendet werden. AutoCAD ist ebenfalls ein CAD System, das für die Zeichnung von 2D-Modellen verwendet wird Axalant Das PDM System Axalant ist das strategische und technische Informationssystem und dient der Speicherung, Verwaltung und Bereitstellung aller produkt- und fertigungsbezogenen Daten und Dokumente. Es ist ein globales, unternehmensweites System, das durch eine Verteilung der Informationen eine enge Zusammenarbeit in der Entwicklung und Produktion über den gesamten Globus ermöglicht. [ZF10] Die Vorteile, die sich durch den Einsatz des PDM Systems ergeben, sind im Einzelnen: Gezielter und geschützter Zugriff auf aktuelle, technische Unterlagen und Dokumente rund um die Uhr, unabhängig vom Standort im ZF Netzwerk Verwaltung von Produktdaten und technischen Dokumenten, als auch Fertigungshilfsmitteln entlang des Produktentstehungsprozesses Weltweite Kollaboration in der Erstellung und Änderung von gemeinsamen Daten Im Folgenden wird auf die wichtigsten Eigenschaften des globalen PDM Systems eingegangen. Klassensystem Ein Klassensystem dient der Ordnung und Strukturierung von gleichartigen Elementen für die eine Beschreibung gegeben ist. Es besteht aus mehreren einzelnen Klassen, die durch bestimmte Merkmale beschrieben werden, wobei die Zuordnung der Merkmale je nach Klasse variiert. Eine Klasse fast somit Elemente zusammen, die gleiche oder ähnliche Merkmale besitzen. Das Zuordnen eines Materialstamms zu einer Klasse nennt man Klassifizierung, wobei die Übersicht über alle Elemente einer Klasse, mit deren Merkmalen und Merkmalswerten, Sachmerkmalleiste (SML) genannt wird. Das Zuweisen von Merkmalswerten zu den einzelnen Sachmerkmalen, wird im Allgemeinen Bewertung genannt. Die spezifische Beschreibung von Objekten durch Merkmalswerte erlaubt eine gezielte Suche nach Elementen mit bestimmten Merkmalen. Neben einer Kosten- und Zeitersparnis und der Minimierung für das Anlegen von redundanten Daten, durch eine gewissenhafte Beschreibung von Objekten, ergeben sich durch das Klassensystem folgende Vorteile: Elemente können nach bestimmten Ordnungskriterien zusammengefasst werden Materialien können genauer beschrieben werden Der Ergebnisraum der Materialsuche ist eingeschränkt Die Suche nach Materialien verkürzt sich 20

21 2.2. Applikationen im FDO Bereich Die Klassen selbst sind hierarchisch angeordnet und stellen mit spezifischen Ober- und Unterklassen einen Klassenbaum dar. Die Oberklassen sind grundsätzlich abstrakte Klassen und beinhalten Unterklassen, wobei die Blätter des Baumes die eigentlichen Materialien sind. Abbildung 2.5.: 2D Sachmerkmale nach DIN4000 [Pet12] Für die Klassifizierung wird die DIN verwendet, die als Basis für eine einheitliche Beschreibung der Sachmerkmalleisten dient und als Standard innerhalb des ZF-Konzerns gilt. Der Aufbau der DIN4000 ist in eine vierstufige Hierarchie eingeteilt, wobei die erste Ebene die Sachmerkmal-Normen enthält, die zweite Ebene die Gegenstandsgruppen, die dritte Ebene die Teilefamilien und als vierte Ebene die Bildkennung (BLD), die ähnlichen Materialien unterschiedliche Merkmalsattribute zuweist. In Abbildung 2.5 ist ein Stufenbohrer mit drei Stufen abgebildet. Dieser ist in der DIN Bohr und Senkwerkzeuge mit nicht lösbaren Schneiden zu finden und besitzt die Bildkennung 2. Die BLD ordnet diesem Stufenbohrer die Merkmale zu, die aus der Abbildung ersichtlich werden, wie als Beispiel B4 Nutzlänge, B5 Gesamtlänge, B6 Spannutenlänge etc. Stammdaten Als Stammdaten werden jene Daten bezeichnet, die selbstständig, ohne Beziehung zu anderen Daten aussagefähig sind. Dabei wird in Axalant zwischen den Typen Materialstamm und Dokumentenstamm unterschieden. Beiden gemeinsam sind identifizierende Attribute, die zur eindeutigen Bestimmung eines Stammsatzes dienen, wie die Dokument- oder Materialnummer und den Funktionsattributen, die zusätzliche Informationen für anderweitige Prozesse bereit halten. Der Materialstamm definiert Materialien, also physikalisch greifbare Objekte, über einen Materialstammsatz, der die zur Verwaltung eines Materials notwendigen Informationen, wie Materialnummer, Benennung, Werkstoff, Abmessung, Status bereithält. Der Dokumentenstammsatz hingegen beschreibt das Material und bezeichnet einen Datensatz mit Metadaten, wie Dokumentnummer, Benennung, Gültigkeit und den zugeordneten Dateien. Durch die Metadaten werden alle Informationen bereit gehalten, die zur Identifikation, zum Austausch, zur Verwaltung und Nutzung eines Dokuments benötigt werden. [ZF13] 2 Diese Norm legt Begriffe und Grundsätze zur Gestaltung von Merkmalen, Merkmal Listen und Konformitätsklassen fest. Diese Merkmale bilden die Grundlage der Kommunikation, zum Beispiel zwischen Anwendern und Lieferanten. Ein weiteres Ziel ist die Kategorisierung dieser Merkmale in Konformitätsklassen, unter anderem zur Vereinheitlichung des Datenaustauschs. 21

22 2. Systemlandschaft Berechtigungen Die Berechtigungskontrolle in Axalant ist hierarchisch in vier Stufen aufgebaut und dient primär zum Schutz der hinterlegten Informationen. 1. Stufe: Sichtbarkeit Die Sichtbarkeit beschränkt den Zugriff auf Metadaten von Stammsätzen und wird über Verteilerflags gesteuert. Nur an Standorten für die das Verteilerflag an einem spezifischen Datensatz gesetzt ist, können diesen auch einsehen. 2. Stufe: Rollen Durch Rollen werden unterschiedliche Berechtigungsstufen umgesetzt, die verschiedene Funktionen, wie Anlegen, Bearbeiten oder Betrachten, an einem Stammsatz freigeben. Rollen sind als ein Container zu verstehen, der alle einem Benutzer zugewiesenen Berechtigungen umfasst. Bei jeder ausgeführten Aktion in Axalant wird unabhängig vom Datensatz überprüft, ob der Anwender die entsprechenden Rollen besitzt. 3. Stufe: Änderungshoheiten Die Änderungshoheit ist als vierstellige Zahlenkombination angegeben und ist Datensätzen als auch Anwendern zugeordnet. Durch die Änderungshoheit wird das für eine Änderung zuständige ZF-Geschäftsfeld bestimmt, sodass Anwender nur Datensätze verändern können bei denen die Änderungshoheiten mit der des Anwenders übereinstimmen. 4. Stufe: Owner Group World Prinzip Jeder Datensatz in Axalant ist einem bestimmten Eigentümer und damit einer Gruppe zugeordnet. So kann für jeden Datensatz explizit angegeben werden welche Rechte der Eigentümer, die zugehörige Gruppe und alle anderen besitzen. Die möglichen Rechte sind eingeteilt in kein Zugriff, lesen, schreiben und löschen. Stücklisten Durch Stücklisten (engl. Bill of materials (BOM)) wird in einer strukturierten Anordnung von Objekten beschrieben, welche Materialien oder andere Positionen wie Stücklistentexte in einem Produkt verwendet werden. Die Stücklisten sind entsprechend im Materialstamm hinterlegt und werden in Axalant angelegt und geändert. Status Der Statuswechsel am FDO Materialstamm dient zur Darstellung des Reifegrades. Die Übergänge zwischen den Status sind in Abbildung 2.6 dargestellt, wobei die Status In Vorfreigabe (FK540) und Freigegeben (FK550) wichtige Abläufe im Prozess anstoßen. Abbildung 2.6.: Statuswechsel im FDO Bereich [ZF10] 22

23 2.2. Applikationen im FDO Bereich Der Statuswechsel auf In Vorfreigabe signalisiert, dass das Material seitens der Konstruktion angefragt wurde, es allerdings noch keinen finalen Reifegrad besitzt. In diesem Fall wird der Materialstamm nach SAP übertragen. Der Statuswechsel nach Freigegeben bedeutet, dass ein Material seitens der Konstruktion freigegeben ist und in den Fertigungsprozess integriert werden kann. Eine erneute Übertragung an das SAP System wird dadurch angestoßen. Neue Daten werden angelegt oder bereits vorhandene überschrieben. Besitzt ein Material eine Stückliste, kann es nur freigegeben werden, falls alle Elemente der Stückliste ebenfalls freigegeben sind FATool Das FDM System FATool ist das Informationssystem zur systematischen Organisation aller Betriebsmittel, insbesondere aller Werkzeuge. Der Organisation liegt ebenfalls das in der DIN4000 und ISO definierte Klassifizierungssystem in Sachmerkmalleisten zu Grunde. Die logische Verwaltung der Betriebsmittel hat im Einzelnen folgende Vorteile: Reduziert die Typenvielfalt von WKZ und FHM Reduziert den Lager- und Umlaufbestand Reduziert den Werkzeugverbrauch Während FATool am Anfang ausschließlich für die NC-Programmverwaltung ausgelegt war, wurde im Lauf der Zeit das Bedürfnis nach mehr Funktionalität größer, sodass heute verschiedene Module im Umlauf sind. Die Module, die in der Betriebsmittelverwaltung zum Einsatz kommen, werden im Folgenden dargestellt: Klassifizierung Bei der Klassifizierung ist zu beachten, dass neue Materialien immer zuerst im führenden System Axalant anzulegen sind, denn nur dort wird eine eindeutige Materialnummer erstellt. Die eigentliche Klassifizierung wird aber häufig in FATool durchgeführt, da es übersichtlicher gestaltet ist und nicht alleine die Sachmerkmalattribute darstellt, sondern auch deren Beschreibung. Komplettwerkzeug (KWZ) Verwaltung Dient der Verwaltung von Werkzeugen, die aus mehreren verschiedenen Bauteilen zusammengesetzt sind und an die CAM Systeme übergeben werden können. Bauteil (BTL) Verwaltung Umfasst alle Teile, die in irgendeiner Form weiter verwendet werden sollen, wie Bohrer, Fräser oder Wendeschneidplatten, wobei die Bauteile in der Klassifizierung nach DIN4000 gruppiert sind. Allgemeine Sachmerkmalverwaltung Zu jedem Werkzeug sind die zugeordneten Merkmale und deren Werte abrufbar und 3 Werkzeugdatendarstellung und austausch. Übersicht, fundamentale Prinzipien und allgemeines Informationsmodell. 23

24 2. Systemlandschaft über eine Stückliste ist die Referenzierung in die Bauteilebene möglich. Der Zusammenbau der Stücklisten erfolgt normalerweise in CREO und wird in Axalant gespeichert. Die zugehörigen Werkzeuggrafiken können ebenfalls als 2D oder 3D Grafik eingesehen werden. Insbesondere die Verwaltung und Erstellung von Komplettwerkzeugen ist möglich. Lagerverwaltung Die Lagerverwaltung unterteilt sich in die Gruppen Lagerstammdaten, physikalische Lagerdaten und Lagerfunktionen. Die Lagerstammdaten sind Voraussetzung um eine Lagerverwaltung aufzubauen, wie Artikeldaten, Lieferantendaten oder Lagerorte. Die physikalischen Daten beziehen sich auf Objekte, die tatsächlich vorhanden sind, also auf den Artikel mit Informationen zu Standort, Anzahl oder dem Prüfdatum. Zu den Lagerfunktionen zählen unter anderem das Bestellwesen sowie die Inventur. Prüfmittelverwaltung Hier werden alle Prüf und Messmittel eingetragen, sodass diese in regelmäßigen Abständen auf ihre Maßhaltigkeit überprüft werden können und dabei die entsprechenden Prüfungen, Durchführungstermine und Ergebnisse erfasst werden können. Ein weiterer wesentlicher Bestandteil ist die NC Programmverwaltung in der alle Daten, die für ein NC Programm erforderlich sind, verwaltet werden. In dieser Verwaltung ist auch die Kopplung mit dem CAM System untergebracht und die Zuordnung von KWZ zu einem NC Programm, die nicht nur für die CAM Systeme wichtig sind, sondern auch für die Übergabe von Werkzeuginformationen an die CNC Maschine. Neben der Maschinenverwaltung spielt in dieser Kategorie auch die Werkzeug Ist Datenverwaltung eine große Rolle. Hier werden die Maße aus der Werkzeugvoreinstellung verwaltet. Obwohl FATool inzwischen an vielen Standorten verfügbar ist, sind die Ausprägungen des Systems durch die Modulstruktur durchaus unterschiedlich. Im Folgenden wird auf die wichtigsten Eigenschaften des FDM Systems eingegangen: Sachmerkmalleisten Der Aufbau von FATool ist durch die Sachmerkmalleisten bestimmt. Die SML sind unterteilt durch ihre Bildkennung, die darüber entscheidet welche Sachmerkmale zugeordnet werden. So können verschiedene Ausprägungen einer Gruppe klassifiziert werden, sodass nur eine Auswahl an Merkmalen angezeigt wird, um die Lesbarkeit zu erhalten. Sachmerkmale sind also Definitionen bestimmter Daten wie Artikelnummer, Durchmesser oder Werkstoff und werden in Gruppen zusammengefasst, den Sachmerkmalleisten. Jedes Sachmerkmal ist innerhalb des ganzen Systems eindeutig durch eine Sachmerkmal ID (SMID) definiert. Alle Datensätze, die in der gleichen Sachmerkmalleiste abgebildet werden sollen, müssen daher mit den in der SML verfügbaren Merkmalen bestimmt werden können. Zur besseren Übersicht sind zusammengehörige Sachmerkmalleisten in Modulen gruppiert. Eine Übersicht über den Vorgang der Klassifizierung mit SML ist in Abbildung 2.7 dargestellt. 24

25 2.2. Applikationen im FDO Bereich Abbildung 2.7.: Sachmerkmalleisten System in FATool [Fas10] 25

26 2. Systemlandschaft Gruppen Die Authentifizierung zum Start der Applikation läuft über den Windows Benutzernamen. Die Benutzerberechtigungen in FATool sind in Gruppen unterteilt, wobei beim Programmstart überprüft wird, ob der Benutzer in einer der entsprechenden Windows Usergruppen eingetragen ist. Je nach Art der Anwendung gibt es im ZF Konzern verschiedene Nutzergruppen, die mit einer dreistelligen Standortkennung beginnen. Für Passau ergeben sich hiermit vier Gruppen: PAS-FASYS-CAM, für die Programmierung PAS-FASYS-ADMIN, für Administratoren PAS-FASYS-VIEW, für die Arbeitsplanerstellung PAS-FASYS-DNC, für die Fertigung Innerhalb von FATool gibt es weitere Gruppen, die die Sichtbarkeit der einzelnen Module regeln. Diese Gruppen sind im Einzelnen: BTL, Bauteilverwaltung KAL, Prüfmittelverwaltung KWZ, Komplettwerkzeugverwaltung PVW, NC Programmverwaltung SYS, FATool Administration LVS, Lagerverwaltung PMV, Prüfmittelverwaltung SML, Sachmerkmalleistenverwaltung Die einzelnen Module sind nur sichtbar, wenn der Benutzer in den entsprechenden Gruppen eingetragen ist. Berechtigungen FATool bietet auch die Möglichkeit die Funktionen auf einzelne Sachmerkmalleisten zu beschränken. Hierfür gibt es ein Berechtigungssystem, das auf jede einzelne Leiste angewendet werden kann. Kennung Berechtigung 0 kein Zugriff 1 zeigen 2 editieren 3 anlegen 4 löschen Tabelle 2.2.: Zugriffsrechte in FATool Die möglichen Berechtigungen sind in Tabelle 2.2 dargestellt, wobei diese Rechte addierend zu verstehen sind, sodass jede übergeordnete Berechtigung die darunterliegenden beinhaltet. Für jede Leiste werden zwei Kennungen zugeordnet, wobei die erste Berechtigungskennung für den Datensatz ist und die zweite für die dazugehörigen Dateien. Ein Auszug möglicher Konstellationen der Berechtigungskennungen ist in Tabelle 2.3 abgebildet und die Maske zur Vergabe von Berechtigungen auf Leistenebene mit Zuordnung von Standorten in FATool ist im Anhang A.2 unter Abbildung A.8 zu finden. 26

27 2.2. Applikationen im FDO Bereich Datensatz Dateien Berechtigung 0 0 Kein Zugriff auf Daten oder Dateien 2 0 Editieren der Daten, kein Zugriff auf Dateien 3 3 Anlegen von Datensätzen und Dateien 4 4 Volle Zugriffsrechte Tabelle 2.3.: Auszug möglicher Berechtigungen in FATool Lizenzen FATool besitzt einen eigenen Lizenzserver, der dezentral für jeden Standort zur Verfügung steht und die Lizenzen an die lokalen Clients verteilt. Sollte ein Client die Applikation öffnen, so wird automatisch die richtige Lizenz vom Lizenzserver angefordert. Die richtige Anzahl an gekauften Lizenzen muss gut kalkuliert sein, denn ist das System unterlizenziert, so ist ein effektives Arbeiten nicht möglich, da auf freie Lizenzen gewartet werden muss. Eine Überlizenzierung ist aus betriebswirtschaftlicher Sicht nicht erstrebenswert. Dabei ist jedoch zwischen verschiedenen Arten von Lizenzen zu unterscheiden, je nachdem wie FATool verwendet wird. Eine Aufstellung der möglichen Lizenzen kann in Tabelle 2.4 eingesehen werden. Lizenz FATool View CAM INV ASM PCD COMx WVE PCDEdt MDE MDEMap DCOM EXT Beschreibung Basis-Lizenz Viewerlizenz (Read-only) Lizenz für die NC-Verwaltung mit Bereitstellungsfunktion Lizenz für die Lagerverwaltung Lizenz für die Werkzeugverwaltung Lizenz für die FAPcd IPC DNC Client Software Maschinenlizenz aus dem FAPcd Lizenz für die Werkzeugvoreinstellung Lizenz für FAPcd mit der Option Editieren der SML Datenbank Lizenz für Maschinen Daten Erfassung Lizenz für Maschinen im MDE Anzahl der max. Aufrufe vom DCOM Server Lizenz für externe Schnittstellen (CREO, SolidWorks, etc.) Tabelle 2.4.: Lizenztypen für FATool Die PCD Lizenz ist mit FAPcd 4 für die Fertigung gedacht, wobei über sogenannte IPC DNC Clients 5 das NC Programm direkt auf die Maschine geholt wird. Die COM 6 Lizenz 4 FAPcd ist ein PC-bedientes DNC System als Standardanwendung. 5 Insel PCs werden verwendet um mehrere Maschinen anzusteuern und mit NC-Programmen zu versorgen. 6 COM steht für eine serielle Schnittstelle bei der die Bits nacheinander über die Leitung übertragen werden. 27

28 2. Systemlandschaft wird ebenfalls in der Fertigung für Server benötigt, die Maschinen mit serieller Schnittstelle ansteuern. Mit PCDEdt kann an der Fertigungsmaschine das NC Programm noch geändert werden. Die Module MDE 7, MDEMap 8 und WVE werden in Passau nicht verwendet. Die DCOM 9 Lizenz wird für den DCOM Server benötigt, der versucht die Netzwerklast zu verringern SAP Als ERP System wird im ZF Konzern SAP R/3 eingesetzt, das zur Steuerung und Verwaltung der Personalwirtschaft, der Logistik, der Arbeitsplanung und des Rechnungswesens dient. Da diese Faktoren keine allgemeine Systemlösungen zulassen, sondern höchstens branchenspezifisch ausgerichtet sind, muss das verwendete SAP System in einem Customizing 10 Prozess an die Erfordernisse des Unternehmens angepasst werden. Das führende System für die Materialstamm und Stücklistenverwaltung bleibt jedoch Axalant. Abbildung 2.8.: Architektur der SAP Systeme im ZF Konzern Aus diesem Grund gibt es innerhalb der ZF eine Reihe vieler verschiedener lokaler ERP Systeme, die an die unterschiedlichen Standorte angepasst sind und daher unabhängig voneinander funktionieren. Wie in Abbildung 2.8 dargestellt, ist allen lokalen Systemen ein SAP Master übergeordnet, der die Daten aus Axalant an die lokalen ERP Systeme verteilt, vorausgesetzt der SAP Standort ist in Axalant für den jeweiligen Standort eingetragen. Durch diese enge Verknüpfung des PDM und ERP Systems ist es möglich fertigungsrelevante Informationen an die werksspezifischen Installationen zu verteilen. Die übertragenen Daten werden unter anderem genutzt, um Arbeitspläne zu erstellen, die Auslastung der Fertigungsmaschinen zu kontrollieren oder Bestellungen durchzuführen. 7 Lizenz zur Maschinendaten Erfassung in der Applikation. 8 Entsprechende MDE Lizenz für die Maschine. 9 Distributed Component Object Model ist ein RPC System von Microsoft, das die Erstellung von Softwarekomponenten ermöglicht, die unabhängig von der Programmiersprache eingesetzt werden können und diese Komponenten über ein Rechnernetz kommunizieren zu lassen. 10 Unter Customizing versteht man die Anpassung eines Serienprodukts an die spezifischen betriebswirtschaftlichen Anforderungen eines Unternehmens. 28

29 2.3. Schnittstellen EdgeCAM EdgeCAM ist das strategische CAM System im ZF Konzern, welches diverse CAD native Daten einlesen kann. Es dient der Erstellung von NC-Programmen für Fertigungsmaschinen im Bereich Drehen, Drehzentren, Bearbeitungszentren sowie Erodieren. Die NC Programme müssen für die Steuerung der DNC Maschinen übersetzt werden, wozu ein Postprozessor erforderlich ist, der in einer Compilersprache oder in einem PP Assistenten innerhalb von EdgeCAM erstellt werden kann. Die in EdgeCAM über die Jahre stark verbesserte Simulation mit Darstellung von Werkzeugen und Fertigungsmaschinen, macht den Bedarf an zusätzlicher Software in der Fertigungssimulation geringer. Für Bauteile bei denen auf höchste Präzision gesetzt wird, kommt die Software NCSimul zusätzlich zur Simulation in EdgeCAM zum Einsatz. Dabei erlaubt NCSimul eine Simulation aller CNC Steuerungen und Maschinen unter Berücksichtigung der physikalischen Maschinenachsen, sodass Programme nicht nur verifiziert, sondern auch optimiert werden können ProE/CREO Das strategische CAD System im ZF Konzern ist ProE, welches innerhalb der ZF im Jahre 2013 durch die neuere Version CREO ersetzt wurde. Dieses System wird primär für die Modellierung von 3D Daten verwendet und wird gleichermaßen im PDO als auch im FDO Bereich eingesetzt. Für immer wiederkehrende Materialien verwendet CREO den normgerechten 3D CAD Katalog der Software PartSolutions. Hier findet man Standard Bauteile, wie Schrauben, Unterlegscheiben oder Federn, die somit leicht in CREO als 3D Modell importiert werden können. Für die Modellierung von 2D Layouts, wie es häufig bei der Erstellung von Grundrissen vorkommt, wird im ZF Konzern AutoCAD verwendet Schnittstellen FATool Axalant Zwischen Axlant und FATool besteht eine Schnittstelle, die je nach Art der übertragenen Daten entweder unidirektional oder bidirektional sein kann. Die unidirektionale Verbindung findet Verwendung bei der Übertragung von Geometriedaten, von 3D, 2D und nicht-digitalen Zeichnungen, sowie von Stücklisten. Da Axalant das zentrale Archiv aller Daten ist, ist es auch die Datenquelle für FATool. Nach FATool werden allerdings nur die relevanten FDO Daten übertragen, sodass diese in beiden Systemen zur Verfügung stehen. Die Übertragung der SML Daten stellt eine bidirektionale Verbindung dar, da sie die Basis der einheitlichen und systemübergreifenden Klassifizierung ist. Materialien müssen zwar wegen der Materialnummer immer in Axalant angelegt werden, da diese konzernweit eindeutig sein muss, die Klassifizierung kann jedoch auch in FATool vorgenommen werden. Nach der Aktualisierung der SML Daten müssen diese anschließend wieder nach Axalant eingecheckt werden. Es werden allerdings nur Daten an FATool übertragen, die in Axalant freigegeben sind. 29

30 2. Systemlandschaft FATool SAP Zwischen FATool und SAP besteht eine unidirektionale Schnittstelle. Dabei wird ein sogenannter Dokument Info Satz übertragen, der die Basisdaten zum eigentlich NC Programm bereithält. Dieser beinhaltet den Arbeitsgang, die Maschinennummer, die NC Programmnummer sowie den View des NC Programms. FATool EdgeCAM Die Verbindung zwischen FATool und EdgeCAM ist bidirektional, denn FATool stellt die benötigten Daten zur Erzeugung der NC Programme bereit, während die NC Programme durch EdgeCAM erstellt bzw. bearbeitet und zurück übertragen werden. Dazu wird auf dem jeweiligen Client eine temporäre Datei gespeichert, die von EdgeCAM aufgerufen wird. Die für die Erstellung der NC Programme benötigten Werkzeuge sind ebenfalls in FATool gespeichert und werden in den lokalen Toolstore von EdgeCAM geladen. Nachdem das Programm erstellt ist, wird der Toolstore wieder bereinigt und das fertige Programm zurück nach FATool übertragen. FATool ProE/CREO Die Schnittstelle zwischen FATool und CREO ist bidirektional, da FATool die nötigen Daten für das CAD System zur Verfügung stellt. Dabei handelt es sich allerdings nur um die Metadaten, also die zugehörigen Merkmalswerte, während die CAD Dateien selbst aus Axalant angefordert werden. Bei Änderungen an den Zeichnungen wird die entsprechende CAD Datei wieder in Axalant abgespeichert, die geänderten Merkmalswerte zieht jedoch FATool beim Schließen der Schnittstelle. Durch eine interaktive Rückgabe zwischen FATool und Axalant werden die geänderten Merkmalswerte auch nach Axalant übertragen. Dabei ist zu beachten, dass die interaktive Rückgabe durch das Starten der Axalant Applikation direkt am Client erfolgt. In FATool können außerdem Flächenmodelle aus den vorhandenen Merkmalsdaten erstellt werden. Dies geschieht durch einen im Hintergrund laufenden Generator, der von CREO zur Verfügung gestellt wird. Für Volumenmodelle sind in FATool parametrisierte Mastermodelle hinterlegt, die direkt an CREO übergeben werden. FATool DNC Distributed Numerical Control (DNC) bezeichnet computergestützte Werkzeugmaschinen, die in der Fertigung durch ein Computernetzwerk angesprochen werden können und die entsprechenden Bearbeitungsprogramme direkt in die Steuerung der Maschinen geladen werden können. Über FATool werden diese Fertigungsmaschinen mit den benötigten NC Programmen versorgt, das ebenfalls die Auswahl der benötigten Werkzeuge enthält. Die Kommunikation zwischen FATool und der Maschine wird über einen als Proxy fungierenden DNC Server in einer Demilitarized Zone (DMZ) ermöglicht. Somit werden die Programme vom FATool Server, der sich im Office Netzwerk befindet, direkt über das sogenannte Shop- Floor-Netzwerk in der Fertigung an die Maschine übergeben. Da es sich hier aber um eine bidirektionale Schnittstelle handelt, können Daten von der Maschine auch zurück an den FATool Server übermittelt werden. Dies ist allerdings nur dann der Fall, wenn das Programm selbst Unstimmigkeiten beinhaltet und direkt an der Maschine geändert werden muss. 30

31 3. Grundlagen Das Thema dieser Arbeit ist die Architektur von FATool hinsichtlich einer Zentralisierung zu dokumentieren und analysieren. Dabei ist zunächst der Architekturbegriff zu klären, der vielfältige Ausprägungen besitzen kann und in verschiedenen Ebenen auftritt, die sich nicht leicht voneinander abgrenzen lassen. Abbildung 3.1.: Architekturpyramide [Sta08] Eine gelungene Trennung dieser Ebenen ist durch die Architekturpyramide in Abbildung 3.1 gegeben. Sie werden nach oben hin abstrakter und beeinflussen sich gegenseitig, sodass ihre Grenzen durch unter oder übergeordnete Ebenen bestimmt sind. An der Spitze steht die Strategie in der die Ziele des Unternehmens formuliert werden, wobei hier ein klar definierter Zusammenhang zwischen Geschäftsprozessen und der IT steht. Darunter steht die Business Architektur, die geschäftliche Prozesse und betriebswirtschaftliche Funktionen definiert. Die Informationsarchitektur definiert die Struktur und die Zusammenarbeit aller IT Systeme eines Unternehmens, indem der Informationsfluss und die Schnittstellen der gesamten Systemlandschaft berücksichtigt werden. [Sta08] Während hier die Gesamtheit der Anwendungslandschaft betrachtet wird und die einzelnen Systeme als Bausteine gelten, beschäftigt sich die Softwarearchitektur mit dem detaillierten Aufbau eines einzelnen Bausteins. Durch ihre vielfältigen Aufgaben lässt sie sich nur schwer definieren und besitzt auch in der Fachliteratur eine Menge an unterschiedlichen Definitionen. In [BCK12] ist eine weitestgehend akzeptierte Version für die Definition von Softwarearchitektur zu finden: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the external visible properties of those components and the relationship among them. Es handelt sich also genauer um die Strukturierung des Systems, die Zerlegung in seine Teile, die Verantwortlichkeiten und das Zusammenspiel dieser Teile sowie deren Schnittstellen. Somit wird eine Vielzahl verschiedener Architekturentscheidungen in nur einem 31

32 3. Grundlagen Begriff zusammengefasst, wobei sehr unterschiedliche Punkte betroffen sein können. Es kann um die Zerlegung des Gesamtsystems in Teile gehen (Strukturierung), um die Art, wie Fremdsysteme angebunden werden, um die Verwendung bestehender Bibliotheken, Komponenten oder Frameworks (make or buy?) und vieles mehr. [Zör12] Am Boden der Pyramide ist die IT-Infrastruktur angesiedelt, die sich generell mit Themen wie Hardware, Netztopologie und den eingesetzten Betriebssystemen und Datenbanksystemen beschäftigt. Die Ebenen Informationsarchitektur und Softwarearchitektur werden durch den Überbegriff Unternehmensarchitektur bzw. IT Architektur zusammengefasst. Sie beschreibt die Elemente der IT und ihre Zusammenhänge untereinander sowie zu ihrer Umwelt und bietet daher eine abstrahierte, unternehmensweite Sicht auf alle Systeme in einem Unternehmen, um Lücken und Redundanzen in der Struktur und den Komponenten der IT schneller zu erkennen. [JS08] Sie ermöglicht außerdem eine reibungslose Unterstützung von Geschäftsprozessen durch Softwaresysteme und wird daher auch als Business IT Alignment bezeichnet. [Sta08] Vor diesem Hintergrund trifft für diese Arbeit der Begriff Softwarearchitektur am ehesten zu, da es sich um die Zerlegung eines einzelnen Systems handelt. Wenn auch die Sichtweise auf die Komponenten durch die Blackbox Sicht eingeschränkt ist, so können doch die externen Merkmale sowie die Schnittstellen zu anderen Systemen charakterisiert werden. Wie in Abbildung 3.2 dargestellt ist, kann daher der innere Aufbau des Systems nicht beschrieben werden, sodass es sich hier bei der Architekturbeschreibung weniger um einen Bauplan als mehr um einen Ablaufplan handelt. Abbildung 3.2.: Blackbox und Whitebox [SH11] Die Aufgaben, die es innerhalb der Softwarearchitektur zu bewältigen gilt, sind ebenso schwer zu benennen wie ihre Definition. Die Hauptbereiche werden in [SH11] allerdings zu den folgenden zusammengefasst werden: Anforderungen und Randbedingungen klären Strukturen entwerfen Technische Konzepte entwerfen Architektur kommunizieren Umsetzung begleiten Architektur bewerten 32

33 Da im Rahmen dieser Arbeit die Strukturen durch das bestehende FATool bereits vorgegeben sind, ist der erste Schritt die Architekturdokumentation in der der Ist Zustand charakterisiert und dokumentiert wird. Sind die Grundlagen geschaffen, können die Anforderungen an das neue System gestellt und in der Anforderungsanalyse richtig formuliert werden. Kriterien zur Bewertung von Architekturen werden ebenfalls erarbeitet. Das kommunizieren der Architektur ist ein begleitender und parallel stattfindender Prozess, der genauso wie die Umsetzung in dieser Arbeit nicht betrachtet wird. In Abbildung 3.3 ist die sog. Architekturbrezel dargestellt, die aufzeigt, dass sich diese Arbeit nur auf den linken Teil der Brezel beschränkt. Nachdem die Ziele in einem ersten Schritt in Form von funktionalen und nicht funktionalen Anforderungen erhoben und detailliert beschrieben werden, kann die Architektur entwickelt werden, die durch Modelle und Konzepte charakterisiert ist. Abschließend werden diese Konzepte bewertet. Die rechte Seite der Brezel ist explizit nicht Teil dieser Arbeit und beschäftigt sich mit der Implementierung und Evaluation sowie der Erarbeitung von Metriken zum Überwachen der Umsetzung. Abbildung 3.3.: Architekturbrezel [Zör12] Die Gliederung dieses Kapitels unterliegt somit dem logischen Aufbau dieser Arbeit. Zunächst muss das bestehende System analysiert werden, sodass die benötigten Anforderungen an das Soll Konzept erarbeitet werden können. Die gefundenen Schwachstellen müssen anhand von Anforderungen im Soll Konzept gelöst werden. Eine abschließende Bewertung stellt das Soll Konzept den Schwachstellen des Ist Zustands gegenüber und zieht Bilanz ob diese erfüllt werden oder neue Schwachstellen entstehen lassen. 33

34 3. Grundlagen 3.1. Systemanalyse Der Erfolg einer Systemanalyse hängt explizit von der Qualität der Systemdokumentation ab. Da beide Begrifflichkeiten in der Literatur vorzufinden sind, aber nicht klar voneinander abgrenzbar sind, da sie sich denselben Techniken bedienen, werden beide in diesem Kapitel zusammengefasst behandelt. Die Systemanalyse kann dabei auf zweierlei Arten verstanden werden. Wenn ein bestehendes System so abgebildet wird wie es in der Realität vorzufinden ist, dann spricht man von der Ist Analyse. Wird spezifiziert wie ein zukünftiges System auszusehen hat, dann spricht man von der Soll Analyse. [Rup13] Um die gewonnen Ergebnisse explizit festzuhalten, werden diese in einer Dokumentation zusammengefasst. Der Begriff Dokumentation wird im Duden definiert mit dem Zusammenstellen und Nutzbarmach[en] von Dokumenten, Belegen und Materialien jeder Art. Somit hilft uns die Dokumentation Lösungen zu finden und diese nachvollziehbar und bewertbar zu machen. Ein weiterer Grund, der eine Dokumentation von Architekturen unabdingbar macht, sind Softwaresysteme, die viele Jahre im Einsatz sind und kontinuierlich weiterentwickelt werden, sodass durch unzureichende Dokumentation eine mangelnde Wartbarkeit entsteht und jede Änderung zu einem Risikospiel wird. (vgl. [Ahl12], S.12) Deshalb ist es ratsam, das Wissen, das in verschiedenen Köpfen steckt auf Papier zu bringen, um die Nachvollziehbarkeit der Systeme auch weiterhin aufrecht zu erhalten. Es ist auffällig, dass sich die in der Softwarearchitektur verwendeten Begriffe nicht immer eindeutig definieren lassen und ihnen nur schwer eindeutige Tätigkeiten zuzuordnen sind. Dies liegt einerseits an der Vielfältigkeit verschiedener Softwareprojekte, aber andererseits auch an einem fehlenden standardisierten Vorgehen für die Analyse und Dokumentation von Softwarearchitekturen. In anderen Disziplinen wie der Gebäudearchitektur gibt es längst standardisierte Verfahren zur Planerstellung, sodass jeder Konstrukteur die Konstruktionszeichnungen seiner Kollegen verstehen und weiterentwickeln kann. Auch in der Softwarearchitektur gibt es Ansätze in Form von Vorgehensmodellen und Frameworks, die versuchen einen Leitfaden für den Aufbau von Architekturen zu liefern und dabei ebenfalls ihre Individualität wahren Standards Ein Standard zur Beschreibung von Architekturen wurde von der IEEE Computer Society mit der Norm ANSI/IEEE geschaffen. Diese wurde am 21. September 2000 freigegeben und am 15. Juli 2007 als ISO/IEC übernommen und gilt seither als internationaler Standard. Am 24. November 2011 wurde dieser Standard überarbeitet und erweitert. Die Norm bildet den Grundstein für Architekturbeschreibungen, bestimmt jedoch nicht wie die Architektur selbst auszusehen hat. Die Anwendungsgebiete für Architekturbeschreibungen sind im Einzelnen: Beschreibung des Systems und dessen Entwicklung Kommunikation unter den Stakeholdern des Systems 34

35 3.1. Systemanalyse Bewertung und Vergleich von Architekturen Planung, Management und Ausführung von Aufgaben der Systementwicklung ISO/IEC/IEEE 42010:2007 Der vollständige Name dieser Norm lautet Recommended Practice for Architectural Description of Software-Intensive Systems und standardisiert Architekturbeschreibungen für softwareintensive Systeme, die sich dadurch auszeichnen, dass das Design, der Aufbau, die Bereitstellung und die Evolution des ganzen Systems durch Software wesentlich beeinflusst wird. In Abbildung 3.4 ist dass Schlüsselkonzept der IEEE abgebildet, das neben den Systemkomponenten auch die Einflussfaktoren auf das System und die nötigen Elemente zur Architekturbeschreibung berücksichtigt und in Relation stellt. Abbildung 3.4.: Konzeptionelles Architekturmodell nach IEEE42010:2007 [ISO07] Der Begriff System umfasst dabei individuelle Anwendungen von traditionellen Systemen, über Subsysteme, Produktlinien, Produktfamilien bis hin zu ganzen Unternehmen. Jedes 35

36 3. Grundlagen dieser Systeme ist bestimmt durch seine Umwelt, die die äußeren Einflüsse verkörpert und somit die Grenzen bezüglich der Anwendungsbereiche setzt. Ein oder mehr Stakeholder 1 haben Interessen am oder Belange an das System, wobei Belange diejenigen Anforderungen repräsentieren, die durch mehrere Stakeholder vertreten werden. Sie beziehen sich auf für die Entwicklung relevante Faktoren wie Performanz, Zuverlässigkeit, Sicherheit, Verteilung oder Evolvierbarkeit. Ein System existiert im Allgemeinen, um einen Auftrag in seiner jeweiligen Umwelt zu erfüllen, der wiederum durch die Stakeholder definiert wird. Ein System besitzt des Weiteren eine zugrunde liegende Architektur, die durch eine Architekturbeschreibung erfasst wird. Diese besteht selbst aus mehreren Bestandteilen und wird durch Sichten organisiert, die die Belange der Stakeholder widerspiegeln. Die Bedingungen für die Erstellung, Abbildung und Analyse von Sichten wird durch Sichtweisen festgelegt, die die Sprachen zur Beschreibung oder die Analysemethoden vorschreiben. Die Sichten sind zusammengesetzt aus einem oder mehreren Architekturmodellen, die aus den in den Sichtweisen festgelegten Regeln erstellt werden. Ein Architekturmodell kann dabei in mehr als einer Sicht beteiligt sein. [ISO07] Eine Architekturbeschreibung nach der ISO 42010:2007 muss die folgenden Kriterien beinhalten: Kennzeichnung (ID), Versionsnummer und Übersichtsinformationen Ausstellungsdatum und Status, ausstellende Organisation Änderungshistorie, Zusammenfassung, Anwendungsbereich Kontext, Glossar, Referenzen Identifikation der Stakeholder und ihre für das System relevanten Belange Benutzer, Erwerber, Entwickler, Instandhalter des Systems Ziel / Aufgabe des Systems Eignung des Systems, Durchführbarkeit, Risikoabschätzung Wartbarkeit, Einsatzfähigkeit, Evolvierbarkeit Spezifikation einer jeden Sichtweise, die für die Repräsentation der Architektur ausgewählt wurde sowie die Begründung der Auswahl Kennzeichnung (Name), Stakeholder, Belange Beschreibungssprache, Modellierungstechniken, analytische Methoden Eine oder mehrere Architektursichten Kennzeichnung (ID) und einleitende Informationen 1 Als Stakeholder wird eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat. 36

37 3.1. Systemanalyse Darstellung des Systems mit den Sprachen, Methoden und Techniken der zugeordneten Sichtweise und Informationen zu Konfigurationen Eine Beschreibung aller Inkonsistenzen unter den geforderten Bedingungen für eine Architekturbeschreibung Eine Begründung für die Auswahl der Architektur ISO/IEC/IEEE 42010:2011 Der vollständige Name der aktualisierten Norm lautet nun Achitecture description und verwendet die bereits bekannten Sichtweisen von Architekturen, ein erweitertes Framework und zusätzlich Beschreibungssprachen für Architekturen. Abbildung 3.5.: Konzeptionelles Architekturmodell nach IEEE42010:2011 [ISO11] Der wesentliche Unterschied der aktualisierten Norm ist, dass die Architekturbeschreibung als eigentliches Produkt mehr in das Zentrum gerückt ist und nun aus mehreren Bestandteilen zusammengesetzt ist, wie in Abbildung 3.5 ersichtlich wird. Weiterhin hat 37

38 3. Grundlagen ein System eine Architektur, wobei dies etwas abstraktes darstellt und nur durch seine Beschreibung greifbar wird. Somit stellt die Beschreibung die eigentliche Architektur dar, wodurch das System identifizierbar wird. Stakeholder des Systems haben Belange, die durch Anforderungen, durch Designentscheidungen, die Implementierung und den Betrieb entlang des Systemlebenszyklus entstehen. Sowohl die Stakeholder als auch ihre Belange werden eindeutig durch die Architekturbeschreibung bestimmt. Die Belange werden durch Architektur Sichten repräsentiert, die wiederum durch Sichtweisen in ihrer Erstellung, Interpretation und Analyse festgelegt sind. Die Sichten bestehen aus einem oder mehreren Architektur Modellen, wobei Modellierungskonventionen von den Belangen abgeleitet werden. Diese Konventionen sind durch die Modellart festgelegt, die dieses Architektur Modell bestimmen. Neue Elemente dieser Norm sind Korrespondenzen, die verwendet werden um Relationen zwischen einfachen Elementen auszudrücken. Jedes Konstrukt der Architekturbeschreibung kann ein solches einfaches Element sein, wobei die Korrespondenzen selbst durch die Korrespondenzregeln geleitet werden. Ein weiterer Bestandteil ist die Architektur Begründung, die Erläuterungen und Argumentationen für bereits getroffene Architekturentscheidungen umfasst. Diese kann den Grund für Entscheidungen, mögliche Alternativen, eingegangene Kompromisse, mögliche Konsequenzen und Quellenangaben zu weiterführenden Informationen beinhalten. [ISO11] Eine Architekturbeschreibung nach der Norm IEEE 42010:2011 muss die folgenden Inhalte berücksichtigen: Kennzeichnung der Architekturbeschreibung und Übersichtsinformationen Identifikation der Stakeholder und ihrer Belange Benutzer, Betreiber, Erwerber, Besitzer, Anbieter, Entwickler, Erbauer, Instandhalter des Systems Zweck des Systems und die Eignung der Architektur um diesen Zweck zu erfüllen Potentielle Risiken und Einflüsse während des Lebenszyklus des Systems auf ihre Stakeholder Machbarkeit, Wartbarkeit und Evolvierbarkeit des Systems Definition einer jeden Sichtweise, die in der Architekturbeschreibung verwendet wurde Belange, die durch diese Sichtweise betroffen sind und die dazugehörigen Stakeholder Modellarten, die in der Sichtweise verwendet werden und die verwendeten Modellierungssprachen, Begriffe, Konventionen, Techniken und analytische Methoden Referenzen zu den Quellen 38

39 3.1. Systemanalyse Eine Sicht und ein Modell für jede genutzte Sichtweise Identifizierende Informationen sowie die Zuweisung der leitenden Sichtweise Architektur Modelle, die alle Belange der leitenden Sichtweise berücksichtigen und das ganze System abdecken Aufnahme aller Probleme innerhalb einer Sicht bezogen auf die leitende Sichtweise Geeignete Korrespondenzregeln, Korrespondenzen und eine Aufzeichnung aller Inkonsistenzen zwischen den erforderlichen Inhalten einer Architekturbeschreibung Begründungen für die getroffenen Architekturentscheidungen Architektur Frameworks Die Verwendung von Architektur Frameworks ist begründet in der Größe von Unternehmensarchitekturen und der Vielzahl an unterschiedlichen Komponenten, die dabei zum Einsatz kommen und somit sichergestellt wird, dass alle benötigten Aspekte berücksichtigt werden. Auch kann das Verwenden einer vordefinierten Struktur dabei helfen die Kommunikation zwischen den Stakeholdern zu verbessern. Sie wahren einen ganzheitlichen Blick auf die IT eines Unternehmens und berücksichtigen dabei die Organisation und zu verwendende Technologien bei der strategischen IT Planung. Allerdings lassen sich Frameworks nur selten generisch verwenden, da sich große Unternehmen auch durch unterschiedliche Anforderungen auszeichnen und somit spezielle Anpassungen an den Frameworks nötig sind. Heutzutage gibt es daher mehr als 70 verschiedene Enterprise Architecture Frameworks auf dem Markt. Allen Frameworks gemeinsam ist jedoch, dass die jeweilige Unternehmensarchitektur durch verschiedene Sichten und Aspekte beschrieben wird. Die Sichten lassen sich abstrakt einordnen in eine Businessarchitektur, Datenarchitektur, Applikationsarchitektur und eine Technologiearchitektur. Die adressierten Aspekte sollen dabei eine Antwort liefern auf die Fragen: Was?, Wie?, Wo?, Wer?, Wieso?, Wann?, Wohin? und Warum?. [Han13] Zachman Enterprise Architecture Framework Das Zachman Framework ist eines der ersten und bekanntesten Architekturframeworks und beeinflusst auch noch heutige Frameworks maßgeblich. Es stellt die Analogie zwischen der IT und Gebäudearchitektur her, die ähnlich komplex ist und ebenfalls die ganzheitliche Betrachtung von Architekturen fordert. [Kel12] Entwurfsziel des Frameworks war die Bereitstellung von Beschreibungskonzepten, die geeignet sind, die vielfältigen Schnittstellen von Komponenten eines Informationssystems sowie deren Integration in die Organisation darzustellen. [Han13] 39

40 3. Grundlagen Auch beim Zachman Framework kommen verschiedene Sichten zum Einsatz, die entlang der Zeilen angeordnet sind, wobei der Detaillierungsgrad der Ebenen von oben nach unten zunimmt. Oft spricht man hier auch von verschiedenen Rollen. Die Aspekte sind entlang den Spalten angeordnet und sind im Gegensatz zu den Sichten nicht sortiert. Jede Sicht wird unter dem jeweiligen Blickwinkel des Aspekts beleuchtet und in den Spalten der Matrix dargestellt. Die Kombination aus allen Einträgen ergibt ein Gesamtbild des Unternehmens. [Han13] In Abbildung 3.6 ist die Matrix zum Zachman Enterprise Architecture Framework visualisiert. Abbildung 3.6.: Zachman Framework [JS08] Somit ergeben sich 36 Kategorien um alle beteiligten Objekte darzustellen, sodass die Stakeholder aus den verschiedenen Sichten auf das Modell schauen können. Jeder dieser Sichten berücksichtigt dabei die Bedingungen der übergeordneten. Es ist allerdings auch möglich, dass untergeordnete Sichten übergeordnete beeinflussen, wobei die Bedingungen der einzelnen Sichten additiv zu verstehen sind. Dabei wird bei den Sichten unterschieden zwischen Planer, Besitzer, Designer, Builder, Programmierer und Nutzer. Die Perspektiven ergeben sich aus der Kombination mit den Aspekten Daten, Funktion, Netzwerk, Personen, Zeit und Motivation. Das Zachman Framework ist allerdings nicht sehr weit verbreitet, da es extrem umfangreich ist und in der Praxis mehr auf prozessorientierte Vorgehensweisen gesetzt wird als auf modellzentrierte. [Kel12] 40

41 3.1. Systemanalyse TOGAF The Open Group Architecture Framework ist das aktuell bekannteste und meist verwendete Modell zur Planung, Entwicklung und Wartung von Unternehmensarchitekturen. Es bietet einen generischen Ansatz, der versucht ein breites Spektrum an Anforderungen abzudecken, sodass auch TOGAF wie schon das Zachman Framework für eine ad-hoc Anwendung zu schwergewichtig ist. Es kann jedoch leicht um Bestandteile anderer Frameworks ergänzt werden und umfasst den kompletten Lebenszyklus einer Unternehmensarchitektur, wobei immer die Informationslandschaften im Vordergrund stehen. [Han13] Das Modell einer Unternehmensarchitektur wird in TOGAF in 4 Domänen unterteilt: Geschäftsarchitektur betrachtet die Strategie, die Geschäftsprozesse und die Organisation des Unternehmens. Datenarchitektur beschreibt die Daten und deren Zusammenhänge sowie Prinzipien, die für die Geschäftsprozesse und Organisation benötigt werden. Anwendungsarchitektur verwaltet die Anwendungen sowie deren Beziehungen untereinander und zu den Geschäftsprozessen. Technologiearchitektur beschreibt die aktuelle technische Realisierung der IT Infrastruktur sowie die technischen Standards. Die Datenarchitektur und die Anwendungsarchitektur werden oft zur Informationssystemarchitektur zusammengefasst. Die Dokumentation von TOGAF ist in sieben Abschnitte unterteilt, wobei die wichtigsten Teile die Architecture Development Method, das Architecture Content Framework und das Architecture Capability Framework sind. Abbildung 3.7.: Architecture Development Method 2 In Abbildung 3.7 sind die acht Phasen der Architecture Development Method zu sehen. Die ersten beiden Phasen Prelim und A legen den Architekturkontext mit seinen Zielen und dem Zeitraum fest. Die Phasen B - D sind verantwortlich für die Architekturinhalte mit Ist und Soll Zustand der spezifischen Teilarchitekturen. Die Phasen E und F heißen Architekturtransitionsplanung und zeigen Möglichkeiten zur Realisierung mit entsprechender Bewertung auf. Die Phasen G und H sind die Steuerung der Implementierungsprojekte zur Überwachung, dass das Projekt den Anforderungen aus dem Soll Konzept entspricht. Im letzten Schritt werden neue Anforderungen gesammelt, die für einen erneuten Durchlauf des Zyklus ausschlaggebend sind. 1 (abgerufen am 04. Februar 2014) 41

42 3. Grundlagen arc42 Die Autoren Hruschka und Zörner bringen mit arc42 ein frei verfügbares Template auf den Markt, das vor allem übersichtlich und praxisorientiert ist. Angetrieben von der Problematik, dass viele Frameworks oder Vorgehensmodelle überladen sind und es mit hohem Aufwand verbunden ist solche Modelle überhaupt einsetzbar zu machen, wird mit arc42 eine leichtgewichtige Strukturvorlage geliefert, die lediglich eine feste Gliederung vorsieht. Natürlich ist diese Gliederung im Laufe der Zeit gewachsen und hat sich inzwischen bei vielen Projekten bewährt, sodass sie dem Architekten vor allem Zeit erspart, auch wenn durch eine feste Gliederung nicht immer alle Eventualitäten eines Softwareprojekts abgedeckt werden können. Sie ermöglicht neben dem Architekturprozess auch die Architekturdokumentation, wobei der Fokus allerdings auf einem einzelnen Softwaresystem liegt. Im Folgenden wird die Gliederung des Templates inhaltlich vorgestellt, das in drei Teile aufgeteilt ist. Der erste Teil widmet sich dem Problemraum, im zweiten Teil geht es um die Lösungsbeschreibung und im dritten Teil folgt eine Bewertung der Lösung. [Zör12] 1. Einführung und Ziele Beschreibung von Sinn und Zweck des Systems mit seinen funktionalen und nicht funktionalen Anforderungen. Es wird mehr Wert auf Übersichtlichkeit gelegt als auf Vollständigkeit, da ein Einstieg in das zu lösende Problem geschaffen werden soll. Kurz und knapp sollen die Aufgabenstellung sowie die Qualitätsziele im Hinblick auf die wesentlichen Architekturziele beschrieben werden. 2. Projektbeteiligte Aufzählen von Personen oder Organisationseinheiten die das System und seine Architektur beeinflussen. Des Weiteren muss benannt werden, wie die jeweiligen Stakeholder mit dem System in Berührung stehen und was sie für das System leisten müssen. 3. Randbedingungen sind diejenigen Faktoren, die die Freiheitsgrade bei Entwurfsentscheidungen begrenzen und sind meist von Auftraggebern oder Stakeholdern vorgegeben. Man unterscheidet zwischen technischen Randbedingungen, wie Hardware, Software und betriebliche Randbedingungen (Betriebssystem, Datenbanken), organisatorischen Randbedingungen, wie Gesetzte, Vorschriften, Normen, Standards und Regularien, und Konventionen in Form von Programmier, Dokumentations oder Namenskonventionen. 4. Kontextabgrenzung Die Kontextabgrenzung sieht das ganze System als Blackbox mit seinen externen Schnittstellen und stellt eine Top Level Darstellung dar. Sie berücksichtigt auch Nachbarsysteme, die Schnittstellen zwischen ihnen, die ausgetauschten Daten sowie Datenformate, die Übertragungskanäle und Metainformationen. Man unterscheidet zwischen einem fachlichen Kontext, in dem die Funktion und das Umfeld des Systems aus einer geschäftlichen oder fachlichen Perspektive beleuchtet wird und dem technischen bzw. Verteilungskontext, in dem die technischen Kanäle und Übertragungsmedien zwischen dem System, seinen Nachbarn und deren Umgebung beschrieben wird. 42

43 3.1. Systemanalyse 5. Lösungsstrategie Hier wird ausgehend von der Aufgabenstellung, den Randbedingungen und den Qualitätsmerkmalen für die zentralen Entwurfsentscheidungen argumentiert. 6. Bausteinsicht Die Systembestandteile werden als Bausteine bezeichnet und stellen die statischen Strukturen des Systems dar. Durch eine Top Down Verfeinerung soll das System immer weiter in seine Bestandteile aufgebrochen werden, wobei immer zwischen Black und Whitebox zu differenzieren ist. Da wir das System nicht in seine einzelnen Bestandteile zerlegen können, sondern als Blackbox betrachten, ist diese Sicht nur sehr eingeschränkt anwendbar. 7. Laufzeitsicht Diese Sicht verdeutlicht die Wirkungsweise des Systems zur Laufzeit. Neben der Zusammenarbeit von Laufzeitkomponenten, beschreibt diese Sicht auch konkrete, exemplarische Abläufe, die klären wie das System die wichtigsten fachlichen und technischen Anwendungsfälle bearbeitet. 8. Verteilungssicht Diese Sicht beschreibt die Ausführungsumgebungen des Systems, die in Form von Knoten (Prozessoren, Rechner, Speicher) angegeben werden. Auf ihnen werden Softwarebestandteile des Systems ausgeführt oder Daten gespeichert. 9. Typische Muster, Strukturen und Abläufe Dieses Kapitel dient um Redundanzen zu vermeiden, indem typische Strukturen oder Grundmuster, die oftmals innerhalb der Architektur wiederkehren, nur einmal beschrieben werden. 10. Technische Konzepte Hier werden die zentralen technischen Entscheidungen dargelegt, deren Verständnis für Projektbeteiligte von großer Bedeutung ist. Neben ihrer Beschreibung, gehört auch eine Begründung für die getroffenen Entscheidungen und eine Evaluation mit möglichen Alternativen in dieses Kapitel. 11. Entwurfsentscheidungen Hier werden die wesentlichen Entwurfsentscheidungen beschrieben, die sich in folgende Kategorien einordnen lassen: Entscheidungen mit lang anhaltender Wirkung Entscheidungen mit Überraschungseffekt für zukünftige Architekten Entscheidungen unter hohem Risiko oder Zeitdruck getroffen Entscheidungen mit enormer Auswirkung auf die Qualitätsmerkmale 12. Qualitätsszenarien werden aufgestellt, um mögliche Risiken und Nicht Risiken hinsichtlich der geforderten Qualitätsmerkmale zu identifizieren. Auf Basis dieser Szenarien lassen sich die Qualitätsmerkmale operationalisieren und messbar machen. 13. Risiken Dieses Kapitel enthält eine geordnete Liste der erkannten technischen Risiken. 14. Glossar Eine Liste oder Tabelle der wichtigsten Begriffe mit Definition. 43

44 3. Grundlagen 3.2. Anforderungsanalyse Auf Basis der Anforderungen entsteht die Architektur, deshalb ist es besonders wichtig eine hohe Qualität bei der Beschreibung der Anforderungen zu gewährleisten. Generell sind Anforderungen als vom System bereitgestellte Funktionen zu verstehen. Die IEEE Computer Society beschreibt Anforderungen als: 1. A condition or capability needed by a user to solve a problem or achieve an object. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. 3. A documented representation of a condition or capability as in 1. or 2. Eine Anforderung kann also eine abstrakte Beschreibung eines Services oder eine detaillierte funktionale Spezifikation sein, die entweder von einem Benutzer gebraucht wird oder vom System eingehalten werden muss. Sie dienen außerdem als Grundlage für weitere Prozessschritte und werden daher oft als Vertragsgrundlage genutzt. [GBBK10] Dabei sind Anforderungen allerdings oft nicht stabil, sodass sie sich während des Prozessfortschritts ändern. Ein häufiges Problem sind Widersprüchlichkeiten zwischen Anforderungsbeschreibungen, die zu Inkonsistenzen führen können, wenn viele Stakeholder am Projekt beteiligt sind und viele verschiedene Interessen verfolgt werden. Dies kann man vermeiden, indem man Anforderungen nach ihrer Relevanz priorisiert oder in stabile und volatile Anforderungen aufteilt, sodass auf Änderungen entsprechend schnell reagiert werden kann. Es gibt Kriterien durch die sich gute Anforderungen auszeichnen. Sie sind eindeutig definiert und abgegrenzt, verständlich, atomar, identifizierbar, einheitlich, notwendig und nachprüfbar. [GBBK10] Eine bekannte Klassifikation von Anforderungen ist die Aufteilung in funktionale und nicht funktionale Anforderungen, wie sie in Abbildung 3.8 dargestellt ist. Während funktionale Anforderungen Funktionen beschreiben, die das System zur Verfügung stellen soll, beziehen sich nicht funktionale Anforderungen eher auf Qualitätsmerkmale, statt ein spezifisches Verhalten zu definieren. Funktionale Anforderungen treffen also konkrete Aussagen wie das System auf bestimmte Eingaben reagieren oder sich in bestimmten Situationen verhalten soll. Abbildung 3.8.: Klassifikation von Anforderungen [Rup13] 44

45 3.2. Anforderungsanalyse Die nicht funktionalen Anforderungen beziehen sich auf das ganze System und nicht auf einzelne Systemfunktionen, wobei sie sichtbare Eigenschaften des Systems charakterisieren, wie Benutzerfreundlichkeit, Zuverlässigkeit oder Sicherheit. Die Trennung der beiden Begrifflichkeiten ist deshalb oft problematisch, denn erschließt man nicht funktionale Anforderungen genauer, werden sie zu funktionalen. Die abstrakte Beschreibung der nicht funktionalen Anforderungen führt zu einer weiteren Unterteilung in Qualitätsanforderungen und Randbedingungen. Die Qualitätsanforderungen spezifizieren detailliert die Qualität von Systemfunktionen und beziehen sich daher auf funktionale Anforderungen. Bezogen auf die Zuverlässigkeit kann als Eigenschaft eines Qualitätsmerkmals zum Beispiel die Fehlertoleranz angegeben werden. Randbedingungen schränken den Handlungsspielraum der Systementwicklung weiter ein und beinhalten als Beispiel Vorgaben an die Hardware. [Rup13] Zu Beginn der Anforderungsanalyse wird zunächst der Scope bestimmt, der den Umfang des Systems definiert. In dieser Analysephase wird der fachliche Umfang festgelegt, der sicherstellt, dass die Anforderungen auf Umsetzbarkeit geprüft werden und durch das explizite aufstellen von Nicht Zielen das richtige System entwickelt wird. Die Anforderungsanalyse umfasst also das Erstellen und Warten eines Anforderungsdokuments bezüglich des Systems und dient der Bestimmung, Dokumentation und Überprüfung von Anforderungen. [Som07] Methoden Die Anforderungen sind das Produkt der Anforderungsanalyse für deren Herleitung es verschiedene Methoden gibt: Nicht strukturierte Methoden: Natürliche Sprache Semi strukturierte Methoden: Basieren auf natürlicher Sprache, werden aber durch Vorlagen, ein eingeschränktes Vokabular und ergänzende Eigenschaften vorgegeben Strukturierte Methoden: Folgen einer definierten Syntax, Notation oder formalen Spezifikation Im Folgenden werden bewährte Methoden zum Sammeln von Informationen über vorhandene Systeme und das anschließende Herauslösen von Benutzer und Systemanforderungen vorgestellt. [GBBK10] Anwendungsfälle (Use Cases) Die Anwendungsfälle beschreiben die Erwartung der Umwelt an ein System auf Grundlage der Interaktionen zwischen dem Nutzer und dem System, indem der Nutzer ein fachliches Ziel zu verwirklichen versucht. Dabei sollen alle möglichen Szenarien berücksichtigt wer- 45

46 3. Grundlagen den, wobei der Detaillierungsgrad beliebig fein gewählt werden. [GBBK10] Eine bewährte Vorlage zur Beschreibung von Anwendungsfällen lieferte Cockburn mit folgendem Ansatz: Name und Identifier: Benennung mit geordneter Nummerierung Beschreibung Beteiligte Akteure: involvierte Personen oder Systeme Status: Fortschritt des Anwendungsfalls Verwendete Anwendungsfälle: Verwendung anderer Anwendungsfälle Auslöser: Gründe für das Ausführen eines Anwendungsfalls Vorbedingungen: Bedingungen, die eine Ausführung nach sich ziehen Invarianten: Bedingungen, die nicht verändert werden dürfen Nachbedingungen: Der zu erwartende Zustand nach erfolgreichem Durchlauf Standardablauf: Darstellung eines typischen Szenarios Alternative Ablaufschritte: Szenarien, die ebenfalls auftreten können Hinweise: kurze Beschreibung und Erklärung zum besseren Verständnis Änderungsgeschichte: Versionierung mit Autor und Datum Nicht nur das Systemverhalten kann durch Use Cases sehr intuitiv beschrieben werden, sie dienen auch zur Abgrenzung der Nachbarsysteme, sodass der Betrachtungsgegenstand festgelegt werden kann. Zur modellhaften Beschreibung von Anwendungsfällen werden oft Sequenzdiagramme verwendet, auf die in Kapitel eingegangen wird User Stories Bei User Stories beschreibt der Kunde selbst in wenigen Sätzen die Systemfunktionalität, wobei jede Story genau eine Funktionalität realisiert. Der Kunde ist über den ganzen Entwicklungszeitraum in das Projekt involviert, woraus sich die genaueren Anforderungen ergeben. Das Vorgehen ist entweder durch ein Schema vorgegeben oder völlig frei. Oft werden User Story Cards verwendet wie in Abbildung 3.9 dargestellt, die das Ziel verfolgen die Systemfunktionalität zu benennen, aber nicht zu ausführlich. Wie auf den Abbildung 3.9.: User Story-Card mit Vorderseite links und Rückseite rechts 3 46

47 3.2. Anforderungsanalyse Story Cards zu erkennen ist, muss jeder Beteiligte seine Rolle angeben, das Ziel das er erreichen möchte und den Nutzen für das System. Auf der Rückseite wird ein Akzeptanzfall beschrieben mit dem die Funktionalität abgenommen werden kann. Die User Stories werden oft bei der agilen Softwareentwicklung eingesetzt, da die einzelnen Stories so beschrieben sind, dass sie im Rahmen eines Sprints 4 umgesetzt werden können. Insgesamt werden bei der agilen Software Entwicklung ca. 80 User Stories entwickelt. [GBBK10] Für die Verwendung von User Stories ergeben sich folgende Vor und Nachteile: + Kurz und prägnant, daher gut wartbar + Fördern die Diskussion zwischen Kunde und Entwickler + Reduzieren das Risiko von Fehlentwicklungen Können kaum als Vertragsgrundlage dienen Sind personenzentriert Starke Involvierung des Kunden ist unrealistisch Sind stark interpretierbar, sodass ein Abnahmerisiko besteht Szenarien Szenarien werden gerne verwendet, um auch die Meinung und Kritik der Stakeholder zu sammeln, die aus technikfernen Branchen stammen. An realen Beispielen wird durch eine geschäfftsprozessgetriebene Sicht die Rolle im Softwaresystem leichter verständlich und die Ausformulierung direkter Benutzerinteraktionen transparenter, sodass die erzeugte Resonanz zur weiteren Ausformulierung der Systemanforderungen verwendet werden kann. [Som07] Da Szenarien meist nur auf textbasierten Ansätzen beruhen, die durch Screenshots oder Diagramme unterstützt werden, sind sie eher als grobgranulare Sammlung von Informationen zu betrachten, die zwar für die Fachabteilungen als Dokumentationen dienen können, aber kaum Rechtssicherheit oder Verbindlichkeiten ausdrücken. [Rup13] Szenarien beginnen immer mit einer groben Beschreibung der enthaltenen Interaktionen und sollten nach [Som07] folgende Punkte enthalten: Erwartungen an das Systems und die Benutzer zu Beginn des Szenarios Ereignisablauf während des Szenarios Auflistung potentieller Fehler während des Szenarios und mögliche Workarounds Berücksichtigung gleichzeitig ablaufender Ereignisse 3 (abgerufen am 28. Januar 2014) 4 Bei Scrum wird inkrementell entwickelt und jedes Inkrement ist ein Time Box von 30 Tagen und heißt Sprint. Mit jedem Durchlauf erhält der Kunde ein lauffähiges System, das sich dem Endprodukt immer weiter annähert. 47

48 3. Grundlagen Beschreibung des Systems am Ende des Szenarios Das Hauptproblem bei Szenarien stellt meist eine fehlende Struktur bei den Beschreibungen dar, sodass keine inhaltliche Einheitlichkeit gewahrt wird, was die Lesbarkeit verschlechtert. Deshalb erheben Szenarien keinen Anspruch auf Vollständigkeit oder Redundanzfreiheit und auch Inkonsistenzen können nicht ausgeschlossen werden. [Rup13] Interviews Interviews sind bei fast allen Anforderungsanalysen enthalten, da sie mit geringem Aufwand gute Ergebnisse erzielen können. Dabei werden den Projektbeteiligten Fragen zum aktuellen und zum zu entwickelnden System gestellt, wobei deren Antworten als die Anforderungen an das neue System gesehen werden. Bei Interviews unterscheidet man zwischen zwei verschiedenen Arten: Geschlossene Interviews durch einen vordefinierten Fragenkatalog Offene Interviews ohne Agenda mit vordefinierten Punkten Interviews sind gut geeignet um zu verstehen wie Beteiligte mit dem zugrunde liegenden System arbeiten und welche Probleme sich in der Praxis ergeben. Da die Beteiligten meist sehr tief im System verankert sind, setzen sie vieles, was dem Interviewer nicht klar ist, als selbstverständlich voraus. Deshalb ist es ratsam neben den Interviews auch noch andere Arten von Bestimmungsmethoden einzusetzen und durch die Mischung bessere Ergebnisse zu erzielen. Doch durch fehlende Dokumentationen sind Interviews oft die einzige Informationsquelle zur Anforderungsbestimmung. [Som07] Modellierung Da wir nun Methoden kennengelernt haben wie das Wissen der unterschiedlichen Stakeholder zusammengetragen werden kann, müssen diese Informationen in eine Form gebracht werden, die es erlaubt von allen Projektbeteiligten verstanden zu werden. Für die Modellierung des erhobenen Wissens gibt es verschiedene Modellierungssprachen. Im Folgenden wird auf die UML, eine allgemeingültige, visuelle Sprache eingegangen und domänenspezifische Sprachen, die nur in einem speziellen Anwendungsgebiet gültig sind. [GBBK10] Unified Modelling Language Während Softwareentwicklern früher einheitliche Tools und Sprachen zur Beschreibung von Architekturen fehlten, ist UML inzwischen als weltweit standardisiertes Verfahren anerkannt. Es wird verwendet um Analyse oder Architekturmodelle von Softwarearchitekturen zu dokumentieren und baut auf verschiedenen Diagrammtypen auf, um unterschiedliche Sichten auf ein System repräsentieren zu können. [Sta08] 48

49 3.2. Anforderungsanalyse Verhaltensmodelle Anwendungsfalldiagramm (Usecase Diagram) Anwendungsfalldiagramme stellen die Sicht der Akteure zwischen ihnen selbst und dem Anwendungsfall dar. Da es sich um ein Verhaltensmodell handelt, wird kein Ablauf modelliert. Man verwendet Anwendungsfalldiagramme zur Modellierung spezifischer Anforderungen an ein System. Aktivitätsdiagramm (Activity Diagram) Aktivitätsdiagramme werden verwendet, um den Ablauf eines Anwendungsfalls zu beschreiben. Mit ihrer Hilfe lassen sich Vernetzungen von elementaren Funktionen sowie der Daten und Kontrollfluss darstellen. Dabei zeigt es die Sicht auf die dynamischen Elemente des Systems. Zeitverlaufdiagramm (Timing Diagram) Das Zeitverlaufdiagramm erlaubt eine zeitliche Sicht auf die dynamischen Aspekte des modellierten Systems. Somit lassen sich präzise zeitliche Aussagen treffen, sodass es sich vor allem zur Spezifikation von Interaktionen eignet. Kommunikationsdiagramm (Communication Diagram) Kommunikationsdiagramme werden verwendet um zwischen assoziierten Objekten übertragene Nachrichten darzustellen. Durch Sequenzausdrücke wird beschrieben welche der Nachrichten parallel und welche sequentiell gesendet werden. 49

50 3. Grundlagen Zustandsdiagramm (Statechart Diagram) Das Zustandsdiagramm wird verwendet um Systemzustände zu beschreiben. Dabei werden vor allem auch Zustandsänderungen und deren auslösende Ereignisse berücksichtigt. Das Diagramm wird immer als endlicher Automat abgebildet und kann zur Beschreibung des Systemverhaltens verwendet werden. Interaktion Übersichts Diagramm (Interaction Overview Diagram) Interaktionsdiagramme werden dann verwendet, wenn Szenarien sehr groß werden und durch Aktivitäts und Sequenzdiagramme dargestellt werden. Sie gewährleisten eine übersichtliche Darstellungen von komplexen Prozessen durch Modularisieren von einzelnen Ereignissen. Sequenzdiagramm (Sequence Diagram) Mit Sequenzdiagrammen lässt sich die Sicht auf die zeitliche Ordnung des modellierten Systems darstellen, wobei Interaktionen zwischen Objekten berücksichtigt werden sowie deren Nachrichtenaustausch. Die Zeitachse verläuft senkrecht, die ausgetauschten Nachrichten werden durch horizontale Kanten dargestellt. 50

51 3.2. Anforderungsanalyse Strukturmodelle Da im Rahmen dieser Arbeit FATool wegen des geschlossenen Quellcodes als Blackbox betrachtet wird, werden die Strukturmodelle durch ihren Bezug zur Bausteinsicht nicht gebraucht. Als die kleinsten Bausteine bei Software werden die Klassen angesehen, auf die somit natürlich kein Zugriff möglich ist. Der Vollständigkeit halber sollen die Strukturmodelle aber aufgezählt werden: Klassendiagramm (Class Diagram) Paketdiagramm (Package Diagram) Komponentendiagramm (Component Diagram) Verteilungsdiagramm (Deployment Diagram) Kompositions Struktur Diagramm (Composite Structure Diagram) Objektdiagramm (Object Diagram) Diese Modelle können wegen der eingeschränkten Sichtweise nicht angewendet werden, deshalb liegt der Fokus auf der Laufzeitsicht Domain Specific Languages Eine Domain Specific Language wird verstanden als eine Modellierungssprache, die speziell für ein bestimmtes Problemfeld geschaffen wurde und nur spezifische Anwendungsbereiche dieser Domäne abdeckt. Durch eine hohe Ausdrucksstärke der Problemspezifität sind DSLs in der Regel nicht auf andere Domänen übertragbar. Man unterscheidet dabei zwischen textbasierten und visuellen DSLs, während erstere oft in XML formuliert werden, sind visuelle meist Erweiterung der UML. [Som07] Bekannte Beispiele für domänenspezifische Sprachen sind reguläre Ausdrücke oder die Structured Query Language, die in mehreren Sprachen Verwendung finden oder systemunabhängig einsetzbar ist Entity Relationship Modell Das Entity Relationship Modell dient als Grundlage der semantischen Datenmodellierung und beschreibt in der Anforderungsanalyse die relationale Datenstruktur eines Systems. Dabei sind diese Modelle gängige Praxis zum Entwurf von Datenbankmodellen und bilden die Basis eines persistenten Informationssystems. Die Daten werden hierbei in Entitäten unterteilt individuell identifizierbare Objekte der Wirklichkeit und durch Beziehungen der Zusammenhang zwischen mehreren Entitäten abgebildet. Informationen und Eigenschaften, die im Kontext zu einer Entität stehen, werden Attribute genannt. Durch Kardinalitäten wird festgelegt wie die Entitäten miteinander in Beziehung stehen, also wie viele Verbindungen zwischen den Objekten erlaubt sind. [GBBK10] Hierbei gibt es folgende Möglichkeiten: 51

52 3. Grundlagen 1:1 Entität A ist genau mit einer Entität B verbunden 1:N Entität A kann mit keiner oder beliebig vielen Entitäten B verbunden sein. Entität B kann nur mit genau einer Entität A verbunden sein. N:M Entität A ist mit keiner oder beliebig vielen Entitäten B verbunden. Gleiches gilt für Entität B im Bezug auf Entität A. Durch verschiedene Notationen haben sich unterschiedliche grafische Darstellungsformen für ER Modelle entwickelt. Eine Übersicht über die verschiedenen Notationen ist in Abbildung 3.10 dargestellt. Abbildung 3.10.: Typische ER Notationen 5 Das erste und bekannteste ER Modell wurde 1976 durch Peter Chen eingeführt und wird deshalb auch als Chen Notation bezeichnet. IDEF1X findet hauptsächlich im Bereich Computer Aided Manufacturing Anwendung. Die Bachman sowie die Martin Notation sind weit verbreitete Werkzeug Diagramm Sprachen. Die Min Max Notation war ein Standard, wurde aber durch die UML Notation abgelöst. 5 Trotz unterschiedlicher Darstellungsformen, drücken alle Notationen in Abbildung 3.10 denselben Sachverhalt aus. 5 (abgerufen am 04. Februar 2014) 52

53 4. Ist Zustand Die Ist Aufnahme des aktuell vorherrschenden Systems wurde nach den vorgestellten Techniken aus dem Grundlagenkapitel erarbeitet. Hierbei werden zunächst in einer Übersicht die bisherigen Prozesse von FATool in Interaktion mit dem PDM System Axalant dargestellt, sowie der interne Aufbau näher erläutert. Anschließend wird der Status Quo hinsichtlich der Zentralisierung relevanter Funktionen beschrieben und schließlich die Schwachstellen im Ist Zustand herausgearbeitet und dokumentiert Übersicht Im Folgenden wird der Ist Zustand, wie er in Abbildung 4.1 zu sehen ist, mit Schwerpunkt auf die AXA2FASys Schnittstelle dargestellt. Die Durchführung der Ist Analyse ist Grundlage für das Bewerten der Soll Architektur, denn Schwachstellen im bisherigen Konzept können leicht zu Problemen in zukünftigen Architekturen führen und stellen daher die Anforderungen an das Soll Konzept. Abbildung 4.1.: Ist Architektur Im Folgenden wird Abbildung 4.1, ausgehend vom Knoten Axalant, beschrieben. 53

54 4. Ist Zustand Das Herz des bisherigen Systems bildet Axalant, das alle Daten global zur Verfügung stellt und somit das führende System repräsentiert. Beim Anlegen von neuen Materialien muss stets mit Axalant begonnen werden, da die Materialnummern dort automatisch und kollisionsfrei mit einem Nummerngenerator erstellt werden und somit sichergestellt wird, dass diese konzernweit eindeutig sind. Ein weiterer Grund ist, dass in Axalant auch die Muss Merkmale hinterlegt sind, also diejenigen SML Datenfelder, die bei der Anlage neuer Materialien zwingend erforderlich sind und somit eine Pflichteingabe darstellen, um einen gültigen Eintrag erzeugen und anschließend freigeben zu können. Da Axalant aber nur eine rudimentäre Beschreibung zu den einzelnen Merkmalsfeldern bietet, ist das Anlegen von Materialien für den Anwender schwierig, sodass nach dem Erstellen der Muss Kriterien zur weiteren Beschreibung nach FATool gewechselt wird. Dazu muss in Axalant zunächst der richtige SAP Standort gesetzt werden, sodass die Daten an die gewünschten lokalen FATool Installationen verteilt werden. Ebenfalls muss der Status des Materials geändert werden, um eine weitere Bearbeitung zu ermöglichen. Nach der Neuerstellung von Materialien ist deren Status in Axalant zunächst auf 510 In Arbeit. Um die Bearbeitung in FATool zu ermöglichen, muss der Status auf 550 Freigegeben geändert werden. Das betreffende Material wird dann auf die sogenannte Auftragsliste gesetzt, die in regelmäßigen Abständen auf Einträge überprüft und nach FATool übertragen wird. Die Kanten von Axalant in Richtung der zentralen FATool Server tragen Bezeichnungen wie FP, PP,.., die als Abkürzungen der einzelnen SAP Systeme gelten (FP für Friedrichshafen, PP für Passau). Zusammengefasst werden diese Abkürzungen als ein einzelnes Programm verstanden, das im Folgenden Dispatcher genannt wird. Dieser wird in Passau verwaltet und verteilt je nach gesetztem SAP Standort die Daten an die lokalen FATool Systeme. Dieses Programm ruft im Minutentakt die Auftragsliste ab und stellt eine Verbindung zu den Schnittstellentabellen her. Sind in der Auftragsliste neue Materialien enthalten, so werden die neu erstellten Datensätze oder die durchgeführten Änderungen an die dezentralen FATool Systeme weitergegeben und aktualisiert. In dieser Abbildung steht GP1 stellvertretend für das SAP System in Schwäbisch Gmünd. Dort läuft ebenfalls ein Dispatcher nach dem gleichen Prinzip wie in Passau, allerdings versorgt dieser nur ZF Lenksysteme mit Daten. Der Grund dafür ist, dass ZFLS ein Gemeinschaftsunternehmen ist und auch unabhängig vom ZF Konzern funktionieren muss. Außerdem werden nur die für ZFLS relevanten Daten aus Axalant zur Verfügung gestellt, da in Axalant auch firmeninternes Wissen aus anderen Fertigungsbereichen gespeichert ist, das für andere Divisionen nicht sichtbar sein darf. Die Materialien aus der Auftragsliste liegen nun dezentral und standortabhängig auf den jeweiligen FATool Servern vor, die mit Passau, GNS,..., Steyr bezeichnet werden. Eine Sonderstellung hat hier ZFLS, das unabhängig und eigenständig versorgt wird. 54

55 4.1. Übersicht Wenn Materialien nun ergänzt oder geändert werden sollen, so erfolgt dies im FA- Tool Client. Nach Abspeichern der Änderungen beginnt eine interaktive Rückgabe der Merkmale nach Axalant. Dies bedeutet, dass die Axalant Applikation automatisch geöffnet wird und die in FATool geänderten oder erstellten Merkmalswerte sofort in der richtigen Eingabemaske in Axalant zur Verfügung stehen. Die Rückgabe in die Eingabemaske von Axalant anstelle des direkten Schreibens in die Datenbank hat mehrere Gründe: Es werden nur Materialien nach FATool übertragen, die den Status 550 Freigegeben haben. Der Status selbst kann aber in FATool nicht geändert werden, sodass für etwaige Bearbeitungen der Status in Axalant auf 565 In Bearbeitung gesetzt werden muss. Sind die Eingaben überprüft, kann das Material wieder freigegeben werden. Somit wird es automatisch wieder auf die Auftragsliste gesetzt und die aktualisierte Version wird wieder an die relevanten Standorte verteilt. Ist einem Material jedoch mehr als ein SAP Standort zugeordnet, kann dieses nur mit einer speziellen Sonderrolle geändert werden, die nur Key Usern zugeteilt wird, da in der Regel eine Abstimmung mit den anderen Standorten notwendig ist. Die Interaktion zwischen Axalant und FATool kann fehlerträchtig sein, da nur Axalant die originale Eingabemaske bietet, die auf die zugrundeliegende Datenbank abgestimmt ist. Falls in FATool also Änderungen gemacht werden und sich diese Änderungen auf Merkmalsfelder beziehen, die in Axalant für das entsprechende Material nicht verfügbar sind, so kann dies bei der interaktiven Rückgabe in die Eingabemaske von Axalant leicht festgestellt werden. Sowohl Axalant als auch FATool gehen bei der Gestaltung von Merkmalen, Merkmalslisten und Konformitätsklassen strikt nach DIN4000 vor. Es kann jedoch vorkommen, dass Änderungen an der DIN nicht zeitgleich umgesetzt werden. Somit ist eines der Systeme auf einem aktuelleren Stand als das andere. Durch die bidirektionale Schnittstelle und den Austausch der Daten zwischen den Systemen, können solche Inkonsistenzen entdeckt und beseitigt werden. Durch den manuellen Statuswechsel in Axalant werden auch Schnittstellen angesprochen, die durch ein direktes Schreiben vernachlässigt würden. Somit findet nach dem Freigeben eines Materials die direkte Übertragung nach SAP statt. Die Kommunikation zwischen dem dezentralen FATool Server und dem FaTool Client ist bidirektional, da es sich um eine Client Server Anwendung handelt und somit die Interaktionen zwischen den beteiligten Komponenten verdeutlicht werden soll. Es werden allerdings auch Daten am lokalen FATool Server gespeichert, die nicht an Axalant übertragen werden. Dabei handelt es sich um zusätzliche Informationen, die von Axalant nicht verwaltet werden können, wie es bei Mehrschneidensystemen der Fall ist. In FATool ist es möglich für dieses Werkzeug verschiedene Schneiden auszuwählen, denen verschiedene Nummern zugewiesen sind. In Axalant werden 55

56 4. Ist Zustand diese Schneiden nicht berücksichtigt, sodass diese Informationen bei der interaktiven Rückgabe verloren gehen würden. Eine Auswahl über verschiedene Schneiden bei Komplettwerkzeugen in FATool mit zugehöriger Stückliste kann im Anhang A.2 in Abbildung A.7 eingesehen werden. Der bisherige Aufbau von FATool hat mit dem Dispatcher bereits eine zentrale Komponente mit dem alle Standorte zentral aus Passau versorgt werden. Nur ZFLS stellt eine Ausnahme dar, das durch einen separaten Dispatcher von Schwäbisch Gmünd aus verwaltet wird. Trotz dieser zentralen Komponente treten alle Nachteile eines dezentralen Systems auf, da jeder Standort durch die Verteilung nur die Daten einsehen kann, die in Axalant mit seinem SAP Standort gekennzeichnet sind und somit eine stark eingeschränkte Sicht auf das komplette System bieten. Dies führt unweigerlich zu Redundanzen und verursacht Mehrkosten, die durch das Neuerstellen von bereits an anderen Standorten vorhandenen Betriebsmitteln entstehen. Das oben beschriebene Zusammenspiel zwischen den Systemen wird in Abbildung 4.2 zum leichteren Verständnis noch einmal als Prozess dargestellt. Diese Abbildung stellt den vorhergesehenen Austausch von Materialstämmen zwischen Axalant und FATool dar. Abbildung 4.2.: Austausch von Materialstämmen Ausgehend von Axalant wird ein Material angelegt für das im nächsten Schritt die hinterlegten Muss Merkmale ausgefüllt werden müssen. Nur durch das Bereitstellen der Muss Kriterien kann ein Materialstamm freigegeben und somit synchronisiert werden. Zur Übertragung nach FATool muss lediglich ein Statuswechsel auf 550 Freigegeben am Materialstamm durchgeführt werden. Eine originalgetreue Darstellung der FDO Materialstammmaske aus Axalant ist im Anhang A.2 bei Abbildung A.1 zu finden. Der gewünschte Datensatz ist dann in FATool verfügbar und kann um weitere Sachmerkmale ergänzt werden. Ist das Zuordnen von Merkmalswerten abgeschlossen, muss das Material wieder mit Axalant synchronisiert werden, sodass beide Systeme konsistent sind. Dazu setzt man in FATool den Betriebsmittelstatus auf Warten auf Axalant Freigabe und es öffnen sich entsprechende Eingabemasken in Axalant. Hierbei handelt es sich um die Materiallistenstammmaske (FDO-ART-SLI) zum Statuswechsel und die Klassifizierungsmaske (FDO-GRP-ART-RLI) zum Eintragen der Merkmalswerte, die im Anhang A.2 in Abbildung A.2 und Abbildung A.3 dargestellt sind. Zusätzlich wurde dieser Eingabemaske ein Menü angefügt mit der Option Zurück nach CAD, um die Schnittstelle zu beenden. Dieser Vorgang wird als interaktive Rückgabe bezeichnet und setzt voraus, dass Axalant 56

57 4.2. Status Quo im Hintergrund geöffnet ist sowie ein User mit ausreichenden Berechtigungen am System angemeldet ist. Um die in FATool ergänzten Daten nun übernehmen zu können, wird in Axalant der Status auf 565 In Nachbearbeitung gesetzt und der Materialstamm anschließend wieder freigegeben. Diese Übersicht liefert eine abstrakte Sicht auf die Architektur von FATool und Axalant. In Abschnitt 4.2 wird auf die Details von FATool eingegangen und in Abschnitt 4.3 werden Schwachstellen des Systems sowie mögliche Ausnahmefälle bei bekannten Prozessen beschrieben Status Quo Wie bereits in der Übersicht angedeutet, werden die Daten zwischen Axalant und FA- Tool mit Hilfe eines Dispatchers synchronisiert. Bisher wurde dieses Programm mit den Abkürzungen der SAP Standorte umschrieben, da genau diese in der Verteilung ausschlaggebend sind. Der Dispatcher wird als Überbegriff für die Verteilung der Daten verwendet, wobei er als ein Zusammenspiel aus mehreren Programmen zu verstehen ist. Eine detailliertere Darstellung des Verteilungsprozesses ist in Abbildung 4.3 illustriert. Abbildung 4.3.: FATool Master und Client Service [Fas12] Die Verteilung ist aufgeteilt in einen Master Service und einen Client Service. Während der Master Service in Passau verwaltet wird und somit schon als eine zentrale Einheit gesehen werden kann, laufen die Client Services an jedem Standort gesondert. 57

58 4. Ist Zustand Der Master Service arbeitet auf den Schnittstellentabellen und verteilt Meta Daten und die zugehörigen Dokumente. Dabei fungieren die Schnittstellentabellen als Zwischenspeicher für die Daten, die aus Axalant stammen und an die zugehörigen FATool Zielsysteme verteilt werden sollen. Damit dieser Vorgang kontinuierlich stattfindet, ruft der Master Service zeitgesteuert im Minutentakt bestimmte Funktionen auf und überprüft eine spezielle Tabelle innerhalb von Axalant. Diese Tabelle heißt Auftragsliste Datenexport und ist im Anhang A.2 in Abbildung A.4 dargestellt. Da die Schnittstellentabellen und die Axalant Datenbank physikalisch getrennt sind, wird für die Übertragung ein Datenbank Link verwendet. Jeder Standort hat seine eigenen FATool Serversysteme, die vom Client Service mit Daten versorgt werden. Genau wie der Master Service wird dieser zeitgesteuert im Minutentakt aufgerufen und fragt beim Master Service nach, ob für das entsprechende Zielsystem Einträge vorliegen. In diesem Fall werden Daten bzw. Dokumente in das jeweilige System übertragen und stehen diesem Standort lokal zur Verfügung. Die FATool Anwendung selbst ist eine Client Server Applikation und kommuniziert mit den lokalen Servern. Falls in FATool Änderungen vorgenommen werden, müssen diese auch in Axalant eingecheckt werden. Für den Rückweg der Aktualisierung gibt es keine automatischen Prozesse, sondern eine interaktive Rückgabe, die benutzergesteuert funktioniert. Dies hat unter anderem mit den Berechtigungen zu tun, die in Axalant benötigt werden, um Änderungen durchzuführen Aufbau Ein typischer Aufbau eines Serversystems zum Betrieb von FATool ist in Abbildung 4.4 zu sehen. Es ist allerdings anzumerken, dass sich der Aufbau je nach Standort unterscheiden kann, wobei es in erster Linie auf den Einsatzzweck von FATool ankommt. Des Weiteren müssen die verschiedenen Server, die hier logisch getrennt sind, physisch keine unterschiedlichen Maschinen sein. Abbildung 4.4.: Serveraufbau für FATool Installation Der Datenbank Server wird vom Client Service mit Daten beliefert und ist aufgeteilt in Konfigurations und Daten Tabellen. Technisch gesehen beherrscht FATool mehrere Datenbank Systeme. Während in Passau Oracle verwendet wird, kommt in Gainesville Microsoft SQL Server zum Einsatz. Der Applikationsserver ist zuständig für die Umsetzung des Client Server Konzepts und stellt das Bindeglied zwischen der FA- Tool Client Anwendung und den restlichen Servern dar. 58

59 4.2. Status Quo Dokumente werden nicht in der Datenbank gespeichert, sondern liegen auf einem Dateiserver, der als Grundlage einen Verzeichnisbaum zur Strukturierung verwendet. Dies gewährleistet einen schnellen Zugriff auf große Dateien durch die Produktion. Der Lizenzserver verteilt je nach Verwendung automatisch die richtige Lizenz und muss immer lokal zur Verfügung stehen, da ein Ausfall eines Lizenzservers auch den Ausfall der Produktion nach sich ziehen könnte. Dies betrifft nur Standorte an denen DNC Maschinen im Einsatz sind Datenbank Die Datenbank von FATool ist intern in Konfigurations und Datentabellen aufgeteilt, wie in Abbildung 4.5 ersichtlich wird. Die Konfigurationstabellen sind fest vorgegeben und werden von der Client Anwendung für etwaige Beschreibungen im Programm verwendet. Sie enthalten Leisteninformationen, die den Sachmerkmalen und Sachmerkmalleisten zugeordnet werden. Die Datentabellen enthalten die Nutzdaten, also die Werte zu den Merkmalen. Während die Konfigurationstabellen grundsätzlich vom System bereitgestellt werden und nicht verändert werden müssen, sind die Datentabellen manuell mit Einträgen zu füllen. Abbildung 4.5.: Datenbankstruktur [Fas10] Die Tabellen orientieren sich dabei an der DIN4000, wobei für jede Leiste eine eigene Tabelle angelegt wird. Um die Menge an Tabellen und Klassen einzugrenzen werden die Bildinformationen verwendet, sodass Sachmerkmale je nach Bildnummer den Leisten zugeordnet werden Schnittstelle Durch die Schnittstelle AXA2FASys (oder auch PDM2FATool genannt) soll der Austausch von Sachmerkmaldaten und Dokumenten zwischen FATool und Axalant sichergestellt werden. Beide Systeme basieren auf der DIN4000, die Klassenbenennung ist allerdings unterschiedlich, sodass Mapping Funktionalitäten benötigt werden, um die Axalant Klassen (z.b. TT0030) in die richtigen Leisten von FATool (z.b. DIN ) importieren zu können. Ein Abgleich zwischen den Systemen ist in beide Richtungen möglich, wobei der 59

60 4. Ist Zustand Weg von Axalant nach FATool automatisch abläuft und von FATool nach Axalant manuell durch die interaktive Rückgabe. Die Schnittstelle selbst arbeitet direkt auf Datenbankebene, sodass gewünschte Datensätze zunächst aus der ursprünglichen Datenbank kopiert und in Schnittstellentabellen zur Verfügung gestellt werden. Die Daten aus den Schnittstellentabellen werden schließlich abgeholt, quittiert und in die Zieldatenbank geschrieben. Für den Abgleich werden verschiedene Komponenten benötigt, wie der Master Service, der den Zugriff auf die Schnittstellentabellen ermöglicht oder der Client Service, der die Daten schließlich in die lokale Datenbank übernimmt, aber auch Komponenten, die seitens der ZF zur Verfügung gestellt werden müssen: Axalant Client zum Herauslesen und Zurückgeben der Daten SQL Prozeduren und Funktionen zum Bereitstellen von Daten in Schnittstellentabellen CAX Batch Client zum Herauslesen der Dokumente aus Axalant Der Axalant Client wird dann benötigt, wenn in FATool Betriebsmittel manuell in das System importiert werden sollen oder wenn durchgeführte Änderungen nach Axalant zurückgegeben werden. Dazu muss der Nutzer mit seinem Account in Axalant angemeldet sein, sodass die entsprechenden Berechtigungen des Anwenders geprüft werden können. Die SQL Prozeduren werden zeitgesteuert durch den Master Service aufgerufen und verwenden je nach durchzuführender Aktion verschiedene Funktionen, die auf den Schnittstellentabellen arbeiten. Dabei werden SML Daten aus Axalant in diese Tabellen transportiert und durch Anfrage des Client Service in die Konfigurations und Datentabellen der lokalen FATool Systeme verteilt. Hierfür werden die Konfigurationstabellen gebraucht, durch die beschrieben wird, wie eine Axalant Klasse nach FATool gemappt wird. Sie beinhaltet die Quellleiste mit der zugehörigen Bezeichnung und die Zielleiste mit einer Bildkennung sowie einen Bezeichner für diese Leiste und einer Menge an Mapping Regeln. Diese Regeln müssen manuell angelegt werden. Für Datensätze, die über keine geeignete Zielleiste in FATool verfügen, werden entsprechend der Konfiguration, vom System automatisch neue Leisten angelegt. Dies ist immer dann der Fall, wenn Klassen aus Axalant keiner entsprechenden Klasse in FATool zugeordnet werden können. Für die Datentabellen gilt, dass sie immer nur von einer Seite gepflegt werden, wobei es eine lesende und eine schreibende Seite gibt. Die schreibende ist in diesem Fall die vom Master Service aufgerufene Prozedur. 60

61 4.2. Status Quo In Tabelle 4.1 werden die Konfigurationstabellen der Schnittstelle aufgelistet: Tabelle AXA_GROUP_FATOOL_SYSTEM AXA_GROUP_DAT AXA_GRP_CLA AXA_ZF_PLANTS Beschreibung Zuordnungstabelle für Leisten zu den lokalen FATool Zielsystemen. Enthält Informationen zur Axalant Klasse wie den Klassencode, die Kurzbezeichnung oder die Beschreibung. Enthält die verschiedenen Merkmalsbeschreibungen, die einer Klasse zugeordnet sind. Für jedes Merkmal wird ein eigener Eintrag erstellt, der einer Klasse zugewiesen ist. Enthält die genaue Definition des Werks, da oft mehrere Werke an einem SAP System hängen, ist die Abkürzung nicht ausreichend für eine eindeutige Identifikation. Tabelle 4.1.: Konfigurationstabellen der Schnittstelle In Tabelle 4.2 sind die Datentabellen der Schnittstelle aufgelistet: Tabelle Beschreibung AXA_MAT_FATOOL_SYSTEM Zuordnungstabelle für Materialstämme zu FATool Zielsystemen. AXA_GRP_ART Enthält die eigentlichen Merkmalswerte. AXA_MASTER_STR Enthält die Stücklisten. AXA_ZF_MAT_SAP Zuordnung von Materialstämmen zum entsprechenden Werk. AXA_FILE_FATOOL_SYSTEM Zuordnungstabelle für Dokumentstämme zu FATool Zielsystemen. AXA_MAT_FILE_DAT Enthält Dokumentinformationen und stellt die Verbindung zwischen Material und Dokumentstamm her. FATOOL_AXA_GRP_ART Dient zur Datenübergabe von FATool nach Axalant. Tabelle 4.2.: Datentabellen der Schnittstelle Der CAX Batch Client ist schließlich zuständig für das Auschecken von Dokumenten aus Axalant. Dieser Prozess erstellt im Allgemeinen eine Kopie des betroffenen Dokuments und setzt es an der richtigen Stelle des Verzeichnisbaumes in FATool ein, sodass es auch in diesem System verfügbar ist. 61

62 4. Ist Zustand Abbildung 4.6.: Übertragungsprozess In Abbildung 4.6 ist der Übertragungsprozess mit Prozeduren und Funktionen dargestellt. Ausgehend vom Master Service wird die Prozedur CADIM_CICS zeitgesteuert aufgerufen. Diese überprüft die Auftragsliste (Datenexport) auf neue passende Einträge. Falls Einträge existieren werden die Sachmerkmale des Materialstamms mit der Funktion GRP_ART_P8 kopiert. Die Stücklisten werden mit MASTER_STR in die Schnittstellentabellen kopiert. Schließlich werden noch mit einer der drei MAT_FILE_DAT Funktionen die angehängten Dokumentstämme untersucht, wobei der Dokumenttyp für den Aufruf der entsprechenden Funktion entscheidend ist. Die beteiligten Aktionen bei der automatischen Übergabe sind in [Fas10] spezifiziert: Stammdaten übernehmen Stückliste übernehmen Standortzuordnungen übernehmen Massenänderungen zurückübergeben Dokumente anfordern oder löschen Interaktive Rückgabe Der Rückweg von FATool nach Axalant ist ein manueller Prozess der als interaktive Rückgabe bezeichnet wird. In Abbildung 4.2 wurde bereits der Hin und Rückweg als Prozess dargestellt. Bei der Rückgabe nach Axalant muss der Betriebsmittelstatus in FATool auf 6 Warte auf Axalant Freigabe gesetzt werden. Ein Axalant Client mit angemeldeten Benutzer muss im Hintergrund laufen. Die Daten werden dann mit Hilfe einer Datei an Axalant übergeben. Die Datei enthält alle benötigten Daten, wobei die Sachmerkmale als Einzelzeilen eingetragen werden und als Trennzeichen zwischen Identifier und Werten 0xA5 verwendet wird. Währenddessen die Schnittstelle zu Axalant geöffnet ist, aktualisiert FATool zwar seine Oberfläche, aber es sind keine Benutzer Interaktionen möglich. Nachdem die Schnittstelle zu Axalant geschlossen wurde, wird in FATool der Return Code ausgewertet. Ist dieser 0, so werden die Daten aus Axalant noch einmal nach FATool geladen, da der Benutzer während der Rückgabe in Axalant noch ergänzende Eingaben machen könnte. Falls dabei der Axalant Status des Materialstamms 550 Freigegeben lautet, so wird der Betriebsmittelstatus in FATool dementsprechend angepasst und auf 0 62

63 4.2. Status Quo Freigegeben gesetzt. Falls der Return Code -1 lautet, so wird eine Fehlerdatei ausgewertet und angezeigt. Der Betriebsmittelstatus bleibt im Fehlerfall auf 6 Warte auf Axalant Freigabe, kann aber durch eine automatische Übergabe von Axalant nach FATool auf 0 Freigegeben geändert werden Transferdaten Um Einträge in den Schnittstellentabellen erzeugen zu können, bedient man sich der zugrunde liegenden Axalant Tabellen, die die gewünschten Daten beinhalten. Die Datenbanksysteme von Axalant und FATool sind jedoch nicht nur physikalisch getrennt, sondern auch an unterschiedlichen Standorten. Während die Server für Axalant in Friedrichshafen stehen, sind sie für die Verwaltung von FATool in Passau angesiedelt. Daten, die von FATool importiert werden, müssen also von Axalant nach FATool transferiert werden, sodass man sie Transferdaten nennt. Als technische Lösung wurden hierfür sogenannte Datenbank Links verwendet, die in Oracle Datenbanken zur Verfügung stehen. Ein Datenbank Link ist als Pointer zu verstehen, der eine unidirektionale Verbindung zu einer anderen Datenbank ermöglicht. Dabei handelt es sich um zwei physikalische Datenbankserver, die als verteilte Systeme zu verstehen sind, aber als eine einheitliche logische Datenbank benutzbar werden. Der Vorteil den Datenbank Links bieten ist, dass ein lokaler Benutzer eine andere Datenbank verwenden kann, ohne dabei als Benutzer der anderen Datenbank eingetragen zu sein. Die Verbindung kann dahingehend kontrolliert werden, dass beispielsweise nur Stored Procedures zugelassen werden. Somit stellt der Datenbank Link eine einfache Weise dar, um Datenbanken miteinander zu verbinden. Abbildung 4.7.: Funktionsweise Database Link 1 eines In Abbildung 4.7 ist die Arbeitsweise eines Datenbank Links dargestellt. Ein Benutzer stellt eine Anfrage an die lokale Datenbank, da diese einen Link zur Remotedatenbank gespeichert hat, wird die Anfrage an diese Datenbank umgeleitet. Der Benutzer selbst merkt davon nichts und kann die entfernte Datenbank mit Hilfe eines eindeutigen globalen Datenbanknamens direkt ansprechen. Globale Namen können mit Hilfe von Synonymen angelegt werden, sodass eine Tabelle, die auf einem anderen Host zu finden ist, ohne Angabe der kompletten URL erreicht werden kann. 1 (abgerufen am 04. Februar 2013) 63

64 4. Ist Zustand 4.3. Schwachstellen im Ist Zustand Inkonsistenz zwischen Sachmerkmalen Inkonsistente Sachmerkmale zwischen Axalant und FATool sind einfach herzustellen. Der Prozess zum Austausch von SML Daten ist bereits in Abbildung 4.2 skizziert und wird in Abbildung 4.8 nun abgewandelt dargestellt. Es beginnt wie auch im vorhergesehenen Prozess mit dem Anlegen eines Materialstamms in Axalant. Der darauffolgende Schritt umgeht jedoch bereits zwei essentielle Vorgänge. In FATool kann ein neu angelegter Materialstamm mit der Funktion Neues Betriebsmittel aus Axalant holen nach FATool importiert werden, unabhängig von dessen Status oder ausgefüllten Muss Merkmalen. Ist dieser Materialstamm erst einmal in FATool verfügbar, können die Merkmalswerte beliebig ergänzt werden und der Betriebsmittelstatus auf 0 Freigegeben gesetzt werden, ohne dass Änderungen nach Axalant eingecheckt werden müssen. Das führende System Axalant wird dadurch umgangen und auch Folgesysteme wie SAP somit nicht aktualisiert. Abbildung 4.8.: Erzeugen von Inkonsistenzen zwischen SML Daten Es muss zu keinem Zeitpunkt der Status auf 6 Warte auf Axalant Freigabe gesetzt werden, was die interaktive Rückgabe aktivieren würde. Inkonsistenzen sollten im Normalfall nur dann auftreten, wenn Mehrinformationen zur Verfügung stehen, die von einem der beiden Systeme nicht verarbeitet werden können, wie es bei KWZ mit mehreren Schneiden der Fall ist Eingeschränkte Suche Die Suche nach Betriebsmitteln in FATool ist auf den eigenen Standort begrenzt. Dies liegt einerseits an dem Verteilungskonzept, das mit den SAP Standorten arbeitet und andererseits an den lokalen Installationen, wodurch jeder Standort seine eigene Datenbank besitzt. Das Problem besteht in der Redundanz bei der Fertigung von Betriebsmitteln. 64

65 4.3. Schwachstellen im Ist Zustand Oft werden solche neu angelegt und entwickelt, obwohl sie an anderen Standorten bereits verfügbar wären, aber schlichtweg nicht gefunden werden oder einsehbar sind. Um trotzdem nach FHM an anderen Standorten suchen zu können, musste man bisher nach Axalant wechseln. War die Suche nach dem Betriebsmittel erfolgreich, so muss der eigene SAP Standort eingetragen werden, der dieses Bauteil am lokalen Standort in FATool verfügbar macht. Ist jedoch mehr als ein SAP Standort eingetragen, darf das Betriebsmittel nicht mehr geändert werden bzw. nur vom Standort mit der entsprechenden Änderungshoheit. Dies kann umgangen werden, indem eine Kopie des betroffenen Materialstamms in Axalant angelegt wird, der nur einen SAP Standorteintrag enthält Klassenmapping Wie bereits beschrieben haben FATool und Axalant verschiedenartige Klassensysteme, auch wenn beide auf DIN4000 basieren. Dies erfordert ein Mapping beim Import von Klassen nach FATool. Die Herausforderung besteht darin, die Klassen in FATool aktuell zu halten, sodass beide Systeme auf denselben Grundlagen beruhen. Es ist jedoch ähnlich wie beim Dokumentabgleich schwierig festzustellen, wann Änderungen an den Klassen vorgenommen wurden. Wenn Änderungen in den lokalen FATool Installationen vorgenommen werden, müssen diese für jeden Standort manuell ausgeführt werden, was mit einem enormen Zeitaufwand verbunden ist. So kann der komplette Update Prozess zwischen acht bis zehn Stunden dauern, sodass während dieser Zeit auch Inkonsistenzen zwischen den Systemen auftreten können Änderungswesen Um Änderungen an Betriebsmitteln in FATool verfolgen zu können, kann ein Konfigurationsparameter gesetzt werden, der diese in einem Änderungslogbuch protokolliert. In diesem Logbuch werden allerdings nur der Änderungsuser und das Änderungsdatum gespeichert, sodass die ausgeführte Aktion nicht mehr nachvollziehbar ist. Durch das fehlende Änderungswesen können Änderungen teilweise nicht mehr rückgängig gemacht werden, da die Art der Änderung nicht mehr bekannt ist Aktualisierungen Bei Änderungen, die alle verfügbaren FATool Installationen im ZF Konzern betreffen, wie dem Klassenmapping, müssen diese für alle Standorte manuell durchgeführt werden. Es muss also für jedes FATool System die gleiche Aktion ausgeführt werden, wobei dieser Prozess zeitversetzt stattfindet und dadurch zeitbedingte Inkonsistenzen zwischen den Systemen entstehen. 65

66 4. Ist Zustand Dokumentabgleich Wenn in Axalant Änderungen an Dokumenten gemacht werden, wird FATool über diese Änderungen nicht in Kenntnis gesetzt, sodass zum Teil veraltete Dokumente im System kursieren. Der Grund dafür liegt in der Schnittstelle AXA2FASys, die zwar Statuswechsel am Materialstamm berücksichtigt, jedoch nicht am Dokumentenstamm. So werden die Dokumente nur aktualisiert, wenn auch Änderungen am Materialstamm vollzogen werden und der Datenexport über die Auftragsliste angestoßen wird, wie in Abbildung 4.9 dargestellt. Eine andere Möglichkeit ein Dokument in FATool zu aktualisieren führt über die Applikation selbst, indem die Funktion Aktuelles Betriebsmittel aus Axalant holen gewählt wird und die entsprechende Materialnummer eingegeben wird. Beide Vorgehen sind jedoch umständlich und nicht intuitiv. Abbildung 4.9.: Dokumentabgleich mit bisherigen Möglichkeiten Ein weiteres Problem des Dokumentabgleichs stellt die Versionierung in Axalant dar. Bei versionierten Dokumente bleiben ältere im System erhalten, haben aber einen ungültigen Status. Die Dokumente in FATool werden nicht durch die neueren Versionen ersetzt. Erschwerend kommt hinzu, dass bei einem manuellen Aktualisierungsprozess in FATool, wie durch Aktuelles Betriebsmittel aus Axalant holen, das entsprechende Dokument trotz neuer Versionen nicht aktualisiert wird. Somit werden durch die Versionierung dauerhaft veraltete Dokumente in FATool gehalten Transferdaten Die Transferdaten sind aus der Gegebenheit erwachsen, dass die Datenbanken von FA- Tool und Axalant nicht nur physisch, sondern auch örtlich getrennt sind. Das Problem bei den Transferdaten besteht darin, dass bei einer schlechten Anbindung des Standorts 66

67 4.3. Schwachstellen im Ist Zustand auch der Datenbank Link in seiner Geschwindigkeit reduziert ist. Dies führt zu langen Ladezeiten und macht große Auswertungen, Massenupdates oder Dokumentüberrollungen in einer angemessenen Zeit nahezu unmöglich. Vor allem viele kleine Anfragen an die Remote Datenbank bremsen den Link aus, da sich die Verzögerung durch die Verbindung aufsummiert. Ein weiteres Problem des Datenbank Link besteht im Aufbau der Queries. Anfragen, die nur wenige Bedingungen enthalten, können den Link schnell verlangsamen, da möglicherweise eine ganze Axalant Tabelle empfangen werden muss und diese erst in den Cache der lokalen Datenbank geladen werden muss. In Abbildung 4.10 ist die aktuelle Situation mit den Transferdaten dargestellt. Die Da- Abbildung 4.10.: Transferdaten mit Verbindung über Datenbank Link ten die gebraucht werden, um die Schnittstellentabellen zu füllen, sind in der Axalant Datenbank zu finden. Diese befindet sich jedoch in Friedrichshafen, während die FATool Verwaltung in Passau ist. Die Prozeduren und Funktionen der Schnittstelle holen sich die Daten über den Link und speichern sie in Passau in den Übergabetabellen. Ein Dispatcher ist zuständig für die Verteilung der Daten an die lokalen Zielsysteme Inkonsistenz zwischen Dokumenten Inkonsistenzen bei Dokumenten entstehen immer dann, wenn Dokumente direkt in FATool verwaltet werden sollen oder nicht nach Axalant eingecheckt werden. Da Axalant das strategische Dokumentverwaltungssystem ist, sollen alle Dokumente, die in FATool zur Verfügung stehen, auch primär in Axalant vorhanden sein. Generell ist es in FATool möglich einem Betriebsmittel ein Dokument manuell hinzuzufügen, was zu dem Problem führt, dass ein solches Dokument nicht von der Schnittstelle 67

68 4. Ist Zustand berücksichtigt wird und damit sehr leicht Inkonsistenzen zwischen beiden Systemen erzeugt werden können. Selbst wenn das Einchecken des Dokuments nach Axalant gewünscht wird, muss zunächst manuell in Axalant ein Dokumentstamm angelegt werden. Ein weiteres gängigeres Szenario ist das Anlegen eines Materials mit dem darauffolgenden Erzeugen eines 3D Modells, wie es in Abbildung 4.11 dargestellt ist. Hierbei kommen mehrere Systeme zum Einsatz, die farblich gekennzeichnet sind: Axalant in rot, FATool in gelb und CREO in grün. Des Weiteren sind auch zwei verschiedene Prozessabläufe gekennzeichnet, wobei der richtige in grün und der falsche in rot abgebildet ist. Abbildung 4.11.: Prozess vom Material zum 3D Modell Der Prozess zum Anlegen eines neuen Materialstamms beginnt immer in Axalant, da hier unternehmensweit eindeutige Materialnummern vergeben werden. Da im aktuellen Zustand noch keine Merkmalswerte eingetragen sind, kann das Material in Axalant noch nicht freigegeben und somit nicht über die AXA2FASys Schnittstelle übertragen werden. In FATool gibt es allerdings die Möglichkeit Betriebsmittel manuell zu importieren, indem man die Funktion Neues Betriebsmittel aus Axalant holen wählt und die entsprechende Materialnummer bereithält. Jetzt können die benötigten Merkmalswerte in FATool ausgefüllt werden und daraufhin ein 3D Modell erzeugt werden. Dies geschieht im Hintergrund, indem CREO aufgerufen wird und eine STL 2 Datei erzeugt wird, die als 3D Flächenmodell im FATool Viewer betrachtet werden kann. Eine originalgetreue Darstellung der Betriebsmittelverwaltung von FATool mit Viewer und den verknüpften Dokumenten kann im Anhang A.2 in Abbildung A.6 eingesehen werden. Zur NC Simulation wird allerdings ein Volumenmodell benötigt, das direkt in CREO erstellt wird. Dazu stellt FATool die Funktion 3D Grafik aus CAD Masterpart erzeu- 2 Surface Tesselation Language bezeichnet eine Sprache zur Beschreibung von Oberflächen durch Dreiecke, die von CAD Systemen unterstützt wird und somit als eine Standardschnittstelle angesehen wird. 68

69 4.3. Schwachstellen im Ist Zustand gen bereit, sodass die eingegebenen Merkmalswerte zusammen mit einem parametrisierten Mastermodell nach CREO übergeben werden. Bevor das Volumenmodell in CREO erzeugt werden kann, muss in Axalant ein Dokumentstamm zum zugehörigen Materialstamm angelegt werden. Dabei kann es nur einem Materialstamm zugeordnet werden, da das Dokument zu den Merkmalswerten des Materials passen muss. Allerdings besteht zwischen Material und Dokumentstämmen im Allgemeinen eine n:m Beziehung, sodass einem Material mehrere Dokumentstämme zugeordnet sein können, aber einem Dokument auch mehrere Materialstämme wie in Abbildung 4.12 ersichtlich wird. Abbildung 4.12.: Beziehung zwischen Material und Dokumentstamm CREO bietet hierfür die Funktion Nach Axalant mit Rückfrage, sodass in Axalant eine Maske erscheint mit der der Dokumentstamm angelegt und einem Material zugewiesen werden kann. Nach dem Anlegen stehen weitere durch Axalant standardisierte Parameter zur Verfügung, die zu dem 3D Modell hinzugefügt werden müssen, um es mit dem Dokumentstamm zu verknüpfen. Hierfür sieht CREO die Funktion Axalant Parameter zuordnen vor. Das 3D Modell ist an dieser Stelle fertig und wird in FATool mit Speichern der 3D Grafik aus CAD zurückgeholt und damit die Schnittstelle zu CREO geschlossen. Das erzeugte 3D Modell liegt in FATool als grafik.prt oder grafik.asm vor. Um die Merkmalswerte nun auch nach Axalant zu übertragen, wird die interaktive Rückgabe verwendet. Dazu setzt man den Betriebsmittelstatus in FATool auf Warte auf Axalant Freigabe und die Schnittstelle wird geöffnet. Während dieser Zeit ist FATool nicht nutzbar und in Axalant erscheint die richtige vorausgefüllte Sachmerkmalleiste. Letzter Schritt in Axalant ist es die Merkmalswerte zu speichern und mit Zurück nach CAD die Schnittstelle zu schließen. Diese Beschreibung stellt den normalen Prozess dar, wie er ablaufen sollte. In der Realität wird allerdings oft nur das 3D Modell in CREO erzeugt und wieder nach FATool zurückgeholt. Dabei wird kein Dokumentstamm in Axalant angelegt und das CAD Dokument steht nur in FATool zur Verfügung. Ohne dem Einchecken nach Axalant läuft dieser Prozess natürlich sehr viel schneller ab, aber andere Standorte haben keine Möglichkeit mit diesen Dokumenten zu arbeiten und es entstehen Inkonsistenzen zwischen den Systemen Dokumentverwaltung FATool besitzt keine eigene Dokumentverwaltung, sodass Dateien nur schwer als aktuell zu erkennen sind und oft redundant im System vorliegen. Dies ist in der Namenskonvention begründet, die in FATool gepflegt wird. So müssen TIF Grafiken, die automatisch im 69

70 4. Ist Zustand Viewer angezeigt werden sollen, den Namen egrafik.tif erhalten und STL oder PRT Dateien den Namen grafik.stl bzw. grafik.prt. Wenn Dokumente in Axalant gespeichert werden, so müssen Sie einem Dokumentstamm zugewiesen werden und bekommen automatisch eine AA Nummer vom System. Will der Benutzer nun die Datei aus FATool mit der aus Axalant abgleichen, so ist dies wegen der verschiedenen Dateinamen nur bedingt möglich. Für den Benutzer ist es also schwer nachzuvollziehen, ob im System die aktuellste Datei vorliegt. Abbildung 4.13.: Redundanzen durch Namenskonventionen Redundanzen liegen dann vor, wenn der Anwender aus den hinterlegten Merkmalen und einem Mastermodell ein 3D Modell erzeugen will, wie in Abbildung 4.13 gezeigt wird. Das Modell wird in CREO erzeugt, wobei der Benutzer die fertige PRT Datei in Axalant einchecken muss. Dadurch wird automatisch ein Dokumentstamm erstellt und für diesen eine AA Nummer generiert. Die aus CREO eingecheckte Datei trägt die AA Nummer als Teil seines Dateinamen. Anschließend wird das Modell von CREO an FATool zurückgegeben und liegt ab sofort dort als grafik.prt vor. Durch die AXA2FASys Schnittstelle wird der neu erstellte Dokumentstamm mit FATool synchronisiert und somit das bereits existierende 3D Modell erneut importiert, sodass es redundant vorliegt Datenleichen Beim Anlegen von neuen Materialien in Axalant, ohne einen darauffolgenden Statuswechsel, kann es dazu kommen, dass Datensätze, die ursprünglich zwischen Axalant und FATool synchronisiert wurden, nur noch in FATool existieren. Dies ist bei synchronisierten Datensätzen unbedingt zu vermeiden, da das System andernfalls Datenleichen enthalten kann. Der Prozess, der zu einem solchen unerwünschten Ergebnis führt, ist in Abbildung 4.14 dargestellt. Nach dem Erstellen des neuen Materials muss man unterscheiden, ob ein Statuswechsel stattgefunden hat. Falls ein Wechsel auf 550 Freigegeben durchgeführt wurde, wird das Material über die bestehende AXA2FASys Schnittstelle übertragen. Ist der Status auf 550 Freigegeben gesetzt, ist das unerwünschte Verhalten nicht zu beobachten, 70

71 4.3. Schwachstellen im Ist Zustand Abbildung 4.14.: Prozess zum Erzeugen von Datenleichen da einmal freigegebene Materialstämme nicht mehr gelöscht werden können. Findet kein Statuswechsel statt, so kann das gewünschte Material manuell nach FATool geholt werden. Für den manuellen Import steht die Funktion Neues Betriebsmittel aus Axalant holen zur Verfügung. Durch Angabe der entsprechenden Materialnummer wird das Betriebsmittel nach FATool importiert. Sollte es nun in Axalant gelöscht werden, bleibt der Datensatz in FATool bestehen, da die Änderungen von der Schnittstelle wegen des fehlenden Statuswechsels nicht berücksichtigt werden. Auch wenn dieser Fall nicht das geplante Vorgehen darstellt, ist er zu berücksichtigen, da unvorhersehbare User Interaktionen zu diesem Verhalten führen können Betriebsmittelstatus In FATool gibt es verschiedene Betriebsmittelstatus, die unter anderem angeben, ob ein Betriebsmittel an einem Standort eingesetzt wird. Außerdem kann hier der Status zur interaktiven Rückgabe gesetzt werden. Es gibt demnach die folgenden Status für Betriebsmittel: 0 Freigegeben 1 Im Test 2 Prüfen 5 ungeprüft 6 Warte auf Axalant Freigabe 7 Archiv 9 Gesperrt In der Verwendung von Betriebsmitteln ist der Betriebsmittelstatus allerdings nicht greifend. Das heißt, selbst wenn ein Bauteil nicht auf 0 Freigegeben gesetzt ist, kann es in Komplettwerkzeugen verwendet werden. Des Weiteren kann das Betriebsmittel auch verwendet werden, wenn der Status explizit auf 9 Gesperrt gesetzt ist. Dies hat eine irritierende Wirkung und führt dazu, dass der Betriebsmittelstatus durch die Anwender schlecht gepflegt und überhaupt berücksichtigt wird. 71

72 4. Ist Zustand 4.4. Zusammenfassung In Tabelle 4.3 sind die gefunden Schwachstellen zusammenfassend dargestellt und mit einer Kurzbeschreibung nach ihrer Priorität sortiert, die von 1 (höchste) bis 3 reicht. ID Name Kurzbeschreibung Priorität 1 Eingeschränkte Suche Das Suchen von Betriebsmitteln ist auf 1 den eigenen Standort beschränkt. 2 Transferdaten Die Performance des Datenbank Link erschwert 1 die Durchführung von Massenup- dates. 3 Aktualisierungen An jedem Standort müssen Änderungen 1 manuell durchgeführt werden, was zu 4 Inkonsistenz zwischen Dokumenten 5 Inkonsistenz zwischen Sachmerkmalen kurzfristigen Inkonsistenzen führt. Ein manuelles Hinzufügen von Dokumenten, sowie das Erstellen von 3D Modellen ohne nachfolgendes Einchecken in das PDM System können Inkonsistenzen auslösen. Eine Rückgabe der geänderten Merkmalswerte ist nicht erforderlich, sodass die Systeme auf unterschiedlichen Ständen sind. 6 Klassenmapping Änderungen an Klassen sind schwer festzustellen und die Systeme demnach nicht konsistent. 7 Dokumentabgleich Veraltete Dokumente durch fehlendes Verhalten der Schnittstelle auf Änderungen am Dokumentstamm zu reagieren. 8 Datenleichen Manuell importierte Betriebsmittel werden ohne zugehörigen Materialstamm als Datenreste im System gehalten. 9 Betriebsmittelstatus Der Betriebsmittelstatus greift nicht und gesperrte Bauteile können dadurch in KWZ verwendet werden. 10 Änderungswesen Durchgeführte Änderungen sind ohne die Protokollierung der ausgeführten Aktion schwer nachzuvollziehen. 11 Dokumentverwaltung Durch die Namensgebung ist es schwierig festzustellen, ob eine Datei aktuell ist und es führt weiterhin zu Redundanzen. Tabelle 4.3.: Schwachstellen im Ist Zustand

73 5. Soll Konzept Szenario In diesem Kapitel wird das bereits geplante Soll Konzept anhand des Lastenhefts detailliert erläutert und gesondert auf Sachwachstellen eingegangen, die durch das neue Konzept hervorgebracht werden. Offene Punkte, die das bestehende Lastenheft nicht abdeckt, werden in einem erweiterten Soll Konzept dargelegt und mögliche Lösungswege für die Schwachstellen des Ist und Soll Zustands beschrieben. In einer finalen Zusammenfassung wird überprüft, ob die gefundenen Schwachstellen durch das bestehende oder das erweiterte Soll Konzept beseitigt werden Bestehendes Soll Konzept Die folgenden Ideen zum Soll Konzept sind dem Lastenheft vom entnommen und spiegeln das geplante Vorgehen wider. Zunächst wird eine Übersicht über die Architektur gegeben und dann auf das Lastenheft eingegangen, wobei jeder Punkt beschrieben und bewertet wird. Schließlich werden die Schwachstellen aufgezeigt, die durch das neue Konzept entstehen Übersicht Die Grundidee für die Architektur des Soll Zustands besteht aus zwei getrennten FATool Master Servern, wobei einer für klassische ZF Standorte verantwortlich ist und der andere für ZF Lenksysteme. Dies ist erforderlich, da es zwischen ZF und ZFLS interne Konkurrenzsituationen gibt, sodass geheime Dokumente nur für die eigenen Zielsysteme sichtbar sein dürfen. Ein anderer Punkt ist die Eigenständig von ZFLS, das heißt die Systeme von ZFLS müssen bei einer eventuellen Trennung vom ZF Konzern weiterhin lauffähig bleiben. Mappings und andere administrative Aufgaben werden dann nur noch auf einem der beiden Master Server ausgeführt, sodass alle Zielsysteme und der Master ZFLS mit den durchgeführten Änderungen synchronisiert werden und diese in allen Systemen konsistent verfügbar sind. Die lokalen Zielsysteme an den Standorten werden aus Gründen der Performanz erhalten bleiben. In der Produktion müssen Daten schnell und zuverlässig zur Verfügung stehen, sodass keine Leerlaufzeiten entstehen. Da es sich dabei oft um große Dateien handelt, müssen diese komplett mit dem zentralen Master Server abgeglichen werden. Auch wegen den automatisch vergebenen Lizenzen muss der dezentrale, lokale Server bestehen bleiben, 73

74 5. Soll Konzept Szenario da ein Verbindungsausfall zum Master Server auch den Ausfall der Produktion nach sich ziehen würde. Das zentrale Viewing der FATool Daten erfordert das Öffnen eines neuen FATool Clients, der Zugriff auf den zentralen Master Server hat. Für den Import von gefundenen Betriebsmitteln muss weiterhin das SAP Standortflag in Axalant wie schon im Ist Zustand gesetzt werden, sodass das entsprechende Material am jeweiligen Standort verfügbar wird. Die Soll Architektur des bereits bestehenden Konzepts ist in Abbildung 5.1 dargestellt und wird im Folgenden detailliert beschrieben. Abbildung 5.1.: Soll Architektur Das PDM System Axalant ist weiterhin das führende System für die Klassifizierung und Stammdatenverwaltung, sodass neue Materialstämme nach wie vor dort angelegt werden müssen und somit konzernweit zur Verfügung stehen. Axalant selbst ist von der Zentralisierung des FATool nicht betroffen und die Änderungen, die um das System herum stattfinden, laufen für Axalant unsichtbar ab. Die Dispatcher, die bisher als zentrale Einheit fungierten, werden nun auf den Master ZF und Master ZFLS verlegt. Damit sind in erster Linie die Schnittstellentabellen und der Master Service betroffen, inklusiver ihrer PL/SQL Prozeduren und Funktionen. Die Verteilung der Daten auf die Master Server läuft ebenfalls über die gesetzten SAP Standorte. Während der Master ZF für alle ZF internen Standorte verantwortlich ist, was mit den SAP Standort Kürzeln FP, PP,.. verdeutlicht 74

75 5.1. Bestehendes Soll Konzept wird und zusammenfassend mit ZFGRP 1 beschrieben wird, ist der Master ZFLS für alle Daten mit dem SAP Standort GP1 verantwortlich, was mit ZFLS bezeichnet wird. Die beiden Master Server beinhalten weitestgehend unterschiedliche Daten. Nur Datensätze denen sowohl ZFGRP als auch ZFLS als Standorteintrag zugewiesen ist, sind auf beiden verfügbar. Neben dem Master Service läuft auch der Client Service am Master ZF, der das Master FATool Zielsystem mit Daten versorgt. Dieses Master System wird ferner als zentrales FATool bezeichnet. Der eigentliche Aktualisierungsprozess über den Dispatcher bleibt somit unverändert, mit dem Unterschied dass anstelle der standortspezifischen FATool Systeme nun der Master ZF und Master ZFLS synchronisiert werden, die die Daten standortübergreifend verwalten. Die Administration des Dispatchers für ZFGRP unterliegt weiterhin der Abteilung FIDA5 in Passau. Die Master Server enthalten also einen Master und einen Client Service, um ihr FATool System das zentrale FATool mit Daten zu versorgen. Sie sind allerdings auch verantwortlich für die Verteilung der Daten an die standortspezifischen FATool Zielsysteme. Dazu muss ein weiterer Master Service betrieben werden, der allerdings abgeändert wird, da die Schnittstelle des neuen Konzepts zwischen den Master Servern und ihren dezentralen Zielsystemen eine bidirektionale Kommunikation vorsieht. Dies ist erforderlich, da zusätzliche Informationen, die von Axalant nicht verarbeitet werden können, trotzdem zentral zur Verfügung stehen sollen. Durch die interaktive Rückgabe über Axalant würden diese Informationen verloren gehen und wären für andere Standorte nicht zugänglich. Dabei handelt es sich um Mehrschneidensysteme für die in Axalant nur ein Stammsatz mit nur einer Schneide existiert, in FATool jedoch flexibel verschiedene Schneiden zugeordnet werden können. Aber auch Benutzerdaten oder 3D Modelle werden direkt von den standortspezifischen Systemen an den Master zurückgegeben. Die dezentralen Server der einzelnen Standorte bleiben natürlich trotz des zentralen Master Servers erhalten, da Fertigungsdaten immer standortabhängig sind. Auch in Anbetracht der Produktion müssen die Server für die Standorte lokal zur Verfügung stehen, denn ein Verbindungsausfall zum Master Server könnte einen Produktionsstopp nach sich ziehen. Auf den lokalen Servern der Standorte läuft ein, hinsichtlich der bidirektionalen Schnittstelle, abgeänderter Client Service, der beim Master Server nach für ihn relevanten Daten anfragt. Die Verteilung erfolgt auch hier weiterhin anhand der SAP Standorte, sodass die lokalen Zielsysteme immer eine Teilmenge an Daten des Master Systems enthalten. Die jeweiligen FATool Zielsysteme werden durch den zuständigen Divisionsstandort administriert. Für die Industrietechnik (I Division) ist Passau der Divisionsstandort und verwaltet somit auch Gainesville. Die interaktive Rückgabe bleibt erhalten, um Änderungen mit Axalant abzugleichen. Zusätzlich kommt die Möglichkeit zum 1 Standorte können zu Gruppen zusammengefasst werden, sodass alle klassischen ZF Standorte mit ZFGRP bezeichnet werden und ZF Lenksysteme mit ZFLS. ZFGRP bezeichnet dabei alle Bereiche außer LS und Standorte in China. 75

76 5. Soll Konzept Szenario Viewen der zentralen Master Daten hinzu. Dies bedeutet für den Endanwender, dass er einen zusätzlichen FATool Client öffnet, der auf die Daten des Master ZF zugreift und somit standortunabhängig alle Daten einsehen kann. Der Master ZF Server wird vom Master ZFLS mit Daten aus dem Bereich ZF Lenksysteme versorgt. Hierbei muss jedoch zwischen den Änderungshoheiten unterschieden werden. Während alle Datensätze am Master ZFLS als Standort ZFLS beinhalten, gibt es einige mit der spezifischen Änderungshoheit Das bedeutet, dass diese Datensätze nur für ZFLS sichtbar sind und somit nicht mit dem Master ZF abgeglichen werden dürfen. Damit beinhaltet der Master ZF Daten von ZFGRP und ZFLS, sodass ZFLS Endanwender auch ihre eigenen Daten beim Viewing am Master Server zur Verfügung haben. Durch das Viewen von Daten anderer Standorte, können Betriebsmittel leichter gefunden und in das eigene FATool Zielsystem importiert werden. Dies geschieht, wie bereits beschrieben, durch das Setzen des SAP Standorts am Materialstamm in Axalant, sodass die AXA2FASys Schnittstelle die Daten mit dem eben hinzugefügten FATool System synchronisiert. Dies gilt auch für ZFLS Benutzer, die jedoch einen eigenen Master Server haben, der ihr Zielsystem abgleicht. Sollen nun Daten synchronisiert werden, die Mehrinformationen beinhalten, solche die also nur von FATool verwaltet werden können (z.b. Mehrschneidensysteme), muss der Abgleich zwischen den beiden FATool Master Servern möglich sein, da in Axalant diese Informationen nicht verfügbar sind. Der Abgleich von gemeinsamen FATool Daten findet also direkt zwischen den Master Servern statt. Bei Änderungen an Mappings von Klassendefinitionen müssen diese in Zukunft nur noch an einem System durchgeführt werden. Neben den Zielsystemen der ZFGRP, wird auch der Master ZFLS mit geänderten Mappings synchronisiert, die nur einer Änderung am Master ZF bedürfen, um alle FATool Systeme einheitlich und konsistent zu halten. Das Viewing der zentralen Master Daten findet auch für ZFLS Anwender auf dem Master ZF Server statt, denn der Master ZFLS beinhaltet nur Daten, die äquivalent mit dem ihres lokalen FATool Zielsystems sind und somit der Vorteil zur Suche von Betriebsmitteln anderer Standorte zunichte wäre. Natürlich muss für das Viewing somit ein erweitertes Sichtenkonzept eingeführt werden, da es innerhalb der ZF interne Konkurrenten gibt, die Daten der jeweils anderen Standorte nicht einsehen dürfen. Diese Regelung besteht nicht nur zwischen ZFGRP und ZFLS, sondern auch zwischen Standorten innerhalb von ZFGRP, sodass das Sichtenkonzept ausreichend feingranular aufgebaut werden muss. 76

77 5.1. Bestehendes Soll Konzept Lastenheft Im Folgenden werden die Punkte des Lastenhefts zitiert, die in Relation mit dieser Arbeit stehen. Zu jedem Punkt werden zusätzliche Informationen mit detaillierter Beschreibung gestellt, damit die Anforderungen für den Leser verständlich werden. Falls Punkte fehlerhaft oder widersprüchlich beschrieben sind, wird in einer Anmerkung die Aussage richtig gestellt. Falls Punkte etwaige Schwachstellen enthalten, werden sie als solche markiert und im erweiterten Soll Konzept mögliche Lösungswege vorgestellt. Konzepte, die FA- Tool spezifisch sind und keine Verbindung zu den behandelten Themen dieser Arbeit aufweisen, werden in dieser Arbeit nicht berücksichtigt. Dies betrifft die Punkte Konzept für Software Releasewechsel und Konzept für dezentrale Funktionserweiterungen je Standort, sowie Analyse der bestehenden Schnittstellen von FATool zu anderen IT Systemen an den beteiligten Standorten. Als Schnittstelle zu anderen IT Systemen wird lediglich die Verbindung zu Axalant berücksichtigt. Berechtigungskonzept Die Sichtbarkeit der Daten aus dem PDM System muss innerhalb der PDM2FATool Schnittstelle realisiert werden. Die Schnittstelle zwischen Axalant und FATool berücksichtigt bereits die Änderungshoheit des Fertigungshilfsmittels bei der Übertragung. Bisher dient die Änderungshoheit in FATool rein informativen Zwecken und stellt keine funktionalen Eingriffe dar. Die Schnittstelle muss dahingehend erweitert werden, dass auch die Änderungshoheit des aktuell angemeldeten Benutzers verwendet und mit der des Fertigungshilfsmittels abgeglichen wird, um über die Sichtbarkeit von Daten entscheiden zu können. Das geplante Vorgehen für die Übertragung von Daten über die Schnittstelle ist zunächst, dass nur Daten übertragen werden, die von allen Standorten gesichtet werden dürfen. Schwachstelle Da auch im FDO Bereich Datensätze existieren, die nur für bestimmte Standorte sichtbar sein sollen, reicht es nicht aus sensible Datensätze in der Schnittstelle zu filtern. Daher müssen die entsprechenden Berechtigungskonzepte aus Axalant nach FATool portiert werden. Dabei ist zu unterscheiden, ob die Sichtbarkeit die Meta Daten, die verknüpften Dateien oder beides betrifft. Anwenderbezogene Änderungshoheit aus PDM System muss in FATool zur Verfügung gestellt werden. In Axalant können einem Benutzer mehrere Änderungshoheiten zugewiesen sein, wobei jeder Benutzer in der Regel eine seinem Standort entsprechende Standard Änderungshoheit besitzt. Diese wird unter anderem beim Anlegen von neuen Datensätzen verwendet, da jedes Objekt eine eindeutige Änderungshoheit besitzen muss. Um die anwenderbezogene Änderungshoheit in FATool umzusetzen, muss zusätzlich der Zugriffstyp auf Datensätze, dem die Attribute Lesen, Schrei- 77

78 5. Soll Konzept Szenario ben und Löschen sowie eine explizite Gültigkeit zugeordnet werden können, synchronisiert werden. Da die Menge an Benutzern in FATool nur eine Teilmenge der Benutzer in Axalant darstellt, können diese anwenderbezogenen Berechtigungen stündlich aktualisiert und gemappt werden. Schwachstelle Bei diesem Punkt wird davon ausgegangen, dass die anwenderbezogene Änderungshoheit als Berechtigungskonzept in FATool ausreichend ist. Dies muss zunächst einer Prüfung unterzogen werden. Unterschiedliche Benutzerverwaltungen für die verschiedenen Systeme würde einen enormen Overhead bedeuten, sodass ein Mapping der entsprechenden Benutzerrechte aus Axalant erstellt werden muss. Welche Berechtigungen portiert werden müssen, wird durch Aufstellen der Anforderungen ermittelt. Das im FATool bestehende Berechtigungskonzept zur Administration der FATool Konfiguration muss verfeinert werden. Die Administratoren von FATool Master müssen auf allen FATool-Zielsystemen angelegt werden. Den Administratoren der zentralen Server muss es erlaubt sein, sich auch auf die dezentralen Zielsysteme einzuloggen, um dort Anpassungen vornehmen zu können. Auf standortspezifische Tabellen sollten allerdings nur die jeweiligen Standortadministratoren Zugriff haben. Ihnen soll es außerdem erlaubt sein, zentral User anzulegen. Allerdings sollten sie keinen Zugriff auf die zentralen Mapping Tabellen erhalten. Administrative Aufgaben, die den eigenen Standort betreffen, sollen durchführbar bleiben. Änderungen, die alle Zielsysteme betreffen, dürfen nur von zentralen Administratoren durchgeführt werden. Anmerkung Diese Anpassung ist außerhalb des Berechtigungskonzepts von Axalant durchzuführen und mit verschiedenen User Rollen innerhalb von FATool umzusetzen. Die User Rollen aus Axalant müssen dennoch berücksichtigt werden, sodass Änderungen nur an zulässigen Betriebsmitteln durchgeführt werden können. Integration der FATool Installation bei ZFLS Systemtechnische Abbildung mit einem separaten Mastersystem ZFLS erforderlich. Wegen der Eigenständigkeit von ZFLS muss ein eigenständiges Mastersystem eingeführt werden, sodass ZFLS bei einer möglichen Abspaltung vom restlichen ZF Konzern weiterhin autonom arbeiten kann. Eine Abbildung des Master ZF betrifft dabei allerdings nur Konfigurationsdaten wie Klassendefinitionen, die auf dem administrativen Master ZF gepflegt und auf Master ZFLS abgebildet werden. Die eigentlichen Nutzdaten werden nicht vollständig zwischen den Systemen synchronisiert, da es auf beiden Seiten geheime Dokumente gibt, die für die jeweils andere Seite nicht sichtbar sein sollen. 78

79 5.1. Bestehendes Soll Konzept ZF-Lenksysteme behält ihre eigenständige FATool Infrastruktur bei. Bereits im Ist Zustand wurde der Dispatcher für ZFGRP und ZFLS separat betrieben. Im Soll Zustand ist es ebenfalls so geplant, mit dem Unterschied, dass nun zunächst der zentrale Master ZFLS mit den Daten synchronisiert wird und erst dann die Daten an das momentan einzige FATool Zielsystem innerhalb ZFLS weitergereicht werden. Schwachstelle Durch die Eigenständigkeit und die getrennten Dispatcher ist ZFLS selbst zuständig für die Verteilung der Daten. Durch diese Selbstregulierung ist es theoretisch möglich, dass ZFLS auch Daten nach Master ZFLS importiert, die nicht für ZF Lenksysteme vorgesehen sind. Hierzu müssen in der jeweiligen Schnittstellenfunktion die gewünschten SAP Standorte eingetragen werden. Dieses Vorgehen kann nicht unbemerkt bleiben, da die Datensätze im eigentlichen Zielsystem fehlen werden. Es sollte aber dennoch als Schwachstelle erwähnt werden. Die FATool Daten aus LS werden durch FASys bei Anlage und Änderung an den ZF Konzern zentralen Master repliziert. Dabei ist das Berechtigungskonzept aus Axalant (Änderungshoheit, Sichtbarkeit an Standorten) zu berücksichtigen. Ein Abgleich zwischen den Servern Master ZF und Master ZFLS ist grundsätzlich möglich, wobei Daten von ZFLS nur dann repliziert werden, falls ihre Änderungshoheit nicht 4320 ist. Darüber hinaus gibt es auch Datensätze, die virtuelle Standorte als Eintrag haben und somit erst gar nicht repliziert werden dürfen. Auch lesebeschränkte Daten sollen übertragen werden, allerdings sollen dabei nur die Meta Daten zur Verfügung stehen. Die beiden Master Systeme sind daher in ihrem Datenbestand relativ unterschiedlich. Gemeinsame Daten kommen nur durch die Replikation von ZFLS nach ZF zustande, wenn ZFGRP und ZFLS als Standorte eingetragen sind oder wenn Datensätze nach ZFLS importiert werden, die Mehrinformationen aus FATool beinhalten und direkt zwischen den Master Servern abgeglichen werden. Für die LS Anwender soll die Möglichkeit bestehen, die Daten im FATool Master ZF per Viewer anzusehen. Werden solche Teile bei ZFLS gebraucht, wird über einen SAP Standort Eintrag im PDM System das Teil auch in das Mastersystem von ZFLS übertragen. Dadurch, dass ZFLS Anwender auch Daten am zentralen Master ZF viewen können, müssen erweiterte Berechtigungskonzepte umgesetzt werden, da am Master ZF Datensätze existieren, die für ZFLS nicht sichtbar sein dürfen. Hierzu wird einerseits die Berechtigung des Users und andererseits die des Standorts überprüft, der durch die Schnittstelle über Axalant zur Verfügung gestellt wird. Der Standorteintrag in Axalant muss manuell durchgeführt werden und setzt ebenfalls die entsprechenden Berechtigungen in Axalant voraus. 79

80 5. Soll Konzept Szenario Der FATool Master ZF sollte alle FATool Daten von ZF und ZFLS beinhalten. Da die Konfigurationsdaten ausschließlich am Master ZF gepflegt werden, muss es sich bei diesem Punkt um die Nutzdaten handeln, die von Master ZFLS nach Master ZF übertragen werden. Da hier von allen FATool Daten die Rede ist, müsste der Master ZF den Master ZFLS komplett beinhalten, was allerdings nicht der Fall ist, wie in Abbildung 5.2 zu sehen ist. Master ZF Master ZFLS Passau Gainesville Padua Dielingen... ZFLS ohne 4320 ZFLS ohne Abbildung 5.2.: Datenüberschneidung zwischen ZF und ZFLS Anmerkung Die beiden Systeme besitzen maximal eine gemeinsame Schnittmenge, die nur die Daten betrifft deren Änderungshoheit ungleich zu 4320 ist. Des Weiteren finden sich auch manuell nach Master ZFLS importierte Daten in der Schnittmenge wieder, die in beiden Systemen verfügbar sind und ein Austausch über Zusatzinformationen stattgefunden hat. Alle Datensätze mit Änderungshoheit 4320 sind nur für ZFLS bestimmt und werden nicht mit Master ZF repliziert. Einheitliche Klassifizierungs und Mapping Tabellen werden auf dem FATool Master ZF gepflegt, sodass beide Master auf dieselbe Basis zurückgreifen können. Die administrativen Aufgaben, wie das Anpassen von Mappings und Klassendefinitionen, müssen nur noch auf dem Master ZF durchgeführt werden. Der Master ZFLS wird direkt synchronisiert und alle FATool Zielsysteme sind mit nur einer Anpassung aktuell und konsistent. 80

81 5.1. Bestehendes Soll Konzept Zentrales Mapping der PDM SML Felder Der Ausgangspunkt für die FHM Übertragung nach FATool sind die PDM Klassen. Der Austausch von Fertigungshilfsmitteln zwischen Axalant und FATool basiert auf den zugrunde liegenden Klassen aus Axalant. Jedes Fertigungshilfsmittel wird einer Klasse in FATool zugeordnet, wofür zunächst ein Klassenmapping erstellt werden muss. Nur durch die richtige Zuordnung von Quell und Zielleiste kann ein Import durchgeführt werden. Die benötigten Klassen je FATool Zielsystem können nach entsprechender Abstimmung standortspezifisch festgelegt werden. Dies wird auf FATool Master ZF definiert und dann auf FATool Master ZFLS repliziert. Angenommen ein bestimmter Standort benötigt eine spezielle Klasse aus Axalant in seinem Zielsystem, dann läuft die Verteilung über Master ZF, wobei die Klasse nur an den speziellen Standort ausgeliefert wird. Trotzdem bleibt sie am zentralen Master Server verfügbar. Solche Klassenmappings werden ausnahmslos am Master ZF gepflegt und auf den Master ZFLS repliziert. Schwachstelle Wenn seitens ZFLS eine neue Klasse und damit auch ein neues Klassenmapping gebraucht wird, so kann dies am zentralen Master ZFLS nicht durchgeführt werden, da Klassenmappings nur am Master ZF definiert werden. Es fehlt eine Lösung wie ZFLS auch Klassenmappings verwalten und neu anlegen kann. Die betroffenen FATool Leistendefinitionen (Sachmerkmale, Leisten und Bilder) werden auf die FATool Zielsysteme sowie auch FATool Master ZFLS verteilt. Die einzige zu pflegende, zentrale Einheit stellt der Master ZF dar, der FA- Tool Daten sowohl an die Zielsysteme, als auch an Master ZFLS verteilt. Dadurch wird der Aufwand bei Anpassungen an Konfigurationsdaten minimiert und kann schnell und konsistent an alle anderen FATool Installationen verteilt werden. In FATool Master gibt es ein einheitliches zentrales Klassenmapping. Das einheitliche zentrale Klassenmapping erhält die Konsistenz zwischen den Systemen. Das Mapping ist somit für alle Standorte gleichermaßen bindend und kann nur zentral verändert werden, jedoch nicht standortspezifisch. FATool interne Leisten werden beim Releasewechsel zentral über FATool Master aktualisiert. Die Verantwortung liegt hier bei der Firma FASys. Bei Einführung des zentralen Systems muss ebenfalls ein Releasewechsel der FATool Applikation durchgeführt werden, der das neue Konzept unterstützt. Falls sich somit Änderungen an Konfigurationsdaten ergeben, muss zukünftig kein Patch mehr verteilt werden, sondern es werden die internen Leisten am Master ZF 81

82 5. Soll Konzept Szenario angepasst und auf die Zielsysteme repliziert. Die Aktualisierung der standortspezifischen Leisten unterliegt der Verantwortung des jeweiligen Standortes. Unter standortspezifischen Leisten versteht man diejenigen Daten, die so speziell auf einen Standort zugeschnitten sind, dass sie nicht zentral gepflegt werden können. Dies ist bei der NC Programmverwaltung der Fall, denn jeder Standort hat verschiedene DNC Maschinen im Einsatz, sodass dieses Modul nicht standortübergreifend verwaltet werden kann. So besitzt jeder Standort am zentralen Master ZF eine eigene standortspezifische Leiste, die die lokalen Daten enthält (z.b. ncpv_pas für Passau, ncpv_pdv für Padova). So werden standortabhängige Daten auch für andere Standorte einsehbar, wobei die Verteilung dezentral durchgeführt wird. Das zentrale Sichten dieser Daten ist mit der Vorreiterrolle in der Produktion begründet, die manche Standorte einnehmen und somit zukünftig für andere Standorte relevant werden. Schwachstelle Es ist nicht geklärt, ob Änderungen an standortspezifischen Leisten am Master ZF oder am lokalen Zielsystem durchzuführen sind. Zusammenführung der vorhandenen Systeme in ein Mastersystem. Da die geplante Schnittstelle zwischen den FATool Zielsystemen und den Master Servern bidirektional sein wird, soll diese genutzt werden, um die Daten von den Zielsystemen auf den jeweiligen Master Server zu replizieren. Die Urladung des Master Systems kommt also von den Zielsystemen selbst. Schwachstelle Beim derartigen Zusammenführen von Daten kann es zu Konflikten kommen, die durch gemeinsam genutzte Datensätze mit unterschiedlichen Merkmalswerten zwischen den verschiedenen Standorten entstehen. Hier sind geeignete Maßnahmen zur Konfliktlösung zu entwickeln. Neue Funktionalitäten Viewing der zentralen Daten auf dem FATool Master ZF muss möglich sein. Das Sichten der zentralen Daten wird durch einen Terminal Server ermöglicht. Das zentrale FATool ist somit eine einmalig, zentral installierte Anwendung, die über leistungsfähige WAN Leitungen von mehreren lokalen Benutzern verwendet wird. Der Terminal Server bietet dabei nur Zugriff auf die Applikation selbst, sodass ein Benutzer eingeschränkte Rechte auf dem jeweiligen Server besitzt. Das zentrale FATool ist eine eigene Applikation und läuft unabhängig vom lokalen FATool. Anwender können so parallel im lokalen und im zentralen System suchen. 82

83 5.1. Bestehendes Soll Konzept Datenabgleich Automatischer Abgleich zwischen den FATool Master und FATool Zielsystemen. Abgleich zwischen FATool Master ZF und FATool Master ZFLS. Komplettwerkzeuge mit allen Schneiden müssen in die FATool Zielsysteme übertragen werden. Der Abgleich von Daten zwischen dem Master ZF und den lokalen Zielsystemen muss in beide Richtungen automatisch funktionieren. Der Grund für die Bidirektionalität liegt in den Zusatzinformationen, die nur von FATool gespeichert werden, nicht jedoch von Axalant und somit direkt zwischen dem lokalen und dem zentralen Server ausgetauscht werden. Die Zusatzinformationen und das Klassenmapping sowie gemeinsam genutzte Datensätze machen einen Abgleich zwischen dem Master ZF und dem Master ZFLS erforderlich. Komplettwerkzeuge mit mehreren Schneiden können somit in jedes beliebige Zielsystem übertragen werden, ohne dass Daten zwischen den Systemen verloren gehen. Im FATool Zielsystem muss es möglich sein, vom FATool Master einen bestehenden Datensatz zu kopieren. Diese Funktion wird immer dann benötigt, wenn es sich um Datensätze mit zusätzlichen Informationen handelt. Wird ein passendes Fertigungshilfsmittel im zentralen System gefunden, so wird es durch das Eintragen des eigenen SAP Standorts in Axalant an das eigene FATool Zielsystem übermittelt. Dabei bleiben die Informationen, die von Axalant nicht gespeichert werden können, auf der Strecke. Um diese Informationen dennoch zur Verfügung zu stellen, muss es eine Funktion geben, die es erlaubt komplette Datensätze aus dem Mastersystem zu kopieren. Abbildung 5.3.: Übertragen zusätzlicher Informationen zwischen den zentralen Systemen 83

84 5. Soll Konzept Szenario In Abbildung 5.3 ist dieses Szenario dargestellt, das mit dem Viewing der zentralen Master Daten beginnt. Ist ein passendes Betriebsmittel gefunden, so wird in Axalant entweder der entsprechende SAP Standort eingetragen oder, falls Änderungen am Material notwendig sind, der komplette Datensatz kopiert. Im nächsten Schritt wird dieser Datensatz durch die AXA2FASys Schnittstelle in das lokale Zielsystem übertragen. In beiden Fällen fehlen jedoch die Zusatzinformationen aus FATool. Hierzu soll es nun eine Funktion geben, um die zusätzlichen Informationen für einen Datensatz von Master ZF abrufen und replizieren zu können. Produktverlagerungen Es muss möglich sein ein NC Programm samt Quellsourcen von einem FATool Zielsystem über den FATool Master auf ein anderes FATool Zielsystem zu replizieren. Da in Axalant keine NC Programme verwaltet werden, greift hier das Verteilungskonzept über die SAP Standorte nicht. Obwohl die NC Daten grundsätzlich standortabhängig sind, muss die Verlagerung von produktionsrelevanten Daten möglich sein. Wenn ein Standort nicht genügend Kapazitäten zur Produktion hat, so können andere Standorte mit freien Kapazitäten einen Teil der Produktion übernehmen. Voraussetzung für ein erfolgreiches Verlagern der Produktion sind natürlich kompatible Maschinen in der Fertigung. Deshalb braucht man Funktionen, die das Replizieren von NC Programmen zwischen den Zielsystemen ermöglichen. 84

85 5.1. Bestehendes Soll Konzept Schwachstellen Im Folgenden werden die Schwachstellen, die im Lastenheft identifiziert werden konnten, herausgestellt und genauer erklärt Selbstkontrolle ZF Lenksysteme übernimmt die Verteilung der für sie bestimmten Daten selbst. Hierfür verwalten sie ihren eigenen Dispatcher, der aus der Auftragstabelle in Axalant alle Einträge mit dem Standortflag GP1 selektiert und die Daten an das bisher einzige Zielsystem an Master ZFLS weiterleitet. ZFLS besitzt eine eigene Schnittstelle nach Axalant, da es als Joint-Venture flexibel bleiben und auch bei einer möglichen Abspaltung weiterhin funktionieren muss. Doch die Schnittstelle wird auch selbst von ZFLS verwaltet und kann somit manipuliert werden. Durch das Hinzufügen oder Abändern von Standorteinträgen in den PL/SQL Funktionen können auch Datensätze, die für andere Standorte bestimmt sind, abgegriffen werden. Es bekommt das System den Vorzug, das die Auftragstabelle schneller abarbeitet. Im anderen System fehlt dieser Datensatz, da ein quittierter Eintrag als abgearbeitet gilt. In Abbildung 5.4 ist eine manipulierte Schnittstelle dargestellt, die eine fehlerhafte Verteilung der Daten erlaubt. Abbildung 5.4.: Fehlerhafte Verteilung durch manipulierte Schnittstelle Die Schnittstelle wurde dahingehend abgeändert, dass zwischen Axalant und Master ZFLS fälschlicherweise Daten synchronisiert werden, die für Master ZF bestimmt wären. Angenommen Master ZFLS arbeitet die Auftragstabelle zum Datenexport schneller ab als Master ZF, dann würde ein Datensatz, der eigentlich für Passau bestimmt wäre, nach Schwäbisch Gmünd transferiert werden. Gleichzeitig würde dieser Datensatz im Passauer System fehlen, was dieses Vorgehen sicherlich schnell aufdecken würde. 85

86 5. Soll Konzept Szenario Berechtigungskonzept Die Änderungshoheit als einziges Berechtigungskonzept nach FATool zu portieren, um die Sichtbarkeit von Stammdatensätzen zu regulieren, kann in manchen Situationen nicht ausreichend sein. Da es weiterhin vertrauliche Daten gibt, die nicht nur zwischen ZF und ZFLS zu verbergen sind, sondern auch zwischen bestimmten Standorten innerhalb ZFGRP, müssen explizit die Änderungshoheiten der betroffenen Stammdatensätze gesperrt werden. Das Filtern der gesperrten Änderungshoheiten wird durch die AXA2FAsys Schnittstelle übernommen. Dies hat allerdings den Nachteil, dass diese Daten auch für den berechtigten Standort nicht mehr verfügbar sind, da sie bereits in der Schnittstelle verworfen werden. Des Weiteren zieht dieses Vorgehen einen enormen organisatorischen Aufwand nach sich, der vor allem bei zukünftigen Änderungen ständig aktuell gehalten werden muss. Doch Änderungen in Axalant sind schwer feststellbar, sodass an dieser Stelle Inkonsistenzen vorprogrammiert sind. Ein anderer Ansatz ist, dass bereits die Schnittstelle die virtuellen Standorte auswertet, die in Axalant verwendet werden, um die Sichtbarkeit auf bestimmte Standorte einzugrenzen. Hat ein Datensatz nur Passau als virtuellen Standort eingetragen, so sind diese Daten für andere Standorte gar nicht erst existent. In der Schnittstelle zwischen Axalant und Master ZF wird nun überprüft, ob der zu übertragende Datensatz als Standort ZFGRP besitzt und somit für alle klassischen Standorte sichtbar sein darf. Datensätze ungleich ZFGRP werden durch die Schnittstelle ausgefiltert. Entsprechend werden für ZFLS Datensätze verworfen, die als Standorte ungleich ZFLS sind. Da es für ZFLS nur ein FATool Zielsystem gibt, sind die fehlenden Datensätze nicht so umfangreich wie es bei ZFGRP der Fall sein wird. In Abbildung 5.5 ist die Filterung bezüglich der virtuellen Standorte durch die Schnittstelle dargestellt. Der Datensatz mit dem Standorteintrag Passau wird somit von der Schnittstelle verworfen und ist keinem Standort zugänglich, selbst der befugte hat keinen Zugriff. Obwohl der organisatorische Aufwand somit eingegrenzt wird, bleibt das Problem, dass auch befugte Standorte auf ihre geheimen Daten keinen Zugriff haben, bestehen. Das direkte Filtern spricht für die Sicherheit der Daten, grenzt allerdings die Verfügbarkeit dieser stark ein, sodass auch dieses Konzept keine ideale Lösung bietet. Abbildung 5.5.: Filterung durch Schnittstelle Ein weiteres Problem der Änderungshoheit ist seine Position im Berechtigungsmodell von Axalant. Die virtuellen Standorte, die speziell die Sichtbarkeit der Daten in Axalant 86

87 5.1. Bestehendes Soll Konzept regeln, sind der Änderungshoheit übergeordnet. Angenommen ein Anwender besitzt viele verschiedene Änderungshoheiten und das Konzept der virtuellen Standorte wird von der Schnittstelle nicht berücksichtigt, dann wäre es möglich, dass dieser Benutzer mit Stammdaten arbeiten kann, obwohl sie für seinen Standort gar nicht sichtbar wären. Im Umkehrschluss könnten Benutzer mit wenigen Änderungshoheiten auch entsprechend weniger Daten einsehen, was die Produktivität des Systems stark einschränkt. Somit ist es unumgänglich, dass die Schnittstelle die virtuellen Standorte unterstützt und zur Verfügung stellt. Die Verwendung der virtuellen Standorte in FATool wird daher als empfehlenswert angesehen Standortspezifische Änderungen Durch das Lastenheft wird nicht geklärt an welcher Stelle standortspezifische Änderungen durchzuführen sind. Im Allgemeinen sind zwei verschiedene Szenarien denkbar, wobei die Änderungen entweder am zentralen Master Server Master ZF bzw. Master ZFLS durchgeführt werden und die Änderungen an das Zielsystem repliziert werden, oder alternativ die Änderungen direkt am Zielsystem durchgeführt werden und anschließend mit dem Master Server abgeglichen werden. Abbildung 5.6.: Mögliche standortspezifische Anpassungen In Abbildung 5.6 sind die verschiedenen Möglichkeiten aufgezeigt, wobei Änderungen am lokalen Server durch blaue Kanten und Änderungen am zentralen Server durch rote Kanten dargestellt werden. Im Falle von ZFLS ist ein weiteres Szenario denkbar, das als grüne Kante dargestellt wird und Änderungen am Master ZF vorsieht. Diese werden synchronisiert bis sie schließlich ebenfalls im Zielsystem vorhanden sind. Durch das Lastenheft wird jedoch nicht geklärt, ob standortspezifische Leisten zwischen den Master Servern repliziert werden und an welchen Stellen Änderungen vorgesehen werden, was dieses Vorgehen ebenfalls relevant macht. 87

88 5. Soll Konzept Szenario Datenmigration Die Master Server sollen durch die mit ihnen verbundenen Zielsysteme in einen Initialzustand gebracht werden, um die Anforderung zu erfüllen, dass sie die Daten aller angebundenen Systeme enthalten. Hierfür wird die bidirektionale Schnittstelle verwendet, die es erlaubt Daten vom Zielsystem auf den zentralen Master zu replizieren. Verwenden jedoch mehrere Standorte die gleichen Stammdaten kann es zu Konflikten kommen. Diese treten immer dann auf, wenn gleiche Datensätze verschiedene Merkmalswerte aufweisen, was bisher in FATool möglich war. Durch diese Änderungen müssen Szenarien zur Konfliktlösung entwickelt werden. Abbildung 5.7.: Konflikt bei der Datenmigration Wie in Abbildung 5.7 verdeutlicht, können die verschiedenen Standorte innerhalb eines Materialstamms und desselben Merkmals verschiedene Werte aufweisen. Da der Master ZF nur einen, für alle Standorte übergreifenden Datensatz speichern wird, muss er entscheiden welcher Merkmalswert übernommen wird. Bei Master ZFLS tritt dieses Problem nicht auf, da bisher nur ein Zielsystem verknüpft ist und somit keine Konflikte entstehen können. Bei dieser Art der Datenmigration werden zwar die Mehrinformationen aus FATool berücksichtigt, wichtige Informationen aus Axalant zur Umsetzung des Berechtigungskonzepts fehlen jedoch. So muss ein Konzept zur Datenmigration entwickelt werden, das beide Systeme unterstützt und die gewünschten Informationen im Master Server bereitstellt Klassenmapping durch ZFLS Auch für ZF Lenksysteme muss die Möglichkeit bestehen Änderungen an Klassenmappings durchzuführen oder bei Bedarf neue anzulegen. Da alle Mappings und Klassendefinitionen ausschließlich auf Master ZF gepflegt werden, muss Anwendern von ZFLS Zugriff auf den administrativen Bereich von Master ZF gewährt werden. Da im Moment noch keine User Rollen innerhalb von FATool entwickelt wurden, ist es schwierig abzuschätzen welche Auswirkungen und Risiken ein administrativer Eingriff in den Master ZF seitens ZFLS birgt. Generell gilt jedoch, dass ein direkter Zugriff auf die zentrale Applikation ein Sicherheitsrisiko darstellt, da somit auch alle ZF Standorte aus ZFGRP in ihren Konfigurationen geändert werden können. 88

89 5.1. Bestehendes Soll Konzept Bewertung Im Folgenden wird validiert, ob die Anforderungen und Schwachstellen des Ist Zustands mit dem bestehenden Soll Konzept gelöst werden können. In Tabelle 5.1 sind erneut alle Schwachstellen aus dem Ist Zustand nach ihrer Priorität sortiert und es wird angegeben, ob diese durch die Anforderungen im Lastenheft gelöst werden konnten. ID Name Priorität Gelöst 1 Eingeschränkte Suche 1 2 Transferdaten 1 3 Aktualisierungen 1 4 Inkonsistenz zwischen Dokumenten 2 5 Inkonsistenzen zwischen Sachmerkmalen 2 6 Klassenmapping 2 7 Dokumentabgleich 2 8 Datenleichen 2 9 Betriebsmittelstatus 3 10 Änderungswesen 3 11 Dokumentverwaltung 3 Tabelle 5.1.: Schwachstellen des Ist Zustands Die Forderung, dass durch das neue Konzept alle Anforderungen mit Priorität 1 gelöst werden müssen, sind nicht vollständig erfüllt. Immerhin kann bei zwei von den drei wichtigsten Punkten Abhilfe attestiert werden, wobei die Anforderungen mit niedrigeren Prioritäten auf der Strecke bleiben. Die standortübergreifende Suche und die Reduzierung des Verwaltungsaufwands wird durch das bestehende Konzept optimal gelöst. Zur Situation der schlechten Verbindung bei Massenupdates wird hingegen nicht eingegangen, sodass dieser Punkt im erweiterten Lastenheft aufgegriffen werden muss. Anforderung der Priorität 2 werden vom Lastenheft gänzlich ausgelassen und können durch teilweise einfache Änderungen in der Infrastruktur der Systeme oder den Prozessen zwischen den Systemen gelöst werden. Lösungsvorschläge für die Punkte dieser Kategorie sind im erweiterten Lastenheft zu finden. Bei den Punkten mit Priorität 3 handelt es sich im Allgemeinen um nicht funktionale Anforderungen, die vor allem das Usability betreffen und im positiven Sinne zur Software Ergonomie beitragen können. Im erweiterten Lastenheft werden diese Punkte jedoch nicht aufgegriffen, da nur Entwürfe für funktionale Anforderungen im Rahmen dieser Arbeit von Interesse sind. Während einige dieser Punkte durch das bestehende Lastenheft einfach nicht erfüllt werden, sind andere Punkte gar nicht berücksichtigt, die aber für ein zentrales Konzept absolut notwendig sind. Im erweiterten Lastenheft wird deshalb zwischen fehlenden Anforderungen, Schwachstellen aus dem Ist Zustand und Schwachstellen aus dem Soll Konzept unterschieden. 89

90 5. Soll Konzept Szenario 5.2. Erweitertes Soll Konzept Das erweiterte Soll Konzept nimmt das vorhandene Soll Konzept als Grundlage und ergänzt es um wichtige Anforderungen, die bisher nicht berücksichtigt wurden aber als essentiell angesehen werden. Außerdem werden erneut die Schwachstellen aus dem Ist Zustand aufgegriffen und Lösungskonzepte angeboten. Durch das bestehende Soll Konzept hervorgebrachte Schwachstellen werden ebenfalls berücksichtigt und mögliche Lösungen aufgezeigt Erweiterungen im Lastenheft Im Folgenden werden Erweiterungen vorgestellt, die bisher vom Lastenheft nicht berücksichtigt wurden Datenreplikation Die Replikation der Daten zwischen den Master Servern und den einzelnen Standorten wurde bisher durch das Lastenheft nicht genau spezifiziert und es sind mehrere Konzepte denkbar. Wenn von Daten die Rede ist, dann sind in diesem Zusammenhang die Dokumente gemeint und die zugehörigen Meta Daten, die eine Beschreibung zu den Dateien liefern. Die Dokumente können unter Umständen - vor allem aber im CAD Bereich sehr groß werden, sodass ein Transfer auf Abruf sehr zeitintensiv ist. Das erste Konzept in Abbildung 5.8 sieht ein Replizieren der Meta Daten als auch der Dokumente auf die lokalen Systeme vor. Abbildung 5.8.: Replizieren von Meta Daten und Dokumenten Jedem Standort stehen die Meta Daten und Dokumente als lokale Arbeitskopie zur Verfügung, sodass Änderungen zunächst immer am dezentralen System durchgeführt werden und anschließend durch die bidirektionale Schnittstelle zwischen dem Master System und 90

91 5.2. Erweitertes Soll Konzept dem lokalen Zielsystem ein Abgleich stattfindet. Diese Methode hat den Nachteil, dass trotz eines Master Systems jeder Standort auf seinen eigenen Daten arbeitet, die später am Master Server gemerged werden müssen. Dabei können aber auch Probleme auftreten wie man sie aus verteilten Systemen kennt, denn durch die lokalen Daten können dieselben Dokumente an unterschiedlichen Standorten gleichzeitig geändert werden. Beim anschließenden Einchecken muss der Master Server entscheiden welcher Datensatz schließlich der gültige ist. Im zweiten möglichen Konzept werden nur die Dokumente mit dem lokalen Zielsystem repliziert, die Meta Daten werden weiterhin zentral verwaltet, wie es in Abbildung 5.9 dargestellt ist. Abbildung 5.9.: Replizieren ausschließlich von Dokumenten Durch die enorme Dateigröße müssen die Dokumente immer lokal am jeweiligen Standort zur Verfügung stehen, sodass diese nicht erst bei Bedarf geladen werden und somit die Produktion verzögern. Da es sich bei den Meta Daten um eine geringe Dateigröße handelt, können diese durchaus online zur Verfügung gestellt werden. Jeder Standort greift somit auf den immer gleichen Datenbestand zu, der somit auch leichter verwaltet werden kann. Konflikte können durch dieses Konzept keine auftreten, da Datensätze, die von einem Standort momentan bearbeitet werden, für andere Standorte gesperrt werden können. Obwohl das Problem der verteilten Daten somit gelöst wäre, entsteht durch dieses Konzept ein neues Problem. Die Verfügbarkeit der Meta Daten ist abhängig von der Leitungsgüte, wobei im schlimmsten Fall die Leitung komplett ausfallen kann und die Meta Daten somit nicht mehr zur Verfügung stehen. Dies würde ebenfalls einen Ausfall in der Produktion bedeuten, was unbedingt zu verhindern ist. Möchte man die positiven Eigenschaften aus den zwei bisherigen Konzepten vereinen, ohne die negativen Seiteneffekte zu behalten, so ergibt sich ein drittes Konzept. Sowohl die Dokumente als auch die Meta Daten werden an die lokalen Zielsysteme repliziert. Änderungen an Meta Daten finden dennoch nur zentral statt, wie es in Abbildung 5.10 dargestellt ist. Alle Daten und Dokumente stehen lokal zur Verfügung und werden auch von den lo- 91

92 5. Soll Konzept Szenario Abbildung 5.10.: Replikation von Meta Daten und Dokumenten aber nur zentrale Änderung der Meta Daten kalen Systemen gezogen, illustriert durch die rote Kante. Die Daten stehen immer zur Verfügung, auch wenn die Verbindung unterbrochen werden sollte. Änderungen an Meta Daten können nur am zentralen System durchgeführt werden, sodass die entsprechenden Datensätze für andere Standorte während der Bearbeitung gesperrt werden, was durch die grüne Kante illustriert wird. Dieses Konzept ist robust gegen Ausfälle und sicher bei Änderungen an Daten, allerdings sind Änderungen nicht sofort am Standort verfügbar, denn die Übertragung durch die Schnittstelle kann Zeit in Anspruch nehmen. Änderungen an den CAD Dokumenten selbst müssen lokal gespeichert werden, da die Dateien für eine direkte Übertragung zu groß sind und zeitversetzt mittels Streamingprotokollen an die zentralen Master Server kopiert werden Synchronisation Unabhängig vom verwendeten Konzept bei der Replikation der Daten, stellt sich die Frage nach dem Zeitpunkt der Synchronisation von geänderten Meta Daten und Dokumenten. Wie bereits beschrieben ist der Größenunterschied zwischen Dokumenten und den zugehörigen Meta Daten enorm, sodass sich auch hier mehrere Konzepte ergeben. Im synchronen Ansatz werden die Dateien und die Meta Daten gleichzeitig mit dem zentralen Server abgeglichen, wie es in Abbildung 5.11 dargestellt ist. Natürlich sind die Meta Daten um ein vielfaches schneller zentral verfügbar als die Dokumente, sodass sich zeitbedingte Inkonsistenzen zwischen Dokument und zugehörigen Daten ergeben können. Das einem Stammsatz zugeordnete Dokumente ist in diesem Fall nicht aktuell, was potentiell gefährlich ist, da der Benutzer nicht auf diesen Umstand aufmerksam gemacht wird. Oft werden jedoch ausschließlich die veränderten Meta Daten zur weiteren Verarbeitung benötigt, die sofort nach dem Einchecken zur Verfügung stehen und den Prozess beschleunigen. 92

93 5.2. Erweitertes Soll Konzept Abbildung 5.11.: Synchroner Abgleich mit Inkonsistenzen Die sicherere Variante stellt der asynchrone Ansatz dar, der zunächst das veränderte Dokument mit dem Master abgleicht und erst nach erfolgreichem Hochladen die Meta Daten synchronisiert, wie es in Abbildung 5.12 dargestellt ist. Abbildung 5.12.: Asynchroner Abgleich mit Wartezeiten Da die Dokumente die meiste Zeit für den Abgleich in Anspruch nehmen, werden sie als erstes synchronisiert und erst dann die Meta Daten, die in wenigen Sekunden abgeglichen sind. Somit sind die verknüpften Dokumente zu den Meta Daten immer aktuell und konsistent verfügbar. Unter Umständen entstehen durch das primäre Abhandeln der Dokumente lange Wartezeiten, die den Prozess verlangsamen können, wenn nur die Meta Daten als weitere Basis gebraucht werden. 93

Einbindung elektronischer Kataloge in eine weltweite Nutzung

Einbindung elektronischer Kataloge in eine weltweite Nutzung Einbindung elektronischer Kataloge in eine weltweite Nutzung Dr. Ing. Peter Robl, Salhi Christian IPPS, Standort Passau ZF Friedrichshafen AG 1 23.01.2015 IPPS, Standort Passau, Einbindung elektronischer

Mehr

Forschungsvorhaben Integration der NC-Planung in das Product Lifecycle Management

Forschungsvorhaben Integration der NC-Planung in das Product Lifecycle Management 1 Forschungsvorhaben Integration der NC-Planung in das Product Lifecycle Management Im Rahmen des durchgeführten Forschungsvorhabens wurden die Einbindungsmöglichkeiten der NC- Planung in das Product Lifecycle

Mehr

Elektronische Kataloge von Kaufteilen und Werkzeugen

Elektronische Kataloge von Kaufteilen und Werkzeugen Elektronische Kataloge von Kaufteilen und Werkzeugen (Integration in eine bestehende Systemwelt) Peter Robl ZF Passau GmbH 1 Die ZF Passau GmbH (eine Tochter der ZF Friedrichshafen AG) Gründung: Werk I:

Mehr

Produktentwicklung im internationalen Firmenverbund

Produktentwicklung im internationalen Firmenverbund Herzlich Willkommen Produktentwicklung im internationalen Firmenverbund Von CAD über PDM zu ERP ISAP Kundentag 2011 Revuepalast Herten Lars Kalveram Bereichsleiter PLM-Consulting Überblick - Begriffsbestimmung

Mehr

DDM9000 : Kurz und bündig

DDM9000 : Kurz und bündig LTE Consulting GmbH Ihr Partner für InformationsLogistik DDM9000 : Kurz und bündig Kennen Sie das? Langes Suchen nach Unterlagen, aktuellen Dokumenten und anderen Informationen Wo sind wichtige, aktuelle

Mehr

Produktionswirtschaft (Teil B) IV. Produktionsplanung mit IKS

Produktionswirtschaft (Teil B) IV. Produktionsplanung mit IKS Produktionswirtschaft (Teil B) IV. IV IV.1 IV.2 IV.2.1 IV.2.2 IV.2.3 Fertigungsautomatisierung Gestaltungskonzeptionen Produktionsplanungssystem (PPS) Computer Integrated Manufacturing (CIM) Product Lifecycle

Mehr

Konzepte und Methoden des Supply Chain Management

Konzepte und Methoden des Supply Chain Management Konzepte und Methoden des Supply Chain Management Kapitel 6 IT-Systeme für das Supply Chain Management Modul Produktionslogistik W 2332-02 SS 2014 Grundvoraussetzungen für eine erfolgreiche Planung und

Mehr

Konzepte und Methoden des Supply Chain Management. Kapitel 6 IT-Systeme für das Supply Chain Management Modul Produktionslogistik W 2332-02 SS 2015

Konzepte und Methoden des Supply Chain Management. Kapitel 6 IT-Systeme für das Supply Chain Management Modul Produktionslogistik W 2332-02 SS 2015 Konzepte und Methoden des Supply Chain Management Kapitel 6 IT-Systeme für das Supply Chain Management Modul Produktionslogistik W 2332-02 SS 2015 Grundvoraussetzungen für eine erfolgreiche Planung und

Mehr

Betriebliche Software: Produktdaten-Management

Betriebliche Software: Produktdaten-Management Betriebliche Software: Produktdaten-Management Betriebliche Software: Produktdaten-Management Aufgrund einer großen Anzahl an neuen gesetzlichen Forderungen, die auf die Qualität, Sicherheit oder Umweltverträglichkeit

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Varianten- und Teilereduktion im Maschinenbau

Varianten- und Teilereduktion im Maschinenbau Varianten- und Teilereduktion im Maschinenbau - Aufbau eines Klassifikationssystems bei der Harburg-Freudenberger Maschinenbau GmbH Bielefeld, 17.10.2006 IGS Ingenieurgesellschaft Prof. Stannek Dipl.-Ing.

Mehr

Präsentation Start+ Die Software für Ihre Projektorganisation und Dokumentenverwaltung

Präsentation Start+ Die Software für Ihre Projektorganisation und Dokumentenverwaltung Präsentation Inhalt: Präsentation Start+ Die Software für Ihre Projektorganisation und Dokumentenverwaltung Anschrift: Büro Josef Feuerstein Wendershausen Hauptstrasse 6 36142 Tann/Rhön Tel.: 06682-9706-0

Mehr

1 Daten und Fakten des ZF-Konzerns, Kurzprofil - 2014, Öffentlich. ZF Friedrichshafen AG, 2015

1 Daten und Fakten des ZF-Konzerns, Kurzprofil - 2014, Öffentlich. ZF Friedrichshafen AG, 2015 Daten und Fakten des ZF-Konzerns, Kurzprofil - 2014 ZF Friedrichshafen AG 1 Daten und Fakten des ZF-Konzerns, Kurzprofil - 2014, Öffentlich Vorstand Dr. Stefan Sommer Vorsitzender des Vorstands Dr. Konstantin

Mehr

Konzeption eines Master-Data-Management-Systems. Sven Schilling

Konzeption eines Master-Data-Management-Systems. Sven Schilling Konzeption eines Master-Data-Management-Systems Sven Schilling Gliederung Teil I Vorstellung des Unternehmens Thema der Diplomarbeit Teil II Master Data Management Seite 2 Teil I Das Unternehmen Vorstellung

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Product Lifecycle Management

Product Lifecycle Management Product Präsentation der Funktionen von PLM-Systemen Stud.-Ing. Ansprechpartner: Dr. -Ing. Harald Prior Fachhochschule Dortmund Sommersemester 2013 Inhaltsverzeichnis Seite 1 Seite 2 Seite 3 Seite 4 Seite

Mehr

Standardisierung im Kontext von PLM- und ERP-Prozessen

Standardisierung im Kontext von PLM- und ERP-Prozessen Standardisierung im Kontext von PLM- und ERP-Prozessen Möglichkeiten und Erfahrungen Udo Buschbeck Direktor PLM Beratung udo.buschbeck@tesis.de TESIS PLMware GmbH Baierbrunner Str. 15 D-81379 München Tel:

Mehr

WENDIA ITSM EXPERT TALK

WENDIA ITSM EXPERT TALK WENDIA ITSM EXPERT TALK WENDIA ITSM WHITEPAPER IT SERVICE MANAGEMENT BASISWISSEN: IN EINFACHEN SCHRITTEN ZUR CMDB Wer, Wie, Was: Die CMDB als Herzstück eines funktionierenden IT Service Management Die

Mehr

NumericNotes NC-Editor CAD-Modul CAM-Modul. GNT.NET NumericNotes. NC-Editor für alle Bearbeitungsarten

NumericNotes NC-Editor CAD-Modul CAM-Modul. GNT.NET NumericNotes. NC-Editor für alle Bearbeitungsarten GNT.NET NumericNotes für alle Bearbeitungsarten für alle Bearbeitungsarten NC-Strichsimulation NC-Programmvergleicher NC-Makroprogrammierung _ NC-Code ohne Postprozessor erzeugen _ Bestehenden NC-Programme

Mehr

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftsingenieur der Fakultät

Mehr

Matthias Schmich Siemens Industry Software Kaiserslautern, 7. Oktober 2015. Trends und Entwicklungsperspektiven der Digitalisierung

Matthias Schmich Siemens Industry Software Kaiserslautern, 7. Oktober 2015. Trends und Entwicklungsperspektiven der Digitalisierung Matthias Schmich Siemens Industry Software Kaiserslautern, 7. Oktober 2015 Trends und Entwicklungsperspektiven der Digitalisierung Realize innovation. Eine kleine Zeitreise 1 9 7 3 1 9 8 5 2 0 1 5 Im Jahre

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Product Lifecycle Management Studie 2013

Product Lifecycle Management Studie 2013 Product Lifecycle Studie 2013 PLM Excellence durch die Integration der Produktentwicklung mit der gesamten Wertschöpfungskette Dr. Christoph Kilger, Dr. Adrian Reisch, René Indefrey J&M Consulting AG Copyright

Mehr

VDMA Leitfaden Produktlebenszyklusmanagement. Vorwort... 4. 1 Einleitung... 5. 2 Begriffsdefinitionen... 6. 3 Phasen des Produktlebenszyklus...

VDMA Leitfaden Produktlebenszyklusmanagement. Vorwort... 4. 1 Einleitung... 5. 2 Begriffsdefinitionen... 6. 3 Phasen des Produktlebenszyklus... 3 Inhalt Vorwort... 4 1 Einleitung... 5 2 Begriffsdefinitionen... 6 3 Phasen des Produktlebenszyklus... 6 4 Prozesse, Methoden, Werkzeuge (PMW)... 8 4.1 PMW-Definition...8 4.2 PMW-Beschreibung...9 4.3

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

PPS Software CoX System

PPS Software CoX System PPS Software CoX System Rückgrat unseres Verwaltungs- und Produktionsablaufs ist unsere PPS Software CoX System. Das von Mair Elektronik selbst entwickelte und auf spezifischen Anforderungen ausgerichtete

Mehr

Handbuch zu AS Connect für Outlook

Handbuch zu AS Connect für Outlook Handbuch zu AS Connect für Outlook AS Connect für Outlook ist die schnelle, einfache Kommunikation zwischen Microsoft Outlook und der AS Datenbank LEISTUNG am BAU. AS Connect für Outlook Stand: 02.04.2013

Mehr

Einführung eines Redaktionssystems für die Technische Dokumentation

Einführung eines Redaktionssystems für die Technische Dokumentation Einführung eines Redaktionssystems für die Technische Dokumentation Leitfaden mit Entscheidungsmatrix Informatik Vorwort Situation Ziel Zielgruppe Auswahl Die Technische Produktdokumentation ist mehr als

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM ist leistungsstark, wirtschaftlich und nutzt konsequent genormte

Mehr

End-to-End System- und Prozesseffizienz mit Teamcenter UA

End-to-End System- und Prozesseffizienz mit Teamcenter UA End-to-End System- und Prozesseffizienz mit Teamcenter UA Vortrag Symposium für Produktentwicklung & Product Lifecycle Management Dr. Christian Mundo - Siemens AG Thomas Pyschny - Dolff, Pyschny & Piper

Mehr

pro.s.app personnel file Transparente Personal- prozesse mit SAP

pro.s.app personnel file Transparente Personal- prozesse mit SAP pro.s.app personnel file Transparente Personal- prozesse mit SAP 1 Gerade vertrauliche Personaldokumente müssen besonders sicher und rechtlich einwandfrei aufbewahrt werden die Lösung pro.s.app personnel

Mehr

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy White Paper IVY Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy Business Process Management (BPM) unterstützt den gesamten Lebenszyklus von Geschäftsprozessen. BPM-Lösungen liefern Technologie

Mehr

codia Schriftgutverwaltung / Aktenplan

codia Schriftgutverwaltung / Aktenplan codia Schriftgutverwaltung / Aktenplan codia Software GmbH Auf der Herrschwiese 15a 49716 Meppen Telefon: 0 59 31/93 98 0 Telefax: 0 59 31/93 98 25 E-Mail: info@codia.de Internet: www.codia.de [1] 1 codia

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

IYOPRO PLM Components

IYOPRO PLM Components IYOPRO PLM Components Prozessorientierte Wertschöpfung 3. BPM Symposium, 11. Dezember 2014 intellivate GmbH Die Herausforderung Die Anforderungen des globalen Marktes sind Schneller! Besser! Billiger!

Mehr

PLM Workshop «Änderungswesen» Prof. Dagmar Heinrich Professorin PLM / CAx, Institutspartnerin IPEK Rapperswil, April 2012

PLM Workshop «Änderungswesen» Prof. Dagmar Heinrich Professorin PLM / CAx, Institutspartnerin IPEK Rapperswil, April 2012 PLM Workshop «Änderungswesen» Prof. Dagmar Heinrich Professorin PLM / CAx, Institutspartnerin IPEK Rapperswil, April 2012 Ablauf Workshop Begrüssung Vorstellung der Teilnehmer und Aufnahme der Erwartungen

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

SEAL Systems Integrationen für SAP PLM 7 und Web UI Anwendungen

SEAL Systems Integrationen für SAP PLM 7 und Web UI Anwendungen SEAL Systems Integrationen für SAP PLM 7 und Web UI Anwendungen Mit SAP PLM 7 und anderen Web UI Anwendungen hat SAP neue Oberflächen für bestehende und neue Funktionalität geschaffen. Diese Anwendungen

Mehr

Product Lifecycle Management: Lieferantenintegration in den Änderungsmanagement-Prozess

Product Lifecycle Management: Lieferantenintegration in den Änderungsmanagement-Prozess Arbeitskreis Softwaretechnologie Konstanz, 12.11.2010 Hans-Joachim Matheus Product Lifecycle Management: Lieferantenintegration in den Änderungsmanagement-Prozess... integrieren... visualisieren... optimieren...

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

Durchgängig IT-gestützt

Durchgängig IT-gestützt Beschaffung aktuell vom 03.09.2012 Seite: 026 Auflage: 18.100 (gedruckt) 10.253 (verkauft) 18.032 (verbreitet) Gattung: Zeitschrift Supplier Lifecycle Management Durchgängig IT-gestützt Obwohl die Identifizierung,

Mehr

Bei Bystronic glass: Hoher Automatisierungsgrad durch die Integration von PLM in CAD und ERP. Anwenderbericht

Bei Bystronic glass: Hoher Automatisierungsgrad durch die Integration von PLM in CAD und ERP. Anwenderbericht Anwenderbericht Bei Bystronic glass: Hoher Automatisierungsgrad durch die Integration von PLM in CAD und ERP Neben ihren eigentlichen Kernaufgaben, der Konstruktion von Maschinen zur Bearbeitung von Architekturglas,

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Process Streamlining:

Process Streamlining: Process Streamlining: Geschäftsprozesse in globalen Business Software-Lösungen Dr. Frank Schönthaler Michael Mohl PROMATIS software GmbH Ettlingen/Baden Schlüsselworte Business Process Streamlining, Multinationaler

Mehr

Eigenschaften von Web Content Management Systemen (WCMS) Thorsten Kanzleiter Web Content Management Systeme

Eigenschaften von Web Content Management Systemen (WCMS) Thorsten Kanzleiter Web Content Management Systeme Eigenschaften von Web Content Management Systemen () 1 Gliederung 1.1 Motivation 1.2 Problemstellung 2. 2.1 Begriffsbestimmung CMS 2.2 Übergang von CMS zu 2.3 sonstige 2.4 Content Life Cycle 2.5 Webpublishing

Mehr

Windows SharePoint Services als gemeinsamen Dateispeicher einrichten

Windows SharePoint Services als gemeinsamen Dateispeicher einrichten Windows SharePoint Services als gemeinsamen Dateispeicher einrichten (Engl. Originaltitel: Setting up Windows SharePoint Services as a Collaborative File Store) Dustin Friesenhahn Veröffentlicht: August

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

EINFÜHRUNG. Durch Model Sharing. Model Sharing ist Bestandteil von Tekla Structures 21.0 Es ist keine zusätzliche Installation notwendig

EINFÜHRUNG. Durch Model Sharing. Model Sharing ist Bestandteil von Tekla Structures 21.0 Es ist keine zusätzliche Installation notwendig TEKLA MODEL SHARING EINFÜHRUNG Durch Model Sharing können mehrere Anwender gemeinsam an einem Modell arbeiten können die Anwender räumlich und zeitlich unabhängig von einander arbeiten ist keine permanente

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP Ralf Ackermann Daimler AG, ITM MBC Powertrain Agenda Ausgangslage EAM Tool-Landschaft bei Daimler planningit

Mehr

Dokumentenmanagement mit active.pdm

Dokumentenmanagement mit active.pdm Dokumentenmanagement mit active.pdm HITTEAM Solutions 22880 Wedel info@hitteam.de Document Management active.pdm für kleine und mittelständische Unternehmen. active.pdm ist eine Datei basierende Document

Mehr

Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte.

Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte. 4 Domänenkonzepte Ziele des Kapitels: Sie verstehen den Begriff Domäne. Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte. Sie verstehen die Besonderheiten der Vertrauensstellungen

Mehr

Workshop 3 Industrie 4.0 im Mittelstand: Vorteile der Digitalisierung in Finanzwesen, Produktion, Fertigungssimulation und Fabrikautomation

Workshop 3 Industrie 4.0 im Mittelstand: Vorteile der Digitalisierung in Finanzwesen, Produktion, Fertigungssimulation und Fabrikautomation Workshop 3 Industrie 4.0 im Mittelstand: Vorteile der Digitalisierung in Finanzwesen, Produktion, Fertigungssimulation und Fabrikautomation Björn Schuster, Business Development 11. September 2015 N+P Informationssysteme

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

ARIGON PLUS Readme. Wichtige Hinweise allgemein: Informationen zum Update Änderungsstand: 13.08.2015 Version: ARIGON PLUS 3.4

ARIGON PLUS Readme. Wichtige Hinweise allgemein: Informationen zum Update Änderungsstand: 13.08.2015 Version: ARIGON PLUS 3.4 ARIGON PLUS Readme Informationen zum Update Änderungsstand: 13.08.2015 Version: ARIGON PLUS 3.4 Wichtige Hinweise allgemein: VOMATEC bietet Ihnen mit diesem Update/Servicepack eine aktualisierte Version

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Workshop 2 Konstruktion an verteilten Standorten: Sicherer Datenaustausch und effiziente Zusammenarbeit

Workshop 2 Konstruktion an verteilten Standorten: Sicherer Datenaustausch und effiziente Zusammenarbeit Workshop 2 Konstruktion an verteilten Standorten: Sicherer Datenaustausch und effiziente Zusammenarbeit Oliver Triebe, IT Consultant - ITSM Uwe Lindner, Prokurist, Bereichsleiter CAD/CAM/PDM 11. September

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Enterprise Rights Management im ProSTEP ivip e.v.

Enterprise Rights Management im ProSTEP ivip e.v. Enterprise Rights Management im ProSTEP ivip e.v. Lennart Oly (ENX Association) Chairman der ERM User Group 2014, ProSTEP ivip e.v. 14-09-25-1 - Gliederung 1. Motivation 2. Informationsschutz, ERM 3. ERM

Mehr

sage HR Zusatzmodul Digitale Personalakte Produktinformationen

sage HR Zusatzmodul Digitale Personalakte Produktinformationen sage HR Zusatzmodul Digitale Personalakte Produktinformationen Vorwort Für Ihr Interesse am Zusatzmodul Digitale Personalakte bedanken wir uns. Integrierte Sage HR Lösungen basierend auf einer Datenbank

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

FILOU NC. Überblick. Copyright 2012 FILOU Software GmbH. Inhalt

FILOU NC. Überblick. Copyright 2012 FILOU Software GmbH. Inhalt FILOU NC Überblick Copyright 2012 FILOU Software GmbH Inhalt Die FILOUsophie... 2 Was will FILOU-NC können?... 2 Warum nur 2D?... 2 Zielgruppe... 2 Was muss der Anwender können?... 2 FILOU-NC, ein SixPack...

Mehr

pro.s.app personnel file Transparente Personalprozesse

pro.s.app personnel file Transparente Personalprozesse pro.s.app personnel file Transparente Personalprozesse mit SAP 1 Gerade vertrauliche Personaldokumente müssen besonders sicher und rechtlich einwandfrei aufbewahrt werden die Lösung pro.s.app personnel

Mehr

Integration von. ERP-Systemen und epages 6. mit Webservices

Integration von. ERP-Systemen und epages 6. mit Webservices Integration von ERP-Systemen und epages 6 mit Webservices - Stand 10/2011 - Einleitung... 2 Grundlagen... 2 Überblick Datenaustausch... 3 Ablauf... 4 Verbindungstest... 4 Testen mit Beispieldaten... 4

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Intelligente Systeme in der Praxis

Intelligente Systeme in der Praxis Ihr keytech Partner DMS für PLM und DMS Intelligente Systeme in der Praxis Systemübergreifende Workflows zur Steigerung der Effizienz Die meisten Dinge, die wir lernen, lernen wir von den Kunden. Charles

Mehr

VARONIS DATA GOVERNANCE SUITE

VARONIS DATA GOVERNANCE SUITE VARONIS DATA GOVERNANCE SUITE VARONIS DATA GOVERNANCE SUITE Funktionen und Vorteile VOLLSTÄNDIG INTEGRIERTE LÖSUNGEN Varonis DatAdvantage für Windows Varonis DatAdvantage für SharePoint Varonis DatAdvantage

Mehr

Schnittstelle SAP. - Schnittstelle SAP

Schnittstelle SAP. - Schnittstelle SAP Schnittstelle SAP - Schnittstelle SAP K3V 3.0 Energiewirtschaft als technische Ergänzung zu SAP als führendes ERP-System K3V 3.0 kann problemlos mit einem ERP-System wie z.b. SAP zusammenarbeiten, auch

Mehr

Anwendertage WDV2012 28.02.-01.03.2013 in Pferdingsleben

Anwendertage WDV2012 28.02.-01.03.2013 in Pferdingsleben Anwendertage WDV2012 28.02.-01.03.2013 in Pferdingsleben Thema: xrepo Auswirkungen auf zukünftige Entwicklungen Referent: Dipl.Ing. Simon Scheler MSc PRAXIS-Consultant Alles ist möglich! 1 Zu meiner Person

Mehr

Manufacturing Resource Library Teamcenter Tool Management

Manufacturing Resource Library Teamcenter Tool Management Manufacturing Resource Library Teamcenter Tool Management Historie 1986-2012 Genius Teamcenter TDM Systems MRL KIT Page 2 Fixtures Machine Handling Blank Part CAD Part Cutting Tools Page 3 Werkzeugverwaltung

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

ONET: FT-NIR-Netzwerke mit zentraler Administration & Datenspeicherung. ONET Server

ONET: FT-NIR-Netzwerke mit zentraler Administration & Datenspeicherung. ONET Server : FT-NIR-Netzwerke mit zentraler Administration & Datenspeicherung Motivation für die Vernetzung von Spektrometern Weiterhin wachsender Bedarf für schnelle Analysenmethoden wie NIR Mehr Kalibrationen werden

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

DGQ Regionalkreis Hamburg 21.05.2012 ISO 10007. Konfigurationsmanagement

DGQ Regionalkreis Hamburg 21.05.2012 ISO 10007. Konfigurationsmanagement DGQ Regionalkreis Hamburg 21.05.2012 ISO 10007 Leitfaden zum Konfigurationsmanagement g Geschichte des Konfigurationsmanagements Mit stetig steigender Produktkomplexität entstanden zunehmend Probleme (z.b.

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Persona-SVS e-sync auf Windows Terminal Server

Persona-SVS e-sync auf Windows Terminal Server Persona-SVS e-sync auf Windows Terminal Server 2014 by Fraas Software Engineering GmbH Alle Rechte vorbehalten. Fraas Software Engineering GmbH Sauerlacher Straße 26 82515 Wolfratshausen Germany http://www.fraas.de

Mehr

keytech Software DMS GmbH Notwendigkeit der Systemintegration in Zeiten wachsender Informationen

keytech Software DMS GmbH Notwendigkeit der Systemintegration in Zeiten wachsender Informationen keytech Software DMS GmbH Notwendigkeit der Systemintegration in Zeiten wachsender Informationen Kennzahlen Gründung: 1994 Mitarbeiter: 55 Standorte: 3 x Deutschland, 1 x USA Umsatz: 5 Mio. Kunden: 720

Mehr

pro.s.app archivelink Die smart integrierte Informationsplattform im SAP-Umfeld

pro.s.app archivelink Die smart integrierte Informationsplattform im SAP-Umfeld pro.s.app archivelink Die smart integrierte Informationsplattform im SAP-Umfeld d.link for archivelink ist die von der SAP AG zertifizierte ArchiveLink-Schnittstelle der d.velop AG. Die Kommunikation zwischen

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Release Notes 2.7 270 Version 1.0

Release Notes 2.7 270 Version 1.0 Web- und datenbankbasiertes Prozess- und Dokumentenmanagement Release Notes 2.7 270 Version 1.0 Juli 14 Abel Systems Hochbergerstrasse 60C 4057 Basel + 41 61 205 60 28 Servic e@qm pilot.com QMP-Release-Notes

Mehr

Universität Passau. Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth. Masterarbeit

Universität Passau. Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth. Masterarbeit Universität Passau Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth Masterarbeit "Identifikation von Erfolgsfaktoren für eine Facebook- Recruiting-Strategie"

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

S-5105 Grundlagen von Produktdatenmanagement im PLM erlernen

S-5105 Grundlagen von Produktdatenmanagement im PLM erlernen Zahlreiche PLM-Lösungen bieten u.a. vorkonfigurierte Standard- Lösungen. Die meisten der dieser vorkonfigurierten Standard- Lösungen adressieren typische PDM/PLM-Prozesse und können als Business-Ready-Solutions

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

Active Repository und Active Migration Manager

Active Repository und Active Migration Manager Mit der neuen Active Outlook App lassen sich Emails direkt aus Outlook 2013 oder aus Outlook 2013 WebApp archivieren oder auf Storagesysteme auslagern! An Funktionalitäten sind die Archivierung und Auslagerung

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

BRUNIE ERP.pps. Produktionsplanungs-/ Produktionssteuerungssystem. Produktionsplanung für BRUNIE ERP Systeme. FotoMike1976 - Fotolia.

BRUNIE ERP.pps. Produktionsplanungs-/ Produktionssteuerungssystem. Produktionsplanung für BRUNIE ERP Systeme. FotoMike1976 - Fotolia. Produktionsplanung für BRUNIE ERP Systeme Produktionsplanungs-/ Produktionssteuerungssystem FotoMike1976 - Fotolia.com Produktionsplanung und Steuerung Leistungsmerkmale Stammdaten Fertigungsdaten Produktionsaufträge

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

How to do? Projekte - Zeiterfassung

How to do? Projekte - Zeiterfassung How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...

Mehr

COMOS Enterprise Server

COMOS Enterprise Server COMOS Enterprise Server White Paper Weltweite Anwendungsvernetzung mit serviceorientierter Architektur August 2010 Zusammenfassung Interoperabilität ist heutzutage für die effiziente Planung und den Betrieb

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

aseaco Central Master Data Management Framework - Whitepaper -

aseaco Central Master Data Management Framework - Whitepaper - aseaco Central Master Data Management Framework - Whitepaper - Autor: Udo Zabel Das aseaco Central Master Data Management Framework (CMDMF) ermöglicht erfolgreiches kollaboratives Stammdatenmanagement

Mehr

Kosten im Vergleich: SAP-Lösungen versus Lagerverwaltungssysteme

Kosten im Vergleich: SAP-Lösungen versus Lagerverwaltungssysteme IWL-München Dietmar Gregarek 22. Juni 2007 Überblick 1 Die Qual der Wahl (Lagerverwaltung) Systemlandschaften mit Ausprägungen Kernfragen Warum SAP in Betracht ziehen Grundlagen Funktional: geeignete Systeme

Mehr

Installation und Dokumentation. juris Autologon 3.1

Installation und Dokumentation. juris Autologon 3.1 Installation und Dokumentation juris Autologon 3.1 Inhaltsverzeichnis: 1. Allgemeines 3 2. Installation Einzelplatz 3 3. Installation Netzwerk 3 3.1 Konfiguration Netzwerk 3 3.1.1 Die Autologon.ini 3 3.1.2

Mehr

Kompetenzfeld Produktstrukturen. Patrick Müller, Thomas Wamsiedl

Kompetenzfeld Produktstrukturen. Patrick Müller, Thomas Wamsiedl Kompetenzfeld Produktstrukturen by CaRD / CaRD PLM 2009 Unsere Mitarbeiter sollen nicht unnötig lange hinter Informationen herjagen, sondern mehr Zeit haben, sich ihren Entwicklungsaufgaben zu widmen Andreas

Mehr

PLM-Software. Lösungen für die Teilefertigung. Answers for industry.

PLM-Software. Lösungen für die Teilefertigung. Answers for industry. Lösungen für die Teilefertigung Ein umfassendes Paket an Lösungen für die Teilefertigung für die Luft- und Raumfahrtindustrie PLM-Software Answers for industry. Teilefertigung für die Luft- und Raumfahrt

Mehr

Aus Daten werden Informationen

Aus Daten werden Informationen Swiss PLM-Forum 2011 Differenzierung durch Standards Aus Daten werden Informationen Jochen Sauter BCT Technology AG Agenda Vorstellung BCT Technology AG Product Lifecycle Management Definition / Daten

Mehr