Dieser Beitrag ist ursprünglich erschienen im Fachbuch „Controlling digitaler Prozesse“, im Original hier zu finden und beschäftigt sich mit der Prozessoptimierung durch Datenfluss-Analyse
- Herausforderungen der Prozess-Digitalisierung
- Systematische Erfassung aller Datenflüsse
- Prozessdokumentation auf Ebene der Datenflüsse
- Analyse der Datenflüsse und Ableitung von Optimierungsmaßnahmen
- Vorbereitung der weiteren Automatisierung der Prozesse
Fachbeitrag: Prozessoptimierung durch Datenfluss-Analyse
1. Einführung
Im Kern sind es die Geschäftsprozesse, die Wert für den Kunden schaffen und damit Einkommen für die Stakeholder des Unternehmens generieren. Daher ist es eine wichtige Aufgabe der Unternehmenssteuerung, die Prozesse im Unternehmen stets an die sich ändernden
Rahmenbedingungen anzupassen und so leistungsfähig zu halten. Das Prozesscontrolling nimmt also einen hohen Stellenwert in der Aufrechterhaltung der Markt- und Kundenorientierung ein.
Mit zunehmender Digitalisierung nimmt die Geschwindigkeit der Veränderung sowohl der Marktanforderungen als auch der technischen Lösungsmöglichkeiten stetig zu. Es ist daher erforderlich, die Prozesse häufiger und intensiver zu hinterfragen. Tiefere Analysen müssen dabei gelegentlich bis auf die Ebene der Datenflüsse hinuntergehen. Die auf dieser Ebene gefundenen Potenziale führen zu Wettbewerbsvorteilen und schaffen eine Basis für eine zunehmende Automatisierung und Digitalisierung der Geschäftsprozesse durch professionelle Verknüpfung der Datenflüsse.
Das hier beschriebene Projekt hatte genau diese tiefe Analyse zum Inhalt. Und im Effekt hat es eine gute Basis für Prozess-Digitalisierung und -Automatisierung geschaffen.
1.1. Grundlagen der Steuerung digitaler Prozesse
Die eingangs beschriebene Anpassung der Prozesse an geänderte, schnellere und dynamischere Rahmenbedingungen verändert auch die Art, in der wir die Prozesse steuern (können). Um den Anforderungen an die Geschwindigkeit der Geschäftsabläufe, also sowohl der Auftragsabwicklung als auch der Neuprodukt-Entwicklung gerecht zu werden, sind immer mehr Digitalisierungen und Automatisierungen erforderlich.
Und die Voraussetzung für die Automatisierung von Prozessen ist deren detaillierte Beschreibung. Während in den vergangenen Jahrzehnten überwiegend fertigungsnahe Prozesse automatisiert wurden, kommen nun Lösungen auf, auch sehr intellektuelle Prozesse zu automatisieren, soweit sie nur beschreibbar sind. Allgemein sind dies z.B. Analyse- und Diagnose-Prozesse inkl. der Entscheidung, Dokumentationsaufgaben und sogar Aufgaben zur Codierung von Software.
Durch intelligente Algorithmen wird damit eine Vielzahl von Abläufen und Aufgaben schrittweise automatisiert werden, die im Extrem zur Automatisierung der eigentlichen Wertschöpfung führt. Die Prozesslandschaft in unseren Unternehmen lässt sich auf dieser Basis tendenziell in zwei wesentliche Blöcke aufteilen:
1. Beschreibbare Abläufe
Diese Geschäftsprozesse werden noch tiefer und detaillierter beschrieben, als dies in den bestehenden Prozessbeschreibungen üblich ist. Zu diesen Prozessbeschreibungen gehört dabei (natürlich) nicht nur die Reihenfolge der Tätigkeiten.

