A business request machine (part 1)
State machines are gaining a lot of traction in the IT world, but how about business? In business, we have exactly the same challenges as we have in IT:
- we have long-running processes;
- we tend to start from scratch when developing them;
- they are always pretty sequential until they aren’t anymore;
- there might be events that overturn everything;
- issues or insights will lead to new process versions that we might want to retrofit to existing cases, or only apply to new ones;
- we might want to hide implementation details to certain stakeholders to not confuse them;
- etc.
What are you going to do? Cram things into a BPMN engine? Buy another best-of-breed case management tool? Maybe code it from scratch and manually try to keep the documentation in sync? If state machines and state charts are a visual representation that I can discuss with my business audience and automate quite easily, it certainly captures my attention.
Consider the following request machine
It can be used for a customer onboarding flow, service request, expense reimbursement, pretty much anything involving essentially three actors: a requestor, an approver and a back-office.
Each rectangle is a state and the machine can only be in one state at a time. The input, approval and fulfillment states of this request machine will probably be pretty exhaustive as they are essentially stages.
The cancelled, rejected and completed states are final states. Once the machine enters these states, the lifecycle is complete.
Because we have stages and final states, we are able to draw a general arrow of time below the machine, and have made some provisions to go back to an earlier stage. If we would be modelling a traffic light, this would not be possible. Then we would have an eternal alternation between red, yellow and green.
If you can think of additional states, they will probably fit under one of the existing states. We could nest these states inside an existing state, essentially turning the visual into a state chart.
The machine will only transition from one state to another if an event happens (an arrow). Although not explicitly depicted in the diagram, in reality we will want to layer on specific criteria for whether the transition is allowed to take place.
So as a consultant, I already feel pretty confident presenting this machine to a business audience to accelerate my understanding of some request flow without scaring them with BPMN or anything else, and that should be the purpose.
Automating this might be as simple as displaying a form for each state and moving the events to an action bar at the top so they can be triggered. All in all this is a decent foundation for automation.
What you might notice is that this model is actor-agnostic. We don’t have swimlanes like we have in BPMN. There might be a customer or an employee involved in the request, maybe line management or a due diligence department in the approval, and some back-office department for the fulfillment, all depending on the exact nature of the request.
The same goes for the exact implementation of the stages, things that need to run in parallel, etc. Let’s see how we can layer that on at a later point in time.
Hope you found this little article useful, enjoy your week!
