© Copyright 2018 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd.

BPMN and the Importance of a Shared Process “Language” by Adrian Reed

Process models can be an excellent way of concisely communicating information about how work ‘flows’ through an organization. Yet if there is not a common understanding of the notation, then misunderstanding and misinterpretation can occur.

In this article, we explore the value of using a common ‘language’ in our process modeling.

Download hundreds of FREE BPMN resources at Good e-Learning today!

www.goodelearning.com/downloads

There are many reasons why we might choose to model a process. A well-defined process model can be an excellent starting point for understanding how a process works, to look at optimization or improvement opportunities, and to manage the process more generally. At their essence, process models are crucial communication tools—they help us to discuss and concisely convey important information about how work should ‘flow’ through an organization, as well as defining what should happen when exceptions occur.

As with any type of communication, issues can arise when ambiguity creeps in. Similar issues exist when communicating in written English. A statement such us “The form is passed to the investigation team once the customer has provided details” leave many important questions unanswered such as who completes the forms, whether it is validated, and what happens if the form isn’t completed.

This type of ambiguity can create a whole range of issues for operational processes. There may be disagreement over precisely who should undertake particular elements of the work, meaning that it doesn’t get done (or it is done inconsistently and begrudgingly by the team that has to respond when a customer complains).

BPMN Series #39 | ATL001:39

© Copyright 2018 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd.

It can lead to an inconsistent customer experience, with different team members interpreting the process very differently. If parts of the process are being automated, it could even lead to a situation where those designing, coding or configuring the automated system have a very different understanding of what is required, leading to a system being implemented that is very different from what we expected.

This highlights the importance of precision, and a shared language. I suspect many people reading this blog will have, at times, created process models using nothing more than sticky notes and lines on a whiteboard. These can be useful models that convey a lot of useful information (I use them all the time, they are a great starting point). However, we may find that different stakeholders make subtly different assumptions about the specific meaning of elements of the notation. Take the following example:

Task 1

One stakeholder might assume “after task A is completed, work starts in parallel”. Another might assume “task A contains a set of rules that determine what happens next”. A conversation with the relevant stakeholders will clarify this, and it is often useful to have a way of unambiguously recording the desired process logic.

When we want to convey more complex information, using a formal approach such as Business Process Model and Notation (BPMN) can be useful. BPMN is a rich “language” which provides us with the ability to create a detailed model that can be viewed at different levels of abstraction. It enables us to create detailed views of processes (with every nuance shown) for those that need it, whilst also having a much higher level view for those who only need an overview. It enables us to show interactions and communications between actors, the flow of the process, activities, events, messages, exceptions and much more.

Yet, just like any language, it is only effective for communicating between people that understand it. BPMN might look similar to other notations, but there are important differences. If we send a BPMN diagram to someone who isn’t familiar with the notation, there is a possibility they will misinterpret elements of it. These types of issues can be overcome by adopting a standard approach to modeling, and ensuring that people receive the relevant training. The type of training required will vary by stakeholder—someone who has to read a high level diagram very occasionally, may need a quick informal walk-through. Those who are working with BPMN all the time will likely need more formal training. There are many excellent classroom based and e-learning options out there.

With a common Process “language” we can communicate more effectively. We will still need to talk, debate and refine parts of the process, but those conversations will be more targeted as we’re able to communicate concisely and precisely with the diagrams we create.