Für ein operatives Funktionieren der Prozesse sind die verschiedenen „Flüsse“ erforderlich, die einen Prozess begleiten, z.B.
- Materialfluss (bei Fertigungs- und Logistik-Prozessen)
- Dokumentenfluss
- Informationsfluss
2. Empathie-bezogene Prozesse
Es wird bei aller Digitalisierung viele Prozesse geben, die nicht automatisierbar sind, weil ihr Ablauf nicht eindeutig beschreibbar ist. In einer immer schnelleren Geschäftswelt ist es u.a. wichtig, viel Kommunikation mit den wesentlichen Stakeholdern zu betreiben, um die Wertschöpfungskette (bzw. zunehmend die Wertschöpfungsnetzwerke) zu koordinieren und für einen reibungslosen Ablauf der Leistungserstellung zu sorgen.
Dies betrifft wesentlich die Führungsprozesse, die kreativen und strategischen Prozesse, etc. im Unternehmen. Die Vernetzung und Geschwindigkeit führen darüber hinaus zu einer Erweiterung der Prozessbetrachtung über die juristischen Unternehmensgrenzen hinaus. Es entstehen Konzepte wie Co-Creation und Coopetition, also die aktive, kreative Zusammenarbeit zwischen Kunden und Lieferanten zur Erstellung der Leistung und zwischen Wettbewerbern, die z.B. bei der Entwicklung einer Technologie-Plattform zusammenarbeiten.
Aber auch solche kreativen, kommunikativen und strategischen Prozesse sind oftmals von IT-Systemen unterstützt und mit beschreibbaren Informationsflüssen begleitet. Zur Sicherstellung eines belastbaren Funktionierens dieser Prozesse muss auch dieser Informationsfluss „im Griff“ sein. Eine wesentliche Voraussetzung für eine solch breit angelegte Automatisierung ist ein tiefes Verständnis der Datenflüsse entlang der Geschäftsprozesse.
Diese und weitere Gedanken waren die Basis für ein Projekt, das im ersten Halbjahr 2019 stattgefunden hat und das eine bessere Steuerung der Geschäftsprozesse durch eine höhere Transparenz der Datenflüsse zum Ziel hatte.
1.2. Beschreibung des Projektes
Das hier zu beschreibende Projekt fand statt in einem Unternehmen der Elektronikfertigung mit eigener Entwicklung mit rd. 1.000 Mitarbeitern und 350 Mio. € Umsatz. Das Unternehmen ist in einer regulierten Branche tätig. Es gibt dort eine gute Beschreibung der Geschäftsprozesse. Das Unternehmen funktioniert gut und ist wirtschaftlich erfolgreich. Es wird jedoch zunehmend über die weitere Beschleunigung der Geschäftsprozesse nachgedacht, um den o.g. Entwicklungen zu begegnen und die Marktanforderungen zu befriedigen. Die Optionen dabei reichen:
- von der Verbesserung der bestehenden IT-Unterstützung, z.B. durch Eliminieren von Medienbrüchen
- über den Einsatz neuer IT-Systeme, die gleich mehrere bestehende IT-Systeme ersetzen und damit Schnittstellen eliminieren und Abläufe beschleunigen,
- über die Erhöhung der Transparenz von Daten und Informationen, um damit bessere und schnellere Entscheidungen treffen zu können (i.W. in empathiebezogenen Prozessen)
- bis hin zu vollständiger Automatisierung von Prozessen, z.B. über Workflows.
Dies gilt dabei sowohl im Kernbereich der Wertschöpfung, also der Fertigung und der fertigungsnahen Bereiche als auch in der kompletten Entwicklung und sogar der Administration und dem Qualitätsmanagement. Wesentlicher Inhalt des Projektes war es, die Datenflüsse im gesamten Unternehmen transparent zu dokumentieren. Diese Dokumentation sollte dann dazu dienen,…
- die Datenflüsse zu analysieren bzgl. evtl. Schwachstellen und daraus Verbesserungsmaßnahmen für die kontinuierliche Prozessverbesserung abzuleiten,
- für anstehende große IT-Projekte eine optimale Arbeitsgrundlage zu bereiten, um die Durchführung der Projekte in möglichst kurzer Zeit mit möglichst wenig Störungen im Tagesgeschäft und mit möglichst großem wirtschaftlichem Erfolg durchzuführen,
- eine einheitliche Dokumentation aufzubauen, die kontinuierlich weitergeführt werden soll, um zukünftige Anwendungen, z.B. neue große IT-Projekte, zu fördern und zu unterstützen.
Es wurde erwartet, dass der Fokus auf der Unterstützung der großen IT-Projekte liegt. Tatsächlich sollte sich herausstellen, dass eine Verbesserung der Prozesse mit kleinen Maßnahmen deutlich stärker durch das Projektergebnis unterstützt wurde, als dies im Vorfeld zu erwarten war. Ein grundlegendes Element jeder vollständigen Prozessbeschreibung ist die Definition der IT-Systemeund -Tools sowie deren Zusammenwirken.
Oftmals gibt es Schnittstellenprobleme, Insel-Lösungen, Redundanzen in den Funktionalitäten, etc. Gerade in einem großen, dezentralisierten Unternehmen entwickeln sich separate Lösungen, die letztlich zu einer großen Liste von IT-Applikationen führt, die entflochten werden muss, um eine gute Basis für effektive und effiziente Prozessautomatisierungen zu haben. Auch dieses Ziel wurde implizit mit dem Projekt verfolgt.
In Summe bestand das Ziel des Projektes also in der Schaffung einer hohen Transparenz in allen Datenflüssen entlang aller Geschäftsprozesse über alle Systeme in allen Standorten hinweg inkl. der Anbindung der wesentlichen Dienstleister. Auf diese Weise wurde durch das Projekt „Datenfluss-Dokumentation und -analyse“ eine Grundlage für viele Anwendungsbereiche der Prozesssteuerung gelegt.
2. Methodisches Vorgehen
Am Beginn des Projektes stand die Identifikation der Stakeholder, also z.B. IT-Abteilung, Fachabteilungen, Management, Process Owner, aber auch die designierten Projektleiter der anstehenden großen IT-Projekte. Mit diesen wurde geklärt, welche Datenbasis und welche Dokumentationen von Prozessen und Datenflüssen es bereits gibt. Diese bestehenden Dokumentationen wurden genutzt, um:
- Doppelarbeit zu vermeiden,
- die Akzeptanz des entstehenden Dokuments zu erhöhen und
- die Abstimmung zu anderen offiziellen Dokumenten sicherzustellen
Alle vorhandenen Darstellungen endeten auf Applikationsebene. Die Datenstrukturen waren nur bedingt verfügbar, werden aber für die IT-Projekte benötigt. Es wurde zudem eine Betrachtung der in den letzten Monaten und Jahren abgeschlossenen IT-Projekte vorgenommen, um aus deren Ablauf zu lernen. Manche Projekte in der Vergangenheit sind bzgl. der Datenanbindung nicht optimal gelaufen und haben Störungen in der Fertigung erzeugt und deutlich länger als geplant gedauert.
Wichtig ist,
- alle aufzunehmenden Informationen vor Beginn der Ist-Aufnahme zu bestimmen (um aufwändige Nacharbeit zu vermeiden)
- den Scope klar festzulegen und alle Prozesse darin vollständig und redundanzfrei zu definieren
- die geplante Auswertbarkeit mit Projektstart festzulegen
2.1. Die Projektphasen
Das eigentliche Vorgehen im Projekt wurde in einem Kick-off-Workshop definiert. Dies sah eine systematische Aufnahme der Prozesse in mehreren Phasen vor:
- Walk-through durch die Prozesse (intensive Kommunikation mit den ausführenden Mitarbeitern vor Ort),
- Review der aufgenommenen Datenflüsse mit den Business-Ownern und
- Ergänzung von Hintergrund-Informationen zu Datenflüssen von den IT-Administratoren.

