On Business Process Flows

Another project we had this year that we feel like blogging about had to do with business process flows. It is easy to understand that businesses have processes and the more efficient they can execute them, the better their performance. There are different measures to improve processes, like more efficient communication or the introduction of automation. An interesting technology that is aimed at bringing all of those features to the table are business process flows and this year we got to do a proof of concept project with a client comparing two different technologies: Microsofts Power Platform process flows and SAPs Build. The goal is to take one of our clients processes (they picked a good one) and implement it in those two techs, showcasing the pros and cons, ultimately allowing the client to make a tech decision. 

Business Process Flow by midjourney

Without going into too much detail, the process has to do with changing a component in a product that our client produces. This comes up quite regularly and involves various steps including:

• stakeholders filling out forms
• updating excel sheets
• emailing/informing other stakeholders
• updating database tables (SAP)
• asking/waiting for approvals

There's a few points in the process where depending on the situation different decisions are being made and the entire process includes employees from different departments and external suppliers. 

A solution in Power Automate can contain various elements, like apps (i.e. user interfaces), process flows, cloud flows, data tables and even agents/chatbots.

First let's start with the power platform solution. As with everything power platform, you start by creating an environment and a solution. The solution contains everything you build. In our case that is a business process and an app. These two represent two views on the process, one is for the process developer and the other is for the users who interact with the process. 

A process flow for a product change process. Note how the stages are following a linear path, one after the other. If multiple actions are supposed to happen simultaneously the are to be implemented as actions within one stage. The actual stages in this screenshot are placeholders.

The process is modeled as a linear sequence of stages, with the ability to add if/else conditional branches. Every kind of parallelism is to be modeled within the stages. Stages contain so called data steps, which can include forms where users insert information, as well as cloud flow automations, which can be triggered in a stage. We've written about cloud flows before, and they bring all the power that Power Automate has to offer, from sending emails, asking for approval all the way to having robots interact with websites on user's behalf. What's most interesting about the Microsoft solution compared to the SAP, is it's approach, the first thing you do is setting up the data tables, that the flow and its different stages are interacting with. We'd describe it as a data first approach. 

A cloud flow that is manually triggered from within the business process flow. If a condition is met, it creates an approval request, which is sent via email to the intended receiver.

Next let's describe the SAP build solution. It comes with a sleek user interface that will feel familiar to everyone used to working with SAP. When creating a process you start by building the flow graph. Adding parallel branches feels more direct, also it goes from top to bottom, where the power solution goes from left to right. Unsurprisingly it brings very much the same features, like data forms, automations or approvals. Data can be inserted directly into SAP, where with the power platform you'd first have it be in a data table and then have a cloud flow copy it into SAP using a connector. 

Inbox of current tasks assigned to a user from SAP build. In this example, all the tasks are about entering data into a form.

When starting the project we were given a list of requirements the client expects, and we find both solutions fullfill them. Many differences come down to personal taste, ie. people used to working with SAP will find it's solution more intuitive where people used to excel, might find the power one more natural. We therefore believe that the question over which solution is a better fit strongly depends on both the processes that are to be modeled and the users that are to be using it. Additional features, like the option to add assisting chatbots to the process, (I.e. powers copilot) can be appealing, if it e.g. aligns with the organizations strategy towards chatbots as a whole.

The project is still on going and we are eager to see what our client ends up going with.