Business Analysis and Process Modelling

Process models can be classified using two independent dimensions:

logical vs. physical; and
current vs. proposed (”as-is” vs. ”to-be”).

Logical Models

Logical models emphasise goals. They are often described using flowcharts or a formal modelling language such as BPMN or UML. However, it is often quicker and easier to describe a logical model using a functional decomposition (see A Guide to the Business Analysis Body of Knowledge for a concise description of functional decomposition).

Unlike flow charts or formal process models, a functional decomposition does not show the sequence in which activities are performed or the decisions that decide whether or not to perform an activity. These are the two aspects of process modelling where business analysts usually become bogged down, and there are good reasons why.

When pressed to describe the sequence in which activities should be performed most business people will arrange them into what they see as a logical sequence. However the sequence they choose is often very subjective. A second stakeholder is likely to propose a different sequence and that is when the disagreements break out.

During our Essentials of Business Analysis course, I ask participants to write down the first activity that must be performed to make a cup of tea. Most write down something like fill the kettle or switch on the hot water jug but of course this is not the only possibility. Some people might check if there is sufficient milk or sugar first, a collector of antique tea cups might contemplate which cup to use while a connoisseur of fine tea might first decide which tea to sample. All of these could justifiably be the first activity performed.

Adding decisions only serve to complicate things further. What is the correct order of deciding which tea to drink or which cup to use?

That is not to say that theses issues are unimportant, they must eventually be addressed but probably not in the logical model which should emphasise the goals that must be achieved.

Physical Models

Physical models include the same details as logical models with the addition of information flows, physical object flows and the actors that perform activities.

Physical models are best described with formal process models. Modelling languages such as BPMN or UML include notations for representing all of the elements described above in addition to events, decisions and activities. They also include notations for describing activities performed in parallel which provide a solution to many of the problems associated with trying to describe a strict sequential order of activities.

Process Quadrants

During my business analysis courses I often summarise the two dimension by drawing a rectangle on the whiteboard with four quadrants.

The classic sequence of developing the four process models is:

current physical;
current logical;
proposed logical; and
proposed physical.

The current-physical-to-current-logical step is supposed to be achieved by applying a series of “transformations” to the model. Some humorists have labelled this step “and then a miracle occurs”.

The current-logical-to-proposed-logical step is normally associated with business process re-engineering. Although in the absence of significant change the two models are often quite similar.

Finally, the current-logical-to-current-physical step is achieved by adding information flows, physical object flows and actors to the proposed logical model during the design of the new business process.

This order of steps is favoured by academics and advocates of structured analysis (often the same group). However, I have never seen it successfully applied in a project setting. The reason for this can be summed up in a single word - time!

Typically, the analysis team comes under time pressure during the transformation from current physical to current logical - if not during the development of the current physical model. This often triggers a rush to develop the proposed physical model in order to meet project deadlines. The result is that the project moves into the requirements identification phase without a proper understanding of the goals of the business area. This usually proves fatal to the project (or at least necessitates a spell in intensive care).

A More Agile Approach

It is vital to understand the goals of the project stakeholders before starting to identify IT system requirements. For this reason, I always start with a current logical model based on a functional decomposition. Development of the model is usually straightforward and can be achieved during a series of facilitated workshop.

The current logical model provides a baseline for the proposed logical model. Often, all that is required to create the proposed physical model, is the addition and/or removal of a few activities possibly combined with a bit of restructuring. However, some areas of the proposed logical model might warrant a more detailed analysis. In which case, the development of a formal business process model focussed on a specific problem or area of the business is worthwhile.

Developing a proposed physical model is part of systems design and for that reason I often delay it until the requirements of the IT systems supporting the business process are better understood. The proposed logical model usually provides a more than adequate basis for identifying IT systems requirements.

There are two situations when the development of a current physical model might be justified:

the model is needed for governance purposes; or
the model is needed as a baseline for an extensive business process improvement exercise.

In both cases it is wise to fund the development of the current physical model separately from the budget for any IT systems that will be developed.

You can learn more about business process modelling in our Software Requirements and Business Analysis courses.