< back to Expert Forum overview
The third BPM Expert Forum took place on July 6, 2021, with Stefanie Rinderle-Ma and Bernd Rücker.
1: What’s the difference between BPMS and developer friendly process automation?
[Bernd] BPMS (Business Process Management Suite) is a tool invented some years ago that typically favoured a low code approach to process automation. These suites were also typically relative complex suites driven by big vendors. These BPMS are typically aliens for software developers, so for example, they cannot use normal version control systems (like GitHub), they invent their own testing or deployment system and thus lock customers out of a best practice CI/CD pipeline.
Because of these problems, the brand “BPM” also suffered amongst software developers over the years. This is why I favour to talk about “developer-friendly process automation technology” or simply “workflow engines” and mean lightweight technology that can be used within the environment of a software developer using all their best practices (e.g. for automated testing, versioning or deployment). In other words: Using a workflow engine must be as simple as using any other library or e.g. a database.
2: Why did you develop a new process orchestration engine - what is different with this one to existent workflow engines?
[Steffi] The manufacturing orchestration engine centurio.work has been developed on basis of the open source process execution engine CPEE (cpee.org). The CPEE has been used in many projects reflected by around 500.000 downloads for the engine and related components . This way we can implement research findings and also requirements that come from our industry partners, e.g., manufacturing-specific extensions such as OPC-UA handlerwrapper.
3: What do you think about to model RPA process using BPMN, as RPA vendors are not doing it? Maybe OMG should provide some guidelines and some artefacts to complete it in order to engage to these vendors?
[Steffi] This is a good idea as processes can be modeled at different levels of granularity and BPMN-based-modeling, in our experience, results in understandability (at different granularity levels). For machining tasks, for example, we also use sub processes modeled in BPMN that describe the steps of the machining task at a rather fine-granular level.
[Bernd] I agree that BPMN as a language would also make sense for RPA flows. But RPA flows are also rather low level as they automate one task at hand (and this is one premise I find very important). Given this, the audience for an RPA flow is smaller than for typical business processes, making it probably a bit less of a problem.
4: Great presentation! We do work for more than 4 years with BPMS and RPA. For us, latter is a tactical tool we apply only if no APIs are available. From an ROI point of view generally BPMS beats RPA (esp. long term). However, is my observation correct that RPA vendors developing their products to be more BPMS like and on the other hand BPMS vendors are acquiring RPA vendors? Do we see a convergence of BPMS and RPA products?
[Steffi] As RPA is done at the task level, from the BPMSs side, these tasks can be treated as tasks in the BPMS-enabled process, either by invoking the RPA tool or as sub process that is run by the BPMSs itself. Vice versa, I am not sure whether and how orchestration can be done via RPA, i.e., via the UI.
[Bernd] First of all, I agree with the observation around ROI. I also see that RPA vendors invest into “long running execution” of RPA flows, making it possible to also automate business processes on these platforms. But you can see that the RPA tooling is not targeted at that use case (e.g. scalability/performance around persistence, operations tooling, not applying BPMN, …) making this a pretty poor choice at the moment. So there is a clear separation of the categories around DPA (Digital Process Automation), RPA and e.g. Process Mining. But I do indeed expect some movement in the process automation market long term
5: What’s mean that RPA like a pain killer? can explain it more to us.
[Bernd] I wrote about this also here: https://blog.bernd-ruecker.com/how-to-benefit-from-robotic-process-automation-rpa-9edc04430afa. In essence: RPA can provide relative quick benefits (“relief”) for an immediate problem. But typically, this cures the symptoms, not the root problem. Increased maintenance effort leads to technical debt with RPA (https://camunda.com/blog/2020/09/three-hidden-threats-of-rpa-technical-debt-you-might-have-overlooked/) that can cause severe trouble in the long run.
When you have concrete back pain – pain killers might be OK – but you also need to think about the long term cure (apply for the gym now and go exercising regularly).
6: What should we call RPA? Bot-based task automation? UI-based task automation?
[Steffi] Explicitly referring to the task-level would be precise. Bot and UI-based - both fits :)
[Bernd] If it would be a green-field, I would love to see “UI-based task automation”. But as RPA is settled as a term we simply have to live with it and educate about the shortcomings to manage expectations.
7: The issue is that we have to compare engines to clarify when to use BPMS, RPA or Process Mining, but the most important issue is that there is an umbrella as Business Process Management as discipline which cover different methodologies to provide an answer to BPM Lifecycle.
[Bernd] This is the nature of umbrella disciplines. Whenever you want to apply them in real-life, you have to select tools and decide what to do exactly. I actually don’t see a problem in this by design.
I also want to add, that this is “the BPM view” on the world. You could also have a “software development” or “microservices” view on the world – where some BPM techniques are simply one aspect in a bigger software development puzzle. This viewpoint is also valid – and I am not sure if a discussion about the general importance of BPM as a discipline helps us further – instead we should focus on concrete procedures and tools that solve concrete real-life problems. But this might be my pragmatic nature talking here 😊
8: I see RPA as a way of automating tasks or sub-processes within processes (e.g. in the sense of a robotic task next to manual or (fully) automated tasks). Would you also see it the other way around in any scenario? That is, there is BPMS automation with an RPA process. Gist of the question: Does one subsume the other conceptually?
[Steffi] See answer to 4.
[Bernd] I definitely see the “orchestration process” in the lead, as this does implement the process, hence controlling for example the sequence of steps. RPA automates one task in such a process. This is also what we found at customers, like for example Deutsche Telekom: https://blog.bernd-ruecker.com/process-automation-in-harmony-with-rpa-720effdb0513
9: What’s missing to enable “economies of speed” for process automation? In our DevOps book, we talk about speeding up deployment to production without sacrificing quality. Do we understand all of the following well enough for process automation?
[Bernd] I think the technology is all there. If we look at our customer, for example, they do use the workflow engine in the context of normal DevOps practices. They write automated test cases and run CI/CD pipelines. Camunda supports that very well and fits into these practices. Of course, there is always room for improvement, but generally I don’t think we lack technical capabilities. But we see a lot of people not being aware of the importance of DevOps for these economies of speed when it comes to process automation. So I think it is much more an awareness/traction problem.
Stefanie Rinderle-Ma is a full professor at the Department of Informatics, Technical University of Munich, Germany, where she holds the Chair of Information Systems and Business Process Management. Before Stefanie worked as full professor at the University of Vienna, Austria. Stefanie’s research interests include flexible and distributed process technology, digitalized compliance management, as well as process and production intelligence. The goal is to enable and accelerate digitalization and automation through processes and at the same time keep the human in the loop. Application areas comprise production, logistics, and medicine.
Process orientation and automation are key to digital transformation across industries. Both, RPA and BPMSs aim at process automation, but from different angles. RPA is an “outside-in” approach [ABH18] and typically suited for simple and repetitive tasks where user interactions with the UI are replaced by software. BPMSs implement and execute process logic “from scratch”, mostly based on process models. The following questions can be raised:
[AHB18] W.M.P. van der Aalst, M. Bichler, A. Heinzl: Robotic Process Automation. BISE 60:269-272 (2018)
I am a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. I contributed to various open-source workflow engines for more than 15 years and I’m the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. I am the author of “Practical Process Automation” and co-author of “Real-Life BPMN”. Additionally, I am a regular speaker at conferences around the world and a frequent contributor to several technology publications. I focus on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.
Process automation covers a variety of use cases. Depending on the nature of the process it calls for different software solutions, like RPA, low-code tooling, or orchestration via workflow engines. All have their pros- and cons and it is vital to understand them to sketch your own architecture and tool stack. For example, RPA in reality is task automation. And while low-code tools have their merits, it can be dangerous to be bypass software development for certain processes that would require pro-code approaches – as this can lead to malicious cycles of developer shortages. In recent customer projects I work with what I call “the process automation map” to classify processes and map them to sweet spots of different tool categories. This allows you to see that RPA is one piece in the overall process automation puzzle, while workflow engines are another. Having said this, we should think twice about using the term BPMS, as this is too often connected to inflexible tools that were stuck-in-the-middle between low-code and pro-code.