Die Basis der Prozessbegehung bildete die vorhandene Prozessdokumentation. Die Prozessbezeichnungen auf Ebene 3 (Sub-Prozesse) wurden strukturiert zusammengestellt und im Laufe des Projektes systematisch abgearbeitet. Dabei wurden die Datenflüsse entlang der Prozesse grundsätzlich entlang des Value Streams erfasst, also von der Innovation über die Produktentwicklung bis zur Markt- und Fertigungseinführung und dann von der Absatzplanung über den Vertrieb/Auftragseingang und die Produktion bis zum Versand, Fakturierung und Geldeingang.
Entsprechend der festgelegten Vorgehensweise wurden die Prozesse mit Datenflüssen und der Zuordnung einer Vielzahl von Attributen aufgenommen. Zuordnung der IT-Systeme: Neben den Datenflüssen war es das Ziel, die vollständige IT-Systemlandschaft abzubilden. Nur die Summe aller Datenflüsse in allen Prozessen mit allen IT-Systemen ergibt ein vollständiges Bild. Zuordnung von Datenattributen: Die Daten sollten in mehrfacher Hinsicht klassifiziert werden, um später systematische Auswertungen und Analysen durchführen zu können.
Als Datenattribute wurde eine Struktur nach Datenschichten zugrunde gelegt. Weitere Attribute betrafen die Art der Verarbeitung, die „Richtung“ der Daten (schreiben/lesen) und weitere, die in der Struktur der Dokumentation im folgenden Kapitel beschrieben sind. Der Umfang der Datenaufnahme inkl. der Datenattribute war also wie folgt vorgesehen:

