Keith Swenson has been writing some great posts on the differences in modeling what he calls "Automator" and "Facilitator" processes. Automators aim to model and control every interaction between systems and potentially also human users. Facilitators on the other hand model at a much higher level, showing the key participants in a process, and the overall flow, but do not need to delve down much beyond this, relying on the underlying system's abilities to assist users.
Keith's post from a week or two back, Human "Facilitator" Processes really lays this concept out well. He shows how a Facilitator process models the interactions between a writer and an editor in the process of preparing an article for publication. Its a two step process that I don't even need a graphical modeling tool to represent:
| O ----> Writer: Write Article ----> Editor: Review Article ----> X |
All in a single line we have represented the key participants and interaction between the writer and editor. According to Keith:
In order to explain this process to a person who was to participate in this, the two nodes would be enough: Betty will write the document, and when completed, George with review the document. Both Betty and George understand their role in the process, and can go about their work.
This only makes sense because most of us (especially Betty and George) understand the process this model is trying to represent. At this level, we don't upset the knowledge workers in the process by limiting their creativity with unnecessary administrative tasks or presuming that we know how to do their jobs better than them. This is the classic 'paving the cowpath' approach to process improvement that really centers on the delivery of work between users (remember the document management workflow world?).
The Automator that Keith talks about focuses on the 'server' and what it does. It deals with the automate-able pieces of the process and just presents work to Betty and George when it can no longer automate. It basically represents the system as an execution / delivery model that saves a developer writing automation code, and relies little on the capabilities of the executing system. If you BPM tool wants to execute at this granular a level, great, but don't expect to benefit from new features it may release in version 6.x without explicitly building them into a process. Do expect to be so restrictive that your users reject the system.
In his most recent post BPMN & Methodology Agnosticism Keith talks about how a modeling standard like BPMN, which is supposed to provide common understanding of process models still implicitly represents much of the underlying capabilities of the system that executes it. This is something that is encoded by the underlying and potentially unwritten methodology of the analysts that designed the process, a methodology that is rightly (I believe) biased towards the available capabilities of the target system.
I like this. It feels like there is a place for me and 'my BPM'. It feels like I don't need to have two steps or 50 steps to represent a business process. If 'my BPM' handles assignments, deadlining, escalation and event handling in a meaningful and flexible way, I don't have to draw this stuff on a model. If some things actually don't fit well in a process but are better represented by other capabilities of my system, even better. As I talked about yesterday in Don't forget the real end-users of BPM, process models shouldn't have to be the center of the world.
With a mixture of Facilitator and Automator plus a whole lot more, my process model really represents the valuable work my people and my systems actually do. A process model drawn in a modeling tool at this level would be understandable to someone outside the organization (think of all the SOX documentation you have describing processes in your organization that an auditor must examine). At the same time I can ensure it is not restricting the knowledge worker but 'facilitating' his or her everyday tasks, while automating the dull meaningless stuff. I suppose that 'my BPM' is an Automacilitator...
Technorati tags: Financial Services Technology New Account Opening BPM
A post from the Improving New Account Opening blog
No comments:
Post a Comment