Momentan befinden sich viele Unternehmen des produzierenden Gewerbes in der gleichen Situation, wie die IT vor 15 Jahren. Daher richten viele Unternehmen ihr Interesse auf die Projektmethoden der IT. Scrum ist diesbezüglich sicherlich die bekannteste Methode. Allerdings ist dem Autor in der OT-Welt kein einziges Unternehmen bekannt, bei dem eine Umstellung auf Scrum sofort vollständig vorgenommen wurde. Die Firmen entschieden sich immer dazu, schrittweise einzelne Teile davon umzusetzen. Die Begründung: Das Team will versuchen auf agilere Methoden umzustellen, um sich die lange Planung am Anfang zu sparen und damit schneller mit der Umsetzung beginnen zu können, das Management besteht allerdings auf einem festen Fertigstellungstermin, fixem Funktionsumfang und der Verfügbarkeit von Support.

Das Problem ist, dass man entweder agil arbeitet oder nicht. Ein halb-agil gibt es nicht, denn agile Projekte basieren auf vielen Techniken und Methoden, die alle ihre Daseinsberechtigung haben. Lässt man einige davon weg, funktioniert das ganze Konzept nicht mehr.

Typischer Sprint, wenn Tasks hinzugefügt werden.

© Christofer Dutz /Timecho Europe GmbH

Die Schwierigkeit dabei ist: Eigentlich wird eine Sprint-Planung durchgeführt, um genau zu planen, was das Team im kommenden Sprint umsetzen soll. Danach wird der Sprint eingefroren und das Team kann sich auf die Umsetzung konzentrieren. Das Hinzufügen von Aufgaben in einen laufenden Sprint gilt als »Todsünde«. Das Scrum-Mittel um mit kurzfristig auftretenden gravierenden Problemen umzugehen, ist es den aktuellen Sprint abzubrechen und einen neuen zu planen und diesen dann zu starten. Das übliche Mittel für nicht so dringende Änderungen wäre, die Punkte in den nächsten Sprint einzuplanen. Nun gibt es immer Begründungen, warum Tasks hinzugefügt werden müssen. In der Regel heißt es: »Die Anlage steht, wir müssen jetzt sofort die Probleme beheben.« Eine Begründung, die durchaus nachvollziehbar ist und die grundsätzliche Problematik aufzeigt, nämlich dass Scrum für diese Aufgabe eventuell die falsche Methodik ist. In Anwendungsfeldern wie dem Support eignet sich Scrum generell nicht. Hier bieten sich andere agile Methodiken wie beispielsweise Kanban viel eher an. Andererseits hat Kanban durchaus große Schwächen im klassischen Projektgeschäft.

Ein Lösungsansatz, der sich in solchen Fällen anbietet, ist der, zwei Projekte durch ein Team gleichzeitig durchführen zu lassen – die Produktentwicklung mittels Scrum, den Support mit Kanban. Die Projektmitarbeiter sind teilweise gleichzeitig in beiden Projekten aktiv und werden anhand ihrer üblichen Auslastung prozentual dem jeweiligen Projekt zugeordnet. Wenn also ein Kollege üblicherweise zwei Tage pro Woche im Support arbeitet, so wird dieser mit 40 % in das Kanban Support-Projekt eingeplant und mit 60 % im Scrum-Projekt. So hat das Entwicklungsprojekt eine gewisse Planbarkeit, ohne dabei Stillstände der Anlage befürchten zu müssen.

Automatisierte Tests und Simulation

© Christofer Dutz /Timecho Europe GmbH

