I agree that most business don't grasp the nuances of BPMN. One of the problems, or opportunities, is linear thinking. Most business and, for that matter, IT customers are not process oriented - they are task oriented. Most business processes are not as linear as knocking down a row of dominoes.
To your point on use of lanes, most processes involve concurrent tasks by other entities or technology. In order for business customers to truly understand and, indeed, manage these processes, we need to educate them on the processes and the opportunities for improvement.
Presenting a traditional flow chart to diagram the process can be followed by a more detailed BPMN drawing, if necessary, to illustrate the process in more detail. While taking a little more time, I find that this is useful when an opportunity for improvement or point of failure can be pointed out that the flow chart did not show. Otherwise, I use BPMN for my analysis to analyze the processes or business model, etc..
Not a BPMN expert; my preference is use cases, supported by activity diagrams, but there is a certain similarity between BPMN and activity diagrams.
So, I have 2 comments:
1) I would not show a use case activity diagram to a customer without first preparing them with a textual description of the activities that they are about to see.
2) In the flowchart diagram, how would you show the customer asking for a drinks menu 'at the same time' as asking for the specials menu?
There are reasons why flowcharts were dropped in preference of BPMN for business modeling.
Thanks for your comments!
@baldrick - If there's a potential for concurrent or parallell activities by one actor you can place all the possible activities between two lines (in Visio known as 'Parallel Mode'). However, if there are several possible activities but only one or more will actually occur I would use a Sub-Process/Pre-defined Process marker in the main diagram and then have a more detailed diagram depicting the possible options that could occur (e.g. decision gates to determine whether customer wants to order food, drinks, etc.).
On a similar note, I wrote this yesterday. I really do not know what inspired this .. the idea just came to me early one morning.
OR, since the URL does not display as a hyperlink
1 Why adoption of BPMN may not be a good idea
This article describes reasoning behind opinions about the direction that I see the BPMN standards heading. (These are purely my own opinions and since I do not have insight into the workings of the BPMN standards bodies, they may contain several misconceptions or even errors.)
1.1 A little BPMN history
BPMN v1.0 was released in 2004. BPMN 1.0 is adopted by OMG in 2006.
1.2 A longer history of Modeling Notations
(A personal experience.)
The 1980’s saw the adoption of Structured System Analysis/Structured Design (SA/SD or SSASD) languages for modeling software. SA was largely based upon Data Flow Diagrams (DFD) and SD upon structure charts. SA and SD are quite distinct notations, with SA, as its name suggests, used to describe the requirements for a system and SD, used to document a design.
The major problem with adoption of SA/SD is that the two methods use quite different notations, and there was no automated way to transfer from one model to the other. Once your Analysis model was complete, the Design model would be handcrafted from scratch and the only link between the 2 models is to capture traceability from the processes in the SA model, to the modules in the SD model. Maintaining traceability becomes a long and torturous process that no-one wants to deal with.
The early 1990’s saw the rise of a new modeling technique to replace SA/SD, named OOA/D. Object Oriented Analysis/Object Oriented Design, is based upon classes and class diagrams that are detailed with operations, attributes and methods. Operations are of a textual nature (but may be described with a formal language, such as OCL); methods are programming language specific and contain the shell for a software procedure and attributes are the data manipulated by the classes. In OOA attributes are a description of the data manipulated by the classes (again maybe using a formal language), and in an OOD model they are described in terms of the language that they will be implemented in.
The major advantage that OOA/D has over SA/SD, is that there is no paradigm shift between the analysis and the design models. Both use a large subset of the same language. This means that traceability may be made almost seamless by simply mapping analysis classes onto design classes.
So where does BPMN come into all this? The answer is UML!
Originally many OOA/D languages and notations were developed; notably Rumbaugh, et al and Booch. A company by the name of Rational, attempted to combine all notations into a single language and the result was the Unified Modeling Language, or UML.UML has since been adopted by OMG. Most of us analysts that are building analysis and design models today are using UML, or a variation of it. A nice thing about UML is that it does not impose icons for the notation describing the language, so that those people that like drawing their classes with rounded outlines or clouds, or colours, still can do so without breaking the rules defined by the UML specs. For many of us, UML was a godsend that put a stop to arguments between people preferring one notation over another in order to describe the same thing.
1.3 BPMN and UML
BPMN appears to have arisen from the opposite end of the spectrum, as it’s name suggests, the business. Now 20 years ago, there was little connection between business process modeling and system process modeling. Over the last 10 years or so, that gap has closed considerably, (the adoption of use cases by UML is a great aid to closing that gap). With the release of the Rational Unified Process (RUP), a method was described for modeling business process using UML too.
But, if business processes and architecture are modeled with BPMN and systems with UML, are we not heading back towards the problematic days of SA/SD?
Where is the traceability between the BPMN model and the UML (or system) model?
Since RUP has shown that UML can be used to perform business modeling and analysis, why do we need another nomenclature, such as BPMN?
1.4 A Solution
Now that I have possibly alienated all those advocates of BPMN, for business modeling, let me try and close the gap between the 2 notations.
As I mentioned, UML does not define symbols for representing it concepts. My guess is that the business is more concerned about the graphical representation of the business modeling concepts than the underlying XML definition. So, if we can find a UML representation for every concept in BPMN and adopt the BPMN icon to represent that concept, would the business really care whether it is called BPMN, or UML, or even BPUMLN?
This is just a start, but what I have done is to go through a list of core BPMN diagram elements and identify a substitute in UML. What I have found in BPMN are:
Events – Are descriptions of things that happen of relevance to the business process. Types are; Plain, Message, Timer, Error, Cancel, Compensation, Conditional, Multiple, Signal, Link and Terminate.
Activities – Are descriptions of work performed by the business. Types are; Multiple, Loop, Ad-hoc, Tasked and Subprocess.
Gateways – Are ways of splitting a flow of events in a process flow. Types are data based, event based, parallel and inclusive. (Complex appears to have no formal definition and therefore I am not considering it.)
Flows – Used to connect the above business concepts in order to show connections between them (In the main flows are directed in order to show the initiator of the connection). Types of flow are; Sequence, Message and Associations.
Data Objects – Are artifacts for capturing data used by the business process.
Swimlanes – Appear to be identical to the UML definition.
Groups – Represent a collection of swimlanes that are associated with a business entity.
Annotations – Ad-hoc textual descriptions of a business process.
Taking each of these BPMN types, the question is; is there an associated UML component that could be used in its place?
Events – UML contains various event types, but they do not appear to be as varied as those in BPMN.
Activities – UML contains the concept of actions, activities and tasks.
Gateways – UML has two types of gateway. The ‘fork/join’ and ‘decision/merge’ gateways.
Flows – UML recognises, process flows, object flows, event and sequence flows and associations.
Data Objects – UML includes objects and classes for capturing data.
Groups – Are a variation of the UML swimlane concept.
Annotations – Also in UML.
So, it appears that BPMN contains a lot more symbols than UML, but no actual concepts that UML does not include. The next question is; for every BPMN element, is it possible to stereotype a UML element including a recognized BPMN icon, such that all of BPMN is defined within UML?
If the answer to this question is Yes; then why not do it!
If the answer is No, then why not extend UML to include the missing BPMN concepts!
Either way, I believe that now is as good a time as any, to think about using a single notation for all of my analysis work.
Jarett, I couldn't agree more, and I've been saying the same thing about BPMN for years. My opinion is that business analysts can use traditional flowchart symbols for 90% of the business scenarios we face. To the point about concurrent activities, I recommend using the activity diagram fork and join notation. It works fine on a traditional process map.
Thanks Rich for your comments! Pareto's law does seem to come into effect with a lot of what BAs do - if I find that your basic process flows can't capture the level of detail you need, I ask if it's necessary to capture that detail in such a graphical format. Usually I find that in extremely complicated scenarios going to a written format is much more appropriate and helps out all stakeholders involved.
Jarett - coincidentally I have recently posted a blog comparing specific UML and BPMN modeling elements, with a discussion of pros and cons. Check out the Modern analyst MA Blog "BA ABCs: “B” is for BPMN at http://www.modernanalyst.com/Community/ModernAnalystBlog/tabid/181/articleType/ArticleView/articleId/1539/BA-ABCs-B-is-for-BPMN.aspx
I can see your point.
One thing to keep in mind is that in BPMN there are 3 levels of modeling abstraction:
and that not every model (or components of a model) should go through all 3 levels.
For the "business" discussions (...let's face it, all discussions are/should be business discussions;-).
I strongly recommend reading Bruce Silver's book "BPMN 2.0 Method and Style".
Just my 3 cents opinion,
Oops, unfinished sentence:
For "business" discussions (...let's face it, all discussions are/should be business discussions;-), the Descriptive model(s) may suffice.
Same Razvan :-)
Thanks for your comments Razvan. Based on Bruce's comments about descriptive modeling (http://www.brsilver.com/three-levels-of-process-modeling-with-bpmn/) I believe this to be essentially equivalent to what I described above using swimlane flowcharts. If you are ignoring rules for valid BPMN as he indicated in his post, then you are essentially using a standard set of symbols to convey meaning to your audience, which is the same as using flowcharts. I can see the potential advantage of using BPMN if there will be a need to delve into a more detailed analysis using the same models, since you won't have to do as much rework.
BPMN notation is good for IT system design. Before you get there though, you should surface the business processes the IT solution is to support and do so by using a methodology employing business oriented language and expressing the model in simple notation. The rigorous methodology has been around for quite some time, rebranded as Riva in 2005 (when it was augmented by Process Architecture) by its author, Martyn Ould. "Marty Ould has re-invented process modeling for the real world." - Howard Smith, Chief Technology Officer, Computer Sciences Corporation, European Group. See the title "Business Process Management: A Rigorous Approach".