I’ve had a view for a number of years now that a process cannot be described with just a process map.

Well, not in its entirety. A standard process map usually consists of rectangular boxes linked with arrows. Better process maps have some variety in the size and shape of boxes representing the variety of actions and decisions that occur at the process steps. When good, these process maps conform to BPMN, UML (Activity Diagrams) or other similar standards. When bad, there can be missing outcomes from decision points, missing references to other processes or references to missing processes and so on, the list goes on.

How Deep?

However, no matter how good the process map, they cannot completely describe the process. Take the instance of capturing an AS-IS process, perhaps during the check phase of lean systems. A process map would only give a brief description (1 to 20 words maximum usually) of the process step in question. Just as a process can be broken down into process steps, process steps can often be broken down to a further level. And then those steps can be broken down again. In practice, there’s a point of diminishing returns after which you decide that enough detail is enough and that to gather more detail, although useful, would not be cost-effective. So it follows that no matter at what level you stop when looking at business processes, there’s always a level of detail that you’re missing. There are exceptions to this, for example when designing circuits, then the process steps may well be atomic. In most cases with business processes, there are further, more granular levels.

BPMN and UML Activity Diagrams are good at showing relationships between steps, including the order and control flow of the process steps and how they link together. That’s useful and should be used. The process maps should be consistent with the standard that the author is using. So make sure that if follows the rules. Simplistically, any decision point has to have at least 2 outcomes. If it has only one, then there wasn’t a decision. How does the standard deal with branching, merging, delays, broken or disjointed processes? Find out and use it. But that’s not all.

So what is missing from a process definition?

Most often, I find that the underling rationale for the process is missing. A process or a process step exists for a reason, usually it’s do something. In reality, the process steps in a process map are representations of what something or someone does on a routine basis. More commonly, it’s an actor (a person or a system) doing an action to transform an object. This could be processing an application form, taking a payment, assessing eligibility, writing a letter, creating an account and so on. Let’s take one of those in more detail. A likely scenario of processing an application would have:

1. a customer submitting an application form
2. the organisation receiving the form,
3. an agent checking the application for completeness
4. the agent recording the application on the organisation’s system
5. the agent assessing eligibility
6. the agent giving a reply to the customer (by letter or email)
7. if the application was accepted, then a new service or entitlement is started on behalf of the customer

Input and Output 

The common item throughout all the above is that there’s an application form being processed. The customer fills it out, the agent assesses it. It goes on a journey and the process steps cover that journey. The application form probably has a “for office use only” on it. Sound familiar? Well the agent would be filling out that part. What’s important is the each process step receives the application from the previous process step. So the application is an output from step (1) and an input to step (2). By noting these on a process map or in an accompanying text document, we’ve improved the quality of process map incredibly. So if a process step needs to receive something, list it as an input. Similarly for output. Often, any analyst who’s previously been a developer  will probably focus on data inputs and outputs to a process, e.g. parameters that have to be passed along the journey. Watch out though, paper, faxes and files are equally as important.

Transformations 

Back to the rationale, the process step will transform the input into the output. These transformations should be recorded. So if the agent adds something to the application, record that fact in the process description. Bear in mind that the process step can (so far) only achieve an output by transforming an input. By recording these, we’ve added more detail and more rigour to the process definition.

Record Data Usage 

In step (5), the agent assesses eligibility. Maybe they retrieve some customer details based on the information in the application form and perhaps also retrieve a sliding scale as a reference. These are pieces of data that the process step uses to change. Ignoring human emotion, the output can only come from a combination of input, retrieved data and an algorithm. From what we covered earlier, the algorithm could be broken down to more more granular steps. The process step could also update a retrieved form or create further data to be stored somewhere. This retrievals and updates should also be recorded as part of the process definition. At a high level, I’d expect to see which systems are being used per process step. At the next level down, we should cover data at the conceptual level (e.g. Customer, Car, Address). Another level down, I’d be looking to record usage of data at the logical level (customer first name, customer last name, address postcode, car registration number). To some extent, the old Data-Flow Diagrams handled the flow of data between process steps. The combination of ERD and DFD seems to be have been lost in today’s modelling skills.

Channels 

In step (6), I mentioned “by letter or by email” rather lazily not differentiating between how the process may differ for each channel. The process should be consistent with the channel that it applies to. If there’s a change in the channel or medium, these should be recorded. Coming from implementing multi-channel solutions, I like process maps to be applicable to all channels and only show the exceptions. In practice, this often requires a split, either due to the time nature of the interaction (synchronous or asynchronous) or whether it’s electronic or in person.

Where? 

Reading the steps in the list above, you’d expect steps (2)-(7) to be performed by an agent in the same place. If the geographic location changes, then record this. Same goes for teams, although using the swimlanes in BPMN and UML should already cater for these. Ideally, anything that changes about the environment in which the processes are conducted should be recorded. It’s best to describe what I mean by example here; if an analyst or group of analysts are mapping a group of processes, if all the processes are performed in one location, then that can be recorded in the text description of the process. If the location changes per process or process step, I’d expect to see each step have the location recorded. It’s better to be explicit rather than leave people guessing, especially where you have the opportunity to reduce ambiguity.

Summary 

To recap, a process definition should consist of at least:

a) a textual description of the process and each process step
b) a control flow of the process through each process step
c) zero or more inputs to the process and to each step
d) zero or more outputs from the process and each step
e) zero or more retrievals for each step
f) zero or more updates for each step
g) environmental variables

Any decent modelling tool should as a minimum allow the analyst to capture this information, be it diagrammatically or textual.

In my experience, the vast majority of analysts do (a) and (b) only. Some analysts make an effort at doing (c) and (d) with varying degrees of success. Get any analyst with a process background rather than full understanding of the systems development life-cycle and you’ll be struggling to get anything beyond (c). I’ve made some generalisations, but they are true from my experience.

Yet there’s still more to capturing an accurate description of a process. Each process has attributes (e.g. time taken, peak volume, average volume, etc.) that should also be recorded.