Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Process Modeling standards: Is it simplifying modeling or creating more confusion?

Category : BPM
The reasons why industry standards are created are clear enough. It brings a degree of consistency of usage, lowers production & service costs and improves user experience. However, what has been very successful in several industries has been relatively less successful when it comes to information technology. This is especially true at the business-technology interfaces.
The "standards" wars in IT have been fierce and often tend to confuse end users. While “standards” focus on brining uniformity, IT vendors want differentiation. This contradiction has caused several standards on the business-technology interface like BPMN to be interpreted differently creating additional silos. While adopting BPMN standards, modeling and BPM tools have adopted “tool specific” variations defeating the core reasons for modeling standards. If someone tries working across a variety of BPM/Modeling tools, one realizes the extent of this problem. The tools and the resultant file formats refuse to work with each other requiring additional transformations and re-work. The excuse from vendors has been that “our” tool provides additional capabilities to more accurately capture processes.

While differentiation is required, it has to be a layer over the standards which need to be adhered to by the letter. In a recent project, we were faced with auditing a series of process models across various modeling streams. The project team was working in multiple streams to create the process models on a popular modeling tool. The tool however had several differences with standard BPMN. Since it did not satisfy all the requirements for end to end process management and traceability, they decided to move their work to another platform mid-way. The new platform too had its own peculiarities and differences with both BPMN standards and the existing modeling platform. On top of that, the various teams had come up with models that neither looked similar (in terms of detailing) nor followed the same standards. While the teams had experienced modelers and domain experts, lack of standards forced them to adopt what they felt “right” in their respective teams. Does it not sound familiar?

To deliver a consistent modeling framework within an enterprise, the critical starting point is to establish a set of modeling standards at an enterprise level. And yes, it is ok to vary your standards from BPMN but each deviation and change has to be documented and communicated. For ex. In order to improve readibility you want to color code "linked" processes in a particular color while using the standard arrow symbol for linking processes. This will work as long as it is agreed upon and part of your enterprise process modeling standards. This way we would have managed to adhere to BPMN standards while making process maps more readable.
I believe that organizations must ensure the following to deliver consistent Enterprise modeling standards. The modeling standards documents should capture
  1. Modeling standards document – This is an Enterprise guidebook that allows everyone to have a consistent understanding of processes within an organization. It is unique to an organization. The standards document need not follow BPMN to the letter but can leverage the BPMN standards as the base
  2. Process levels: Processes follow a certain hierarchy so that overall enterprise visibility and readability is not impacted. It is critical to define clearly the level of detail required at a particular stage in the modeling process. Ex. Level 1 represents Main Processes flows within the End to End Process Streams( e.g. S2P: Sourcing + Procurement + AP + T&E + Audit & Recovery; O2C: Order Management + Order to Cash + Customer Operational Management). There is a tendency among different modeling streams or teams to interpret this differently. As a result we have process models having the same level but detailed differently. While there are best practices, the enterprise is free to define its standards.
  3. Grouping of processes – there is no correct way of doing this. Some modelers do it by line of business, functional area or cross-functional area etc. However it is important to always take an enterprise view of processes, so that processes can act as pieces of a zig-saw that fit to provide a clear view of how processes interact across business units, functional areas and individual departments.
  4. Labeling standards – Poor labeling has been the bane of process models. It is an area which has the least amount of standardization. This makes the same process made by 2 different individuals radically different. It is critical to define naming conventions for event, decision gateways, messages etc.  Events including start and end must clearly describe the activity being performed ex. Initiate Customer background check.
  5. Color coding - BPMN does not specify specific color coding standards. Colors make the process model much more readable. Ex. We can color code manual activities as grey. Based on the tool selected and enterprise preference, certain color coding can improve readability significantly.
  6. Annotations – There is significant number of assumptions and back ground information that is critical to understand or audit the process at a later time. Using annotations in a standard way to address this improves process readability
  7. Decisions – There is considerable confusion around which gateways to use. Clear understanding to each type of decision gateway is very important. It is also critical to detail the decision parameters to ensure there is no confusion.
The list could go on and on. But ultimately the devil is in the detail. Just capturing a process is not sufficient, it is important to gather enough detail around the process parameters - service level agreements, cost, time, resources etc. so that the processes can be simulated and improved. It is important to remember that the idea of process modeling is to ensure everyone has common and consistent undertanding of the process and the model can then be used to deliver business results.

About the author

Tanmay Dey
Tanmay Dey
I help define BPM strategy and solutions for customers especially around how BPM interacts with various technologies including MDM, Analytics, Social media and cloud
2 Comments Leave a comment
Thanks for an excellent post about the importance of teams to standardize on the right "approach" before proceeding with process modeling. Just deciding to use BPMN is not sufficient, there should be agreement on meta-data such as hierarchy/levels, grouping, and most importantly the details of documenting the process rules. As correctly mentioned, most tools offer support for BPMN but it may not be 100% compliance so there is lot of room for differences just as far as process diagrams go. Further, there is no standard for process documentation which makes the exercise even more difficult. In our continuous improvement team, after lot of research, we decided to use AccuProcess Modeler ( It is probably the easiest to use modeling tool for business people and it standardizes on both the process diagram and documentation. It also makes it easy to navigate between different levels of process models and, importantly for us, allows import of existing Visio process diagrams which saved us a lot of time. Standardizing on the tool is a great way to initially standardize on the correct approach. Thanks, happy process modeling to all. = Kathy
tanmdey's picture
Thanks kathy for the encouragement. Process modeling means many things to many people. As long as we know what we want, tools are just means to the end. happy modeling :)

Leave a comment

Your email address will not be published. Required fields are marked *.