Process Is Not Just A Flowchart (or A BPMN Model)

A Process is Not Just a Flowchart (or a BPMN model) The two methods of representing process designs that I see most frequently are process drawings (typically in Microsoft Visio) and BPMN models (and often Visio drawings of BPMN). It is probably a good thing that more people are documenting their processes and that they are also turning to a standard notation such as BPMN. However, neither of these representations really describes all you need to know about processes. We need to think about more than just the process flow. In my BPTrends Column, "What Makes a Good Process?" [1] I introduced the idea that a process model must described by three key aspects (See Figure 1): The definition and sequence of tasks The resources needed to operate them The business environment in which they operate. Trigger Product Role Data Activity Data IT system Risk Decision Outcome 1 Outcome 2 Figure 1. The Three Aspects of Process Design 1

The Tasks The main elements of a process, and the most familiar, are the tasks or activities that when linked together into a sequence create the process flow that delivers some value to the business. This is what most people concentrate on whether they are drawing in Visio or using a BPMN modeling tool. Of course, there are different types of activities; some represent manual tasks done by people, others automated tasks done by systems. Often this will be all that many people describe, but some tasks represent decision points that change the process flow. A correctly designed process flow should not just consider the "sunny day" scenario (i.e., what happens when everything goes right), but also take into account potential failures and alternative scenarios. In reality, you can't model every possibility so you need to concentrate on scenarios that have significant impact on the customer (or end user of the process), on costs, and on business risk. It would be a step forward if all people responsible for processes did, in fact, produce rigorous well thought-out designs that covered the most important eventualities. Unfortunately, many of them don't. However, even when a good quality process flow has been created it is not the whole story. We still need to consider the resources and the business environment. The Resources A process is not just a theoretical concept; it must be turned into a reality that will deliver benefit to a business or an organization. To create that reality you have to implement the process, and, hence, the process design must consider the resources necessary to carry it out. Typical resources include People IT Systems Business Capabilities or Services Data Equipment Consumables It may well be a sensible first step to design an idealized process without considering resources. However, it’s only when you starting thinking about the resources needed to implement the tasks that the process starts to come alive. Quite often you will realize that the resources needed for a particular step in the process are not yet available so the process will need to be modified to add extra steps to obtain that resource. In addition, when talking to people about the manual steps they perform, and what they need to undertake them, they will often tell you of other activities that are actually part of the process. I have found that a good way to develop a process when working with stakeholders is to first produce a quick “rough and ready” view of the process flow. Then to go back and revisit each step, adding the resources and modifying the process flow as a result of the extra insight gained. Another useful approach is to consider each process step as a transformation. The task must take an input and turn it into an output (see Figure 2). So some of the resources mentioned above can actually be thought of as inputs and outputs. 2

