I am a little surprised at the scores on my BPMN self-test. Ten questions, four diagrams each, one of which is the correct answer. The scenarios are typical from real-world processes, and most of the patterns should be used routinely in process models. A couple of questions are a little hard, but I would have thought that more people understood the basic usage of timer, message, and error events, event gateways, loop vs MI activities, etc. The highest score so far is 80 (out of 100). (You can take the test more than once but I’m only tabulating the first one.) Here is the histogram of scores so far:
Oh well… The goal was to get people to think about training. I guess it should. Click here to take the test.
Bruce, how many people took the test?
regards Jakob
At least I need not to be embarrassed with two wrong answers. The result, of course, shows that not everybody is a fluent BPMN 2.0-Modeler yet. On the other hand, some of the BPMN constructs are not easy to use. And even if you know BPMN rather well, you need to think quite a while about the exact meaning of some of the diagrams.
So the question is whether attached intermediate events or the communication between different activities via signals, actually should be used in a business level model at all. What worth is a model if you need to sit down for quite some time and figure out what it actually means?
Sometimes it can be more useful to model the basic sequence flow and to add a few remarks concerning what happens in the case of an exception. Everybody will understand it, while a complicated model will only be accepted and understood by experts, and it is still error-prone.
I think BPMN is way over-engineered by enthusiastic systems engineers who forgot that the “B” stands for “Business.” I’ve been modeling on and off for about 15 years, and never found a use for more than the most basic constructs. I bet that all the complicated constructs (timers, intermediate events, exceptions, etc.) can all be reduced to basic ‘flowcharting’ type of constructs. They’d be a lot more intelligible. Right now BPMN intimidates even IT modelers, let alone business analysts.
Who cares if the system is elegant, if it is impractical and unusable? So who cares if James Maxwell’s four elegant equations unify electricity and magnetism? Just give me simple rules that show me how to connect up wires or to change the light bulb.
I’d say forget about BPMN, stick to the basics.
Thomas (and maybe also kirankg),
I think incorrect to say that something unfamiliar is intrinsically “hard” or “business-unfriendly.” For me, speaking German is “hard.” I don’t know how to do it, but it seems no problem for many people, even little children. It’s not hard, really, only that I have not been trained how to do it. This is my objective of the whole exercise… BPMN has the appearance of familiarity — that is it’s great appeal — but to use it effectively takes a bit of education. I offer this, in a book, in training, as do others. My approach emphasizes the parts of BPMN that business — yes, I repeat, business — needs to understand in order to document how their current processes actually work and to model improved to-be processes. I will agree with you that one can get along fine without knowledge of the fine details of the Signal event, and I say so in both the book and training. But understanding the basics of timer, message, and error events, or exception propagation from subprocesses… no, if you don’t understand these things you cannot properly do process modeling.
I agree with Bruce. I have seen a lot of wonderful simple process diagrams in a lot of documents that were meant do describe software requirements. Unfortunately, the diagrams were quite meaningless, so all the requirements had to be written down, with all the risks and problems we all know. We use BPMN in our IT projects quite successfully, it is just a more effective instrument for talking about processes, than “simple flow chart notations” could ever be. We even started to combine BPMN with agile approaches like scrum – and YES, it does work. BPMN is not over-engineered, it is just a powerful instrument which people must learn to gain the profit. Bridging the gap between business and it is not about looking for some magic silver bullet making everythin easy for business. You can search for ever, if you stick to that illusion. It is about people communicating more effectively, because EVERY fraction in the process has become smarter, by learning new stuff, like BPMN.
I’d have to third this; one of things that I find astounding about people’s resistance to more sophisticated concepts for process modelling is that it actually ignores the fact that business processes can, and most often are, complex and that traditional ‘flowcharting’ concepts simply do not articulate the real world.
Intermediate events are one of the key examples for me; the fact is that processes get interrupted mid-sequence. Trying to model an exception after a task has finished using a gateway is not only inaccurate, there could also be multiple exceptions that could occur, potentially resulting in endless chains of gateways.
To get a bit pretentious for a moment, Albert Einstein said “Make everything as simple as possible, but not simpler’. But by rejecting the power of some of BPMN’s concepts is to do exactly that. I’ve heard a number of people (and rather surprisingly, it’s often IT people) say “the business won’t understand some of those concepts”. However, in my experience, it’s actually the business that are more ready to embrace the concepts, because they understand their processes, but these have typically been expressed in disparate ways, using any number of flowcharting methods, or pages and pages of texts with ‘this happens, but if this happens, then this does’ etc etc. To see something that actually articulates the process accurately is something new and provides something standard and reusable. If they don’t understand the concepts, it’s down to the analyst to sell the advantages to them, because it’s in their interests. It’s like Bruce says in his book, sometimes the business don’t understand enough. Why is process modelling one of those things that it seems unacceptable to know more about? As the business gets more complicated, it’s naive to think that traditional methods can always solve the problem.
I also think that it underestimates the capacity of the business area to learn and use BPMN. From the experiences I’ve mentioned above, it’s typically someone like an analyst or another IT person that almost dumbs them down before BPMN gets anywhere near them.
The model could also be seen as a type of contract for delivery (even if it is not automated at a later stage); because BPMN is a standard and when used properly (which is obviously can present a challenge in itself), there is no room for misinterpretation and therefore the business can be more secure in knowing that what they need has been expressed sufficiently.
The last point is that the concept of traditional flowcharting infers some sort of standard; one of the reasons for the development of BPMN in the first place was that no consistent standard existed for process modelling. BPMN provides that and now the business and IT need learn one only, rather than potentially be presented with different ‘traditional’ methods every time a different analyst or project comes along.
And breathe…….