Process Mapping Basics

Introduction

This is the first article in the Fundamentals of Process Mapping series. In the series, I want to discuss the areas that most process mapping tutorials miss.

In this bite-sized article, I’ll introduce the idea of a basic process map.

Let’s get some background about process mapping first.

What is a process map?
A process map is a tool. It is not an end in its own right. They are often used in software development lifecycle or within Business Process Re-engineering (BPR). If the methodology you’re working in states that one is required, you’re not writing a map just to fulfill that aim, but because the creators of that methodology realised that a process map would be a useful tool to have.

I see a process as one component of a process description, not necessarily the only component. That’s worth remembering.

What are the purposes of a process map?

I have at least four aims when I’m process mapping:

1. To describe a process in pictorial form
2. To provide a quick way of understanding how the main steps in a process fit together
3. To provide documentation for agreeing what happens in a process
4. To provide documentation for what could happen in a process, e.g. process improvement

There are other aims depending on the need, e.g. for collaborative working, facilitating workshops. Whatever the discrete aims are, they all boil down to communication.

What are the components of a process map?
Every process has at least one process step, at least one starting point and at least one ending point. The process step is an action that is performed by an actor (either a person, a system or an organisation).

Our initial basic process will have the following:

• one starting point
• two process steps
• one end point
• connectors showing the direction of flow

For the process map here starts at Process Start, continues to Process Step 1. Once that is complete, continue to Process Step 2. Once that is complete, continue to Process End and the process is terminated.

To put that into context, imagine a simplified process for buying a book in a bookstore.

The customer wants to buy a book, so process start (Buy a Book), customer Chooses a Book, then Customer Pays for Book. Once that’s complete, the Book is bought. I’ve simplified it so we can discuss it in more detail later on.

Notation
Your software may have different notation for process start/initiators, process ends/terminators and process steps (often just called processes). That’s ok. As long as you can tell the difference between them.

What Next?
That’s the very basics covered. I’ll go into more detail about processes, process steps, decision points and common pitfalls in the following articles in the series.