Is input for Data is changed by Activity Data Figure 2. The Process as a Transformation For most non-manufacturing processes, these inputs and outputs are, in fact, data. Very few people actually model the data being “processed” by their process, which I believe is a major shortcoming in process designs and leads to many of the “process failures” encountered in organizations today. Failure to consider how the data flows through the process, and the lifecycle of the data, results in missing data, duplicated entry, error, and poor data quality. The Environment I have already mentioned that the purpose of a process is to deliver value to the business or organization. While the sole purpose of some processes is to carry out internal functions (e.g., Finance or HR), the core processes of the business must deliver value to someone outside of the organization. It is the delivery of this external value that generates revenue, which enables the process to deliver value to the organization. As a result we can't design a successful process without understanding the business objectives, products, and outcomes that the process must deliver. A vital part of understanding how well the process achieves these aims is the definition and allocation of measures (KPIs). Furthermore, in the past few years a number of high profile corporate failures, not to mention the world-wide banking crisis, have focused people's attention on risks. Initially, this was financial risk, but increasingly people are considering all sorts of operational and business risk. These environmental aspects of a process are not necessarily considered in detail during the initial design of the process. However, it is essential that the verification and validation phases of the design ensure that these aspects have been defined and taken into account. A Model is More Than a Drawing In the previous sections we have seen how it is not just the sequence of tasks that is important, but also the resources and environment that relate to the tasks and the process. Capturing this information is essential to producing good quality process designs, but is often more than can be readily represented on a single drawing. Furthermore, a key benefit of capturing this information is the ability to undertake enterprise-wide analysis of this information (e.g., "How many processes are supported by this IT System?" "What risks are associated with this process?" "What tasks are carried out by this role?"). The consequence of this is that creating process drawings using a graphical design tool is not adequate for designing any serious business processes. What is required is a process modeling tool that enables you to create multiple models based on a repository where all the business entities we have discussed in the previous sections are represented by objects in the repository. In this way we can represent the enterprise and its processes using a variety of process models. We can analyze and report on the relationships between these entities, and we can extract information from the repository to generate documents, create Intranet portals, and support implementation. Why BPMN is Not Enough For many organizations, BPMN is becoming the modeling notation of choice, especially where the models are likely to be used by the IT Department for automation. In many respects, this makes good sense as BPMN was specifically designed with IT implementation in mind and contains many constructs that support workflow (e.g., looped tasks, time-based triggers, etc). However, the current BPMN notation does not support the richness of objects that can describe all the business entities we have been discussing. 3

Of course, Pools and Lanes may be used to represent organizations and roles, and data can also be modeled in BPMN. In theory, it is also possible to model other business entities using artifacts, but people rarely do, and there is no direct way to model and analyze the relationship of a process to risks, roles, IT systems, etc. As a result, BPMN only really fulfils one of my criteria for a good process design – the process flow part. This is not to say that we shouldn't use BPMN, but that it is not the whole story. Process Design Requires a Rich Modeling Environment So we can see that just creating a simple flow chart or a drawing using a BPMN template is not creating a process design. It is comparable to trying to design software by writing the code out by hand, something that nobody would dream of doing anymore. In order to create high quality process designs that can be implemented manually or automatically, we need to produce those designs using a rich process modeling environment. Such a repository-based environment should support a range of different notations (BPMN, UML, EPC, etc.), industry standard frameworks (TOGAF, SCOR, TMF Forum, etc.), and allow true hierarchical modeling (see Fig. 3). The notations should be integrated so that it is possible to be fully compliant with standards such as BPMN or UML while at the same time being able to enrich them with relationships to other business entities. Only when we can convince organizations to employ process professionals and use professional process design tools will businesses get the quality of processes they need to ensure effective business performance. Figure 3. Hierarchical Modeling Including BPMN 4

References [1] Rob Davis. What Makes a Good Process? BPTrends, Nov 2009 ------Author Rob is a Senior BPM consultant with Software AG, which merged with IDS Scheer in 2011. He is an internationally recognized expert in Business Process Management (BPM) and the practical use of the ARIS Design Platform. Previously, Rob worked for British Telecom (BT) where he was responsible for selecting and implementing ARIS in a large-scale implementation. Rob has built extensive experience of all aspects of BPM and specializes in providing consultancy on BPM, process modeling and design, architecture and frameworks, process governance, and integrating process and IT design. Rob has written three definitive books on the practical use of ARIS Design Platform for BPM. For more information, see http://www.rob-davis.co.uk. BPTrends Linkedin Discussion Group We recently created a BPTrends Discussion Group on Linkedin to allow our members, readers and friends to freely exchange ideas on a wide variety of BPM related topics. We encourage you to initiate a new discussion on this publication or on other BPM related topics of interest to you, or to contribute to existing discussions. Go to Linkedin and join the BPTrends Discussion Group. 5

Rob is a Senior BPM consultant with Software AG, which merged with IDS Scheer in 2011. He is an internationally recognized expert in Business Process Management (BPM) and the practical use of the ARIS Design Platform. Previously, Rob worked for British Telecom (BT) where he was responsible for selecting and implementing ARIS in a large-scale