Beim Thema Testen ist der Rückstand der Automatisierungs-auf die IT-Welt mit Abstand am größten – die OT hinkt schätzungsweise 15 bis 20 Jahre hinterher. Das Hauptproblem der OT: Man ist meist auf echte Hardware angewiesen; teils müssen Anlagen zunächst gebaut werden. Auch haben die Tool-Hersteller – also die großen Automatisierer – bis vor sehr kurzer Zeit noch »geschlafen« und es gibt schlichtweg keine etablierten Tools zum automatisierten Testen und Simulieren von Anlagen. So ist dem Autor keine Engineering-Umgebung bekannt, bei der »Testen« ein fundamentaler Bestandteil ist. Es gibt zwar Ansätze, die rudimentäres Testen erlauben, allerdings ist deren Reifegrad üblicherweise noch sehr weit entfernt von dem der Lösungen der IT-Welt, bei der Testen einer der wichtigsten Säulen der Qualitätssicherung ist und sich dies vor allem in den Entwicklungstools und der Anzahl der verfügbaren Werkzeuge widerspiegelt.

Hier tut sich aktuell zwar schon einiges und es gibt erste Lösungen, bei denen eine simulierte SPS mit einer simulierten Anlage getestet werden können, allerdings noch nicht im Einsatz. Eines der wohl häufigsten Argumente lautet: Für Testen haben wir jetzt keine Zeit, kein Geld, oder beides.

Eine häufig gemachte Erfahrung in der Praxis: Mit viel Glück lässt sich mal eine SPS erkämpfen, die sich zum Testen nutzen lässt. Allerdings sind diese dann auch immer die ersten Geräte, die den Projekteuren weggenommen werden, wenn es Lieferprobleme bei der Hardware gibt und diese somit anderswo dringender benötigt werden. Eine solche Priorisierung verdeutlicht schon den Stellenwert des Testens in der Welt der Automatisierung. Es ist immer noch so, dass üblicherweise immer am Echtsystem getestet wird; im Idealfall fest eingeplant während eines Shutdowns oder als Teil der Inbetriebnahme, leider oftmals aber auch im laufenden Betrieb am Wochenende, wenn die Anlage nicht dauerhaft in Betrieb ist. Funktioniert etwas nicht wie geplant, so kostet dies durchaus den einen oder anderen Feierabend oder gar das Wochenende, das für das Aufspüren und Beheben von Problemen nötig ist, damit die Produktion wieder anfahren kann.

Die Nutzung der Cloud

© Christofer Dutz /Timecho Europe GmbH

Ein weiterer Trend, der aktuell von der IT in die Welt der Automation schwappt, ist der Drang in die Cloud zu migrieren. Das betrifft allerdings nicht alle Teilaspekte der Automatisierung betrifft. Oft ist inzwischen die Rede von Cloud-MES oder von Cloud-SPSen. In der Praxis zu sehen sind solche Konzepte bislang allerdings nicht. Speicher- und Rechenkapazität sind in der Cloud zwar beide theoretisch nahezu unbeschränkt verfügbar, aber durchaus nicht kostenfrei. Dennoch wirkt eine solche Lösung für manchen Anwender verlockend. Vermutlich, weil das Skillset, das Mitarbeiter für den Betrieb eines lokalen Big-Data und Machine-Learning Clusters mitbringen müssten, im Unternehmen schlichtweg nicht vorhanden ist. Bei der Cloud-Nutzung gibt es mehrere Kostenfaktoren zu beachten, die anders als bei klassischer Datenverarbeitung durchaus wichtig sind:

• Kosten der Internet- beziehungsweise Cloud-Verbindung: Nicht selten, gilt es Initiativen früh abzublocken, die alle Produktionsdaten in die Cloud bringen wollen. Grund ist eine simple Rechnung, die aufzeigt, dass es oftmals gar nicht möglich wäre die dazu nötige Internet-Anbindung bereit zu stellen, beziehungsweise die Kosten hierfür unverhältnismäßig hoch wären.
• Kosten für die Speicherung und den Betrieb: Mietet ein Unternehmen bei egal welchem Cloud-Anbieter einen Rechner und betreibt diesen zu 100% der Zeit, so wird dies immer teurer sein, als würde der gleiche Rechner lokal betrieben werden. Einzige Ausnahmen sind vermutlich Virtual Server, bei denen mehrere virtuelle Server sich die Kapazität eines echten Servers teilen. Hier können die Unternehmen mit der Cloud Geld sparen, da sie sich die Beschaffung und den Aufbau von speziell geschultem Personal sparen können.
• Transferkosten: Üblicherweise verlangen Cloud-Anbieter Geld für die Übertragung von Daten. Arbeitet ein Unternehmen viel mit seinen Daten, so steigen auch die Transfer-Kosten. Was viele allerdings vergessen ist, dass je länger ein Unternehmen Daten in die Speicher eines Cloud-Anbieter pumpt, desto teurer wird es, den Provider zu wechseln. Sollte sich das Unternehmen in der Zukunft dazu entscheiden den Anbieter zu wechseln, dann kann dies unter Umständen sehr teuer werden. Wie sich dies in Zukunft entwickelt, gilt es zu beobachten: gerade vor wenigen Wochen hat Google mit dem Marketing-Coup für Schlagzeilen gesorgt, dass die Transferkosten für den Cloud-Transfer abgeschafft seien.