2.2. Begehung der Prozesse und Aufnahme der Datenflüsse
Die aufgenommenen IT-relevanten Prozessschritte zeigten am Ende, wie IT-intensiv die einzelnen Geschäftsprozesse sind. Zur Überraschung aller Beteiligten wurden auf diese Weise deutlich über 1.000 Datenflüsse aufgenommen. Während der Begehung der Prozesse wurden zunächst handschriftliche Notizen und teilweise Screenshots gemacht, die dann unmittelbar nachher in diese Tabelle übertragen wurden, soweit die Informationen dazu aus dem Erstgespräch hervorgingen.
Um möglichst korrekte, vollständige und vor allem ausreichend detaillierte Informationen zu bekommen ist es erforderlich, dass die Aufnahme der Prozessschritte und der daran hängenden Datenflüsse unmittelbar zusammen mit den ausführenden Personen erfolgt. Gerade bei den
„physischen“ Prozessen der Fertigung und der Logistik sind wir zusammen mit den ausführenden Kollegen dem Wertstrom entlang gelaufen und haben jeden Handgriff aufgenommen, sofern er mit der Generierung von Datenflüssen in Zusammenhang steht.
Dabei hat sich sehr oft herausgestellt, dass viele Mitarbeiter neben den offiziellen Systemen ihre eigenen individuellen Excel- und Word-Dateien erzeugen. Sofern diese für die Durchführung des Prozesses signifikant waren, wurden sie aufgenommen. Das zugehörige IT-System war dann z.B. Excel. Auf diese Weise wurden fast 100 Excel-Dateien über alle Prozesse identifiziert.
Für den Prozess „unwichtige“ Excel-Dateien der Kollegen wurden nicht aufgenommen. Es ist klar, dass diese Excel-Dateien keiner Versionskontrolle unterliegen, bis zu diesem Projekt in keinem zentralen Verzeichnis enthalten sind und daher bei der Veränderung der IT-Umgebung, z.B. einer neuen Windows-Version, nicht sichergestellt werden kann, dass der Prozess weiterhin reibungslos funktioniert.
Hier wurden also durch diese wichtigen individuellen Dateien Prozessrisiken aufgedeckt und dokumentiert. Wenn es für die Dokumentation des Datenflusses sinnvoll war, die Darstellung am Bildschirm zu zeigen, wurde ein Screenshot erstellt und ein Link zu diesem Screenshot in die Tabelle eingetragen.
Am Ende des Projektes wurde ein Owner der neugeschaffenen Dokumentation festgelegt und alle Unterlagen in den Regelbetrieb, also in die laufende Pflege und Unterstützung der Projekte und Prozesse, übergeben.
3. Struktur der Daten-Dokumentation
Die Datenfluss-Dokumentation war von Projektbeginn an als eine offizielle Gesamtdokumentation gedacht, die fortan versioniert und weiterentwickelt wird. Je nach Adressaten sollte die Dokumentation sowohl eine strukturierte tabellarische Darstellung haben als auch grafische Darstellungen aus unterschiedlichen Blickwinkeln (i.W. Fachbereich- und IT-Sicht).
3.1. Tabellarische Dokumentation als Basis
Die Dokumentation erfolgte zunächst in einer strukturierten Excel-Datei für jeden Standort. Auf dieser baute dann die grafische Dokumentation der Datenströme auf. Um eine Grundlage für die weitere Bearbeitung dieser Dokumentation in der Zukunft zu legen,
wurde großer Wert auf die Durchgängigkeit / Integrität der Dokumentation gelegt.
Die Dokumentation hatte folgende Struktur:

