Datendurchgängigkeit – der Befähiger zur Kollaboration

A Si
da ch
pt er
ie
re
n
tig
eu ren
nd ie
Ei oris
i
Pr
h en
ac ier
n f is
Ei ron
h
nc
Sy
Datenkonsistenz
„Single source of truth“
St
ru Frü
kt h
ur
ie
re
n
Lean
Innovation
Datendurchgängigkeit –
der Befähiger zur Kollaboration
Dr. Stefan Rudolf (Complexity Management Academy) / Elisabeth Schrey (WZL)
IT-Landschaften in Unternehmen besitzen häufig eine Historie und Vielfalt, die deren Harmonisierung behindern. Dabei liegt gerade in der Datendurchgängigkeit aller Geschäftsprozesse
der Schlüssel für große Effizienzsteigerungen. Ein durchgängiger Backbone, der die aktuellsten
Daten jeder Funktion zeitgleich zur Verfügung stellt, ist deswegen der ideale Zielzustand.
Motivation
Wachsende Datenmengen und eine vielfältige
IT-Landschaft gehören in vielen Unternehmen
zum Alltag. Für produzierende Unternehmen mit
einem variantenreichen Produktprogramm ist diese Herausforderung besonders gravierend. Eine
Lösung versprechen PLM-Systeme, welche eine
Durchgängigkeit im Datenfluss ermöglichen sollen. In der industriellen Praxis ist dies aber noch
ein Ideal, weil das Denken und Handeln in Unternehmensfunktionen als in sich abgegrenzte Einheiten mit eigenen informationstechnischen Anforderungen noch dominiert. So entstehen beim
Generieren von Daten Redundanzen und Inkonsistenzen, sodass effizientes Arbeiten behindert
wird. Um dem entgegenzuwirken, ist als Grundvoraussetzung eine durchgängige Datenstruktur
für eine Single Source of Truth zu schaffen.
Geschäftsprozesse sind über gemeinsame
Datenstrukturen zu verbinden
Die Grundlagen dieser durchgängigen Datenstruktur sollen durch die Zusammenhänge von Geschäftsprozessen, IT-Systemen, Produktdaten im
Folgenden beschrieben werden. Insgesamt ist die
gesamte Vernetzung der Geschäftsprozesse entlang
der Wertschöpfungskette anzustreben. Eine vollständige Beschreibung der unternehmensweiten
Prozesslandschaft stellt sicher, dass die Ansprüche
aller Unternehmensfunktionen und -hierarchien
an die Datenstruktur berücksichtigt werden. Eine
Übersicht für Referenzprozesse, die in diversen Industrien bereits verwendet wurde, ist das Ergebnis
eines Forschungsprojektes des Werkzeugmaschinenlabors (WZL) der RWTH Aachen zusammen
mit dem Institut für Arbeitswissenschaft (IAW)
der RWTH Aachen und dem Fraunhofer Institut
für Produktionstechnologie (IPT) in Aachen. Das
Handbuch des Transferbereichs (TFB) 57 gibt
einen umfassenden Überblick der zu betrachtenden Geschäftsprozesse und beschreibt deren
Strukturen und Rollen sowie mögliche unterstützende Methoden. Der Zusammenhang der 13 beschriebenen Prozesse ist in Abbildung 1 zu sehen. Beispielhaft ist die Auftragsabwicklung zu nennen, welche
in die allgemeinen Phasen Auftragserfassung und
-prüfung, Angebotserstellung und Auftragsausführung unterteilt wird. Es wurde ein detailliertes
Prozessmodell einheitlich im Standard der Business Process Modeling Notation (BPMN) dargestellt und Methoden der Auftragsabwicklung wie
Complexity Management Journal 02/2015
13
die belastungsorientierte Auftragsfreigabe (BOA)
beschrieben. Optimalerweise werden diese Methoden durch bedarfsgerechte IT-Systeme realisiert.
Diese stellen jeder Unternehmensfunktion anwendungsspezifisch alle relevanten Informationen zur
Verfügung und ermöglichen es, den Bereichen
über Informationen im Austausch zu stehen und
diese zu verändern, zu ergänzen oder zu löschen.
Informationen liegen für jeden Geschäftsprozess
in unterschiedlichen Formaten vor. Beispielsweise
benutzen Vertriebsmitarbeiter einen Produktkatalog oder webbasierten Konfigurator und geben
Bestellungen per Artikelnummer über ein ERPSystem an relevante Bereiche weiter. Für das Beispiel der Auftragsabwicklung ist ein relevantes
IT-System das Customer Relationship Management (CRM), in welchem die Historie aus Kundendaten mit oder ohne direkten Produktbezug
gespeichert werden kann.
liche Sichten auf das Produkt. Bei diesen Sichten
wird zwischen Anforderungs- und Funktionsstrukturen sowie verschiedenen physischen Produktstrukturen unterschieden. Im Vertrieb sind
bspw. die Produktfunktionen oder Anwendungsoptionen im Fokus, die über einen Konfigurator in
dem Prozessschritt Anfragenerfassung und -prüfung ausgewählt werden können. Jede dieser Sichten beinhaltet die relevanten Informationen, welche in den IT-Systemen bearbeitet werden. Die
benötigten Informationen umfassen nicht nur
Produktdaten, sondern ebenso Kunden- und Lieferantenangaben in Form von Datenbanken oder
Ergebnissen aus Analysen wie Marktprognosen.
Weitere wesentliche Informationen treten im Zusammenhang mit der Produktion auf, welche in
Fertigung und Montage mit statischen Maschinendaten und dynamischen Prozessdaten arbeitet.
In Abbildung 2 ist diese Vernetzung mit beispielhaften IT-Systemen aufgezeichnet. Es ist ebenfalls
erkennbar, dass in multinational agierenden Unternehmen IT-Systeme nicht nur an einem Standort miteinander verbunden werden müssen, sondern, dass diese Problematik häufig global ist.
Durch Geschäftsprozesse und IT-Systeme entstehen in jedem Unternehmensbereich unterschied-
Datendurchgängigkeit und -synchronisation
stellen die Kernelemente einer Single Source
of Truth dar
Die Datendurchgängigkeit stellt dabei an die ITLandschaft einerseits die Anforderung der Systemvernetzung, die im Artikel zum Product Lifecycle
Management beschrieben wurde. Andererseits ist
Auftragsabwicklung
Einzelprojektcontrolling
Ideenmanagement
Produktprogrammplanung
Produktplanung
Anforderungsmanagement
Funktionsmanagement
Produktmanagement
Änderungsmanagement
Kollaborative Entwicklung
Produktentwicklung
Risikomanagement
Qualitätscontrolling
Legende
Personalauswahl und -entwicklung
Steuerungszugriff
Informationsfluss
Gestaltung eines belastungsoptimalen Arbeitsumfelds
Abb. 1: Prozesslandkarte der gesamten Referenzprozesse
14 Complexity Management Journal 02/2015
Abb. 2: Ideal einer Single Source of Truth
es für effiziente Prozesse wichtig, dass die Unternehmensfunktionen zeitgleich auf die gleiche Datenbasis zurückgreifen können im Sinn einer Single
Source of Truth. Dazu müssen sich die IT-Systeme
ihre jeweilige Datenstruktur aus einer gemeinsamen Datenquelle ziehen, aus der die relevanten
Sichten für die Unternehmensfunktionen ausgeleitet werden. Für produktbezogene Daten gilt dabei, dass sowohl die betrachteten Elemente innerhalb der Strukturen als auch die Hierarchieebenen
der Produktstruktur je nach Unternehmensfunktion unterschiedlich ausgeprägt sein können.
Trotzdem werden von der gleichen Datenbasis für
jede Funktion die aktuellsten Daten gezeigt und
jede Unternehmensfunktion bekommt die relevanten Daten zur Verfügung gestellt. Der zugrunde liegende Datenbackbone sollte außerdem
mit Bibliotheken verbunden sein, die Stammdaten
verschiedener Funktionen ordnen und mit denen
Elemente aus der Produktdatenstruktur eindeutig
verknüpft werden können. Dieser Zusammenhang
ist in Abbildung 1 als Datenbackbone dargestellt,
der als einziger Informationsfluss die Systeme verbindet und auch Informationen aus Bibliotheken
transportiert. Beispielsweise ist hier ein Customer
Relation Management zu nennen, in welchem
Kundendaten mit den jeweils abgesetzten Produktkonfigurationen verknüpft sind. Der Problematik
der unterschiedlichen Produkt- und Stücklistenstrukturen wird so begegnet, dass auf derselben
Datenbasis alle Strukturen anwendbar sind. Es gibt
bereits erste IT-Systeme, welche diese Flexibilität
vor allem im Bereich der Produktplanung und
-entwicklung erlauben.
Nutzen des Datenbackbones
Der Nutzen eines Datenbackbones liegt folglich in
der Erhöhung der Datenqualität entlang der gesamten Wertschöpfungskette. Diese Datendurchgängigkeit kann gerade dann als Beschleuniger in
den Geschäftsprozessen fungieren, wenn im Unternehmen der erfolgreiche Ansatz der modularen
Complexity Management Journal 02/2015
15
Produktbaukästen genutzt wird. Produktbaukästen
unterteilen ein Produkt in standardisierte und flexible Bausteine und unterstützen damit einerseits
eine dem Kunden angepasste Variantenvielfalt
und andererseits standardisierte Prozesse im Unternehmen. Für die Produktentwicklung bedeutet
dies, dass möglichst in Modulen gekapselte Funktionen parallel von verschiedenen Entwicklungsdisziplinen realisiert werden. Hier entsteht häufig
das Problem von unterschiedlichen Produktstrukturen, wenn zwischen Funktionen und Modulen
keine 1:1-Beziehung besteht. Der Vorteil einer gemeinsamen Datenbasis und der Ableitung von
funktionsabhängigen Sichten liegt in der Möglichkeit zur Kollaboration. Je nach Entwicklungsdisziplin und -gegenstand können Maschinenbauer,
Elektrotechniker oder Softwareingenieure an einer
Funktion arbeiten und zeitgleich die aktuellsten
Änderungen anderer Bereiche einsehen. Durch
die üblichen Check-in und Check-out Funktionen
von PLM-Lösungen wird dabei verhindert, dass
zwei Änderungen gleichzeitig an einem Dokument umgesetzt werden können. Auf diese Weise
werden in kurzen Zyklen Entwicklungsstände aggregier- und überprüfbar. Dadurch entfallen lange
Iterationsschleifen aufgrund mangelnder Kommunikation oder Versionierungsproblemen.
Zusammenfassung
Zusammenfassend steht fest, dass die Datendurchgängigkeit im Unternehmen die Berücksichtigung aller Funktionen und Geschäftsprozesse
erfordert. Diese müssen über eine gemeinsame
Datenquelle verfügen, aus welcher beliebige Ansichten auf das Produkt ausgeleitet werden können. Mit der Vernetzung zu Stammdatenbanken
entsteht eine Single Source of Truth, die für effiziente Prozesse elementar ist. Für Unternehmen, die
stark funktionsorientiert und zeitgleich in verschiedenen Entwicklungsdisziplinen entwickeln,
ist die einheitliche Datengrundlage besonders
wichtig, um Redundanzen in der Datenhaltung
und damit ineffizientes Arbeiten zu verhindern.
Literaturhinweise
Schuh, G.; Schlick, C.; Schmitt, R.; Lenders, M.; Bender, D.; Bohl, A.;
Gärtner, T.; Hatfield, S.; Müller, J.; Mütze-Niewöhner, S.: Systemunabhängige Referenzprozesse für das PLM, Open Space Seminar, 2008
Kontakt
Dr. Stefan Rudolf
Geschäftsführer
Complexity Management Academy GmbH
Telefon:+49 241 51031 500
[email protected]
Elisabeth Schrey
Abteilung Innovationsmanagement
Werkzeugmaschinenlabor WZL der RWTH Aachen
Lehrstuhl für Produktionssystematik
[email protected]
16 Complexity Management Journal 02/2015