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
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.