Fortunately I was on vacation last month when Jim Sinur launched his fatuous “Burn Baby Burn” bomb, the one about how BPMN is too hard for Gartner clients. In the ensuing discussion, cooler heads mostly walked Jim back off the ledge, but the back-and-forth still did not get to the heart of the real problem, at least as I have experienced it.
In my view, it’s not really about “business users” or what exactly is a business user. Creating good BPMN is often more difficult for architects and developers than for business people. It has nothing to do with BPMN 2.0 vs BPMN 1.x. Almost all of the differences between them are below the waterline, in hidden XML details, not in what prints in the diagram. And it’s not about the unwieldy BPMN vocabulary of event and gateway types. As others have pointed out, we already have a limited working set of shapes and symbols in the Descriptive process modeling subclass, and tools like IBM Lombardi Blueprint have an even more limited palette than that. Trust me, you can create bad BPMN with nothing more than tasks, XOR gateways, and None start and end events.
I say with some confidence that I have probably looked at more bad BPMN than anyone on the planet. And I don’t say it proudly, because these are certification exercises submitted to me by students following two days of intensive BPMN training delivered by me personally. While we get some “ordinary business users” in the training, the majority nowadays are business process analysts, business architects, enterprise architects, BPM consultants, and BPM developers. Most of them are not new to process modeling, either.
The problem with BPMN is it demands you follow the rules. When we used to draw process diagrams in plain Visio or PowerPoint, there were no rules. Modelers made up their own rules. They knew the meaning, more or less, or boxes and arrows and diamonds, and close was usually good enough. But in that kind of modeling, the diagram was rarely meant to be a standalone artifact. It was just a vague depiction of a process detailed in an accompanying 100-page book of documentation or business requirements.
On the other hand, BPMN lets you create diagrams that stand on their own, describing the activity flow precisely and compactly, what comes before what, what activities are conditional, what activities are concurrent, the logic of taking this path or that, how the process starts and the various states in which it can end, and how the process touches the external environment… all without resorting to the 100 pages of documentation. In fact, if your process diagram doesn’t reveal all those things, I call it bad BPMN.
To create good BPMN, you need to follow the rules. It’s not really hard to do, and it’s a readily learnable skill. Still, for some experienced modelers that’s a problem, since they’ve already made up their own rules and prefer to follow those. The real problem is knowing what the rules are!
First, the BPMN spec does not enumerate its rules. They are in there, but buried in the narrative of a 516-page specification in combination with some UML class diagrams and an XML schema. And sometimes those three sources don’t precisely agree with each other. There should be an appendix that simply lists the rules, in plain English and in a way that is easily computable by any tool. But there isn’t.
Real BPMN tools, like Process Modeler for Visio from itp commerce, or native Visio Premium 2010 from Microsoft, include a validation function that tests a model against that tool’s interpretation of the BPMN spec. That’s a good thing, and I don’t want to minimize the value of that feature. But they don’t go far enough. Those rules just enforce the basic semantics of the shapes and symbols, for example the difference between sequence flow and message flow, what can legally connect to what. Your model can have zero validation errors in the tool and still be, by anyone’s definition, bad BPMN.
Good BPMN goes beyond the rules of the spec, into the realm of “method and style.” What makes good BPMN, I suppose, depends on your purpose. My purpose is creating non-executable models in which the diagrams stand on their own, clear and complete, shareable across the business (to those that understand the rules) and between business and IT. So I have developed an expanded set of BPMN rules, encompassing both those of the spec and the method and style domain, and that’s mostly what my BPMN training is about.
My problem, like that of the BPMN spec itself, is that those rules are not listed in one place. In the training they are mostly collected in two or three places, and the key ones repeated throughout… but really they should be in a simple list, in one place, formatted for easy reference. OK, that’s coming.
And, like the rules of the spec, they should be supported by a tool. That’s coming too, hopefully this week. Users will upload models in XML from either itp commerce Process Modeler or Microsoft Visio Premium 2010, and the tool will list both the spec errors and the “style” errors. Beyond students in my training, I haven’t decided how to expose the tool to the general public, but if you are interested in trying it out, contact me and we’ll see what we can do.
This is a good place to stop. Next time I’ll provide the list of BPMN rules.
[…] This post was mentioned on Twitter by Kevin Brennan, Jan Schirmer. Jan Schirmer said: "Following the rules" /Silver http://bit.ly/b62tL9 #bpm #bpmn […]
Hi Bruce,
I’m very interested in your “validation tool”, and also the tools mentioned in previous post for exporting valid BPMN from Tool A to B.
I wonder if you have a suggestion for me on how to publish the processes for a greater number of employees, without the need for Visio(or any other special tools)
Many thanks
utterly astonishing… the lack of logic behind this ‘BPMN for all’ argument is stunning.
In my understanding BPMN was created with the express intent of building a standard language for graphical representation of executable processes. Why therefore is there this completely illogical attempt to portray BPMN as a good way of building processes that are not to be automated (which represent the large majority of activities in any organisation)??
It’s either that the BPMN experts simply don’t understand the business user’s reality (quite possible in my experience), or that there is a totally irrational compulsion to standardise for the sake of it (also sadly a fairly frequent occurrence).
I think that MS Excel is a great piece of software; however trying to sell me on the fact that I could write my letters in it by explaining to me that I could set the cells to word-wrap, format text as required and position things very easily is not something that anybody has tried lately.
Bruce, I understand your business is built on BPMN training however I am clear from experience with hundreds of clients and hundreds of thousands of business users that you are doing yourself no favours with this approach. Any sensible business user is going to call your bluff on this if you try to push BPMN as a business user standard. Indeed this has already happened in numerous organisations.
I absolutely agree that manual processes need to be built with a logic and structure otherwise they add little or no value, here’s the kicker though; the standards and logic required for a human are fundamentally different to those required for a computer (one of the obvious reasons as to why your smartphone OS interface isn’t ones and zeros…)
The requirement is CLEARLY that 2 standard languages are required; one for the automated requirements for which BPMN is clearly a great candidate although I’m not qualified to comment further, AND a business language, for which I would suggest UPN is the most obvious and widely used candidate. Then we need a clear governance structure to ensure that the 2 models are managed it sync. (roundtripping between business user processes and automated ones is a pipe dream and will NEVER happen, simply because the levels of abstraction required for each audience are wildly different).
One could, (and you do I believe) argue that the business user language should be BPMN lite (therefore tacitly agreeing with my point about 2 languages). That is however akin to putting text boxes on top of Excel to make it work better as a word processor…
Or how about this analogy: taking a graphical programming language and trying to simplify it, is a basically what Microsoft did with tablet computers; try to simplify Windows to work with the new form factor and pointing mechanism and guess what? nobody bought one. Apple re-thought the whole thing from scratch and produced a specifically built OS, put it on the iPad and bingo! subsequently everybody has cancelled their planned Windows based tablets as it’s clear that it doesn’t work.
Let’s therefore agree that we need 2 languages; BPMN (experts to comment here) and UPN i would suggest. Different languages designed from the ground up for their different audiences.
Bruce, there is clearly enough business for you to do very well training BPMN, just keep it to where it needs to be.
I can assure you there is ZERO chance of rolling out BPMN content to thousands of end users in a company and having that company achieve the amazing ROI experienced by clients that use UPN for that approach. Equally you would be laughed out of the IT department if you attempted to use UPN for building executable diagrams.
Either way you will only look ridiculous if you try.
Yes, well you’re entitled to your opinion. I never heard of UPN. Is there a reference for it? What BPM tools support it?
Hi Bruce,
You have a good point for the validation. I use the iGrafx software that provides (from my perspective) a very good validation feature for the BPMN modeling and for the process simulation, but it stills let you create bad BPMN diagrams….
Looking forward to your list of BPMN rules… which will be easier to consume than the 500 some pages of the BPMN 2.0 specs document. 🙂
BTW, I purchased your BPMN Method and Style book, and I got to say that this is one of the best book I bought on Process Modeling.
To Mads: iGrafx allows you to export into HTML native format, or HTML Java format for greater functionality. Worth looking at I think. You can get a trial key… http://www.igrafx.com.
Hi Bruce,
Thanks for such an eloquent summary of the common difficulties with BPMN and modelling in general. You’ve expressed in writing, some of the same things I have lamented to fellow business analysts about encouraging people to produce models that are semantically correct and readable to both a technical and a business audience.
You’ve hit the nail on the head, many people are unwilling to outlay the time and effort it takes to learn a standard notation and yet they’ll spend time developing and refining their own version. Their argument is often that they don’t have the time to digest the rules of a modelling language like BPMN or UML Activity Diagrams. Their role as they see it, is to produce business requirements, which they will invest hours in creating unwieldy text documents. However if they spent some time learning the rules of modelling, then they would be able to spend time thinking about composing the business process itself and not have to worry about how to communicate it. They would also be able to communicate the business process more thoroughly and simply. It’s much like the time and effort you have to put in to learning a foreign language. The goal isn’t to learn the language itself, but to communicate with people who speak that language. The time and effort to learn the language is worth it, rather than trying to devise an ad-hoc series of gestures and attempt to use that to communicate with the people who speak the foreign language on a regular basis.
I agree about method and style too. I understand that you’ll elaborate what you mean by that in further posts. For my mind, it’s similar to communicating well in written English. To be easily understood and not caught up in jargon and legalise, you should to paraphrase George Orwell, use short words instead of long ones and cut out words where you can. I think this can be applied to modelling style. Use simple symbols where you can; use more complex symbols where it will reduce symbols and provide just enough detail to adequately communicate the business process at the desired level, but no more
Mark, while I appreciate your well structured argument. I think you have misconstrued the original intent of BPMN. While it’s secondary purpose is the visualisation of executable XML based business process languages, the BPMN specification clearly states this is in a business-oriented notation.
That said, I do agree with you that most business people aren’t going to actively compose process diagrams. They don’t see themselves as documenters of process, but rather executers. My goal is to get them to read and understand my diagrams, rather composing them, which I see as my role. I haven’t heard of UPN either and upon investigation I see that it is a proprietary language primarily (possibly even solely) produced by one consulting firm. I don’t think it has a big following and it certainly isn’t open like BPMN is. Rather than two notations as you propose I think being mindful of the audience is a better approach.
[…] Quotes of the week On BPMN and Business users – Bruce Silver In my view, it’s not really about “business users” or what exactly is a […]
Anthony: I completely agree with your point about the vast majority of people being consumers of process rather than creators. Ergo, we need a notation that requires as little training as possible in order for potentially tens of thousands of people in an organisation to be able to quickly understand what is required to do their job from looking at a process. Any notation therefore needs to have 2 characteristics:
1) simple to build correct, logical, structured business user focused content
2) simple to understand for untrained users
Clearly BPMN fails on 1), at least according to Bruce in his post; “I say with some confidence that I have probably looked at more bad BPMN than anyone on the planet. And I don’t say it proudly, because these are certification exercises submitted to me by students following two days of intensive BPMN training delivered by me personally. While we get some “ordinary business users” in the training, the majority nowadays are business process analysts, business architects, enterprise architects, BPM consultants, and BPM developers. Most of them are not new to process modeling, either.”
Either Bruce is a bad teacher or the notation is too hard, I don’t see any other possible conclusions. Given that from feedback I’ve had Bruce is actually an excellent teacher then it follows that BPMN is too hard. If the initial content is bad then point number 2) becomes moot as we don’t want to be deploying it anyway!!
Taking number 2), we have done numerous test showing normal business people ‘simple’ BPMN and asking for their interpretation of what it means. Guess what? you get almost as many interpretations as there are people, failure number 2. I accept that you may be able to train people to understand simple BPMN, but immediately you decide to do that you’ve just saddled the organsation with a huge, ongoing (because of employee churn and ensuring people’s skills are ok) and therefore costly training exercise (maybe that’s why Bruce thinks it’s a good idea?). All for what? To train people about how to do their job by using an arcane language that was never designed in the first place with them as the audience in mind.
Have I misconstrued the original intent of BPMN? Maybe, but you know what, it doesn’t matter; ‘Judge people on what they do (actions) not what they say’.
BPMN is clearly NOT focused at normal people and I don’t care what the OMG says it’s for because its ‘actions’ are clearly aimed at executable processes. For example since when did normal people need to know what logic gates such as AND,OR and XOR are? Wikipedia sums it pretty clearly by categorising logic gates as ‘Categories: Digital circuits | Logic in computer science’.
There is ABSOLUTELY NO NEED for normal people to understand the arcane symbols of BPMN in order for them to understand a process, i.e. how to do their job. If the original intent of BPMN was indeed to engage with normal people then it has patently failed. If the current intent of BPMN is to provide a standard graphical language for executable processes then great, that is certainly necessary although I’m not qualified to comment as to whether BPMN is the best answer or not.
So we’re back to my original point (that Bruce and anybody who uses a simplified version of BPMN for normal people agrees with) that 2 languages are necessary; BPMN for executable processes and something else for normal business users, and that something else should be designed from the ground up with them in mind, not a bastardised version of a graphical programming language, i.e. not a simplified version of BPMN.
With regard to UPN it is a proprietary standard yes (originally created by Nimbus), but one which anyone can use with any software you want, http://www.nimbuspartners.com/documents/584. It is probably the most widely used notation worldwide with literally millions of people interacting with UPN diagrams everyday. Its capabilities in allowing rigourous end-user focused content to be simply built and deployed to thousands of users to be used on a daily basis is beyond question;6 of the top 10 biggest companies in the world use it.
To be clear, this is in no way a software pitch (I’ll re-iterate, UPN can be used with any software you like), it is an impassioned plea on behalf of the millions of business users around the world not to attempt to inflict something on them that is clearly not designed with them in mind.
Dear Bruce,
I really appreciate your work in education and consolidation of BPMN (I read your book and I read with much interest also your recent online decalogue for BPMN design).
I have mixed feelings on the target users of BPMN: business users can for sure understand and design BP diagrams (if we assume usage of a “baseline” version of BPMN), but as you (and the other comments) abundantly demonstrate, it’s already a big challenge to end up with a reasonably well-formed and sense-making model.
However, this is only the first step.
The actual challenge would be to get value from these models: models should help improving processes, identifying requirement mistakes or other issues, possibly automatically executing/prototyping processes, and effectively documenting.
The question is: given the difficulty to reach the first objective (correctness), do you expect that the actual value will ever be achieved?
Our experience is that BPMN models are of huge value for process designers and engineers, but when it comes to getting feedback from the stakeholders (business users,…) nothing worked better than interacting upon running prototypes.
We recorded precise measures of our activities and productivity.
The good news was that we were able to automatically generate such prototype from BPMN and thus achieve quick redesign cycles.
(we presented our experience at BPM 2010, Hoboken, NJ too)
Mark,
Your comment is a complete misreading of what I said. It has nothing to do with the “arcane” symbols of BPMN. We are talking about simple boxes and arrows. It would be the same in UPN or whatever proprietary alternative you are selling. Probably my standards for good and bad BPMN are different from yours. For me, good BPMN means that the diagram stands on its own, i.e. the process logic is evident from the diagram itself, without accompanying documentation. Also, that you can understand at a glance how the process starts, its possible end states, and its touchpoints with the global environment. With bad BPMN, the problem is rarely some arcane symbol like complex gateway or escalation event. The problem is more often a gateway with no label and no labels on the gates. This is what I am talking about; please don’t twist it into a commercial for another tool.
–Bruce
Marco,
I agree that BPMN alone is insufficient for BPM projects. The issue is simply how much information to include within a single standard. BPMN provides hooks for lots of other stuff, but has not defined a particular way to connect that stuff to the process model. OMG itself has various groups working on some of those standards, most of them blissfully unaware of BPMN or unconcerned about linking them together. In any case, the purpose of formalizing the interconnections between all this process-related information is interoperability between tools. We don’t even have tools stepping up to the simplest level of Descriptive subclass interoperability, so adding more to the standard is, at best, premature.
Bruce
Bruce, you are misunderstanding, misreading and misrepresenting all in the same post – that’s a lot of misses, maybe you should be an england football player??
Misunderstanding – my point is that you are tacitly proposing 2 languages for process, BPMN for automation and a simplified version for people. I am saying that I’m completely fine with BPMN for the technical piece however it makes no sense to use a technical language and try to simplify it for humans, why not use one that’s built from scratch for that purpose? Also your point illustrates the problem; “For me, good BPMN means that the diagram stands on its own, i.e. the process logic is evident from the diagram itself, without accompanying documentation”. The question is, evident for whom?? The vast majority of normal people do not understand what you would consider to be simple BPMN unless they are trained – fact.
By the way I agree, it often isn’t the symbols that confuse people, it’s the semantics of how they are used and the preciseness with which they must be used which is frequently the issue.
Misreading – you say; “whatever proprietary alternative you are selling”… I said; “one which anyone can use with any software you want”. Ergo I’m not selling anything, simply suggesting that UPN is an extremely effective and proven way of communicating to normal people which anybody can use, no charge.
Misrepresenting – you said; “This is what I am talking about; please don’t twist it into a commercial for another tool”… I said; “To be clear, this is in no way a software pitch (I’ll re-iterate, UPN can be used with any software you like)”. The only person with a commercial axe to grind here is you; you sell BPMN training courses, you are clearly commercially interested in BPMN’s success (which by the way I’m fine with, we all have to earn a living). Financially I couldn’t care less whether people use UPN or not, I make no money from it. I’m simply saying that it is a much better answer for normal people than a ‘lite’ version of BPMN is.
The bottom line is whether any of these languages actually work (for humans that is). I.e. can you show me a company where thousands, tens or even hundreds of thousands of normal users look at BPMN content on a regular basis (daily, weekly) to understand how to do their job? Ask that question of UPN and the answer is yes, time and time again, with frankly astonishing results in terms of money saved and earned.
Good luck with the football 😉