Digitale Planungs- und Steuerungsprozesse in der Fertigung? Klar, agil und vollständig integriert! E in Kunde trug die Anforderung an uns heran, ihn bei der durchgängigen Gestaltung und vollständigen Digitalisierung der Planungs- und Steuerungsprozesse in der Komponentenfertigung zu unterstützen. Gleichzeitig sollte die in einem großen Produktlebenszyklus-Management-System (PLM-System) implementierte Planung der Fertigung flexibilisiert werden. Änderungen in der Fertigung sollten zurückgemeldet und in der Planung zukünftiger Fertigungsprojekte berücksichtigt werden können. Trotz der Flexibilisierung sollte der Prozess so implementiert werden, dass er zu einer Entlastung des Personals führt und bei steigender Variantenvielfalt effizientere Planungszyklen ermöglicht. Die Herausforderung Auf der Basis dieser Anforderung konnten wir die folgenden Ansatzpunkte für eine Optimierung der Prozessdigitalisierung identifizieren: > Die Daten zur Fertigungsplanung befinden sich in verteilten Systemen. Innerhalb der Fertigungssteuerung werden zwar Messdaten erhoben, bislang aber nur partiell am Ort der M essung genutzt; sie sind daher auch nur dort verfügbar. > Der Fertigungsplanungsprozess ist nicht durchgängig – vom Fertigungsauftrag über die Fertigungsfreigabe, Bereitstellung bis hin zur Änderungsrückmeldung nach Start der Fertigung – definiert und implementiert. > Eine zentrale Steuerungseinheit, in der – ähnlich dem menschlichen Gehirn – die über die Sensoren (Sinnesorgane) aufgenommenen externen Informationen (Reize) via Datenkanäle (sensorische Neuronen) zusammenkommen, auf Basis von Kontext und Erfahrung über eine Reaktion entschieden wird und diese wiederum über Datenkanäle (Motoneurone) an die ausfüh- 10 Detecon Management Report dmr • 2 / 2015 renden Ressourcen (Muskelzellen) zur Ausführung kommuniziert wird, ist in der Fertigungssteuerung nicht vorhanden. Die Lösung Für eine vollständige und durchgängige Digitalisierung der Prozesse und der Realisierung von Optimierungspotenzialen fiel zunächst Architekturarbeit an. Im ersten Schritt haben wir in die Prozesse eine Ende-zu-Ende-Betrachtung eingezogen und anschließend für die Implementierung eine Vier-SchichtenArchitektur ausgestaltet. Erst nach Abschluss der Architekturarbeit sind wir in die Ausgestaltung, Automatisierung und Integration der Prozesse eingestiegen. Für die Prozessarbeit haben wir das subjektorientierte Business Process Management (S-BPM) verwendet und eine Tool-Suite eingesetzt, die S-BPM in der Modellierung und Implementierung von Prozessen unterstützt. Ende-zu-Ende-Betrachtung im Prozess Zur Strukturierung und Reduzierung der Prozesskomplexität haben wir in einem ersten Schritt die Ende-zu-Ende-Betrachtung in die Prozessarchitektur unseres Kunden eingefügt. Auf diese Weise wurde ein Prozessmonolith in sechs Prozesse z erlegt. Für jeden Prozess wurde der funktionale Umfang definiert und eindeutig von anderen abgegrenzt. Die Ende-zu-EndeBetrachtung ist darüber hinaus ein Ansatz zur vollständigen und konsistenten Identifizierung notwendiger Geschäftsobjekte und deren Lebenszyklus. Jeder Prozess hat nun einen dedizierten Auslöser, über den er gestartet wird. Gleichzeitig wird sowohl das Geschäftsobjekt identifiziert, das notwendiger Eingang für den Prozess ist, als auch das Geschäftsobjekt, welches in dem Prozess bearbeitet und am Ende der Prozessdurchführung als Ausgabe zur Verfügung gestellt wird. Aus dieser Betrachtung lassen sich später wichtige fachliche Status für die Spezifizierung des Lebenszyklus eines Geschäftsobjekts ableiten und somit Haltepunkte Eine Säule zur Gestaltung der digitalen Transformation ist die Prozessdigitalisierung im Sinne einer durchgängigen, vollständigen Automatisierung und Integration der Prozesse. Einblicke in ein Kundenprojekt zeigen, wie die Umsetzung funktioniert. für die Prozessmessung und Prozesssteuerung erkennen. Die Ende-zu-Ende-Betrachtung des Prozesses ergab die in Abbildung 1 dargestellte übersichtliche Struktur. Aus der Ende-zu-Ende-Betrachtung des Prozesses ergaben sich unter anderem die folgenden Geschäftsobjekte mit entsprechenden relevanten, fachlichen Definitionen: Der Planungsauftrag geht über E-Mail als strukturierte Excel-Datei oder strukturiertes Word-Dokument ein. Für jeden Planungsauftrag wird auf Basis eines entsprechenden Masterplans die Planung erstellt und abgestimmt, bis die Planungsfreigabe durch das zentrale Steuerungsgremium erteilt werden kann. Mit der Planungsfreigabe startet die Festlegung und Spezifikation der Komponenten, die eingekauft werden sollen. Nach abgestimmter Spezifikation wird die Einkaufsfreigabe für den Einkauf der Komponenten erteilt. In Folge der Einkaufsfreigabe wird entlang der Terminpläne die Komponentenbereitstellung überwacht. Wenn die Komponentenbereitstellung sichergestellt ist, wird der Zusammenbau von Komponenten aus der Eigenfertigung und der Fremdfertigung erprobt, bis der Fertigungsstart zu 100% festgelegt werden kann. Nach Fertigungsstart werden alle Änderungen im Fertigungsablauf an die Planung als Änderungsrückmeldung kommuniziert. Jede Änderungsrückmeldung wird analysiert, um die Ursachen für die jeweilige Änderung zu identifizieren. Im Falle von systematischen Änderungen wird eine notwendige Planungsänderung spezifiziert und als Masterplananpassung in zukünftigen Planungen berücksichtigt. Architekturbild für die Prozessdigitalisierung Im nächsten Schritt haben wir auf Basis dieser übersichtlichen Ende-zu-Ende-Betrachtung die Prozessarchitektur um weitere Schichten ergänzt. Es entstand eine Architektur aus vier Schichten. Für die durchgängige und vollständige Prozessdigitalisierung wurde die Prozesslogik in einer eigenen Schicht gekapselt. Auf diese Weise konnte der Prozess für die geforderte Prozessdigitalisierung von den Restriktionen bestehender Schnittstellen zwischen den Bestandssystemen entkoppelt werden. In der Prozessschicht befindet sich der Prozess mit den fachlichen Prozessfunktionen und der Prozesslogik. Der Prozess ist subjektorientiert ausgeprägt. Die fachlichen Prozessfunktionen werden Abbildung 1: Das Ende-zu-Ende der Prozesse 1 Planungsauftrag bis Planungsfreigabe 2 Planungsfreigabe bis Einkaufsfreigabe 3 Einkaufsfreigabe bis Komponentenbereitstellung 4 Komponentenbereitstellung bis Fertigungsstart 5 Fertigungsstart bis Änderungsrückmeldung 6 Änderungsrückmeldung bis Masterplananpassung Quelle: Detecon 11 Detecon Management Report dmr • 2 / 2015 als internes Verhalten eines Subjektes, also des Prozessbeteiligten, ausgeführt. Bei der Prozessausführung werden sie über ihre Kommunikationsbeziehung, also den Austausch von Nachrichten, synchronisiert. Die Prozesslogik wird in einer Workflow-Engine implementiert. Jede Prozessfunktion wird entweder als manuelle Tätigkeit oder automatisch durch einen Webservice-Aufruf oder mehrere fachlich zusammenhängende Webservice-Aufrufe implementiert. In der Prozessschicht werden somit die für eine vollständige und durchgängige Digitalisierung notwendigen Services entlang der Prozesslogik fachlich orchestriert und mit den manuellen Tätigkeiten zusammengebracht. ausgeprägten Ablagestruktur wird die eindeutige Abgrenzung, die Wiederauffindbarkeit und damit eine möglichst hohe Wiederverwendbarkeit der Services ermöglicht. In Abbildung 2 ist ein Ausschnitt des hierdurch entstandenen Service-Repositoriums abgebildet. Auf die Einbindung eines Enterprise Service Bus (ESB) haben wir zur Umsetzung der Integrationsschicht verzichtet, da die vom ESB angebotenen, hoch standardisierten Services aus fachlicher Sicht nicht den Anforderungen des Prozesses genügten. In der Datenschicht liegen die Datenobjekte. Die Datenobjekte wurden fachlich abgegrenzt und überschneidungsfrei den zur Prozessausführung benötigten fachlichen Fähigkeiten zugeordnet. Dabei wurde gleichzeitig jedem Datenobjekt ein System zugeordnet, dass die Create-, Read-, Update-, Delete-Funktionen für das Datenobjekt übernimmt. Auf diese Weise wurde auch die Verantwortung für die Datenpflege eindeutig und überschneidungsfrei definiert. Die redundante Pflege der Daten sowie die notwendige Validierung und Konsolidierung der Daten im Rahmen der Prozessausführung konnten so auf ein Minimum reduziert werden. Als zentrales datentragendes System wurde das vorhandene Standard-PLM-System erhalten. Dies sicherte die Investitionen in das PLM-System. Der Anteil notwendiger Änderungen wird in der Zukunft zu einem sehr viel größeren Anteil mit den Standards des PLM-Systems abgedeckt. Auf- In der Integrationsschicht liegen die Services zur Automatisierung des Prozesses und zur Integration der Fertigungsressourcen, datentragenden Systeme und Bestandssysteme. Die Services werden über Service-Aufrufe aus der Prozessschicht in den Prozess eingebunden. Die Ablagestruktur der Services ist entlang der zur Prozessausführung benötigten fachlichen Fähigkeiten ausgeprägt. Im vorliegenden Fall handelt es sich um die Fähigkeiten, die unser Kunde zur Planung und Steuerung seiner Fertigungsabläufe benötigt. Diese fachlichen Fähigkeiten haben wir mit dem Kunden definiert, unabhängig von dem aktuellen Aufbau der Fertigung, der aktuell betriebenen IT-Systemlandschaft und den implementierten Prozessen. Mit der nach fachlichen Fähigkeiten Abbildung 2: Architekturbild für die Prozessdigitalisierung Exem p laris Prozesslayer Planung Fertigungsplan erstellen Integrationslayer Losgrößen ermitteln PDM Maschine ansteuern ERP Quelle: Detecon 12 Material transportieren Fertigung Planabweichung analysieren Datenschicht Infrastrukturlayer der Fertigung Materialmanagement Material identifizieren Detecon Management Report dmr • Special Automotive 2015 PLM cher Fertigungsschritt durchführen MES Aus sc hnit t wände für notwendige kundenindividuelle Änderungen an dem PLM-System konnten durch die Verlagerung der Umsetzung in die Prozessschicht signifikant reduziert werden. In der Infrastrukturschicht liegen die Fertigungsressourcen. Für jede Ressource werden Funktionen definiert, welche diese zum Aufruf über Services in der Integrationsschicht bereitstellen. Die Fertigungssteuerung kann Änderungen beispielsweise zur Optimierung oder Fehlerbehebung an den von der Ressource erbrachten Funktionen vornehmen. Dadurch, dass diese nun via Services „veröffentlicht“ werden, sind im Rahmen einer ServiceÄnderungsdokumentation oder Release-Dokumentation solche Veränderungen für die Prozessbeteiligten transparent. Kleinere Veränderungen werden im Rahmen einer neuen Revision dokumentiert. Wirken sich solche Änderungen auf die Kompatibilität zu Eingangs- und Ausgangsgrößen aus, wird eine neue Nebenversion veröffentlicht und in der Integrationsschicht als verbesserte Alternative bereitgestellt. Größere Änderungen, die auch Änderungen an der Schnittstellendefinition mit sich führen, werden in einer neuen Hauptversion veröffentlicht. Über die Verbindung mit der Prozessschicht wird sichtbar, welche Version in welchem Prozess genutzt wird. Damit ist die Grundlage für Gespräche zwischen Disponenten, Steuerern und ITlern über den zukünftigen Einsatz und die Weiterentwicklung der von den Fertigungsressourcen bereitgestellten Funktionen geschaffen. Subjektorientierte Ausgestaltung der Prozesse In der Prozessschicht haben wir die Prozesse subjektorientiert ausgeprägt und eine Workflow-Engine verwendet, die es ermöglicht, aus den Prozessmodellen die Prozessapplikation zur Implementierung der Prozesslogik zu generieren. Und dieser Aspekt ist zu betonen: Für die Implementierung der Prozesslogik muss nicht mehr programmiert werden, denn die Applikation wird aus den Modellen generiert. Änderungen an der Prozesslogik verursachen bei unserem Kunden also nur noch Modellierungsaufwand. Änderungen am Prozess sind nur dann mit Entwicklungsaufwand verbunden, wenn die Webservices zur Prozessautomatisierung und Prozessintegration geändert, ergänzt oder neu entwickelt werden müssen. Mit der subjektorientiert ausgeprägten Prozessschicht kann unser Kunde die Änderungszyklen und Änderungsaufwände signifikant reduzieren. Mit dieser Prozessschicht war unser Kunde in der Lage, Änderungen am Prozess flexibel und schnell umzusetzen. Noch während des Projekts hat unser Kunde festgestellt, dass er ein Instrument zur Gestaltung agiler Prozesse an der Hand hat, das ihn bei der Differenzierung im Wettbewerb unterstützt. Bleibt die Frage, ob die Disponenten und Prozessbeteiligten in der Lage sind, diese flexiblen und schnellen Änderungen mitzumachen und ihre tägliche Arbeit darauf einzustellen? Diese Frage konnte unser Kunde mit einem klaren „Ja“ beantworten. Die Begründung für dieses „Ja“ ist so einfach wie die Methode, die wir für die Ausgestaltung der Prozesse in der Prozessschicht verwendet haben. Die Disponenten aus der Fertigungsplanung und -steuerung haben ihre Prozesse und damit notwendige Änderungen selbst gestaltet und modelliert. Die selbst gestaltete Prozesslogik und Zusammenarbeit im Prozess konnte unmittelbar nach der Modellierung in einer Prozessapplikation erlebt und angefasst werden. Kritische Erfolgsfaktoren in der Prozessdigitalisierung Die Anwendung des S-BPM Ansatzes wirkte sich insbesondere auf folgende kritische Erfolgsfaktoren in der P rozessdigitalisierung positiv aus. Verwendung und Akzeptanz der Modellierungssprache bei den Fachanwendern Nur fünf Modellierungssymbole in Kombination mit der natürlichen Sprache sprechen eine eindeutige Sprache. Die Disponenten haben sofort verstanden, wie die Modellierung funktioniert. Ein besonderes Aha-Erlebnis hatten wir, als die Fachanwender gesehen haben, dass die Bezeichnung von Prozessfunktionen und deren Erklärungen nicht nur in den Modellen, sondern eins zu eins auch in ihrer Prozessapplikation zu sehen waren. Dementsprechend dienten die Prozessmodelle nicht nur der Prozessbeschreibung, sondern auch als Handlungsanweisung in der Prozessapplikation. Bereitschaft der Disponenten, sich in Modellierungsworkshops einzubringen Im ersten Workshop haben wir „nur“ über die Kommunikationsbeziehung zwischen den Prozessbeteiligten gesprochen und ermittelt, welche Informationen ausgetauscht werden müssen. Das führte dazu, dass wir kritische Punkte im Zusammenarbeitsmodell zwischen den Prozessbeteiligten aufgegriffen haben. Die Disponenten haben bereits im ersten Workshop festgestellt, 13 Detecon Management Report dmr • Special Automotive 2015 dass Aufgaben in der Realität nicht so verteilt sind, wie sie laut Governance-Modell des Unternehmens verteilt sein sollten. Diese kritischen Punkte haben wir ausdiskutiert, um zu einem verbesserten und gleichzeitig machbaren Prozessablauf in der Organisation unseres Kunden zu kommen. Diese kritisch konstruktive Auseinandersetzung mit den aktuellen Problemen und die leichtverständliche Darstellung einer Lösung mit nur zwei Symbolen (dem Subjekt und der Nachricht), hat jede anfängliche Zurückhaltung auf der Seite der Disponenten verschwinden lassen. Nachhaltige Akzeptanz der Workshop-Ergebnisse und Zusammenspiel mit der IT In den Workshops saßen neben den Vertretern aus Fertigungsplanung und -steuerung von Anfang an auch Vertreter der IT und Fertigungs-IT. Das hatte zunächst nur symbolische Bedeutung, um zu zeigen, dass Fachseite und IT gemeinsam an einem Modell arbeiten. In einer späteren Projektphase, in der zur Veredelung des Prozesses Webservices für die Automatisierung und Integration in den Prozess eingebaut wurden, haben wir gezeigt, dass über die Symbolik hinaus Fachanwender und IT eine Sprache und damit über dasselbe Modell sprechen. Die Disponenten haben unmittelbar erlebt, dass ihre fachlichen Modelle von der IT genutzt und eins zu eins umgesetzt werden. Die Fachanwender haben die Workshop-Ergebnisse als nachhaltig auf der Arbeitsebene verankerte Modelle und als ihre eigenen Prozesse und Applikationen akzeptiert. Management-Support Beim Einsatz von S-BPM haben wir ein Phänomen beobachtet, dass die verbindliche Einbindung des Managements erheblich erleichtert hat: Die Fachanwender haben die gestalteten Prozesse als ihre Prozesse erlebt und festgestellt, dass diese Prozesse eins zu eins in Prozessapplikationen umgesetzt werden. Demzufolge haben die Fachanwender von sich aus versucht, ihr Management von der Richtigkeit und Notwendigkeit der Prozessimplementierung zu überzeugen. Die Fachanwender bei unseren Kunden haben die Rolle des Projekt-Marketings übernommen. In Terminen zur Präsentation von Zwischenergebnissen sind die Fachanwender selbst aufgetreten und haben die P rozessapplikation und ihre Vorteile präsentiert. Die Reaktion des Managements war naheliegend: „Wenn meine Mitarbeiter davon überzeugt sind und mit der Prozessapplikation einen Hebel zur Erreichung unserer Ziele an die Hand bekommen, dann unterstützen wir das.“ Von der ersten Präsentation der Zwischenergebnisse an war das Projekt nicht mehr unser Projekt, das wir als Berater für Abbildung 3: Die Adaption des agilen Scrum-Rhythmus für die subjektorientierte Prozessdigitalisierung Process Increment vi Re ew Daily Scrum Process Release Sprint Backlog Process Backlog Changes Retrospective PO Plann i ng 2 PO Process Vision Quelle: Detecon 14 Detecon Management Report dmr • Special Automotive 2015 Selected Process Backlog 1 Process Owner Release Planning g nin Plan PO Impediment Backlog Process Backlog unseren Kunden durchgeführt haben. Es wurde zum Projekt unseres Kunden, der Mitarbeiter aus dem Fachbereich und der IT, das wir als Berater lediglich begleitet haben. Agile Vorgehensweise im Scrum-Rhythmus Das Projekt wurde im Rhythmus von Scrum aufgesetzt, um die Komplexität handhabbar zu machen. Die Kommunikation zu den Projektergebnissen haben wir entlang des zunehmenden Verständnisses der Fachanwender für ihren Prozess proaktiv gestaltet. Die Prozessreleases haben wir an den Ende-zu-EndeProzessen ausgerichtet und entlang einer zunehmenden Prozessautomatisierung und -integration abgegrenzt. Am Ende eines jeden Sprints wurde im Sprint-Review als Prozessinkrement immer eine Prozessapplikation präsentiert. Die P rozessapplikation wurde von Sprint zu Sprint immer weiter veredelt – mit jedem Sprint ist der Grad der Automatisierung und Integration gestiegen. In Abbildung 3 ist dargestellt, dass alle Prozess-Backlog-Items immer auf die Erstellung und Veränderung einer Prozessapplikation als Prozessinkrement eingezahlt haben. Frank Lorbacher ist Managing Consultant. Er hat über 20 Jahre Erfahrung mit BPM in unterschiedlichen Branchen. Sein Schwerpunkt liegt in der Konzeption und Implementierung agiler Prozesse in serviceorientierten Architekturen. Er ist Experte für die Prozessdigitalisierung und die damit einhergehende Prozesstransformation. Michael Spiller ist Consultant und berät Unternehmen der Automobilbranche in den Bereichen Digitalisierung von Prozessen und Unternehmensarchitekturmanagement. Als zertifizierter Scrum-Master beschäftigt er sich auch mit der agilen Prozessmodellierung und -implementierung. Kontinuierliche Verbesserung ist das Ziel Schnelligkeit und Flexibilität in der Fertigungsplanung und -steuerung erfordern die Integration aller Prozessbeteiligten, der IT, Daten- und Fertigungsressourcen. Informationen sind in Echtzeit zu erheben und unverzüglich den jeweiligen Adressaten bereitzustellen, damit sie Änderungen umgehend nachvollziehen oder selbst anstoßen können. Dies betrifft vor allem die Akteure, die täglich damit arbeiten. Die subjektorientierte Prozessmodellierung gibt den Disponenten die Möglichkeit, ihre Prozesse selbst zu modellieren und ständig anzupassen. Das Modellierungsvorgehen bringt Fachanwender und IT an einen Tisch – Missverständnisse und Kommunikationsprobleme werden signifikant reduziert, Änderungen schnell und für alle transparent nach dem Lego-Prinzip integriert. Alle Beteiligten arbeiten in einem Workflow zusammen, der die involvierten Systeme in einem „Single User Interface“ vereinigt. Die Beteiligten verfügen somit über die für sie relevanten Informationen. Da subjektorientierte Prozessmodellierungstools die ausführbaren Prozessapplikationen direkt aus den Prozessmodellen generieren, sind Änderungen schnell und einfach „live“. Zusammen mit unseren Kunden gestalten wir eine ganzheitliche Fertigungsplanung und erleichtern die Evaluierung sowie die kontinuierliche Verbesserung von Strukturen und Prozessen in der Fertigung. Zitation: Der Artikel basiert auf Lorbacher F. (2015) Designing an Agile Process Layer for Competitiv Differentiation In: Fleischmann A., Schmidt W., Stary Ch., S-BPM in the Wild Practical Value Creation, Spinger Open, S. 97 – 100. 15 Detecon Management Report dmr • Special Automotive 2015
© Copyright 2024 ExpyDoc
