Doing BPM right requires the right modelling language
Business process management (BPM) - done right - has a long history of proven success. However, doing it correctly requires the use of - and fluency in - the right modelling language.
That's the view of the co-authors of Maximizing Return from your BPM Investment: Bruce Silver of BPM training and certification provider, BPMessentials; and Katharina Clauberg of Signavio, a developer of Web-based collaborative BPM software.
"Everything in BPM begins with process modelling, describing the process flow in the form of a diagram. Whether it's simply documenting your current-state process for compliance, analysing your process for potential improvement, or redesigning an improved future-state process - either with or without the use of a BPM Suite for automated workflow and performance monitoring - you need to capture the process logic in a diagram," they said.
They caution against recording the process steps in text, warning that that merely creates "shelfware" - a pretty document that people rarely bother to read. However, recording the process logic in a diagram allows for easier collaboration between all those involved in the BPM project.
According to Silver and Clauberg, the swimlane flowcharts created in standard desktop tools like Visio or PowerPoint, which were the staples of process improvement teams for many years, are no longer good enough.
One of the major problems with these flowcharts is that the flowcharting shapes used usually lack a well-defined meaning.
"Each modeler makes up his or her own meaning for them, so the resulting diagrams are subject to personal interpretation," they explain.
The development of a standard business process modelling language would quickly resolve that problem. However, there are several competing standards for business process modelling languages used by modelling tools and process.
Everything in BPM begins with process modelling, describing the process flow in the form of a diagram.
Silver and Signavio believe the most effective of these is business process model and notation (BPMN), a standard graphical representation for specifying business processes in a business process diagram that includes execution semantics alongside the notational and diagramming elements.
One of its main advantages is it can be used and understood by both technical and business users, including the business analysts who create and refine the processes, the technical developers responsible for implementing them, and the business managers who monitor and manage them.
BPMN therefore serves as a common language, bridging the communication gap that frequently occurs between business process design and implementation.
"BPMN looks like traditional flowcharting, but the precise semantics of its shapes and symbols mean it comes with rules about the right and wrong way to express pieces of process logic.
"Using it correctly therefore requires 'following the rules' - both the official rules of the specification and the 'style rules', conventions that ensure diagram clarity" they say.
According to Silver and Signavio, because BPMN is so widely used, and because many of its symbols are so intuitive, it's not unusual for users who are less than fluent in its use, to make potentially costly mistakes.
"While BPMN processes are composed of only three basic shapes - activities, gateways, and events - the language provides hundreds of variants of those shapes based on various markers, icons, and border styles attached to them," they explain.
In addition, BPMN changes the meaning of certain shapes and symbols from their traditional usage in flowcharting. A diamond shape, for example, in flowcharting typically makes a decision, but in BPMN only an activity - the rounded rectangle - can make a decision. The diamond, called a gateway, only tests the decision, branching one way or the other depending on the result.
"Following the BPMN rules is not difficult, but it requires training and use of the right tools," they conclude.
For more info, go to https://www.signavio.com