An independently managed company of Siemens AG, Siemens Mobility has been a leading provider of transport solutions for over 160 years while developing its portfolio constantly through innovation. Its core business comprises rail vehicles, rail automation and electrification solutions, turnkey systems, intelligent road transport technology and related services. Siemens Mobility capitalizes on digitization to enable mobility operators all over the world to make their infrastructure intelligent, ensure sustainable value enhancement over the entire lifecycle, improve passenger comfort, and guarantee operational availability.
This official message notwithstanding, we wanted to know more precisely how Siemens Mobility is also digitizing its internal processes, so we asked Benjamin Bock specifically about the business benefits of Robot Process Automation (RPA) at Siemens Mobility.
Benjamin Bock is Head of Digital Transformation and Automation at Siemens Mobility GmbH: Upon earning a degree in business information technology, he worked as a management consultant at KPMG, primarily in IT and process optimization in finance, for more than five years. He then joined Siemens AG in the strategic area of Global Share Programmes, where he managed several teams. Since the end of 2017, Benjamin has been responsible for Robotic Process Automation at Siemens Mobility GmbH. He supports the 38,000 or so employees worldwide with more than 300 locally and virtually robotized processes (Image: Siemens Mobility).
Siemens AG is world-renowned, of course. But how does mobility fit in place?
Siemens AG has the core areas of Digital Industries, Smart Infrastructure and Siemens Mobility. In addition, there are various majority and minority holdings.
Siemens Mobility provides solutions for everything to do with trains, trams, commuter railways, high-speed trains such as the ICE 3 and ICE 4, but also rail infrastructure such as rails and interlockings. It also comprises road traffic technology such as traffic lights, as well as new technologies in eHighway or hydrogen propulsion, to name just a few.
How did you end up at RPA?
RPA was launched a good three years ago with a project in Brazil, where someone had developed software robots independently. We took this up and analysed processes that correspond to an RPA robot, i.e. monotonous, repetitive, high frequency, many items, rule-based.
Engineering services from different projects with different hourly rates, for instance, still had to be transferred manually from a cost centre to the individual projects without RPA, according to the scenario: Book €10 from cost centre A to project B in SAP. This is highly repetitive and requires no cognitive excellence, so it was an ideal process for Robotics, which is still in use today. We have accordingly scaled it to other plants such as the one in Mumbai since. This robot was so scalable and flexible from the outset, that we can now roll it out in several countries with almost no changes.
Can a robot like this be used from one software to another? For example, can an Excel spreadsheet be connected to a SAP application?
Absolutely. In fact, that is our most frequently occurring use case. Two thirds of all our processes run with SAP in some form. The essential advantage of RPA is that the software operates the computer like a human being. I just have to tell the robot what to do in which case, analogous to if-then rules. A robot can thus do anything a human does, as long as I can describe it.
How difficult is it to set up this human-robot? Could I learn it in 24 hours? Or do I have to undergo six months of training?
That depends on what kind of robot it will be in the end. I am pretty sure that you could learn a happy path robot, i.e. a robot that does not include exceptions or errors, in less than 24 hours.
The UiPath platform has two development environments: the regular Studio, and the Studio X. The latter is for people without an IT or programming background. I am sure that you can learn and implement in half a day an application like: “Read data from Excel, enter it into a website, take feedback from the website, write it back to Excel.”
We moreover have business processes that have to run very reliably. We therefore need extremely stable robots for highly important and relevant business processes. An IT background is required in order to build such robots. I need non-invasive programming to that end. I no longer tell the robot: “Click here or click there,” but: “If you clicked there, are you really at the place where you wanted to be? If so, then click on the next field, but only then.”
So we have two use cases for RPA: Individual users can automate what they do in their limited environment with RPA; but when it comes to large, value-added business processes, then much more needs to be considered, up to and including compliance rules. For example, how do I deal with financial data, information security? with data protection? This is professionally programmed and goes through a quality gate and User Acceptance Test (UAT): The end user checks whether the robot is doing exactly what it is supposed to do – and nothing else. It is then lifted into a production environment, where it can no longer be touched. The developer has no access to the programme code either from then and can thus not change it any longer.
These are the two areas we have: Once more in the Citizen Developer area, where colleagues automate their own processes. They are relatively free there, because they can step in at any time in case of doubt and carry out the process manually again themselves. A more extensive development must be run through for large, cross-departmental, valuable processes however, but this guarantees significantly more security and stability. It can also generate large savings. If I still have to keep a human on hand in case the robot doesn’t work, however, I cannot generate such large savings.
Are there other examples besides Excel?
In our own environment, it’s mostly about things like: get different reports from SAP, download them, put them together in Excel, prepare them, and transfer them to a business intelligence (BI) solution such as Qlick, Tableau, or Power BI from Microsoft; or send them to a manager or colleague in the process chain via Excel.
And monthly and weekly reports? For repetitive work processes that have to be performed obstinately over and over again?
Yes, ideally even daily. This is automated by the colleagues themselves, by anyone with an affinity for computers, who need not have a degree in computer science.
In the other category, we have only computer scientists who can develop in a “real” programming language such as Java or C#.
How are these processes embedded in the organization? And what role do you play in them?
We have a community approach. We do not aim to build an RPA centre to take over the robotization of all processes worldwide. For we would then virtually take the processes away from our colleagues on site, carry them out in our company, and they would never learn how it is done with RPA themselves. They might then come to have less trust in RPA. And we would lose them on the way to digitization. This community approach is therefore important for us, so that employees can learn and apply it themselves as widely as possible within the company. This is the only way we can take all employees with us on the journey to digitization. We have over 500 employees in the extended community who are actively interested in this topic. We have set up 40 local teams in 16 countries that are actively developing robots themselves for themselves and their colleagues in the immediate vicinity.
How many RPA processes do you have?
About 350 worldwide.
Are these robots running in a cloud at UiPath, or in an on-premise environment at Siemens?
For security reasons, they are exclusively in an on-premise environment, in a secure data centre where our SAP systems are also located. We don’t have anything at all in the cloud — not from UiPath, and not from anyone else. So UiPath cannot see what we use their software for either. We have also had our IT experts check the RPA software to see whether any information is leaking. We have used network sniffing to check what is being sent and where. The only question, in fact, is whether the robot is using a valid license key. No other information is sent to UiPath. Our RPA robots run with the same high level of security as our SAP systems.
How many robots are related to SAP programmes?
About two thirds.
Does everyone involved in RPA participate voluntarily? I noticed a real RPA fan club on your LinkedIn page.
Yes, fortunately. We don’t force anyone to automate their process. It’s all driven by intrinsic motivation from the community. We were initially concerned that the concept of Robot Process Automation would fan fears that employees would be replaced by a robot. We therefore prefer to talk about FLoW, which stands for Fast Leveraging of Workflows, because we don’t want the term robot to feature prominently in the foreground. However, we find that employees have no fears, but are rather grateful to be relieved from the repetitive and monotonous tasks in their work thanks to RPA, so that they can concentrate on more interesting, creative and value-adding activities.
What does the future look like? Are 350 processes just the beginning of a big movement? Or is the RPA market already saturated in your company?
There is great potential as before. Most robots have hitherto been created at the request and initiative of employees themselves. This will change somewhat because we have now also built up central capacity and experience to approach the organization systematically.
There have been no information campaigns in internal newsletters up to now. We want to push that more in the future. There is still a lot of potential in the application fields. Furthermore, the topic will also continue to develop on the technological front. Machine learning and artificial intelligence will also help in programming robots in the future, i.e. robots will watch how humans make decisions in various situations and then, given a certain degree of certainty, will make such decisions themselves. This does not remove humans from the overall process, who would still check and verify the overall process in the end. No matter how many robots are used, humans will always remain in charge, and can never put the blame for any errors on a robot.
Where do you fall under in the organization? Traditional IT or rather the CFO? Would both be conceivable?
We are more of a staff unit in the CFO environment. In other words, we don’t report to IT. That was a very conscious decision. But we work very closely with IT of course.
And what is the much larger rest of Siemens doing in terms of RPA?
The Siemens Digital Industries and Smart Infrastructure divisions are driving RPA with an approach very similar to ours.
Will we get a robot for every person in the future?
It is still too early for that. We are nonetheless looking into the matter to gauge whether, and if so, when the time is right.
Benjamin Bock was one of the speakers during the UiPath Reboot Work Festival
