BPMN seems to be the most popular process notation standard, although if you Google it, there is still more than a little debate around its merits.
The primary goal of standards like BPMN (Business Process Model and Notation) according to Wikipedia is to provide a standard notation that is readily understandable by all business stakeholders. Those who create the processes, those responsible for implementing them, and the business managers who monitor and manage them. BPMN serves as a common language, bridging the communication gap that frequently occurs between business process design and implementation.
So what’s our view on the idea of agreed standards for communicating process knowledge?
We believe this is a valid concept for technical teams, for specialists in design and build phases of projects and perhaps even for the representatives from business teams that have been selected to assist them in their projects.
However, the idea of a standard for sharing this information with business teams, and that this is somehow the best way to implement new ways of doing things and for on-going process management, seems flawed.
History has judged notations harshly from the perspective of business teams actually owning them after projects. Unfortunately, information like this has been ignored almost universally for years now. Why? Because it’s too confusing, it doesn’t actually help teams get it right, and it doesn't even come close to a format that they themselves would choose to explain a process. Which by the way, varies team by team. Want to show a manufacturing team how to perform a process safely and quickly? They’ll ignore the confusing charts, but embrace a short YouTube clip. This sort of team will always choose a different format from say a team of lawyers managing legal matters. To engage with business teams, there simply is no miracle single notation to rule them all.
So that’s our view. For the challenges of systems and process design - standards are a really good idea. They give a consistent communication format for the different teams of people collaborating on projects. To them this information is ‘readily understandable’ and does bridge a communication gap.
For business teams though, this information will continue to be ignored for the simple reason that no process engagement means no process management.