Successful process mapping: creating process maps
What are process maps?
Process maps are graphical representations of processes. Creating process maps is called mapping or process mapping. Process mapping can be done in different ways (which will be discussed in detail in the following posts) but all process maps are flowcharts of one kind or the other.
Process maps illustrate the sequence of activity in an organisation or unit. The level of detail depends on why you are mapping the process (for whom).
Why are you doing it?
Reasons for process mapping can determine or play a part in deciding:
- Level of detail
- Mapping conventions and language (eg: Business Process Modelling Notation)
- Scope of processes (end-to-end or by department
Some of the common reasons for mapping (see the first post) your processes include:
- Problem solving – fixing a defective or inefficient process
- Performance management – improving processes
- Compliance – to comply with a particular standard or regulation
- Training – to train your employees on new/changed processes
- System implementation – a baseline for buying or building systems
For example, IT would require process maps for implementing a new ERP system. Process mapping would be helpful to establish a baseline and review changes.
As we said above, the reasons will significantly affect how you do the mapping, and what the maps look like.
Process maps in detail
A map should show one or more processes, including:
- What goes in (inputs and possibly resources)
- What comes out (end result and interim outputs, such as status reports)
- What happens
- Who does what
Here’s an example of a process map for payroll (click on the image to enlarge):
The input to this process is a request from an employee that triggers the first step. The final output is a status report to Finance. As you can see, the scope or boundary of this process is limited to payroll processing. There are three roles: HR Administrator, Payroll Clerk and Finance. Several KPIs could be set for this process, such as accuracy of the payroll or the number of payrolls processed.
You can’t map processes if you do not know what they are (where they start and finish, in other words a process framework or architecture). In a typical organisation, processes are classified by their relationship, as shown in the figure below.
The diagram above shows a process hierarchy. As you can see, management processes control the organisation. Core processes produce the products/services for customers. Support processes provide resources for core processes. Together they constitute the hierarchy or process architecture of an organisation.
Most of us are familiar with these types of hierarchies in our organisation but there are other process classifications. There are end-to-end processes and departmental processes, for instance. So are these processes outside the hierarchy? No, they are just management, core or support processes grouped under a different classification, quite often based on their functions.
End-to-end processes are high-level and customer-triggered processes that go through a series of steps or sub-processes to produce an output. End-to-end processes are mostly customer-oriented. A good example would be order fulfilment as shown below (click on the image to enlarge).
The customer orders a product/service, which triggers the process. This initiates planning the product/service, manufacturing/designing, quality control/testing, delivery and invoicing.
Departmental processes on the other hand, start with inputs to the department, are done by people in one department, usually, in one chain of command, and the output goes to another department. For example, Production is part of the end-to-end Order Fulfilment process and it is a departmental process (see diagram above).
Why do we need to consider the difference?
Creating process maps is like solving a jigsaw puzzle. You need to know which part you are working on, and keep the ‘big picture’ in mind. Starting with departmental processes might be logical to establish key tasks or you may work with end-to-end processes first and set the framework. In any case, you need to identify your processes and have a clear understanding of how the maps should look.
Detailed process identification
We have put together a task identification chart (TIC) that can help you with process identification, and details of individual processes. This chart has the following fields to capture details of each process:
- Name of the process - (what is the name of the process?)
- Identifier (number or ID) - (what is the process identifier or number?)
- Purpose – (what is the purpose of the process?)
- Scope – (what is involved?)
- Boundary – (where does it start and end?)
- Customer – (who receives the output?)
- Initiator – (who initiates it?)
- Process performance goals – (what are the goals for the process? e.g., improve turn-around time)
- Workflow – (what are the steps? who are the suppliers and customers? what are the inputs and outputs?)
- Verification methods – (How do you verify the process when it is designed?)
- Checker – (who checks the work?)
- Approver – (who approves it?)
- Owner – (who’s the owner of the process?)
- Exceptions – (what are the exceptions to this process?)
- Reports – (what reports are generated?)
- Business opportunities identified – (what are the opportunities identified? e.g., system implementation)
- References / standards – (what references and standards are applicable?)
- Input / Output documents – (what are the input and output documents?)
- Evaluation metrics – (how do you assess process performance? See goals)
- Customer satisfaction metrics – (how do you assess customer satisfaction?)
- Evaluation method – (How do you evaluate performance of this process?)