Die Basisdaten dienen u.a. der Sicherstellung einer einheitlichen Schreibweise. Diese werden über Drop-Down-Menüs in die eigentlichen Prozessdarstellungen mit ihren Datenströmen übernommen. Auf diese Weise sind mehrere formale Dinge sichergestellt:
- Die Schreibweise von Prozessen, Fachbereichen und IT-Systemen ist durchgängig einheitlich.
- Durch die Rückverknüpfung der aufgenommenen Daten in die Basistabellen ist eine Vollständigkeitskontrolle möglich.
- Längere Namen/Bezeichnungen können deutlich einfacher/schneller in die Dokumentation übernommen werden.
Im Zentrum der Prozessaufnahme standen die Tabellen der Prozessdokumentation. Diese haben folgenden Aufbau:
No. – lfd. Nr.
Designation – Bezeichnung
Remark – Hinweise/Bemerkungen
Pecularity – Auffälligkeiten
Input – Input
Supplier – Lieferant
Responsibility – Verantwortlich
OrgUnit – Organisationseinheit
Contribution – „trägt bei“
OrgUnit – Organisationseinheit
Contribution – „trägt bei“
OrgUnit – Organisationseinheit
Information – wird informiert
OrgUnit – Organisationseinheit
Output – Output
Customer – Kunde
Documents – genutzte Dokumente
Information flow description – Kurzbeschreibung Informationsfluss
IT System – IT-System
Transaction – ggf. Transaktion im System
Report/View – Report/View
Screenshot? – Screenshot?
Data Folder – Daten-Ablageort
Layer – Datenschicht
Data Object – Datenobjekt
Type of Processing – Art der Verarbeitung
Type of Data – Datentyp
Data Format – Datenformat
Archived? – wird archiviert?
Data released/ approved? – Datenfreigabe erforderlich?
write/read – lesen / schreiben
read frequency – Lesehäufigkeit
write frequency – Schreibhäufigkeit
Die in diesen Dateien dokumentierten Prozessschritte beschränken sich auf die IT-relevanten Schritte. Es gibt daher keine Redundanz zu der bereits vorliegenden offiziellen und vom Qualitätsmanagement verantworteten Prozess-Dokumentation. Diese zeigt zwar die beteiligten IT-Systeme, aber nicht die Datenflüsse mit all den in der o.g. Tabelle dargestellten Details. Die Prozesse wurden zum Verständnis der Datenflüsse dokumentiert. Innerhalb eines Hauptprozesses wurden die verschiedenen Subprozesse separat dargestellt. Der Gesamtprozess wurde mit wesentlichen Angaben wie
- Trigger / Auslöser
- Owner und
- Output
versehen. Die Exceltabelle mit den 33 Spalten ist nachfolgend dargestellt:


Als Zusatzangabe zu den Prozessen wurden die Verantwortlichkeiten nach dem SIPOC-Prinzip dargestellt. SIPOC steht dabei für Supplier, Input, Prozess, Output und Customer.

Diese Angaben haben sich als wichtige Angaben zum Verständnis der Datenflüsse herausgestellt. Erst, wenn klar ist, welches Formular von wem geliefert wird (z.B. der Fertigungsauftrag), kann man nachvollziehen, warum gerade dann der nachfolgende Datenfluss entsteht (z.B. der Abruf des Materials).
3.2. Datenattribute
Zu jedem einzelnen Datenfluss wurden mehrere Datenattribute vermerkt, die auch in der grafischen Darstellung mit modelliert wurden. Auf diese Weise ist man nachher sowohl im grafischen Datenmodell als auch in der Excel-Dokumentation in der Lage, z.B. alle Stammdaten-Datenflüsse zu selektieren. Auch interessant ist die Art der Verarbeitung. Bei jedem Datenfluss wissen wir nun, ob die Daten manuell oder automatisch verarbeitet werden. Die Attribute entsprechen den bereits oben genannten allgemeinen Strukturierungsmerkmalen von Daten.

