BPMN – To Show IT or not to Show IT?

Knowing when to show automation and IT on a process diagram is a tricky balance. Show too much, and stakeholders will ‘turn off’. Yet the detail often does need to be captured. In this article, we discuss striking a sensible balance, and discuss how (and when) to show IT and automation.

When formally modeling a process with using an approach such as Business Process Model and Notation (BPMN), it is possible to show which elements of the process are automated, and which are manual. This can be very illuminating, as it shows the particular parts of the process that flow through without human intervention, and also the situations where additional effort is required. When looking to improve process efficiency, we may look at minimizing the amount of human intervention, focusing it on the cases where it is most useful and where the customer most values it.

Even processes that seem very ‘manual’ almost certainly have elements of automation and use of IT. If you take your car to a garage (auto-shop) for a service, the ‘core’ part of the process will be undertaken manually. Yet the booking, allocation of work, looking up of parts and even ordering of parts may involve automation, semi-automation and use of IT. You might have even booked your appointment online, without speaking to a receptionist! If we want to manage, monitor or improve the process, it’ll be important to understand these technological elements too.

BPMN and the use of IT in Processes

BPMN provides a number of ways to show automation and the use of IT. This includes the ability to denote different types of task (such as ‘manual tasks’ that are entirely manual, ‘user tasks’ where IT is used as well as ‘service tasks’ that are automated and call on some type of service). Additionally, it is possible to include a system as a lane within a BPMN diagram, and it is even possible to show data flows and data stores. An example of the visual notation for manual, user and service tasks are shown below:

One of BPMN’s significant advantages is that it allows these types of rich detail to be captured and conveyed. We are able to describe very precisely how the process should work. However, if we were to create a BPMN diagram for a complicated process that showed every single data store and data flow, every nuance of every piece of automation it would likely be a very busy diagram indeed. Stakeholders might find it very hard to read—and some stakeholders might not need to know about the details of the automation.

However, whilst this information can be specified within a BPMN model, even when it is specified it is not always necessary to show it on a particular diagram. There will be some audiences—for example systems analysts, designers and developers—who will be interested in the finite detail of how every piece of the automated process works. Other stakeholders—for example end users—might care more about where they need to interact with the system, the types of data that they will enter and retrieve and so forth.

It is worth considering this before presenting a diagram to stakeholders. The following suggestions may also prove helpful:

Lane: It is useful to show a system as a lane when it is necessary to specify the processing that the system undertakes. Showing it as a lane also makes it clear which ‘participant’ controls the system (as the lane will exist within a ‘pool’).
Data Objects/Stores: It can be valuable to see these in processes that are predominantly focusing on the processing data, particularly when data is input by one step (by one actor) and then retrieved or altered/processed further by another. Where an ‘as is’ process currently relies on somewhat ‘informal’ exchanges and stores of data (e.g. spreadsheets etc.) showing data objects can help achieve better clarity.
Task Types: It can be useful to use BPMN’s different task types, and when it comes to automation, particularly the manual, user and service task types can prove useful (others are available too which allow further nuances to be shown). However it is important to ensure that those reading or reviewing the diagram understand the symbols. As with BPMN generally, it is a rich and logical notation but more ‘advanced’ nuances are not always intuitive to those who have not worked with it before!

In summary, BPMN provides us with a rich notation and a common approach for modeling processes. It is possible to show the use of technology and automation—but as with any approach, it is important that we think about our audience when producing diagrams!

Learn BPMN 2.0 with Good e-Learning

Business Process Management (BPM) and Improvement (BPI) is now an embedded practice in all commercial organizations across every industry sector. It’s likely that you are here because you or your organization require training to support this need.