Processes and value

Organisations, commercial and non commercial, serve groups of people who can be regarded as clients or customers. It is essential that every organisation understands what these customers value. The organisation must create that value and create a strategy to deliver it.

Business process improvement must be based on:

• Understanding of the customers
• Awareness of what they value
• Appreciation of the strategy to deliver that value.

This is the basis for boosting business agility.

Organisations create value – Business processes deliver that value

The above model demonstrates how any business process operates in the context of:

• The external environment, that is outside their control but which they have to align with
• Suppliers of resources linked in often complex and increasingly international supply chains
• Partners
• Customers for their services and products
• Competition for their customers and their suppliers: this affects their costs and their pricing
• Sources of finance
• Executives and “owners”:

For more views on this model, see:

• ‘White Spaces Revisited’ by Rummler
• ‘The Basics of Business Process Mapping’, by Damelio

Top 3 rows of Zachman column, ‘How’ – The Processes

The top three rows of the ‘How’ column are concerned with defining and modelling the business processes. The language of these rows is the language of the business stakeholders.

• Row 1: Contextual. Try to list all of your organisation’s core and support business processes.
• Row 2: Conceptual. Try to identify the areas of activity that your organisation is concerned with.  Highlight the dependencies between these areas. Peter Checkland pioneered the development of such models, in what he termed, ‘Soft Systems Methodology’. For more on this topic, see, ‘Soft Systems Thinking, Methodology and the Management of Change’ by Happeren and Wilson.
• Row 3: Logical. Logical process models are popularly shown in the form of swim lane diagrams, a technique pioneered by Rummler. Popular notations for such models include Business Process Modelling Notation (BPMN) and UML Activity Diagrams.

Lower 3 rows of Zachman column, ‘How’ – The Processes

The lower three rows of the Zachman framework are concerned with increasingly technical views of how the business processes are supported by IT.

These rows are of interest primarily to technical strategists and architects and to those roles that are responsible for making purchasing decisions on systems software and hardware.

The business analyst should be able to contribute to discussions on IT strategy for technical support of business processes. The business analyst should therefore have, at least, an appreciation of the technology. They need to be aware of what technologies are available, e.g. for automating workflows.

Each process interacts with other elements

The Zachman model demonstrated how business processes interacted with other architecutural elements. We reflect this in the accompanying diagram

A business process:

• Creates, views, modifies and deletes business data
• Is constrained by business business rules
• Operates across locations and organisation units
• Is the responsibility of particular stakeholders
• Is triggered according to business timings
• Has a rationale in terms of its support for business objectives

Core and support processes

Many of an organisation’s business processes provide routine support.

A critical subset are strategically important and deliver value created by a business. These are the core processes. The goals of these processes are crucially linked to the strategic objectives of the organisation.

All organisations must continually find ways to incrementally improve business process performance. Many such approaches to improvement are inspired by ideas from Japanese manufacturing sectors. See, for example, the publication, ‘This is Lean’, by Modig.

If any core business process is not effectively supporting the business strategy and goals we may need to take a more radical approach to improvement. Radical improvement was the subject of Hammer and Champy’s ‘Re-engineering the Corporation‘ some years back. That approach spawned a number of later ideas and approaches.

If there is a change to the environment in which the organisation operates, prompting a need to change strategic goals and approach, then one or more core processes will probably need to be changed.

Better business process design and modelling

In this article, we look at some simple steps to improve the design of your business processes and your business process modelling.

A Process Hierarchy

The 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 their book, “Workflow Modelling”.

The diagram is often referred to as a ‘process hierarchy’. It allows 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.

Designing the ‘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.

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 our model, the activities, ‘Take Order’ and ‘Prepare Order’ have been expanded to a third level of detail. This approach of working top down to the detail is sometimes described 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

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, suggest 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 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.

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”?

Cohesion

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 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 have not identified a cohesive unit of functionality.

Coupling

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 drivers for change. This is not just an 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 the 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

respectively.

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

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.

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. This practice is facilitated by using programming languages such as Java that explicitly support the concept of components.

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