3.3. Liste der IT-Systeme
Die Liste der IT-Systeme lag grundsätzlich zentral vor und wurde als Basis-Tabelle aufgenommen. Die vorgenannten individuellen Excel-Dateien wurden dieser Liste nicht hinzugefügt; es ist eine Aufgabe der Bearbeitung der „Schwachstellen“, für jede dieser Excel-Dateien zu prüfen, wie damit umgegangen werden soll, z.B.
- Aufnahme in die offizielle Liste und Vergabe von „Ownern“ für Business und IT (Admin),
- Ersatz der Excel-Datei durch eine professionelle Lösung oder
- Umgestaltung des Prozesses und damit Wegfall der Datei.
Im Laufe der Aufnahme wurden jedoch viele IT-Systeme bzw. überwiegend kleinere Tools gefunden, ohne die der Prozess nicht läuft und die aber auch in keiner offiziellen Liste enthalten sind. Die Effekte sind dieselben wie bei den Excel-Dateien (keine Versionspflege,Prozessrisiko, etc.). Solche Tools werden oftmals bei der Entwicklung und dem Test von Elektronik-Komponenten genutzt, weil der Hersteller der Komponente diese Tools bereitstellt und die Komponente damit programmiert oder getestet wird.
In der Summe über alle Tools, integrierte Entwicklungsumgebungen, einzelne Editoren und Compiler, etc., etc. kamen im Laufe der Begehung sehr viele IT-Tools zusammen, die
- nicht offiziell bekannt waren,
- nicht durchgängig lizensiert waren (teilweise wurde Freeware genutzt, die aber auch bei professionellem Einsatz nicht immer ohne Weiteres genutzt werden darf),
- sich inhaltlich/funktional oft deutlich überschnitten.
Begonnen wurde die Liste zum Start des Projektes mit rd. 300 IT-Systemen und offiziellen Tools. Am Ende des Projektes waren es fast doppelt so viele! In die Liste der IT-Systeme wurden auch Web-gestützte Systeme aufgenommen. So ist für das Patentwesen die Datenbank des Deutschen Patentamtes eine wichtige Quelle, die teilweise aus internen IT-Systemen automatisch angesprochen wird. Auch dabei ist es wichtig zu klären, ob dies bei Versionsänderungen bzw. Anpassungen der IT-Umgebung noch funktioniert.
3.4. Grafische Darstellungen
Auf der Basis der umfangreichen Excel-Datei mit den über 1.000 Datenflüssen, Prozessinformationen und Datenattributen wurde ein grafisches Modell erstellt. Die Suche nach einem geeigneten Tool, welches
- die Prozessinformationen aufnehmen und darstellen,
- reine Datenflussmodelle darstellen und vor allem
- Auswertungen über die vielfachen Detailinformationen
ermöglicht, resultierte in der Entscheidung für das bereits vorhandene Tool ARIS Connect.
Die Datenbank hinter den Modellen ermöglicht die Aufnahme vielfältiger Detailinformationen wie die Datenattribute, aber auch Erläuterungstexte und Beispiele zu jedem einzelnen Element. Wie bei Datenbank-gestützten Modellierungssystemen üblich werden IT-Systeme, Organisationseinheiten, etc. nur einmal modelliert und dann ggf. mehrfach in den verschiedenen Modellen verwendet. Eine Änderung von Bezeichnungen, Ergänzungen von Daten-Details, etc. werden dann auch nur einmal zentral vorgenommen und sind sofort in allen Modellen geändert.
Dennoch war die Modellierung eine aufwändige Fleißarbeit, da zu allen Datenflüssen, IT-Systemen und Datenobjekten die jeweiligen Attribute in zwei Sprachen erfasst wurden. Am Beispiel der Erstellung einer Bestellung wurden folgende Datenattribute gepflegt:

Als Ergebnis der Modellierung wurden zwei unterschiedliche Modelle erstellt, nämlich
- ein Datenflussdiagramm, in dem „nur“ alle IT-Systeme und die Datenflüsse zwischen ihnen dargestellt wurden und
- eine Prozess-/Datenfluss-Darstellung, in der die wesentlichen Prozessschritte mit all ihren Verknüpfungen und den bearbeiteten Datenobjekten und IT-Systemen.
3.4.1. Datenflussmodell
Das Datenflussmodell ist für eine reine IT-Betrachtung wertvoll und liefert kompakte Informationen zum Zusammenwirken der IT-Systeme. Für ein tieferes Verständnis sollte jedoch die Prozessdokumentation hinzugezogen werden. Ein größerer Ausschnitt aus dem Datenflussmodell sieht folgendermaßen aus. Alle Datenflüsse sind mit dem jeweiligen Inhalt gekennzeichnet, es ist in einer vergrößerten Darstellung also genau zu erkennen, welche Datenobjekte welche Inhalte in die jeweiligen System bringen oder aus den Systemen gelesen werden.

3.4.2. Prozess-/Datenfluss-Darstellung
Die Prozessdarstellung mit allen Datenflüssen, IT-Systemen und Datenobjekten auf einer Seite ist ein gewaltig großes Bild, bietet aber für alle Beteiligten, z.B. Projektleiter oder Process Owner, ein verständliches und vollständiges Bild. Die Verantwortlichkeiten sind dabei über Swimlanes dargestellt. Dies bedeutet, dass auch Verantwortlichkeitswechsel in den Datenflüssen erkennbar sind. Nachfolgend wird ein leicht verfremdeter Ausschnitt des riesigen Bildes dargestellt, um die Systematik zu zeigen, in der pro Prozessschritt die Datenobjekte und die IT-Systeme modelliert wurden.

