By chance I stumbled over the blog post Draw your daily routine if you want to learn about workflow diagramming from Zsofia Herendi. She did a great post on how hard it actually is to understand real-life processes — and that drawing diagrams helps.
The real thinking behind was that I really want to show you that creating workflow diagrams is a very useful thing and can help you oversee everything basically. […] Every single time I’ve faced with any problem at work throughout this past 15 years it helped me a lot to start drawing.
When I saw this diagram, I immediately started to post-process it in my mind:
Daily routine workflow from medium.com/@zsofideaz/draw-your-daily-routine-if-you-want-to-learn-about-workflow-diagramming-7827077b768c
This is a habit I developed working on process automation/workflow engine projects. This diagram is a great prototype of typical requirements you get in the context of process automation projects.
In order to make this workflow executable, you basically need to:
- Clarify the scope of automation.
- Separate decision rules from control flow.
- Model the workflow in an executable notation.
Let’s do this exercise quickly in this post (if for nothing else, you can learn how my brain works 😉).
Scope of automation
Let’s imagine you need to build an application supporting the daily routine (OK, maybe even I wouldn’t automate my daily routine, but let’s assume it for the sake of the argument).
This is most possibly not about the automation of the tasks itself, so no dog walking robot and no WIFI-enabled automated coffee machine. It is much more about the automation of the control flow, hence a workflow engine could steer the workflow, letting participants know what happens next. In this case, the only participant is you (and probably your spouse).
That means a workflow engine will probably get your alarm set at the right time automatically, and use a slack-bot to chat with you about what you should do next:
RoutineBot: “Hey, it is later this morning. Get up and get the dog out for a short walk please.”
You: “Done”
RoutineBot: “Great. Thanks! Dog seems to be happy. Now please feed the dog.”
You get the idea. Workflow engines nowadays really often hide behind a user interface that is not the classical task list people think about when they hear ‘workflow engine’. I know real-life projects actually using a slack-bot. So the scope of automation is the control flow, the sequence of tasks, not the tasks itself.
Separate decision logic from process logic
Now, an even more interesting aspect. As soon as I read the diagram, I immediately saw that it was hard to understand because it mixes decision logic (which days constitute a workday?) with process logic (what happens on workdays?).
You can use the DMN standard to express rules in a decision table. I quickly drafted this table:
The beauty of this table is that it is directly executable. You could even use online simulators to type in required input and get a result back.
There are different ways of designing that table. You could even split it up into multiple tables. You could decide it should contain more information (like the drinks you want to have) or less. The table structure typically settles after a round of discussion and implementing a first runnable prototype.
Either way, the rules are now separated from the process flow. They are clearly expressed in one place. If they are wrong, you can easily adjust them. If, for example, you feel like changing the drinks for Tuesday only, it is easy to do. And as soon as you captured that new rule in the decision table, you can simply deploy it. The rules do scale. In this case they might be rolled out to your spouse too, and you do not even have to talk to them! (OK, I exaggerate).
This also simplifies the workflow diagram, as we will see shortly.
Model the workflow in an executable notation
Now there is the point where I don’t agree with Zsofia:
Shapes are just shapes.
Don’t stress too much about using the right shape that UML prescribes for us. You can use anything with what you can best express your thoughts. Also, simpler and more generic shapes are available everywhere, you don’t need specific flow charting products for it.
I am much in favor of having a standardized notation, a lingua franca of processes and workflows, which is the ISO standard BPMN. BPMN diagrams are still easy to read, as they only contain boxes and arrows. But the semantics are clearly defined and the notation can be executed directly on a workflow engine.
But I agree with Zsofia, that this should not stand in the way of getting started, so it can be a second step after an initial business analysis. Still, a business analyst should know these tools, to be able to prepare a process diagram for automation.
The resulting process might look like this:
I could more or less directly execute this on a workflow engine, I simply would need to program the Slack-bot integration. Unfortunately, I have to continue writing my book and exhausted my procrastination time for today.
Conclusion
I hope you could see that:
- Extracting rules as a decision table makes the rules more explicit and simplifies the process.
- Using BPMN can help to create a more readable diagram, for example because there are clear semantics around activities and events, concepts mixed up in typical visio charts, making people think too much.
- Everything can be automated easily 😊
- BPMN and DMN are executable models that foster business IT collaboration.
But now I really need to go back to work.
Bernd’s book – Practical Process Automation – will be available for early access around September. In the meantime, some of our Camundi shared their favourite ‘everyday automation’ diagrams:
Here’s Developer Advocate Niall Deehan’s morning routine:
And Consultant Nele Uhlemann’s Cheese Fondue:
Got an interesting ‘everyday automation’ diagram? Share it with us on Twitter – we love seeing what you’re automating with BPMN!
Start modelling business process workflows using BPMN
