What is Business Process Modeling?

Introduction

Before we can say what business process modeling is we need to know what a Business Process is! This may seem like striking the obvious, this is one of the most widely misused and misunderstood terms in business and in business modeling! Analysts and managers alike often use the term when what they are really talking about is a Business Function or a Business Procedure. No wonder there is confusion !!

Definitions

Business Function: " A coherent, discrete activity that a business must perform in order to meet its business objectives and continue in existence."

Business Process: "Describes the order in which Business Functions need to be carried out in order to achieve a specified objective."

So, in short, Functions describe what a business needs to do in order to continue in existence and Processes describe the order in which this needs to be done.

From this we can also see that it is not possible to do effective Business Modeling before we have modeled the Functions !!

The Building Blocks of a Process

The essential elements are:

• Objective
• Trigger
• Functions
• Precedence
• Outcome

Objective:

Every Business Process must have a clearly defined objective that answers the question "what is this process mean to achieve?". If the business does not have a clearly defined (written) view of what is meant to achieve then there is very little chance of it achieving it.

It will not be possible to work out what functions need to be carried out and in what order in order to arrive at the preferred Outcome.

In fact, without having defined objective, the business might not be able to define what the preferred exit actually is. This statement may seem simplistic but it is the primary reason why so many Business Processes are inefficient or fail altogether.

Triggers:

These are events that occur because require the business to respond in some way – they "trigger" a response in the business. Every Process must begin with at least one Trigger.

Outcomes:

Other events occur as the result of activities carried out by the business itself and these are called "Outcomes". In every Process the business gets from the Trigger to the Outcome by carrying out Functions in the correct sequence.

Precedence:

Precedence is not, as many analysts mistakenly believe, a definition of how the steps within a process are triggered. A more effective definition is to say that it is a very specific way of clearing what functions must have been completed before others can begin.

The succeeding functions can then begin at any time convenient to the business, in accordance with existing business rules. This definition is especially useful as it makes the business ask the question, "before we begin step X what other steps must have been completed?"

More on Outcomes

There are two types of output that can occur in a Business Process: Preferred and Non-preferred.

A Preferred Outcome is the result that the business would like to achieve as the result of successfully carrying out the process and should correspond to the designated objective.

Every Process must have at least one Preferred Outcome.

A Non-preferred Outcome is a valid and controlled output other than the Preferred Outcome.

Suppose that we are taking orders from customers. The Preferred Outcome would be "order authorized" but a Non-preferred Outcome could be "bad credit rating: order declined". A Business Process can have several Non-Preferred Outcomes.

Elementary Business Process

Each step in a Process is a Function, which comes from the Function Catalog (see the foot of this article for more on this) andought to be from the bottom level of the Catalog as it stands at that the moment in time. Ideally, these should be Elementary Business Functions (EBFs). A Process drawn using EBFs is called an Elementary Business Process.

Decomposing Processes

One of the biggest mistakes analysts make when doing Business Process Modeling is to "decompose" (a lovely term!) Processes. This means that they break the process down into more and more detail.

This is a practice to be avoided AVOIDED AT ALL COSTS as it has two main faults: 1) it requires drawing more more diagrams than are necessary (up to 300{4ec66d537739005ccd5ed56e62ee5e9eb3f533a4d07ddf8b17a0db96e01adf11} more) 2) it introduces fundamental logic errors.

To avoid these errors all decomposition (someone will have to think of a nicer word) should be done using the Function Catalog and each Process model should be drawn using functions from the bottom level of the Catalog (preferably EBFs).

Summary

• Business Functions and Business Processes are NOT the same thing.
• A Business Function describes what the business bought to do; A Business Process describes the order in which it has bought to do it.
• Business Process Modeling should ALWAYS be preceded by Business Function Modeling
• Processes must always contain all of the defined elements of Objective, Trigger, Outcome, Functions and Precedence.
• The objective of a Process should always be clearly sated in writing before the Process can be properly modeled.
• Business Processesought NEVER be decomposed – this should be done using the Function Catalog.

Note: The Function Catalog is the core model of the Integrated Modeling Method (IMM) a fully integrated business systems modeling method. ### This article is copyright 2009 – John Owens – all rights reserved