4. Auswertungen
Neben der vollständigen und übersichtlichen Darstellung der Datenflüsse in ihrem Zusammenwirken war die Analyse der gesammelten Informationen ein zentrales Ziel. Mit den Ergebnissen kann die Steuerung der Prozesse und damit in Summe des gesamten Unternehmens verbessert werden. Bereits während der Aufnahme der Daten wurden Auffälligkeiten notiert. Am Ende des Projektes wurden in einem Workshop weitere Erkenntnisse aus der Dokumentation erarbeitet.
Die Liste der Auffälligkeiten wurde kategorisiert und priorisiert. Auf diese Weise ergaben sich klare Handlungsfelder und in diesen klare Empfehlungen für Sofort-Maßnahmen zur Verbesserung der Durchgängigkeit, etc. Es wurden 127 Auffälligkeiten dokumentiert, die wie folgt strukturiert wurden:

Obwohl es sich um eine IT-orientierte Dokumentation handelt, waren die meisten Auffälligkeiten Prozess-Schwachstellen. Beispiel: Arbeitsgänge werden erst am Ende der Schicht vom Schichtführer im MES-System bzw. ERP-System zurückgemeldet; dadurch stehen Informationen über den Fortschritt der Fertigungsaufträge nicht real-time zur Verfügung und eine Steuerung des Prozesses wird deutlich erschwert.
In einem weiteren Beispiel wurde festgestellt, dass keine aktive Nutzung der Maschinendaten erfolgte, damit auch keine echte „Big Data-Anwendung“ möglich ist wie z.B. Predictive Maintenance. Das Projekt hat die Aufbereitung und Verwendung dieser Sensordaten allerdings initiiert. Zukünftig werden Daten gesammelt und sowohl zur Steuerung der bestehenden Prozesse, als auch zur Gestaltung neuer Prozesse verwendet.
Ein Beispiel für neue Prozesse wäre eine andere Art der Qualitätsprüfung. Aufgrund von vielfältigen Sensordaten wie Temperatur, Druck, Ausschussteile, etc. könnte ‚in-Process‘ die Qualität des Produkte geprüft werden bzw. entschieden werden, ob eine manuelle Prüfung erforderlich ist. Dies würde den gesamten Fertigungsprozess drastisch verkürzen und deutlich kostengünstiger machen.

