Bruce Silver points out that it’s been 10 years since the finalization of BPMN 2.0, the standard notation that we use for modeling (and sometimes executing) business processes. The standard wasn’t published until some time after that, and there have been revisions over the years, but BPMN 2.0 was the start of a wave of standardization in the BPMS market since it included the notation (a serialization file format) that made model interchange between products possible. There’s always been some amount of controversy swirling around BPMN: some consider it too difficult for non-technical people to understand, some consider it too restrictive for technical implementations, and more. I believe that a subset of BPMN is a good tool for process modeling by business people, and that it’s a powerful process implementation tool for developers, but I agree that it’s not the only tool you should have in your toolbox.
Bruce’s post takes us back to some basic definitions of a process, and why BPMN is a better fit for modeling processes. He also covers some of the things that are not great about the standard:
The ability to understand the process behavior in detail simply by inspecting the diagram, unfortunately, was not top of mind in the BPMN 2.0 task force in 2010. They were solely focused on making the diagrams executable on an automation engine. But to most BPMN users today, precise description based on the diagram alone is much more important.
To help with the adoption of the standard, Bruce developed conventions for the use of the standard, publishing his BPMN Method & Style books and training. Some modeling vendors have even incorporated this into their product, so that you can validate your models against his conventions.
Regardless of whether you love or hate BPMN, it’s impossible to deny the impact that it has had on the BPMS market.
I couldn’t agree with you more when you say that a subset of BPMN is the best tool for business people.
As long as you define a common “process language” within your organization and don’t start from scratch (i.e. a subset of BPMN), you will reap the benefits of speaking a common language while keeping barriers to entry low for any new team members that need to learn your “language”.
If you’re using a BPMN and need to go to that granular level for automation, I still think you should maintain process models with your subset. As the main tool for process change discussions within the business, the value of this subset will be much greater than only maintaining the machine readable BPMN diagrams.