Stephen White made a comment on my Human “Facilitator” Processes post that deserves highlighting. You probably know the Stephen was the chairman of the working group that developed BPMN.
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.
He is completely right, and this is really really important. I have discussed this with Stephen before, but this is something that very few of the experts seem to understand. What he is saying is that the way you draw something with BPMN depends upon your methodology you use. Given one method for one purpose (e.g. Automators) it would be right and correct to draw one way, but with a different method and different purpose (e.g. Facilitators) it would be right and correct to draw a different way.
This makes those who want ONE TRUE WAY to draw process diagrams extremely uncomfortable. This was never the goal of BPMN. BPMN instead had the goal to define a set of common elements that could be used for multiple different specific diagramming needs. I might even venture that this is why BPMN did not have a meta-model to begin with. I might also venture that BPMN success is precisely because it was flexible to be adopted in slightly different ways. Had it been overly rigid, it might have been rejected.
I would have said it slightly differently: that differences in the diagrams come from differences in the capabilities of the underlying system that will enact the processes. This amounts to the same thing since tools are created with a particular methodology in mind, and that use of a particular methodology draws you to particuar tools. What you are allowed to draw, and how you draw it, depends on things outside the BPMN standard.
What does this really mean? It means that using one methodology one might draw a given process one way, while using another methodology one might draw it a different way. Those who want a single diagramming approach, want a single methodology, as well as single set of underlying capabilities. That would make life easier, in the sense that having a single flavor of wine would make life easier. The world is not so simple, and some of those differences have great value and utility.
This calls into question all sorts of things. For example, is it possible to exchange process models? The answer depends upon whether the tools exchanging the models have similar enough underlying capabilities. My position has always been that a process model has many aspects, and some aspects of the model will translate with full fidelity, but other aspects will not fare so well, and we must be satisfied with partial fidelity. Still, it is worth-while to get the part that does carry over.
At the risk of being repetitive, let me stress this one more time. You might be able to draw a particular diagram using one fully BPMN compliant tool, and not be able to draw that same diagram using a different BPMN compliant tool. Both tools are BPMN compliant. I will leave you with that thought for today, but there is clearly much more to discuss, particularly when considering Facilitators and Automators.
Pingback: Improving New Account Opening
Pingback: links for 2007-10-09 « steinarcarlsen
Most methodologies have an intended audience and intended purpose. The audience, whether it be business people or technical people will require different levels of details to address the intended purpose.
If the methodology’s purpose is to communicate and educate and the audience are new staff members, the process may not warrent in depth details in the diagram. The author of the process can still use BMPN to describe the process, but restrict the amount of information to address the methodologies purpose.
As I mentioned in my second comment on the previous article.. “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.”
I happened to face a situation few days ago when i was mapping a simple “credit request” process in a course of mine and I couldn’t agree more with the agnoticism you wrote about.
We (me and my student) finished mapping the process and at the end we had two pools. One for the client view where it had only two activities: the request itself and the response for that. Couldn’t be simpler.
And the second pool had the whole process with all the approvals and other activities. The company view.
Then my student asked me: Why isn’t the client inside the company view? Why we have to use this “messaging stuff” instead of using the simple sequence flow?
Well, my answer was that we were mapping the company’s view of the process. It receives a request, treats it and returns it. The client is not part of the company, doesn’t participate of any of the activities. That’s why i put in a different pool.
But I could do the other way, couldn’t I? Put the client’s view in the same pool as a participant like any other actor in the same pool. Right?
I think this is an example of u just wrote. Our goal, at that moment, was to map the company point of view. That’s why we opted to put that way.
Well, think that’s all. I’d appreciate if u comment that.
Pingback: A Methodology for Human Processes « Go Flow
Pingback: BPMN Modeling and Reference Guide « Go Flow
Pingback: Will BPMN 2.0 have “Model Portability”? « Go Flow