Weitere Auswertungsfragen, die sich aufgrund der Datenattribute und Prozesszuordnung durch einfache Auswertungen beantworten lassen, sind:
- Welcher Prozess erzeugt/nutzt welche Daten?
- Welches IT-System wird in welchem Prozess genutzt?
- Welches System hält welche Masterdaten?
- In welchen anderen Systemen werden diese Daten noch verwendet?
- Welche Daten liegen auf welchem Server?
- Wo werden Stammdaten erzeugt?
- Welche Daten werden offiziell archiviert?
- …
Diese Auswertungen sind sowohl aus den ARIS-Modellen heraus möglich als auch aus der Excel-Datei mit den aufgenommenen Detail-Informationen. Die Auswertungen erlauben Aussagen in diverse Richtungen und unterstützen so die Unternehmenssteuerung und die Prozessoptimierung.
5. Vorbereitung der Automatisierungsprojekte
Ein wesentliches Ziel war die Unterstützung der anstehenden IT-Projekte, um die Performance des gesamten Unternehmens stetig zu verbessern. So wurden die Analyse-Ergebnisse den Leitern der verschiedenen ‚Business-getriebenen‘ Projekte zur Verfügung gestellt. Darüber hinaus ergaben sich aus den Ergebnissen der Datenfluss-Analysen Anregungen für weitere Projekte.
Business-getriebene Projekte, z.B.
- Process Mining
- Material Management
- Projektmanagement für flexible Teams
Datenfluss-getriebene Projekte, z.B.
- Workflow-Management
- Reduzierung/Harmonisierung der IT-Tools
- Verbesserung der Steuerung, u.a. mit Qlik Sense
- Predictive Analytics zur Verbesserung der Forecast-Qualität
- Verwendung der Maschinendaten für Predictive Maintenance, etc.
Weitere Vorschläge für Verbesserungen aus der Schwachstellen-Analyse heraus waren z.B.:
- Elektronische Archivierung und Suche statt Papier-Archivierung
- Automatisierung von Standard-Reports
- Intensive Nutzung von Maschinensensordaten
- Anbindung von strategischen Partnern an die eigenen Systeme
- Automatisierung der Auftragsrückmeldungen
- Mehr SAP-Automatisierung
- Wiki-Einsatz für Erfahrungsdatenbanken statt Excel-Tabellen
Die Ergebnisse der Daten-Analyse haben somit Fragestellungen aus verschiedenen Bereichen beantwortet, z.B. Fragen von IT-Projekten:
- Liegen alle (Log-)Daten vor, die für das Process Mining erforderlich sind?
- Sind die Datenströme erkennbar, die vom neuen Feinplanungssystem für die Fertigung verwendet werden?
- …
Fragen des IT-Bereichs:
- Sind redundante Datenablagen erkennbar?
- Können Datenströme vereinfacht werden (z.B. Zugriff auf gemeinsame Datenbasis)?
- …
Fragen des Industrial Engineering-Bereichs:
- Gibt es Use-Cases im Industrie 4.0-Szenario, die abgedeckt werden sollen? Das könnten sein…
- Condition Monitoring (machine conditions, …)
- Quality Monitoring (process compliance, product quality, …)
- …
Fragen der Process-Owner:
- Gibt es Hinweise auf Prozess-Schwachstellen? Maßnahmen daraus könnten betreffen:
- Qualitätsverbesserung (Pünktlichkeit, Anzahl Fehler, …)
- Beschleunigung (Reduzierung Liegezeiten/Bearbeitungsz.)
- Steigerung Wertschöpfung (mehr Durchsatz/Umsatz)
- Kostensenkung (Prozesskosten, Qualitätskosten, …)
- Welche Schwachstellen sind in den Datenflüssen selbst aufgefallen, z.B. bezüglich
- Medienbrüche
- Inkonsistenzen (Formate, Detaillierungsgrad)
- Schnittstellenprobleme
- Intransparenz (Messgröße, Auswertung)
Eine überschlägige Bewertung der identifizierten Verbesserungsmaßnahmen hat ergeben, dass die Kosten des Projektes in sehr kurzer Zeit amortisiert werden können. Zudem verbessern die generell die Wettbewerbssituation des Unternehmens durch eine höhere Transparenz und damit Reaktionsfähigkeit für Prozessanpassungen.
6. Aufwand für das Projekt
Das Projekt hat insgesamt einen Aufwand von rd. 60 Personentage verursacht. Darin sind nicht berücksichtigt die Zeiten der Gesprächspartner, die jeweils mal eine oder zwei Stunden investiert haben, um Fragen zum Prozess oder zum IT-System zu beantworten. Mit diesem Aufwand wurde eine Transparenz geschaffen, die…
- in den anstehenden IT-Projekten eine deutliche Arbeitsersparnis und eine verkürzte Realisierungszeit bringen wird,
- Risiken des Betriebsablaufs offenlegt und zumindest potenziell Störungen in den Prozessen bis hin zu Produktionsstillständen vermeidet und
- zu der Vielzahl von gefundenen Handlungsfeldern konkrete Maßnahmen initiiert, durch die signifikante Reduzierungen des Arbeitsaufwands und der Prozesslaufzeiten erwartet werden.
7. Fazit
Der Aufwand war groß, wird sich jedoch in kurzer Zeit amortisieren und darüber hinaus nicht-finanzielle Faktoren wie die Transparenz, die Flexibilität, die Durchgängigkeit und die Zusammenarbeit positiv beeinflusst. Es wurde eine Basis für eine Steuerung der (digitalen) Prozesse geschaffen, sowohl für die Process Owner als auch für die Controller. Die so geschaffene Basis ermöglicht weitere Digitalisierungen, ohne konkrete neue Basisarbeiten zu investieren.
Die vielfältigen Erkenntnisse aus diesem Projekt waren im Vorfeld nicht erwartet worden. So bildet die Datenfluss-Datenbasis auch Erkenntnisse für die Optimierung der IT-Systemlandschaft durch Harmonisierungen und Eliminieren von IT-Risiken durch individuelle Excel-Dateien.



OPEX Training & Consulting GmbH