In a previous post, I introduced the concept that there are two predominant views of BPM. One view is that of the Automators, who are creating business processes which replace humans by doing the same things that had traditionally been done manually. The other view is that of the Facilitators, who are creating BPM processes to involve actual people in processes can not and probably never will be fully automated. Both groups see themselves as making “human processes”, both groups create BPMN diagrams filled activities and gateways.
To illustrate the differences, consider a very simple process that represents a writer writing an article for a reputable publication, and an editor which must reviewing that article to make a decision on whether the article is suitable for publication or not. This is not a pretend process, this is a real process which when used in a real organization provides real value. A Facilitator would draw it like this:
That is all you need at a human activity level. 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.
An Automator is likely to look at this process and say it is ridiculously simple. People are not just sitting around like servers handling requests like “Write Article”. Automators are looking specifically at what the server must do, to enable the process. For example, the server does not write the document, but people do. What the server does is
- determine who should be the writer this time
- put the task on a task list that the user can browse
- some users also want an email message prompting them
- receive the email message back with the document in it
- remove from task list
- determine who should be the editor this kind of article
- put the task on a task list that the editor can browse
- some users also want an email message prompting them
- receive the email message back with the decision in it
- remove from task list
It gets more complex when you include features which are commonly included in a human BPM system. First of all, it is not always possible to know (with the data available to the system) who the write editor is. It might on the surface be an article about vacation travel, slated for the Travel section, but it actually is a news story about smugglers pretending to be on vacation. Many good human BPM systems give you the ability to reassign the activity to another person. So you need to add that there are two possible emails that might come back: one with the results, and the other saying “Joe should review this document”.
Second area of flexibility is the initial assignment of the writer. A good human BPM system will have a way to offer a task to a group of people, and people can accept the task, and bring it to them, informing the others that the task has been taken. This now makes the task list more like:
- send an email offering the chance to write an article
- receive email from first person responding that they will take the task
- send email to all the original group informing them that the task has been taken
- put the task on a task list that the user can browse
- send an email (some users)prompting for the actual writing
- receive the email message back with the document in it
- remove from task list
- determine who should be the editor this kind of article
- put the task on a task list that the editor can browse
- some users also want an email message prompting them
- receive the email message back with the decision in it
- OR receive an email sayting to reallocate to a different person, loop back a couple steps.
remove from task list
Most good human workflow systems have a way to remind the users that they are approaching a deadline. A typical two step reminder is that the first reminder is to the person performing the task, and if that does not work, then an “escalation” reminder which goes not only to the performer, but also to a group of others who will look into the problem and see why it is no progressing. This adds a few more steps:
- send an email offering the chance to write an article
- receive email from first person responding that they will take the task (presumably you ignore any later email message to this effect, and drop them on the floor)
- send email to all the original group informing them that the task has been taken
- put the task on a task list that the user can browse
- send an email (some users)prompting for the actual writing
- send reminder email to performer
- send escalation email to wider group of people
- receive the email message back with the document in it
- remove from task list
- remove from task list
- determine who should be the editor this kind of article
- put the task on a task list that the editor can browse
- some users also want an email message prompting them
- send reminder email to performer
- send escalation email to wider group of people
- receive the email message back with the decision in it
- OR receive an email sayting to reallocate to a different person, loop back a couple steps.
- remove from task list
Such a process might be diagrammed a bit like this:
I am sure there are MANY problems with the above diagram. If you would like to draw this process correctly, please do so and attach it to a comment (or email it and I will attach). I am not sure that a complex condition node can “loop back” to a previous task (that is what I want to do but it might not be allowed by BPMN guidelines) I am not sure how to have one timer go, and then a later time, and still allow that if the response comes before one or the other the process continues. I think I need to use a subprocess box to get that to work correctly. in any case, the exact way that one would draw this depends upon details of the system you are implementing on. For example, how did you recognize that the email was a completion email, or a request for reassignment. And what is missing from this is the requests that the user makes to the system to retrieve the current worklist. But this diagram is good enough for me to make a point.
The Automator is happy, because this diagram represent a more “truthful” description of what the system has to do. It makes explicit the various email messages that must be sent and received. What we have done here is to move away from the representation of what people do, and moved instead to a representation of what bits and bytes need to be sent and received by the system. The activities describe what the system does, not what the people do. That is great, if you are a programmer.
The detailed diagram has lost the representation of the fact that there are actually only two human activities being performed. You can’t really see what the people are doing, without getting lost in the details of what the system has to do to communicate to the people. The diagram could be simplified by hiding a lot of the detail in subprocesses, so you have only the two nodes at the top level and drill down to see the detail.
The point is not that “Automator” processes are more complex. My point is that with a human BPM system, the “Facilitator” gets a lot of capability built in “for free”. Simply draw an activity, and assign it to a person, and the human BPM system at that point does multiple things to inform that person that they have something to do. There can be built in mechanisms to negotiating who does that activity. There can be built in mechanisms for reassigning the activity. There can be built in mechanisms for reminder messages. And finally there is a built in mechanism to recognize when the person declares that they are done. All of these capabilities are common across any task you wish to give to a human. Why should you have to re-invent how to notify the user for every process? The Facilitator wants to focus on the human tasks, not the bits and bytes that the system sends and receives. The Facilitator learns that all these capabilities are built into an activity node.
But what to do? BPMN does not have the concept of assigning a person to an activity. BPMN was designed primarily (but not exclusively) by people with the Automator viewpoint. Much time was spent on how to translate to BPEL, which is exclusively Automator viewpoint. The BPMN group kept their options open, to allow for a Facilitator view implementation, but there are contradictions if you follow this path. This causes people to look at an implementation of BPMN, and way “that is not standard”. Indeed it is not: a Facilitator diagram does not look like an Automator diagram.
Thinking Matters 
Keith,
In my current assignment I had a similar situation where the business stakholders tend to view things in a facilitor fashion while the senior BA (me) and IT view the process in a automated fashion.
You are very correct in that a facilitator diagram does not look like an automator diagram BUT they can compliment each other in a similar way a BOM compliments and ERD or a logical architecture diagram compliments a physical architecture diagram.
Taking the BOM/ERD example, the BOM has entities and attributes which represent things at a high level that the business stakeholders are familiar with. The ERD takes that BOM and transforms it into something that can be implemented techincally allowing the business to use those items in the ways they want.
“Most” business users don’t care how the system is implemented and what technology is used, as long as they get the what the facilitor diagram sets out to achieve. Our jobs as technical people is to hide the complexities behind what business people see.
With today’s modeling tools, you can define human, system, send, receive, etc.. activities/tasks in the model, but it’s up to the analyst or whomever the process is documented by to decide on what levels of detail their auidence is comfortable with. So the business users would see the “write article” and “review article” while the implementation team see the complexitites on how to make it all happen.
I will close with a metaphor that sums it up best, the failitator diagram represents the swan swimming gracefully on the lake, the automator diagram represent the swan’s not so graceful legs thrashing under water. You can’t have one without the other.
Cheers,
Grant
Pingback: facilitators « processi
Pingback: links for 2007-09-29 « steinarcarlsen
Grant,
Thanks for the very thoughtful comment that that certainly enhances the main points I was trying to make. There are different levels of abstraction, and it is not possible to represent everything to every level of detail in a single diragram. Dr. Michael zur Muehlen gives a great talk called “BPM 101” where he cites an extensive British Telecomunications PLC study in 2006 which identified and categorized a freamwork of six levels of abstraction from the top level of corporate goals, down to detailed diagrams of processes involving individuals.
I love the metaphor of the swan (presumably not a black one, but lets not get distracted) of the graceful swimming and the not so graceful thrashing of the legs. I certainly agree that to make human level process work, there must be detailed mechanisms at work. Clearly our information technology works on electrical impulses, which are coordinated by machine code, which is grouped into libraries, which have other libraries built on them, and so on.
However, I am not sure that I agree that the lower level “model” needs to exist as a model that is created by modelers.
What if I showed you a system on which you could draw a facilitator process, and it is executed directly? Agreed, there are more detailed mechanisms making it work, but the designers of the process have no need to be aware of them. In this case, it is not simply the choice of the analyst to decide what levels of abstraction their audience see. There is, in fact, no need for the analyst to draw a picture of how the bits and bytes flow through the system. The analyst would then simply focus on the human tasks, and the system would provide at run time all the rest. Many people today draw facilitator processes without every having to worry about how data is sent or received. In fact a central paradigm behind the systems I have designed is that information is “location independent” and as such the concept of sending data from point A to point B is simply meaningless at the human level. Under the covers, the system does whatever is necessary to get the data wherever it is needed.
I do agree, however, that not all systems are built this way, and in some systems an analyst might draw a Facilitator diagram, as well as an Automator diagram that in a sense “implements” the other.
We still need Automation, a.k.a. service orchestration, to create system-2-system processes. And we need Facilitation of human-2-human processes. I think the primary mistake we seem to make, is assuming that these are the same thing and should be modeled the same way. We assume that the necessary modeling primitives are the same in both domains, but I see no logical reason to believe this.
Anyway, I do hope you will continue to comment in future articles as we try to sort this all out.
Great post. You may be interested to check out Human Interaction Management, a set of principles and patterns that support human BPM such as you describe – see http://human-interaction-management.info. A free desktop application to support these ideas is available – see http://humanedj.com.
All the best
Keith
I think that a Role Activity Diagram would be a far better way of depicting that sort of process (that Keith HB’s stuff is largely based on). You can download a free Eclipse based Role Activty Diagramming tool at http://www.instream.co.uk … and make sure you get Martyn Ould’s book “Business Process Management – a Rigorous Approach”. I will see if I can come up with a prettier BPMN model for you too.
Keith wrote “…But what to do? BPMN does not have the concept of assigning a person to an activity.”
Actually, BPMN 1.0 has User Tasks where you can assign a “Performer” (i.e., the User, although it could be software) to the Task. In BPMN 1.1, which hasn’t been officially released yet, a Performer can be assigned to any activity, to provide some human interaction or surpervision over any activity.
While BPEL was important factor in the development of BPMN, so were the needs of Business Analysts for general process modeling.
The discussion of the different diagrams shown in the post really have nothing to do with BPMN per se, but with the methodologies that would be used to model with BPMN. BPMN is generally methodology agnostic. The way that a process is modeled, to what level of detail, and what information should be captured, is really up to the methodology and the purpose for creating the process model.
BTW, I would probably tweak the second figure a bit here and there, but it basically shows what you were talking about.
Keith,
You are quite right when you say that the “low-level” model doesn’t have to exist. Today’s BPM tools allow for BP diagrams to exist in a “facilitator” view. Tools like Tibco, Aqualogic, Oracle SOA suite, Filenet etc.. allow modelers to model processes in a facilitator manner which can be executed by the system directly. This is due to the integration between the modeling tool and the middleware, often supplied by the same vendor.
Automation can be used for human-2-human processes too by simply routing the task to different people upon completion of the activity, this can also be said that a facilitator can be used for system-2-system tasks (in the form of a trigger for example – think of the BIG RED BUTTON!!).
The advances in BPM and the modeling tools/middleware that support BPM, have made great strides in recent times and because of that I’m hoping that in the not too distant future, with a little help, I can empower my business users to take back the ownership of the process.
I guess at the end of the day, what I’m trying to put across is that the level of detail will depend on the audience. It’s no use telling a child to turn down a stereo because you are suffering from cephalalgia..unless that child is a doctor and knows that cephalalgia means migraine.
Cheers,
Grant
Pingback: BPMN & Various Methodologies « Go Flow
Pingback: Improving New Account Opening
In response to Derek Miers comment – yes, Martyn Ould and I are colleagues of old, and there is still a lot of synergy between our work. In particular, the process architecture aspects of Martyn’s RIVA method are recommended in the GOOD methodology associated with Human Interaction Management (HIM). However, the process modelling aspects of RIVA are no more applicable to the kind of “human-driven” process that Keith Swenson describes here than BPMN, BPEL, or XPDL. To deal with such processes, you need the notational technique of HIM. Both RIVA and HIM notations may derive originally from the same source, the Role Activity Diagram notation of Holt et al (1983), but they are very different, and intended for different purposes. As Martyn acknowledges, RIVA process modelling notation is essentially equivalent to BPMN. HIM notation currently has no equivalents – it is the only mainstream process notation intended for modelling human-driven work.
Pingback: A Methodology for Human Processes « Go Flow
Pingback: Human Process: Trouble Ticket « Go Flow
Pingback: Model Strategy & Performance « Go Flow
Pingback: Representing Choice in a Process Diagram « Go Flow
Pingback: Is BPM Dead? « Thoughts on Collaborative Planning