Industrielle Automatisierung hat sich verändert
Die Ziele der Automatisierung haben sich verändert. Es geht nicht mehr darum, wie noch in der industriellen Massenproduktion, viele gleichartige Produkte möglichst günstig herzustellen. Vielmehr liegt der Schwerpunkt auf Flexibilität und Qualität. Das Ziel von Industrie 4.0 ist seit Langem die individualisierbare Produktion von geringen Stückzahlen bis hin zur Einzelanfertigungen (Losgröße 1), die mit den Kosten der Massenprodukten mithalten können.
Um dieses Ziel zu erreichen, werden Systeme über Abteilungsgrenzen hinweg digitalisiert, vernetzt und automatisiert. Je stärker die Vernetzung voranschreitet, desto komplexer werden Prozesse und Automatisierung. Immer häufiger müssen Anpassungen und Änderungen vorgenommen werden, um zum Beispiel die Produktion an neue Produktvarianten anzupassen, zu optimieren oder Geschäftsentscheidungen umzusetzen. Ein digitales System kontinuierlich weiterzuentwickeln und aktuelle Versionen in Betrieb zu nehmen, ist in DevOps als Continuous Delivery (CD) bekannt.
Flexibilität durch häufige Anpassbarkeit
Continuous Delivery ist eines der Ziele von Softwareunternehmen, wenn DevOps zum Einsatz kommt. DevOps ist ein Oberbegriff für Werte, Prinzipien, Methoden und Technologien, um häufige Änderungen an komplexen Systemen durchzuführen und in Betrieb zu nehmen.
Ein weiteres Ziel von DevOps ist es, kundenzentriertes Arbeiten zu ermöglichen. Dabei stehen die Kunden im Mittelpunkt. Entscheidungen werden daran gemessen, ob aus der Sicht der Kunden das beste Ergebnis erreicht wird.
Aber wie begann alles? Durch den Einsatz agiler Methoden in der Softwareentwicklung (Dev) entstanden Aktualisierungen in immer kürzeren Abständen. Die Inbetriebnahme erfolgte durch die IT-Operations (Ops) Abteilungen im Unternehmen, die jedoch nicht auf so viele Updates eingestellt waren. Der so entstandene Konflikt wurde durch die enge Zusammenarbeit von Softwareentwicklung und IT-Operations gelöst und DevOps war geboren. Heute hilft DevOps dabei, gigantische, hochkomplexe Softwaresysteme zu entwickeln und täglich hunderte von Änderungen durchzuführen.
Industrie 4.0, Smart Factory und Industrial DevOps
Auf dem Weg der fertigenden und verarbeitenden Industrie zur Smart Factory und einer agilen Produktion sind ähnliche Probleme zu lösen. Die in DevOps bereits existierenden und erprobten Methoden und Techniken können auf die Industrie übertragen und sinnvoll ergänzt werden. Hier kommen zum Beispiel Schlüsseltechnologien wie das Internet der Dinge (IoT), Sensorik und Cyber-physische Systemen ins Spiel. Weitere Lösungen der digitalen Transformation wie Cloud Computing, künstliche Intelligenz, agile Methoden und Big Data werden im DevOps-Ansatz bereits seit Jahren genutzt.
Wie schon bei Banken, Versicherungen oder im Einzelhandel führt der verstärkte Einsatz von Software auch in produzierenden Unternehmen zu einer grundlegenden Veränderung. Sie entwickeln sich zu Softwareunternehmen mit Produktionsanlagen. Es scheint daher nur logisch zu sein, auch hier die erprobten Methoden der Softwareunternehmen zu nutzen. Der DevOps-Ansatz in der fertigenden und verarbeitenden Industrie wird Industrial DevOps genannt.
Die spezielle Herausforderung liegt in der Verschmelzung von physischer Welt, also den Maschinen und Produktionsanlagen und der digitalen Welt der Software. Fachkräfte verfügen über das Wissen und die Fähigkeiten ihres Arbeitsbereichs, sind aber in der Regel keine ProgrammiererInnen. ProgrammiererInnen können auf der anderen Seite keine Experten für jeden Fachbereich sein. So entsteht ein hoher Bedarf, Anforderungen zu kommunizieren, was Zeit kostet und so zu Lasten der Flexibilität geht. Die aktuell diskutierte Lösung für dieses Dilemma ist eine neue Art von ProgrammiererInnen, die in ihrem Fachbereich zu Hause sind und eigenständig mit No-Code oder Low-Code Prozesse automatisieren und anpassen können. ProgrammiererInnen werden dadurch nicht überflüssig, allerdings kommen sie nicht mehr bei jeder Anpassung benötigt.
Eine neue Art ProgrammiererInnen
No-Code ermöglicht es Fachkräften ohne Programmierkenntnisse mittels einer grafischen Benutzeroberfläche (GUI) Prozesse als Teil ihrer täglichen Arbeit zu automatisieren und anzupassen. Diese sogenannten Citizen Developer bringen das Wissen ihres Fachbereichs mit. Sie können am besten entscheiden, was benötigt wird. Die oft langwierige Kommunikation mit IT und Softwareentwicklung entfällt. So wird die Zeit zwischen dem Erkennen eines Bedarfs und der Umsetzung einer Lösung drastisch reduziert. Die Flexibilität steigt, weil Änderungen im Tagesgeschäft durchgeführt werden können. Die kleinen zielgerichteten Änderungen sind mit einem geringeren Risiko verbunden als große Projekte. Funktioniert eine Änderung nicht wie gewünscht, kann sie einfach zurückgenommen werden. Die Vorteile von No-Code liegen auf der Hand. Dennoch müssen auch die Schwierigkeiten und die Kritik in mögliche Entscheidungen einbezogen werden.
Kritik an No-Code und Low-Code
Programmieren ist mehr als nur funktionierende Lösungen zu entwickeln. Es geht auch darum, dass das gesamte System langfristig, pflegbar und erweiterbar bleibt. In der Softwareentwicklung spricht man von Qualität. Beispiele für schlechte Qualität sind:
- zu komplizierte Lösungen
- fehlende Dokumentation
- schlechte Lesbarkeit (schwer zu verstehen)
- unnötige Funktionen
- Abhängigkeiten, wo keine sein sollten
No-Code und Low-Code stehen in der Kritik, weil bei der Anwendung in der Regel keine effektiven Methoden zur Sicherung der Qualität von Lösungen zum Einsatz kommen. Das kann zur Degenerierung des gesamten Systems führen und geht zu Lasten von Pflegbarkeit, Erweiterbarkeit und schließlich auch der Betriebssicherheit.
Qualität ist ebenfalls ein Ziel von DevOps und damit auch von Industrial DevOps. Klare und dennoch flexible, modulare Strukturen bilden die Grundlage für Qualität. Kollaboration, also die Zusammenarbeit im Team und über Teamgrenzen hinaus ist ein wichtiger Faktor. Solide Prozesse, um Veränderungen schnell umzusetzen und dabei die Qualität der Lösung sicherzustellen, bringen alles zusammen.
Für No-Code-Plattformen bedeutet das, genau diese Qualitätsfaktoren mit entsprechenden Funktionen zu unterstützen.
No-Code, Modulare Strukturen und Kollaboration
Die Team-Workspaces der No-Code-Plattform titan sind Arbeitsbereiche, die zum Beispiel für den jeweiligen Fachbereich angepasst werden können. Das Team sieht nur, was für die Automatisierung der eigenen Prozesse benötigt wird. So entsteht ein Modul, das von den FachexpertInnen der Domäne, dem jeweiligen Fachbereich, autonom verwaltet wird. Für eine Kommunikation mit anderen Fachbereichen oder Anwendungen im Netzwerk (Tools) werden klare Schnittstellen festgelegt. Natürlich müssen dabei im Sinne von DevOps die betroffenen Fachbereiche eng zusammenarbeiten. Vergleichbar ist ein Team-Workspace mit den aus der Softwaretechnik bekannten Microservices. Das sind skalierbare Module, die über festgelegte Schnittstellen im System miteinander kommunizieren und für die jeweils ein Team explizit die Verantwortung übernimmt. So entsteht ein digitales Abbild der Organisationsstruktur des Unternehmens.
Kognitive Belastung und Conways Gesetz
Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design produzieren, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.
Ein System ist zum Beispiel ein komplexes Produkt, wie eine Softwarelösung, eine Maschine oder ein technisches Gerät. Die Produktionsumgebung oder die vernetzte IT-Infrastruktur eines Unternehmens sind ebenfalls Beispiele für Systeme.
Matthew Skelton und Manuel Pais zeigen in ihrem Buch Team Topologies, wie die Organisation der Teams im Unternehmen und technische Lösungen voneinander abhängen. Dieses als Conways Gesetz bekannte Phänomen kann effektiv genutzt werden, um die kognitive Belastung der Menschen im Unternehmen zu senken. Wird Conways Gesetz nicht berücksichtigt, sondern stattdessen, Organisation und technisches System unabhängig voneinander zu betrachtet, kommt es zu Workarounds und sinkender Qualität der Lösungen. In Team Topologies und DevOps wird das Unternehmen als soziotechnisches System betrachtet. Menschen, Organisationsstrukturen und Kommunikationswege (von Angesicht zu Angesicht oder auf technischem Weg) fließen in die Betrachtung ein. So werden alle Aspekte erfasst. Betrachtet man nur das eine oder das andere, ist man auf einem Auge blind und übersieht Chancen und Probleme. Anzeichen dafür, dass Conways Gesetz nicht ausreichend beachtet wird, sind:
- hohe mentale Belastung der Teams
- zu viele unterschiedliche Aufgaben zur gleichen Zeit
- häufige Reorganisation der Teams und Prozesse
- sinkende Motivation
- häufige, unvorhergesehene Störungen des Ablaufs
Fazit
Die kontinuierliche Lieferung neuer und verbesserter digitaler Prozesse ist kein Projekt, sondern ein Unternehmensziel. Natürlich ist die Kultur ein wichtiger Faktor auf dem Weg zum Ziel, allerdings nicht der einzige. Unternehmensweite Vernetzung, ohne dabei die eigentlich angestrebte Flexibilität durch sinkende Qualität zu verlieren, bedarf einer modularen Architektur, die sich an der Struktur des Unternehmens selbst orientiert. Damit der Kundennutzen im Zentrum der unternehmerischen Tätigkeit stehen kann, darf die Technologie keine Hindernisse aufbauen. Sie muss Teil der täglichen Arbeit sein und darf als solche nicht negativ auffallen.
Modulare Architekturen helfen dabei, zu skalieren, neue Technologien zu adaptieren, neue Geschäftsfelder zu digitalisieren und sichere Schritte in Richtung einer agileren Produktion zu gehen. Mögliche Hindernisse und Risiken lassen sich so besser erkennen und vermeiden.
Fachkräfte in Abteilungen zu befähigen, ohne die Hilfe von IT-Experten Prozesse zu automatisieren und regelmäßig anzupassen, mag wie ein Paradigmenwechsel erscheinen. In DevOps und in der Organisation moderner, erfolgreicher Unternehmen ist die Autonomie fachlicher Teams jedoch der Weg zu besseren Entscheidungen, schnelleren Reaktionen und mehr Toleranz gegenüber unvorhergesehenen Ereignissen (Resilienz). Der Grund dafür ist die Nähe der Fachkräfte zu den dafür nötigen Informationen.