Business process modelling, analysis and design are essential skills for a business analyst. In this article, we look at some simple steps for better business process design.

Estimated reading time: 12 minutes

A Process Hierarchy – Start point for business process design

The diagram shows a business process design organised as a hierarchy of activities. Note that I have named each activity in the verb noun format, e.g.

• Fulfill (Verb)
• Order (Noun)

Also note that each activity name is singular, i.e. ‘Fulfil Order’, not ‘Fulfil Orders‘. The task is repeated for each order.

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’. Sharpe and McDermott made this suggestion in their classic book, “Workflow Modelling”.

The diagram is shows a ‘process hierarchy’. Process hierarchies allow us to analyse and design the structure of a process without refering 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 understand the structure of the business process and its tasks, so we focus on those.

We can create separate models to show data and business rules, and then bring all of these models together.

Designing a ‘Process’ Hierarchy

The top level activity in our diagram is ‘Fulfil order’.

It has low level activities:

• Take Order
• Prepare Order
• Deliver Order

Each of these activities is 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.

How to improve the design of your business processes

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 lower level 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 the model, I have expanded the activities, ‘Take Order’ and ‘Prepare Order’ to a third level of detail. This approach of working top down to the detail is known as ‘process decomposition’.

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

Remember that activities at the bottom of any leg in the hierarchy are called ‘tasks’. You 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 frequently quoted guideline for what constitutes a task is, ‘Work done by one person, at one place, at one time’ OPOPOT; ‘one person’ might be a group of people effectively acting as one. Perhaps, ‘Role’ is a better word than ‘Person’; some roles can be performed by machines rather than people.

Is there an optimal number of levels in designing business processes?

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 activity levels.

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 normally be achieved by one role in one place at one time.

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 to achieving better 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 for better business process design

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?

Naming the outcome, or result, of a process

Internationally acclaimed business process expert, Alec Sharpe, suggests that if we have chosen an accurate and meaningful name for an activity, we can reveal its 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 a 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.

How big is an activity?

Better business process design demands that activities are as free standing as possible. It should do one job and it should do that job completely. Connections between such complete activities will be few and simple. The ‘right’ size for an activity is one that achieves this independence. If you struggle to name your activities in the singular, it could be that they are too big and do too many things.

These practices have names: ‘Cohesion’ and ‘Coupling’.

Cohesion

Cohesion is key to designing better business processes.

A cohesive activity does one thing, and one thing only. Highly cohesive activities do not need an ‘and’ in their name, e.g. a cohesive activity cannot be ‘Check-in and Check-out client’. If we wanted to represent both of these as 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. The more cohesive an activity is, the easier it will be to name.

Coupling

Coupling is another key element when considering how to design business processes. It is closely related to, and supportive of, cohesion.

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 – Loose coupling

High cohesion and loose coupling are mutually supportive. They are at the heart of effective business process design.

Think how easy it is to replace a component in a computer. Each such component is highly cohesive; it does one thing only. The connections between components are as direct and as simple as possible. This makes it easy to replace components. A replacement can 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 drivers for change. This is not just an abstract theory.

Starting and ending an activity

Events and Outcomes

Activities are normally started by a business event. Examples of events are:

• Customer makes an order (Starts, ‘fulfil sales order’)
• Stock level goes below the minimum level (Starts, ‘Purchase product’)
• End of quarter (Starts, ‘Create ‘End of quarter’ report’)

Other terms for ‘start a process’ include ‘initiate’, ‘trigger’ and ‘instantiate’.

Identifying the triggering event

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. All these things lead to better process design.

Each instance of an event is unique

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 for 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. Organisations can make members of staff accountable for performance.

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:

1. Take the guest name or booking reference number
2. Use the name or reference to retrieve the booking details
3. Record the arrival of the guest
4. Complete the allocation of a room to the guest
5. Etc.

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.

It should be considered in the design of your business processes and other aspects of your architectures.

Conclusion

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 manufacturer.

That’s how software should be designed. Programming languages such as Java that explicitly support the concept of components can facilitate this practice.