Business Process Modeling Notation (BPMN) to Communicate Business Processes

[Peter Fraser]

Does anyone have an opinion on the use of the Business Process Modeling Notation (BPMN) as a means to communicate business processes?

I understand that part of the public sector in England and Wales is having BPMN-compliance specified as a requirement of any software they purchase to define and communicate their processes, but at first glance it seems far too complex to provide a simple, standard way to communicate with most staff.

I see from Wikipedia that: "The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes".

This list seems to me to be a very limited subset of "all business stakeholders". Does anyone use BPMN, and if so for what?

Many thanks.

[CarolX]

Any thoughts from the group?

[harry]

Introduction to BPMN is attached for those interested to know what it is.

[Peter Fraser]

CarolX / Harry

Thanks for the prompt - I think that I will take the lack of response as an indication that there are not many users out there!

[Patricia Ravanello]

In Reply to Parent Post by Peter Fraser

Does anyone have an opinion on the use of the Business Process Modeling Notation (BPMN) as a means to communicate business processes?

...
This list seems to me to be a very limited subset of "all business stakeholders". Does anyone use BPMN, and if so for what?

Many thanks.

Hi Peter,
Thanks for posting the information about the BPMN. It aroused my curiosity. I looked at the article and the samples which they used, and there didn't seem to me, to be anything particularly remarkable or innovative about it, other than the attempt to standardize the use of symbols in flowcharts. I see that it was written by Stephen White from I.B.M, so I gather that there was some rationale for computer software developers to propose a methodology to ensure that they are creating software that does what their customers want...and that the customers understand what they are buying. It seems that the proposed BPMN is to be the common "vehicle" for communication. It would appear to have some merit in that regard.

The article stated that it took 2+ years to develop it, and it looks like something developed by a committee...and overworked. I would tend to agree with you that it appears too complex to be readily utilized, but then, there always is a learning curve with any new methodologies.

Anyone who uses MSVisio Software is already familiar with the generally accepted symbols for "activities", "decisions" etc. The stencils in MSVisio already do what the committee has re-invented. Perhaps they just want to ensure standardization in the use of graphic elements and to establish some basic models...kind of laying the groundwork for communication.

As for using it...without being aware of it, I would say that I am using a very similar methodology (see attachment). I use flow charts to define all Key processes, and where time permits, I often develop flowcharts for the drill-down activities or "Work Instructions" which are referenced in the Flow Charts. One thing I don't like about the BPMN is that they add a lot of text outside of the "stencil shapes", and I think much of that information can be incorporated into the text inside the "rectangle" or "diamond" or whatever. My sample includes a shape for "input" on the left of the activity and "output" on the right. I also include a colored rectangle for the "reference standard" (ISO/TS, ISO 14000, Customer-specific reqt's, etc.). This sample looks busy but in MSVisio you can include or "hide" any grouping of elements to simplify the flow chart...and customize it for your audience. This particular view is used by Internal Auditors to provide reference to applicable standards. It also demonstrates the use of "swimming lanes" to distinguish activities performed at a "Sales/Design Site", vs. the "Manufacturing Site". Activities which are shared straddle the line (something the BPMN model doesn't mention).

I find the information in their "Activity" rectangles too vague to be useful, and, from my perspective, would require the creation of supporting "narrative" documents that would tell the user what they have to do. They don't reference input and output documents either, which means, you'd have to go elsewhere to get more detail.

I think that a lot of companies have utilized similar methodologies to initially achieve certification of the ISO family of standards, but now that the dust has settled, they are finding that these documents are too vague, and not comprehensive enough to be used as training tools, and are poor audit tools, unless you have very well-developed internal auditors. I think the BPMN is not bad for a "first kick at the cat", but I think it is of limited utility.

...and there you have it...MHO.
Thanks again for opening the discussion.

Patricia

[pldey42]

In Reply to Parent Post by Peter Fraser

Does anyone have an opinion on the use of the Business Process Modeling Notation (BPMN) as a means to communicate business processes?
...

I see from Wikipedia that: "The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes".

This list seems to me to be a very limited subset of "all business stakeholders". Does anyone use BPMN, and if so for what?

Many thanks.

I'm no expert on BPMN but as an ex-software engineer these days active in the ISO 9001 world, I think your question actually contains the answer. It seems to me that BPMN is designed to be used when one wants to automate a process using computer software. Although it could be used to communicate the process to everyone, that's not its purpose -- and yes, it's probably too bloated for that.

We're all familiar with horror stories of people being given wonderful new software tools that are supposed to make their lives easier, only to find that now they spend half their time persuading the tool to do what's necessary, or calling supervisors to okay the workaround. Often the reason the software is so bad is that the requirements for it are poorly specified, because the details of the process it's supposed to be supporting are too vague.

It seems to me that BPMN has been developed to help address this need. Yes, it's complicated but so too are the details of processes, and it's necessary to be precise about them prior to writing the software that will support the process.

In the pdf there are references to OMG and UML. OMG is a software industry standardising forum, and UML is a diagram notation that's used to 'draw' the internal design of software, like a blueprint which guides the writing of program code. It appears that the idea is to be able to draw diagrams that show the both process and its software automation, and that ought to be a good way of ensuring that software does what it is supposed to do when it's written to support a process.

This would explain the limited audience for BPMN. You use it to specify a process in sufficient detail for the software engineers to automate it. You check the diagrams of both the process and the software to make sure that both human and automatic operations are correct, interact smoothly, and that all possible combinations of events (likely and unlikely) are properly catered for. Then you write and test the software. Finally you use something simpler to explain the now-automated process to those that will operate it.

Hope this helps,
Pat

[Peter Fraser]

Patricia and Pat

Many thanks - you are confirming what I was already thinking. As a tool for describing a process in detail, for a specific purpose, it may work, but my concern is that (part of) the public sector in the UK is being driven to use it for describing and communicating complete sets of processes. I don't think that it will work too well for that!

I believe that there are ISO standards for flowcharting (which are not universally followed), but I think that it is more important that people understand the output than that they comply with strict standards. The oil & gas industry uses RACI (Responsible / Accountable / Consulted / Informed) to describe people's involvement, and I am not sure that there is a universal standard for that - but it works well for the reader! [We have modified it slightly so "A" means "Assists" - see attached]

I wonder sometimes if there is too much focus on "flowcharting" at the expense of just getting a clear message across.

[Willem]

Try Microsofts "Visio professional 2003" for flow charting. I've used it with my procedures. It is very user friendly. Easy to use. All you need for flowcharts are in there.