A Pragmatic Guide to Process Modelling: a talk by Jon Holt

'Modelling is the last hiding place for people who don't have the wit or the wisdom to actually do anything…' (David Brent, The Office)

The Magic of Process

Everything we do is a process and could conceivably be put into a Standard Operating Procedure (SOP). Processes are often deceptively simple, for example a magician performing a card trick. It looks simple and straightforward but is invariably the outcome of a well-practiced process.

Within any process there will be different viewpoints from both the observer and the executioner of the process. Additionally, there will be traceability where one can follow through the steps involved in the evolution of the process.

There will also be roles for those people or things (shareholders) involved in the process. Finally, there has to be a reason why that process is being performed. What requirement has necessitated the use of that particular process?

Who follows processes? People, as individuals, and organisations follow processes. Such processes can best be understood and analysed through modelling.

Process Modelling is known under various names, including Business Process Modelling, Business Process Management, and Business Re-engineering, to name but a few. Modelling techniques can be applied to all these.

Problems with processes

Processes are often:

Too long;
Too short;
Written by a committee;
Too many;
Unrealistic;
Have language problems;
Demonstrate a poor awareness of the issues;
Have a fear of failure built into them;
Reveal a poor perception of the real issues needing to be addressed.

Modelling: simplifying reality

Modelling helps to combat the three evils of life, namely:

Complexity:

After all, humans can only ever remember seven, plus or minus two, things at any one time. Processes are often more complex than they first appear to be, particularly when examining the relationships involved in their implementation.

Lack of understanding:

People often don't understand what is required of them or what the problems are within a system. There is frequently a lack of compatibility.

Communication problems:

This can be between people or machines. For example, when the singer Lonnie Donnigan died the Nikkei stock exchange was brought to an abrupt halt as eastern executives misinterpreted events thinking that, then president, Ronald Reagan had died.

All too frequently words have two or more different meanings in how they are applied, and in what country they are used in. For example, 'to section' has two meanings in the NHS, and the word 'crackers' takes on a whole new meaning near Christmas.

It is impossible to eliminate the three evils but we must do all we can to minimize their impact.

Modelling techniques

There are many techniques that are used on a regular basis, including flow charts, RACI matrix tables, BPML, IDEF and UML. In the case of the latter, the unified modelling language, symbols and pictures are brought to the fore.

UML originated in the software world and is the one modelling language that has taken the best bits from a number of others.

It is a visual software language, which uses open standard modelling, on the I50 standard. Created in 1997 UML is the consolidation of 120 or more techniques and notations, it is probably the best modelling format currently available.

'A fool with a tool is still a fool…'

As with any powerful tools UML still needs to be utilised appropriately.

The rationale for using UML is that it is accepted internationally, uses ISO 19805, has a UK government mandate, is intuitive, and can be used extensively throughout any part of an organisation.

Process Modelling

Processes are complex and there are different types. For example:

Very high level (ISO, IEC, B51);
High level (including standards, PAS);
Medium level (in house processes);
Low level (Procedures);
Very low level (guidelines, work instructions).

Templates can be very dangerous. For example, a process description should meet an organisation's requirements, and needs at least some aspects of validation. A process model should organise a process's knowledge.

Stakeholders all have a different viewpoint as to a process's requirements. In fact, within any process there will be a number of viewpoints including:

Requirement view

Specifies the overall aims and is essential for validation. After all requirements need to be checked periodically as they do change over time. Hence, timeliness is most important. If one doesn't revisit a model regularly, yearly at least, then one won't know if the process requirements have changed.

Process structure view

Specifies the structure of concepts and terminology used and helps to pin the language used down.

Process Content View

Identifies actual processes in each group and encourages the analysis of actual requirements and process description breakdown.

Stakeholder view

Identifies shareholder roles within an organisation, project or system.

This view presents shareholders in a classification hierarchy. Additional relationships may be added as appropriate. It's easy to make assumptions regarding someone's role.