A common reason for examining an existing set of business processes is to look at improving them. As well as simplifying and streamlining the processes themselves, significant benefits can be gained from process automation. When automation is applied in a strategic way, that is sensitive to the overall process context it can help to potentially reduce processing time, increase quality and it reduces costs. Yet process automation is not a ‘silver bullet’. It is tantalizingly tempting to take a macro level view of a process and make the assumption that whole chunks of the process can be automated. There is a significant danger that without analysis of the detailed process, we might end up creating problems for ourselves in the long term—we might actually end up making things worse!
Let’s take an example—perhaps a manager is examining how to improve a hotel booking process that is currently managed manually using spreadsheets and other documentation. They may (quite rightly) observe that the process could be at least semi-automated, and there are undoubtedly software packages that will help achieve this.
Jumping in head-first might mean that we select a software package, and then go about trying to get it to ‘fit’ within the organization. We might then find that the software isn’t quite as automated as we had hoped… or that it doesn’t quite cater for the level of variation that the organization needs. Perhaps a Sales director needs the ability to manually alter bookings when a ‘VIP’ arrives, or there is a need to recognize (and differentiate between) individual bookings and group bookings. Implemented poorly, we now have a solution that is hindering the process and upsetting our customers. With an inadequate or poorly configured IT system, you can imagine a corporate customer saying:
“I don’t want 30 invoices; we’ve always had one consolidated invoice in the past!”
All of a sudden, it’s necessary for manual workarounds to be introduced, and we are pretty much back to square one. Inefficiencies emerge and the process starts to drift out of control.
However, these types of situations can be avoided by gaining a thorough understanding of the current process, improving it and simplifying it before automating, and then deciding where automation would be most beneficial. This approach also allows crucial conversations to take place when selecting an IT solution: It is important to consider how much of the off-the-shelf functionality will be adopted ‘as is’, and assess the implications on the processes.
Process modelling of any type will help, but the Business Process Model & Notation (BPMN) framework in particular is extremely beneficial in these types of situations. It allows us to create a single underlying model with multiple ‘views’. This enables us to start at a ‘macro level’ but then ‘zoom in’ to examine the particular areas that might benefit from, or be affected by, automation. Collaboration diagrams can help us understand the impact for other participants too, and the ability to show different task types (Such as service tasks, that are fully automated, or user tasks, where a user is interacting with an IT system) can help us to denote where automation takes place. The ability to show business rules tasks helps us to show where the decision logic sits—and we could link this to a decision model (using the Decision Model & Notation standard), or other decision artefacts.
Automation can yield benefit, but is certainly no ‘silver bullet’. Careful analysis, including an analysis of the existing (and desired) process is crucial, and the BPMN standard provides an excellent way for us to document and analyze the process.