Introduction
Before we can say what business process modeling is we need to know what a Business Process is! This may seem like stating 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
Every Business Process must have a clearly defined objective that answers the question "what is this Process meant 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 a defined objective, the business might not be able to define what the preferred outcome actually is. This statement might seem simplistic but it is the primary reason why so many Business Processes are inefficient or fail altogether.
Triggers:
These are events that occur that require the business to respond in some manner - 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 defining 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 outcome 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 stated objective.
Every Process must have at least one Preferred Outcome.
A Non-preferred Outcome is a valid and controlled outcome 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 Catalogue (see the foot of this article for more on this) and ought to be from the bottom level of the Catalogue 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 far more diagrams than are necessary (up to 300% more) 2) it introduces fundamental logic errors.
To avoid these errors all decomposition (somebody will have to think of a nicer word) should be done using the Function Catalogue and each Process model should be drawn using Functions from the bottom level of the Catalogue (preferably EBFs).
Summary
- Business Functions and Business Processes are NOT the same thing.
- A Business Function describes what the business ought to do; a Business Process describes the order in which it ought 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 Processes ought NEVER be decomposed - this should be done using the Function Catalogue.