Siemens Mobility ist ein eigenständig geführtes Unternehmen der Siemens AG. Siemens Mobility ist seit über 160 Jahren ein führender Anbieter im Bereich Transportlösungen und entwickelt sein Portfolio durch Innovationen ständig weiter. Zum Kerngeschäft gehören Schienenfahrzeuge, Bahnautomatisierungs- und Elektrifizierungslösungen, schlüsselfertige Systeme, intelligente Straßenverkehrstechnik sowie die dazugehörigen Serviceleistungen. Mit der Digitalisierung ermöglicht Siemens Mobility Mobilitätsbetreibern auf der ganzen Welt, ihre Infrastruktur intelligent zu machen, eine nachhaltige Wertsteigerung über den gesamten Lebenszyklus sicherzustellen, den Fahrgastkomfort zu verbessern sowie Verfügbarkeit zu garantieren.
Soweit die offizielle Message. Wir wollten genauer wissen, wie Siemens Mobility auch seine internen Prozesse digitalisiert und haben Benjamin Bock speziell nach den Business Benefits der Robot Process Automation alias RPA bei Siemens Mobility befragt.
Benjamin Bock ist Head of Digital Transformation and Automation bei der Siemens Mobility GmbH: Er arbeitete nach seinem Studium der Wirtschaftsinformatik über fünf Jahre als Unternehmensberater bei KPMG, vorrangig im Bereich IT- und Prozess-Optimierung im Finanzwesen. Danach wechselte Benjamin zur Siemens AG in den strategischen Bereich der Global Share Programs, wo er mehrere Teams leitete. Seit Ende 2017 ist Benjamin für Robotic Process Automation innerhalb der Siemens Mobility GmbH zuständig und unterstützt die weltweit rund 38.000 Mitarbeiter mit über 300 lokal und virtuell robotisierten Prozessen (Bild: Siemens Mobility).
Die Siemens AG ist ja global bekannt. Aber wie genau ist Mobility dort verankert?
Die Siemens AG hat die Kernbereiche Digital Industry, Smart Infrastructure und Siemens Mobility. Dazu kommen unterschiedliche Mehr- und Minderheitsbeteiligungen.
Siemens Mobility bietet Lösungen für alles rund um Züge, Tram, S-Bahn, High-Speed-Züge, etwa ICE 3 und ICE 4, aber auch Bahninfrastruktur, wie Schienen und Stellwerke. Hinzu gehört auch Straßenverkehrstechnik wie Ampelanlagen, sowie neue Technologien im Bereich eHighway oder Wasserstoffantrieb, um nur einige zu nennen.
Wie seid Ihr auf RPA gekommen?
Angefangen hat RPA vor gut drei Jahren, durch ein Projekt in Brasilien. Dort hat jemand selbstständig Software Robots entwickelt. Wir haben das aufgegriffen und Prozesse analysiert, die einem RPA Robot entsprechen, also Monoton, Repetitiv, hohe Frequenz, viele Items, Regelbasiert.
So etwa mussten Ingenieurs-Leistungen aus unterschiedlichen Projekten mit unterschiedlichen Stundensätzen ohne RPA noch manuell von einer Kostenstelle auf die einzelnen Projekte umgebucht werden. Nach dem Motto: Buche in SAP 10 Euro von der Kostenstelle A auf das Projekt B. Das ist natürlich hoch repetitiv, ohne kognitive Exzellenz zu erfordern, ein idealer Prozess für Robotics, der ist heute noch im Einsatz. Den haben wir derweil auch auf andere Werke skaliert, etwa auf Mumbai. Dieser Robot war von Anfang so skalierbar und flexibel aufgesetzt, dass wir den jetzt fast ohne Änderungen auf mehrere Länder ausrollen können.
Kann man so einen Robot von jeder zu jeder Software verwenden. Könnte man etwa eine Excel-Tabelle mit einer SAP-Applikation verbinden?
Absolut. Das ist sogar unser häufigster Anwendungsfall. Zwei Drittel aller unserer Prozesse laufen in irgendeiner Form mit SAP. Der wesentliche Vorteil von RPA ist, dass die Software den Computer wie ein Mensch bedient. Ich muss dem Robot nur sagen, was er in welchem Fall zu tun hat: Analog zu Wenn-Dann Regeln. Somit kann ein Robot alles tun, was auch ein Mensch tut, solange ich es beschreiben kann.
Wie schwierig ist es, diesen Mensch-Roboter einzurichten? Könnte ich das binnen 24 Stunden lernen? Oder muss ich da sechs Monate auf Schulung gehen?
Das hängt davon ab, was es am Ende für ein Robot werden soll: Ein Happy Path Robot, also ein Roboter, der keine Ausnahmen oder Fehler mit einbezieht, da bin ich mir ziemlich sicher, das könntest Du in weniger als 24 Stunden lernen.
Die Plattform UiPath hat zwei Entwicklungsumgebungen: Das normale Studio, und das Studio X. Letzteres ist für Menschen ohne Informatik- oder Programmier-Hintergrund. Eine Anwendung wie: „Lies Daten aus Excel, trage diese in eine Website ein, nehme Rückmeldung von der Website entgegen, schreibe diese zurück in Excel“ könntest Du in einem halben Tag lernen und umsetzen, da bin ich mir sicher.
Wir haben aber auch Geschäftsprozesse, die sehr zuverlässig laufen müssen. Für hoch wichtige und relevante Geschäftsprozesse brauchen wir extrem stabile Robots. Um diese zu bauen, braucht man auch Informatik-Hintergrund. Dazu brauche ich Non-Invasive Programming. Ich sage dem Roboter dann nicht mehr: „Klicke hier, klicke da, klicke dort“, sondern: „Wenn Du da geklickt hast, bist Du dann auch wirklich an der Stelle, wo Du hin wolltest? Wenn ja, dann klicke auf das nächste Feld, aber nur dann“.
Wir haben also zwei Anwendungsfälle für RPA: Das was der einzelne User in seinem begrenzten Umfeld macht, das kann er mit RPA auch selber automatisieren. Wenn es aber um große, werthaltige Geschäftsprozesse geht, dann muss viel mehr berücksichtigt werden, bis hin zu Compliance Regeln, etwa: Wie gehe ich mit Finanzdaten um, mit Information Security, mit Data Protection: Das wird professionell programmiert, durchläuft einen Quality-Gate und UAT (User Acceptance Test): Da prüft der Endanwender: Macht der Roboter genau das, was er tun soll? Und auch nichts anderes? Danach wird der Robot in eine produktive Umgebung gehoben, und kann dort auch nicht mehr angefasst werden. Auch der Entwickler hat dann keinen Zugriff mehr auf den Programmcode und kann den nicht mehr verändern.
Das sind die zwei Bereiche, die wir haben: Einmal mehr im Bereich Citizen Developer: Da automatisieren die Kollegen ihre eigenen Prozesse. Dort sind die Kollegen relativ frei, weil sie dann im Zweifel auch jederzeit einspringen können, und den Prozess auch wieder händisch selber durchzuführen. Für große, abteilungsübergreifende, werthaltige Prozesse dagegen ist eben ein umfangreicherer Entwicklungsprozess zu durchlaufen, der aber für deutlich mehr Sicherheit und Stabilität bürgt. Daraus lassen sich dann auch große Savings generieren. Wenn ich immer noch einen Menschen vorhalten muss, für den Fall, dass der Roboter nicht funktioniert, kann ich keine so großen Savings generieren.
Gibt es noch weitere Beispiele außer Excel?
Im eigenen Umfeld geht es meist um Dinge wie: Hole Dir aus SAP unterschiedliche Reports, lade diese herunter, füge sie in Excel zusammen, bereite die auf, und übergebe die in eine BI Business Intelligence Lösung, wie etwa Qlick, Tableau, oder Power BI von Microsoft. Oder verschicke Sie per Excel an einen Manager oder Kollegen in der Prozesskette.
Also etwa für Monthly und Weekly Reports? Für repetitive Arbeitsgänge, die immer wieder stur durchgeführt werden müssen?
Ja, idealerweise sogar täglich. Das automatisieren sich die Kollegen selber. Das kriegt jeder Computer-affine Mensch hin, auch ohne Informatik-Studium.
Bei der anderen Kategorie haben wir ausschließlich Informatiker, die in einer „echten“ Programmiersprache wie etwa Java oder C# entwickeln können.
Wie sind diese Prozesse in der Organisation verankert? Und welche Rolle spielst Du darin?
Wir haben einen Community Approach. Unser Ziel ist es nicht, ein RPA-Zentrum aufzubauen, das die Robotisierung aller Prozesse weltweit übernimmt. Denn dann nehmen wir den Kollegen vor Ort ja quasi die Prozesse weg, führen die bei uns aus, und die Kollegen lernen gar nicht selber, wie das mit RPA geht. Dann entwickeln die Kollegen vielleicht auch weniger Vertrauen in RPA. Und wir verlieren sie auf dem Weg der Digitalisierung. Für uns ist deshalb dieser Community Approach wichtig, dass die Mitarbeiter das möglichst breit im Unternehmen selber lernen und selber anwenden können. Nur so können wir die Mitarbeiter auf der Reise in die Digitalisierung alle mitnehmen. Wir haben in der erweiterten Community über 500 Mitarbeiter, die sich aktiv für das Thema interessieren. Wir haben 40 lokale Teams in 16 Ländern gegründet, die aktiv selber Roboter für sich und die Kollegen in der näheren Umgebung entwickeln.
Wie viele RPA-Prozesse habt ihr?
Ungefähr 350 Prozesse, weltweit.
Laufen diese Robots in einer Cloud bei UiPath, oder On Premise bei Siemens?
Aus Sicherheitsgründen ausschließlich On Premise, in einem gesicherten Data Center, wo auch unsere SAP-Systeme stehen. Wir haben gar nichts in der Cloud. Nicht von UiPath, und auch sonst von niemand. UiPath kann auch nicht sehen, wofür wir deren Software verwenden. Wir haben die RPA-Software auch von unseren IT-Experten prüfen lassen, ob irgendwelche Infos nach außen gehen. Wir haben per Network Sniffing geprüft, was wohin verschickt wird: Da wird tatsächlich nur abgefragt, ob der Robot einen gültigen Lizenzkey verwendet, aber sonst gehen da keine weiteren Infos an UiPath raus. Bei uns laufen die RPA-Robots genauso hoch gesichert wie unsere SAP-Systeme.
Wie viele Robots hängen mit SAP-Programmen zusammen?
Ungefähr Zwei Drittel.
Machen bei RPA denn alle Beteiligten freiwillig mit? Ich habe auf Deiner LinkedIn-Seite einen wahren RPA-Fan-Club bemerkt.
Ja, glücklicherweise. Wir zwingen niemand, seinen Prozess zu automatisieren. Das wird alles durch intrinsische Motivation aus der Community getrieben. Wir hatten zunächst die Befürchtung, dass der Begriff Robot Process Automation Ängste erzeugt, dass die Mitarbeiter durch einen Roboter ersetzt werden. Deshalb sprechen wir lieber von FLoW, Fast Leveraging of Work Flows, weil wir den Begriff Roboter nicht so in den Vordergrund rücken wollen. Wir stellen aber fest, dass die Mitarbeiter keine Ängste haben, sondern eher dankbar sind, dass die repetitiven und monotonen Aufgaben dank RPA aus ihrem Arbeitsfeld verschwinden, und sie sich auf interessantere, kreativere und wertschöpfendere Tätigkeiten konzentrieren können.
Wie sieht die Zukunft aus? Sind 350 Prozesse nur der Anfang einer großen Bewegung? Oder ist der RPA-Markt bei Euch intern schon gesättigt?
Das Potenzial ist nach wie vor sehr groß. Die meisten Robots sind bisher auf Wunsch und durch Initiative von Mitarbeitern selbst entstanden. Das wird sich etwas ändern, weil wir jetzt auch zentrale Kapazität und Erfahrung aufgebaut haben, um systematisch auf die Organisation zuzugehen.
Bisher gab es noch keine Informationskampagnen in internen Newslettern. Das wollen wir künftig stärker treiben. Da gibt es noch viel Potential in den Anwendungsfeldern. Außerdem wird sich das Thema auch technologisch weiter entwickeln. In Zukunft wird auch Machine Learning und Artificial Intelligence bei der Programmierung der Robots helfen. Das heißt. Die Roboter werden künftig zuschauen, wie sich der Mensch in diversen Situationen entscheidet, und dann bei einer gewissen Sicherheit diese Entscheidungen selbst vornehmen. Das löst den Menschen trotzdem nicht aus dem Gesamtprozess, sondern er würde dann am Ende immer noch den Gesamtprozess prüfen und verifizieren. Egal wie viele Robots zum Einsatz kommen: Der Mensch bleibt immer in der Verantwortung. Der Mensch kann die Schuld für eventuelle Fehler nie einem Roboter in die Schuhe schieben.
Wo bist Du in der Organisation aufgehängt? In der klassischen IT oder eher beim CFO? Denkbar wäre ja beides?
Wir sind eher eine Stabsstelle im CFO-Umfeld. Also nicht der IT unterstellt, das war eine ganz bewusste Entscheidung. Aber wir arbeiten natürlich sehr eng mit der IT zusammen.
Und was macht der große Rest von Siemens in Sachen RPA?
Die Siemens-Divisionen Digital Industry und Smart Infrastructure treiben RPA in einem sehr ähnlichen Ansatz wie wir.
Werden wir künftig einen Robot for Every Person bekommen?
Dafür ist es noch zu früh. Wir schauen uns das Thema aber natürlich an und prüfen, ob und wenn ja wann der richtige Zeitpunkt dafür ist.
Benjamin Bock war einer der Redner beim UiPath Reboot Work Festival