Momentan ist in der Welt der IT zu beobachten, dass einigen Unternehmen ihre Cloud-Kosten über den Kopf gestiegen sind und sie dabei sind, ihre Rechenzentren in die Unternehmen zurückzuholen. Auch gibt es mittlerweile IT-Dienstleister, die sich darauf spezialisieren, die Cloud-Kosten für Unternehmen zu optimieren. Aber auch Aktionen wie die von Microsoft sorgen dafür, dass sich Firmen die Cloud-Thematik genau ansehen: So hat vor einigen Wochen Microsofts Abkündigung ihres Azure IoT Central Angebotes einige Firmen durchaus unvorbereitet getroffen. Zuerst sah es so aus, als wenn diese nun gezwungen gewesen wären, innerhalb von zwei Monaten einen essenziellen Teil ihrer Lösungen neu entwickeln zu müssen. In diesem Fall hat Microsoft wohl zurückgerudert und die offizielle Ankündigung als Falschmeldung bezeichnet. Allerdings hat dies vielen Unternehmen aufgezeigt, wie abhängig diese von den Cloud-Anbietern geworden sind. Daher ist es immer empfehlenswert darauf zu achten, dass man sich nicht zu sehr von dem Angebot eines Cloud-Anbieters abhängig macht. Nur dann kann man flexibel in solchen Situationen reagieren. Dass also auch in der Automation eine gewisse Cloud-Ernüchterung einsetzen wird und die Speicherung und Verarbeitung von Daten durchaus wieder zumindest teilweise ihren Weg ins Unternehmen zurückfinden werden, ist abzusehen.

Die Konsequenz

Die Umwälzungen, die momentan die Welt der Automation bewegen, sind meist nichts Neues, andere Branchen – insbesondere die IT – haben sie größtenteils schon hinter sich. Leider sind derzeit vielfach Automatisierungsprojekte zu sehen, die genau die gleichen Fehler machen, die wir in der IT schon vor Jahren beobachten konnten. Die Automation könnte also von einer anderen Branche lernen – sie muss dies nur tun. Zwei Beispiele:

Thema Agilität: Um teure und langwierige Fehler zu vermeiden, empfiehlt sich vielfach, dass sich die Verantwortlichen eingehend mit der Vielzahl an Optionen auseinandersetzen. Hier bieten sich IT-Consultants an: Deren sinnvoller Beitrag könnte sein, auf Basis der aktuellen Situation im Unternehmen eine maßgeschneiderte Lösung zu erarbeiten und passende Schulungen anzubieten.

Der Autor: Christofer Dutz ist Solutions Consulting Expert bei Timecho Europe.

© Timecho Europe GmbH

Thema Testen: Hier existiert viel Aufholbedarf. Zunächst wäre es wichtig, dass die Hersteller von Automatisierungsgeräten entsprechende Lösungen anbieten. Eine Alternative könnte, wie in der Welt der IT auch, Open-Source sein. Allerdings müsste diesbezüglich die Industrie selbst mehr Initiative zeigen. Open-Source bietet verschiedenste Möglichkeiten, um selbst mit Konkurrenten zusammen an Lösungen zu arbeiten, von denen alle profitieren und die für ein Unternehmen allein nicht zu stemmen wären.