business process diagram

This content is an extract from GetAhead in Business Analysis - the FULL course is in eBook and multimedia CD-Rom format.

Combining Processes within a Business Process Diagram.
In this section a variety of simple techniques are introduced to show how a business process diagram can be clarified. The examples used do not relate to any specific scenario but are hypothetical abstracts used for the purpose of illustration. Firstly, where a business process diagram (BPD) is considered to contain too many processes, those that are related can often be combined. As a general rule no BPD should contain more than 12 process boxes. In the example above, the process boxes 'Find Driver' and 'Notify Driver' have been identified as being related and can be combined into the single process 'Find & Notify Driver'.

Streamlining Data Flows.
Where information is being retrieved from a data store, it is not necessary to show the selection criteria, or key, that is being used to retrieve it. In the first example, the customer details are shown being retrieved from the data store but the key used to retrieve this information is not shown. Where a data store is being updated, only the data flow representing the update needs to be shown. The fact that the information must first be retrieved does not need to be shown. Only the most important reports, enquiries, etcetera should be shown on the diagram. Less significant communications can, if necessary, be detailed in support documentation.

Combining External Entities.
Another way to reduce the complexity of a BPD is to combine any related external entities. For example, a business system will often be dealing with different units from within the same external organization, and these can be combined into a single external entity. Where these units are uniquely identified a number should follow the entity identification letter. However, when they are combined the numbers placed after the identifying alphabetic character is not shown. In a similar way, data stores that are holding related information should be suffixed with a lower case letter. Related data stores can also be combined, and where this is the case the letters placed after the identifying alphabetic/numeric character is not shown.

Shifting the Analysis Boundary.
Each process within a given BPD may be the subject of further analysis. This involves identifying the lower level processes that together constitute the process as it was originally identified. This procedure is known as top-down expansion, decomposition or leveling. As a BPD is decomposed, each process box becomes a boundary for the next, lower level, diagram. The diagram that results from this decomposition is said to be one level below that which contains the original process.

The Top-Down Pyramid.
In order to illustrate top-down expansion, consider the three processes shown within this BPD. No detail is shown, only the outline of the process boxes, which have been identified during the drawing of this level 1 diagram. Any area of a level 1 diagram is likely to require further analysis, as the level 1 diagram itself only provides a functional overview of the business system. Therefore, below the level 1 diagram there will be a series of lower level diagrams. These are referred to as level 2, level 3, and so on. In practice, level 2 is usually sufficient and it is unusual to carry out an analysis beyond level 3. In this example the process numbered 3, at level 1, will be investigated further; thereby giving rise to a level 2 diagram. In the level 2 diagram four processes of interest have been identified and the numbering of these processes must reflect the parent process. Therefore the level 2 processes are numbered 3.1, 3.2, 3.3 and 3.4.

Suppose that of these four level 2 processes, one was of sufficient interest and complexity to justify further analysis. This process, let's say 3.3, could then be further analyzed - resulting in a corresponding level 3 diagram. Once again the numbering of these processes must reflect the parent process. Therefore these three level 3 processes are numbered 3.3.1, 3.3.2 and 3.3.3.

Numbering Convention.
The process boxes on the level 1 diagram should be numbered arbitrarily, so that no priority/sequence is implied. Even where data from one process flows directly into another process, this does not necessarily mean that the first one has to finish before the second one can begin. Therefore the processes on a level 1 diagram could be re-numbered without affecting the meaning of the diagram. This is true within any BPD as these diagrams do not imply time, sequence or repetition. However, as the analysis continues beyond level 1 it is important that a strict hierarchical numbering convention is followed. The processes on level 2 diagrams must indicate their parent process within the level 1 diagram. This convention should continue through level 3 diagrams, and beyond - should that level of analysis ever be required. This diagram clearly illustrates how processes on lower level diagrams identify their ancestral path.

When to Stop the Analysis.
It is important to know when to stop top-down expansion. Usually this will be at level 2 or level 3. There are 3 useful guidelines to help you to decide when to stop the analysis: Firstly, if a process has a single input data flow or a single output data flow then it should be apparent that there is little point in analyzing it any further. Secondly, when a process can be accurately described by a single active verb with a singular object, this also indicates that the analysis has been carried out to a sufficiently low level. For example, the process named ‘Validate Enquiry’ contains a single discrete task. Finally, ask yourself if anything useful will be gained by further analysis of a process. Would any more detail influence your decisions? If the answer is no, then there is little point in taking the analysis further.

This content is an extract from GetAhead in Business Analysis - the FULL course is in eBook and multimedia CD-Rom format. TOP