Goo Goo Gaa Gaa BPMN
Fig 1: Goo goo gaa gaa BPMN
You got it. BPMN (that’s the graphic symbol in the baby’s speech-bubble above) is a language just like any other language. And languages are just about the most important asset we have. Without a language (sign/graphic/aural/written..) you cannot express abstract concepts. The more abstraction there is, the more important the language in making the intangible tangible.
Ergo: If you don’t have a common language your collaborative project will be a mess.
BPMN (Business Process Modeling and Notation) is the language of Business Processes. These processes involve time, people, domains, parallelism, organization, information…. you can’t get more abstract than that.
Ergo: trying to build, improve or even describe a process without a common process language, (BPMN being a good candidate) … will be a mess.
And as you see above, a picture (irrespective of quality) is worth a thousand words, so it’s no coincidence that the language of processes, BPMN, is a graphical language.
Returning to the natural language analogy, let’s say we settle on the language “English” to pursue our goal. That doesn’t mean to say we have to stick to one dialect or one set of conventions. Again, there’s a choice to make. For example the expressions LY2; best regards, forever your obedient servant… are all valid sign-offs but each would be inappropriate when used in the wrong environments.
Why am I writing up this obvious conclusion? Because there’s a general feeling that to be BPMN is an expert language best left to the real experts in the field who know all the connotations of the tiniest squiggle in BPMN to the detail level beyond the tiniest small print.
But that is not true!!! To use a language effectively you have to be creative, within the bounds of the context.
A simple “OMG” [1] expresses more than a twenty page article, in the right circumstances. But it’s still English. The same is true of BPMN. You can use just as much poetic license in BPMN as in any natural language. Don’t be shy. Don’t be timid. Don’t be intimidated. Just use it in whatever way you like, to satisfy your requirements.
Fig 2: Napkin BPMN
Look at the BPMN napkin example above. Purists might complain that there are syntax rules broken in this BPMN model. But the point is that this diagram achieves its goal, and describes the process better than a diagram that meets all the BPMN governance requirements (grammar – to you and me). Just like LY2, which #fails in many grammatical aspects, it is still English and can be more expressive than a longer more grammatically perfect equivalent.
The point I will make in this article is that BPMN covers the full gamut of the process spectrum, from creativity to precision, and that you can cover this complete spectrum by sticking to one single language.
Fig 3: Creativity versus Precision
The BPMN napkin diagram is a good starting point for describing the process – perhaps even enough to win the proposal. And you can use this very same diagram before triggering the process to discuss some of the details with friends, such as where/if a parental approval is necessary (I got that one wrong ;-) but that was before BPMN was invented ).
Being a descriptive language, it’s nearly always used in a collaborative environment. Napkins are fine as a starting point. But in a professional environment you’ll want an electronic rendering to follow the napkin/whiteboard in order to take it to the next stage where more and more detail gets added in an iterative way. Here you could use any desktop/tablet drawing software to capture electronically and occasionaly print. I personally prefer something cloud based for creative work because I like to have able access at any time, so I draw the BPMN diagram in SAP StreamWork using Gravity. It also offers you the chance to share online with colleagues (wherever they are) and lets them express their ideas in the same diagram. In addition - you’ll see later there’s another important aspect – it supports interoperability.
Fig 4: Printout from BPMN in SAP StreamWork
BPMN can also be used to express graphically to others what has already been determined in other non-graphic ways.
A good example of this is with SAP Operational Process Intelligence on HANA, where the process definitions are imported from different sources (such as SAP Business Workflow or the configuration tables of an ERP system) and converted to BPMN rendering so that the consultant configuring the dashboards can easily map different parts of the process to the phases rendered in the performance dashboard. Interpreting the BPMN graphic is much simpler than trying to customizing tables or intricacies of the proprietary SAP Business Workflow editor format. BPMN offers a common language, irrespective of the process-automation source.
Fig 5: BPMN in SAP Operational Process Intelligence on HANA
Another example is when consultants and integrators configure an SAP landscape. This is done in SAP Solution Manager, using a top-down approach (what systems has the customer purchased or planned to purchase) and how can these be configured using the different switches, ABAP programs and configuration tables in the IMG. Out of this the consultant can generate BPMN diagrams (again with a bit of poetic license to improve the expressiveness of the diagram ). The diagrams are easier to interpret at a glance than the textual descriptions of the pre-delivered SAP process fragments in combination with the customizing switches, as you can see in this example below.
Fig 6: BPMN in SAP Solution Manager
Incidentally, the same gravity graphic library is shared between the StreamWork tool and the SAP Solution Manager tool, even though they are in different domains (Cloud/ABAP) and follow different purposes. Sharing code is thrifty and good , but trying to do everything in one tool will mean you sacrifice creativity or precision.
Adding precision…
Fig 7: Precision versus Creativity
It’s unlikely that you’re a chronic polygamist and want to automate your napkin proposal process, but if you design or interpreting business processes on a regular basis the situation is very different. You want your business processes to run repeatedly, without disruption and without ambiguity. The processes drive a department or company, so the more well-oiled and consistently your company processes run, the better the department/company runs. Customers see it this way too. So the Grammar of the diagram becomes important. Loose grammar is fine in the creativity stages, but loose grammar beyond a certain point can lead to fatal consequences:
“A panda eats shoots and leaves” <> “A panda eats, shoots, and leaves” [3]
Figure 8: BPMN crossing your t's
This is where the BPMN experts come into the picture. They understand the deeper Grammar of BPMN. For example the difference expressed between a dotted line and a solid line (message flow and sequence flow) and they understand the consequences of the distinction. A good analogy is the difference between a layman looking a diagram of a house, and an architect. Process engineers are grateful for the early input of BPMN diagrams from paper napkins or StreamWork activities, but these experts will take the diagram to the next level and use this next level of BPMN Grammar/semantic when communicating with each other.
Companies invest money in training BPMN because the payback in being able to describe the process to the level of detail needed to make the process a success is easily justified. Bruce Silver training courses are a good example of this. And the beauty of this BPMN language is that the engineers can take this diagram back to the initial stakeholders without having to re-render it (just like the architect’s diagrams can be understood by the layman) even though the stakeholder will not perceive all the detail.
This next level requires different tools to add the detail. So it makes sense have an interoperable standard that supports the different tools so that the files/content can be transferred from one to another. BPMN delivers this by converting the graphics into XML. No-one reads the XML, but the tools can import it and render the results back into the graphic format. Of course you could skip the XML part and import the graphics by scanning and interpreting (like a sophisticated qrcode reader) but the XML rendering is digital and hence more reliable. Very little gets lost in translation.
The standard is extendable, so if the chronic polygamist requires a new step-type with the rose graphic symbol and semantics associated with it, then he/she could add it as an extension to the vanilla BPMN standard, or even propose that the standards body, OMG[2], adds it to their next version of the standard.
This interoperability capability of BPMN is the Holy Grail of process management. Consultants can now automate the process using software, and don’t have to rely on the people involved in the process to read and interpret the BPMN diagrams. You simply import the diagrams into your software, such as SAP HANA Cloud Integration or SAP NetWeaver BPM, and let that system get on with the automation.
Fig 9: BPMN in SAP NetWeaver BPM
Fig 10: BPMN in SAP HANA Cloud Integration
BPMN is the cad/cam standard for processes. But there will be a choice of automation tools to use, because of the huge differences between how processes are automated in different environments (for example integration processes versus human workflows). Nevertheless, the graphic view offered by these tools will be similar and should be based on BPMN.
Consultants use the different tools to add the necessary fine-tuning, configuration, exception handling to the process definition to allow the software to automate the processes come-what-may. So NetWeaver BPM, which is ideal for user-based workflows, offers a different (though similar) BPMN view compared to SAP HANA Cloud Integration, which is focused on system-centric integration and the processing of packages of information hurtling from system to system.
Relying on different tools which support the same graphical language is not specific to BPM. At the end of the day an architect’s office uses a different cad/cam tool than the car-manufacturer, even though there will be an early phase of the design where the diagrams may be drawn using the same graphic tool to render both the house and the car. But at the last phase, the tool used will be matched exactly to the goal in hand. It is the interoperability of standards and ability to expose in graphic form enables the initial designs to pass from phase to phase without keying in the data again.
So if you are involved in process design, be it for your department, for your company, or for your domain, don’t try inventing a new language. Use BPMN. Don’t being intimidated (just like you’re not intimidated by the sheer number of words and weight of an English dictionary). I recommend using the StreamWork process tool for the early stages because it will guide you as you go but it won’t dictate or cramp your expressivity. And it helps you learn as you go so if you activate syntax checks you’ll see hints about suggested improvements (just like in a word processor.)
I hope I have given you the courage to get started. Anyone can logon to www.streamwork.com, which you’ll find is the simplest way to get started. (Tip: Use the URL from the last question of this FAQ to avoid passwords.) I hope I have made it clear how important standards are. I hope you understand why there is no single tool that fits all, but SAP has done an extremely good job at supporting this standard and interoperability for the different tools it offer that play a role in process design and process execution.
[1] If you understood OMG to mean „Object Management Group” or www.omg.org, the standards body behind BPMN, then you might want to flush your mind before reading on)
[2] Pun intended.
[3] (ISBN 1592400876 by Lynne Truss)
