A Process Hierarchy
The adjacent diagram shows a hierarchy of activities. Each is named in the verb noun format, and is singular, i.e. ‘Fulfil Order’, not ‘Fulfil Orders‘
It is common to refer to the activity at the top of such a hierarchy as a ‘Process’ and the activities at the bottom as ‘Tasks’. This suggestion for terminology was made by Sharpe and McDermott in there book, “Workflow Modelling”.
The diagram at the right is often referred to as a ‘process hierarchy’. It allows us to analyse and design the structure of a process without reference to data, business rules or sequencing. All models are simplifications of reality. One key to successful modelling is to ignore anything that is irrelevant to the objectives of your model. Here, we are trying to achieve optimal definition of the business process and its component activities, so we focus exclusively on those.
Designing the ‘Process’ Hierarchy
The top level process in the case shown in the accompanying diagram is ‘Fulfil order’. We might refer to this as an ‘end to end’ process. Multiple organisation units are likely to be involved in its execution. In the above diagram, ‘Fulfil Order’ comprises three activities,
• ‘Take Order’,
• ‘Prepare Order’
• ‘Deliver Order’.
Each of these activities are likely to be performed by separate organisation units.
Some process modellers might refer to activities at this level as ‘sub-processes’, depending perhaps on the size of the activity.
The modeller must ensure that ‘Take Order’, ‘Prepare Order’ and ‘Deliver Order’ really do cover everything that is assumed to be in ‘Fulfil Order’.
The modeller might realise at this stage that Fulfil Order implies something more or something less than than the three subordinate activities identified above. The modeller might then take corrective actions such as adding and removing activities, or simply make name changes so that the names at both of the two levels adequately describe what is going on. This work is likely to be iterative, working alternately, top down and bottom up. It is worth taking the effort to get things ‘right’ at this stage because it can help to ensure that we are designing the optimal structure for the process.
In our model, the activities, ‘Take Order’ and ‘Prepare Order’ have been expanded, (‘decomposed’) to a third level of detail. This approach of working top down to the detail is sometimes described as ‘process decomposition’.
As for the initial decomposition of Fulfil Order, the modeller must now ensure that ‘Record Order’ and ‘Allocate Order’ completely describe ‘Take Order’. Similarly, that ‘Pick Order’ and ‘Pack Order’, completely describe ‘Prepare Order’.
Tasks – The Bottom of the Hierarchy
Referring to our earlier suggestion that the activities at the bottom of a hierarchy are referred to as ‘tasks’, we can see that there are five tasks, each labelled with the letter T. Note that 4 of the tasks are at the third level of the hierarchy, whereas one of them, ‘Deliver Order’, is at the second level. In practice, ‘Deliver Order’ will probably be decomposed into smaller activities. A useful guideline for what constitutes a task is, ‘Work done by one person, at one place, at one time’; ‘one person’ might be a group of people effectively acting as one.
There is no fixed rule about how many levels there should be in a process hierarchy; Usually, three or four will be sufficient to understand an existing system or to propose a new one. It is also likely that each leg of the hierarchy will consist of a different number of levels of activities. A useful hint is to write a brief description of each activity; this will quickly show if you have reached the task level, i.e. work that would be normally be achieved by one person in one place at one time. A similar guideline can be derived for tasks that are to be fully automated, i.e. that do not require any involvement from a human.
At the task level, the modeller will consider the logical flow of tasks as they combine to complete the entire process. Note that when we initially investigate a process, talking to the stakeholders that do the work, we may well start with the tasks and work bottom up. It is when we design new processes we are more likely to work top down in the manner we have been describing.
Challenges in Creating the Optimal Business Process Design
There are several challenges with this effort of creating hierarchies.
• What to call each activity.
• How to form an activity, i.e. what does an activity look like, how big is it?
• When to stop decomposing the activities into smaller activities, i.e. how will we recognise a task and know that we can stop decomposition?
All of these points are related; we have already referred to them in passing. We will develop the topics in the following sections.
Naming an activity
Activities should be named using a verb-noun or verb-noun phrase., e.g. Fulfil order, Check in passenger, Take booking, Calculate net pay, …..
The name of the activity should reflect its business purpose, or ‘objective’. If you can give a succinct name to the activity, you probably understand that purpose. If you do not really understand what it is supposed to achieve, you probably resort to naming it with a verb such as ‘handle’, ‘manage’, ‘process’, ‘perform’, etc.
To help name an activity, consider its objectives; what is the expected ‘outcome’ or ‘result’ of the activity? What is it intended to achieve? What value does it contribute?
Sharpe and McDermott, always pragmatic, suggests that if we have chosen an accurate and meaningful name for the activity, we can reveal the outcome by reversing the word order of the name, i.e. noun-verb instead of verb-noun. For example, Fulfil Order results in Order Fulfilled. If you had named the activity something such as ‘Handle order’, the result is ‘Order handled’, which is meaningless without a further definition of ‘handled’.
Reversing the word order to uncover the outcome is great start. You will find it useful to elaborate on that outcome, e.g. what exactly is a fulfilled order? Another useful exercise is to look at all the possible states of order, e.g. ‘provisional’, ‘confirmed’, etc. to see if additional tasks can be identified.
Note that we named all of the activities with singular verbs, i.e. Fulfil Order, not Fulfil Orders. This is deliberate. We will return to this point shortly.
Well formed activities – Cohesion and Coupling
To help us create well formed, solid activities, we can employ the concepts of Cohesion and Coupling. The ideal is high coupling and low, or loose, coupling. We will explore these concepts below, but it’s worth noting that the effort we went to in naming the activities and creating the hierarchy, has got us off to a good start. Cohesion and coupling can help answer the question, “How big is an activity”?
A cohesive activity does one thing, and one thing only. Highly cohesive activities could not be named using a conjunction, e.g. a cohesive activity cannot not be Check-in and Check-out client. If we wanted to represent both of these in a single activity, we should choose an activity name, in verb noun format, that implies both of these things.
Cohesion is demonstrated in the components of a device such as a computer. Components include the disc drive, sound card, memory, etc. Each component has a single job to do; the disc drive is not normally expected to double as a sound card.
Each of these highly cohesive objects typically consists of smaller components, which themselves are cohesive, i.e. each component has a single job to do. So we can identify components, sub-components, sub-sub-components, etc., each of which is cohesive, each of which will have a function that can be named in verb noun format. This is true however high or low we are in the component hierarchy. The same thing should be true of our process hierarchies.
Having trouble naming an activity may indicate that you do not have not identified a cohesive unit of functionality.
Closely related to, and supportive of, high cohesion, we also have coupling. Coupling refers to the interfaces or connections between components. These connections should be minimal and as simple as possible. For coupling, the ideal is loose, or low. High cohesion and loose coupling are mutually supportive. Think how easy it is to replace a component in a computer. A replacement component could even be from a different manufacturer to the original; the interfaces between such components are typically the subject of international standards.
Getting the right names for activities should help to ensure that your process comprises loosely coupled activities.
Cohesion, Coupling and Business Agility
One aspect of business agility is the ability to respond quickly and effectively to change in the external or internal environments in which an organisation operates. An organisation’s processes are key to its intent of delivering value. The more highly cohesive and loosely coupled the activities are, the more responsive an organisation can be to be to drivers for change. This is not just abstract theory.
Starting and ending an activity
Events and Outcomes
Activities are normally initiated by a business event. Examples of events are:
• Customer makes an order (Triggers ‘fulfil sales order’)
• Stock level goes below minimum level (Triggers ‘Purchase product’)
• End of quarter (Triggers ‘Create end of quarter report’)
The above are sometimes referred to as:
• External event
• Internal event
• Time event
Other terms for ‘initiated’ are ‘triggered’ and ‘instantiated’.
Identifying the triggering event and having a clear outcome, or result, as referred to earlier, facilitates the modeller’s understanding of the intent of the activity. It also facilitates the naming of that activity. Clear delineation of an activity, between its triggering event and its outcome also helps to answer the question about how big should an activity be.
Each instance of an event will occur at a particular point in time. It is separate from all other instances of that same type of event, e.g. one request for a hotel room booking is distinct from all other requests for a room booking.
Similarly, one instance of an outcome is distinct from all other instances, i.e. one booking is distinct from all other bookings.
Returning to the earlier point about naming activities with singular verbs, one instance of an event will trigger an activity to start. Having started, it will either achieve its expected outcome or it will fail in some way to do so. This happens once for each event, hence the verb is singular. We can repeat this singular activity as often as necessary; we do not need to imply this recurring behaviour by making the verb plural.
Inputs and Outputs to and from an activity
Events are typically associated with physical inputs of some kind. E.g. the event, ‘Hotel booking requested’, will be associated with inputs describing the sort of room required, number of persons, start and end dates, and so on.
Outcomes are typically associated with physical outputs from an activity. These may be produced at the end of an activity or at some intermediate point. Exactly what is produced will depend on whether the activity is successful or not. For example, an activity that responds to the event, ‘Request for holiday booking’, is likely to produce outputs such as tickets, travel itinerary, etc. Such an instantiation of an activity would be considered as successful.
An unsuccessful instantiation of such an activity may occur if, for example, suitable dates cannot be found or the price is beyond the customer’s budget.
By considering inputs and outputs we have another aid to defining the appropriate size of an activity.
Sequencing the activities
Having identified the activities / tasks, we can now order them into a logical sequence, as shown in the accompanying diagram.
In fact, delineating the activities/tasks and sequencing them will probably be done iteratively.
Note that each activity/task is complete in itself but it is part of a larger activity or process. Each activity is loosely coupled with its predecessor(s) and successor(s); if there is a human involved in the task, they will understand that as their job.
A manager might be responsible the whole sequence of activities. We can have a management hierarchy to match the process hierarchy. Management reporting can be done at each level of the hierarchy.
Business rules might apply to each level of the hierarchy. Somebody should have sight of the whole ‘end to end’ process. This oversight will be accompanied by suitable control and reporting mechanisms; it is important that individual tasks are not optimised at the expense of the overall process flow.
Just as each activity and task must be clearly delineated and have a clear outcome, so should each sequence of activities and tasks. This ensures that cohesion and coupling apply at all levels in the process hierarchy. Accountability for performance can be appropriately allocated to staff members. Performance can be measured. Training can be given as needed. Procedures can be clearly defined.
Beyond tasks to task steps
Tasks are usually executed as a series of steps. E.g., in checking in a guest, a hotel receptionist will probably:
- Take the guest name or booking reference number
- Use the name or reference to retrieve the booking details
- Record the arrival of the guest
- Complete the allocation of a room to the guest
In business processes, there is often no need to create a diagram for the steps; creating a diagram, or flowchart, may be justified if the steps themselves are complicated. The usual guideline is that we do not explicitly model the process below the level of the task. BPMN for example, stops at the task; below that we have to find other means to document the steps. One form of flowchart that can be used for modelling tasks is the UML artefact, an Activity Diagram.
One key to achieving business agility in business process design is to ensure that you apply the principles of cohesion and coupling. It has worked brilliantly in the design of all living things since, well, since there were any living things. That’s how transplants of body parts are even possible.
It has also worked brilliantly in the design of our machines, where each component has a distinct role and communicates with other components via, typically, internationally agreed interfaces. That is how we can, for example, replace the disc drive in our laptop with one from a different manufacture.
That’s how software should be designed. This practice is facilitated by using through programming languages such as Java that explicitly support the the concept of components.