Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

What is Process Modelling?

Is This a Silly Question?

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, however, “process” is one of the most widely misunderstood and misused terms in business and business modeling! Managers and analysts alike often use the term “process” when what they are really talking about is a Business Function or even a Business Procedure. No wonder there is confusion!!

Modelling Definitions

So let’s start with a few essential 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 outcome.”

So, in short, Functions describe what a business OUGHT 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 Business Functions!!

The Building Blocks of a Process

Every true Process will contain the following elements:

  • Objective
  • Trigger
  • Functions
  • Precedence
  • Outcome

Objective:

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 down) view of what a process is meant to achieve then there is very little chance that the process will achieve 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 like, “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 Outcome and Non-preferred Outcome.

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 that 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 (EBP).  EBPs are what the business does on a day-to-day basis.

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 AT ALL COSTS as it has two major flaws:

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

Process Modelling is a Secondary Modelling Technique

Contrary to popular belief, Process Modelling is a secondary, not a primary, business modelling technique.

It is ideal for modelling processes. It is not suited to modelling the business as a whole. This is the roll of the Function Model.

When process modelling is used as the primary modelling technique it results in up to 30% of business functions being missed out of the resulting business model. Most of these functions are those that create the major reference data for the business. This in turn has a negative impact on the quality of the enterprise data model and resulting databases.

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 be done.
  • Business Process Modeling should ALWAYS be preceded by Business Function Modeling
  • Processes should 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.
  • Process Modelling should never be used as the primary modelling technique when modelling a business.

Useful Links

Video on Business Modelling Techniques

More on Function Modelling

If you liked this article, please feel free to leave a comment below.

Tags:

4 Responses to “What is Process Modelling?”

  1. Ronald Kgafela September 22, 2010 11:54 pm #

    I want to be a Business Process Re-engineering Specialist(Certified) Please help with those accredited institutions i can enrol with

    • John Owens September 23, 2010 9:24 pm #

      Hi Ronald

      There are many institutions with which you can get certified – you can find these by doing a Google search. But the main question to ask yourself is, “Why I you want to get certified?”

      The main thing to do is to acquire the skills that will enable you to practice BPM (more importantly, Business Modelling in general) to a high level of proficiency and quality.

      Certification in itself will not give you this, as many of the techniques for which certification is given, are not very good.

      Regards
      John

  2. Giovanni Focaraccio May 6, 2010 7:45 pm #

    Thanks for a great article John. Everything you say makes perfect sense to me even though in goes against the typical school of thought. To incorporate your approach into an existing environment where the more “conventional” process modelling is already entrenched, do you have any suggestions on how one would proceed and whether there are any other sources of supporting information one could reference (besides your own personal experience and common sense of course).

    I’m based in South Africa for what it’s worth and came accross IMM on youtube for what it’s worth.

    Regards

    Giovanni Focaraccio

    • John Owens May 6, 2010 8:39 pm #

      Thanks for your kind comments, Giovanni.

      Other resources? Very hard to direct you to any that are published. I have searched on the net without much success. Oracle Case Method at one time made the Function Hierarchy a key business model but never fully integrated it with Process and Data. IMM is unique in putting this at the core of all other models.

      Mechanically it is very simple to incorporate IMM into a “conventional” process modelling approach; simply build a Function Model, for all or part of the business, based on WHAT the business OUGHT to be doing. You will need to build this using input from the most senior executives.

      When updating existing process models ensue that each step in that process is a Function from the Function Model. I hope that this helps.

      The hardest part of introducing IMM is changing the way people think. Changing them from always trying to deal with and tune how things are currently done to dealing with WHAT OUGHT to be done.

      As you have asked the question, I will put this on my list for future articles.

      Regards
      John

Leave a Reply