Business process modeling has been practiced within organizations for a long time for a variety of purposes, such as documentation or workflow implementation. Flow charts, functional flow diagrams, control flow diagrams, activity diagrams and Gantt charts are a few examples that have been commonly used during the last twenty years. The recent introduction of legislative frameworks, such as the Sarbanes-Oxley Act, further contributed to an interest in business process modeling as a way of capturing and graphically documenting the processes of an organization. Process modeling is also widely used within organizations as a method to increase awareness and knowledge of business processes, and to deconstruct organizational complexity.

There are several approaches or methodologies for creating process models and there have been several consortiums that have attempted to standardize these approaches, of which some have been more successful than others. OMG or Object Management Group has been the most widely accepted so far and the BPMN (Business Process Modeling Notation) has been adopted by many software vendors providing tools for business analysts to model these processes.

Whatever the methodology, traditionally a business analyst would talk to the business owners, gather as much information as possible to understand the process and then draw it up in a tool like Visio. If and when the process needed to be automated, that diagram would be passed on to the implementation team. Even though that approach worked, an inherent problem was that there were still several unanswered questions that the technical team needed to ask from technology point of view to implement it. Often enough a back and forth cycle would occur with the analyst as a go-between, but sometimes that introduced gaps between what the business wanted and what got delivered. To overcome these gaps, business analysts spent thousands of hours sitting down with the technical teams to find out what they needed to collect from the business owners. In many organizations this effort resulted in functional and technical requirement document templates. These templates were then used when collecting requirements for business process automation. The problem still was that every business process was different and therefore needed different questions answered.

As the collaboration technologies became popular in the last few years, businesses also realized that there was definite advantage in opening up the communication channel between business users and technical teams. They understood that even though business analyst is a useful role, having a technical team representative in those meetings with the business assured that the requirements were understood and delivered better. Organizations that adopt this approach find a competitive edge over those that do not. The ability to excel in key business processes sooner and more accurately gives them what they need to get that competitive edge.

Besides minimizing gaps, having technical teams involved in the process modeling from early on in the cycle offers another big advantage. While a diagram representing the business process is the primary goal of the exercise, a process model is more than just a diagram. A properly done process model should follow a standard like Business Process Modeling Notation (BPMN) so it can be understood by various tools without alterations. At the same time it should also be clear and logical to be understood by fellow business users in order for them to reuse the same model if needed. Quite often modelers tend to put all the details on the first layer of the model which makes it difficult for others to understand. On the other hand a process model not drawn according to the BPMN standards may not be readily consumed by a Business Process Management tool.

The collaborative effort allows modelers to deliver an end result that has both the right semantics and the logic of the process. Some SaaS based tools make it very easy for different teams to work collaboratively. Not only that a business owner and a technical team representative can see what the business analyst is drawing while the process is being drawn, but they can all make modifications to it at the same time. The tool also allows users to chat from within it if they are not already over the phone talking.

Creating a process diagram that would be read and understood by both business users and technical team has always been challenging. Business users generally know all the details so well that they want them hidden on the diagram, whereas technical users require all the details shown in order to implement the process correctly. A good process modeling tool resolves these tensions by providing different views of the process: a simpler business view that is suited for a business user and a technical view that has full control over the behavior of each step. A business user and a technical user could therefore be looking at different views of the same process model and still work collaboratively to make sure they capture what is wanted by both teams.

A good modeling tool also captures the context of different pieces of the process. But to make sure that the model can still be understood by someone looking at it later, it is equally important that it is logically clear and has labels to reduce ambiguity; labels should be put on everything including events, sub-processes, tasks or activities, rules, roles, decision gateways and lines connecting various artifacts of the process. Assuming that a line doesn’t need to be labeled because it is obvious could lead to confusion at a later point.

As a best practice, label all human activities or tasks based on the action that the owner of the task would be performing. For example, Create Request is a better name for a task than Request Creation. This emphasizes that some “work” will be performed as part of that task. On the other hand, a system task should be labeled Email Notification rather than Notify via Email emphasizing that the action will happen automatically. This also clearly distinguishes human tasks from system tasks.

A common mistake when creating process models is the use of routing actions as tasks or activities. Routing is part of a workflow system so it doesn’t need to be called out as a task. For example, having a task named Send for Approval is not a good idea. The line between two tasks already indicates that some work is being sent from one to another. Besides, the keywords “Send” and “Receive” should be reserved for tasks communicating with external systems indicating sending or receiving messages to or from those systems.

A good process model has several layers representing the cross-functional hierarchy a business process typically has. Capturing a complex business process using a diagram that fills up all four walls inside your office only makes the implementation of it that much complicated. A business process model should be created in several layers using a top-down approach. Start at a high level and nest the sub processes so it is broken down into layers. Keep in mind the possibility of reuse of these layers from other similar processes.

An important point to remember when layering the process model is to show message flows in every layer that it needs to trickle down to. Message flows represent any exchange of messages or events between your process and any external process. Message flows, unlike activity flows, are not considered repetition even if repeated in process layers. But just like activity flows, message flows should be labeled properly to show the business context representing the exchange with the external system.

Exception paths should be drawn out after the happy paths are completed, sometimes even in a different iteration of process modeling. This is true for both main process diagram and any sub processes. As a best practice, use separate end events for the happy path and the exception path in a sub process. This approach will help handle the exception paths separate from the happy paths. The exception handling activity flows should be captured as their own sub processes which can later be reused by other processes to handle similar exceptions. Using exception handling sub processes like this also allows the attachment of message events to the entire exception handler.

Lastly, when drawing out the process model, adopt a phased approach. Quite often, business analysts or IT personnel do not consider a process model as complete until it has captured every single detail of the process. Even though there is nothing wrong with that approach, a process modeling exercise does not need to be that lengthy. If the scope is broken down into phases, it is much easier to see early on if something needs to be changed.

A good process model is always a work in progress. Modern BPM products incorporate sophisticated monitoring, process analysis and optimization features, allowing the organization to quickly optimize the processes across the enterprise, rather than simply routing work and documents between employees. A process model should be designed with the idea in mind that it will and should change as the business adapts and evolves the operating procedures over time.

These guidelines are not required by BPMN specs, but will ensure that the process model created is understandable by both humans and BPM tools. Following these suggestions will allow you to create the next top business process model for your organization.