Many publications have established that one of the main prerequisites for success of the Business Process Management (BPM) undertakings is close cooperation between business and IT. One of the ways to ensure such cooperation is the development of the Business Process Management Notation (BPMN), which is supposed to be a process definition language shared between IT and business. BPMN 2.0 has introduced a lot of constructs allowing to directly define process execution and as a result has been adopted by several vendors as a run-time language for BPM. But many analysts think that such an enhanced execution support makes the language too complex for business users. Jim Sinur asserts that BPMN is demanding too much from the business people:
BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark. IT professionals can’t really expect business folks to understand cryptic/standard formats when they really want to see a real representation of their processes with desirable icons; not engineering Icons. It’s kind of like someone saying "let them eat cake". It is this IT arrogance that could sink BPM technologies... BPMN really stands for "Business People May Not... understand"
Sinur’s blog post opened a flood gate of responses. Scott Frances, for example, considers that we can ask business people to acquire new skills as long as they are asking IT people to improve theirs:
Respectfully, I think Jim is letting the business off the hook.No need to learn any new skills over there on the business side, just draw something on a napkin and hope it turns into a process. Just make up any old iconography you want, no problem if no one other than you can understand it (you know, the value of standards is that more than one person or team can understand what is produced)... At a time when we’re asking IT to learn new skills and to be more business oriented, is it too much to ask Business to learn new skills to support process improvement?... The problem isn’t that BPMN, as a notation, is too hard. It is that too many people think that BPM starts and stops with BPMN! There is so much more to managing business processes, and improving them, than BPMN.
Keth Swenson notes that most of the enhancements to the new version of BPMN are for developers, not for business people, turning it into a graphical programming language for processes. He questions whether vendors will move from BPMN 1.2 to 2.0 if their focus is on modeling rather than execution. In his opinion:
For server integration style BPM, otherwise known as Enterprise Application Integration, or Web Service Orchestration, there is a reasonable advantage in getting the additional formalism of BPMN 2.0 for this kind of programming. For human style BPM which uses diagram to depict the actions of organizational members, instead of servers, may find that the additional complexity of BPMN 2.0 only adds additional complexity without sufficient benefit to the users
Answering to Swenson’s comment, Sandy Kemsley strongly disagrees with him:
I think that Keith is throwing the baby out with the bathwater here: although a lot of new constructs have been added that make BPMN more useful for developers, that doesn’t make the basic subset inappropriate for business people who are already mapping their business processes with flowcharts. In the absence of any specific direction, I most often see business people (and business analysts) use flowcharts to represent their business processes; introducing them to the simplest BPMN subset will at least put some standardization around those flowcharts so that there’s no confusion over the shapes used on the diagram, and to reduce some of the spaghetti around flowcharting events.
Neil Ward-Dutton takes a middle ground approach:
... the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for "the business" is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that "the business' is some kind of homogeneous organization with one set of skills, experiences and inclinations... there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams.
Yes, the majority of the new features in BPMN 2.0 is aimed to make it an executable language and, yes, the complete standard is fairly complex, but as Bruce Silver explains in his book. BPMN 2.0 can be used on three different levels - descriptive, analytical and executable. If we assume that businesses will start from level 1 comprising 10 main icons, that can’t be too complex. But the advantages of a formalized standard language understood and interpreted the same way by both business and IT are huge.
