Business Process Modelling – the basics

This article explains why you should produce a business process model, what they are and how we can produce them.

Business process models are important for a number of reasons:

  • provides a business context for the project
  • assists in identifying requirements
  • establishes a shared understanding of end to end process(es) between all stakeholders across business units
  • reflects the business process in a simple form in the ‘language’ (i.e. business processes) that the business understands
  • is used as a ‘common thread’ throughout the project to support testing and production of training and user manuals

What is it?

The business process model shows in diagrammatic form all of the processes under consideration. It shows the trigger that initiates the process; the sequence of steps to complete the process; which business units/teams are responsible; handoffs between teams; business rules.


A typical process model will have several levels of detail with the highest level showing, for example, the lifecycle of a customer from the point of becoming a customer through to the point their relationship ends. The detail processes will show specific interactions or transactions the customer has with the business.

It can be used to represent the current state of the business (i.e. ‘As is’) or the target state (i.e. ‘To Be’).

There are many different forms for representing the business process but they tend to convey the same information, just with different representations. Some well known approaches include UML (Unified Modelling Language) use of ‘swim lanes’ or activity diagrams; Business Process Modelling Notation (BPMN); and IDEF0.

The examples shown here use activity diagrams.

Why use it?

Business process models are used in a variety of circumstances including Business Process Re-engineering (BPR) and Business Process Management (BPM) and it can play a part in process improvement approaches such as Lean and Six Sigma. This article considers how process models can play a part in a ‘typical’ project where existing processes are impacted or new processes are introduced and does not explore Lean or Six Sigma.

In a typical project of reasonable complexity, there is value in modelling the ‘To Be’ processes as these will be of value in the project for the reasons described at the start of the article.

There may also be value in modelling the ‘As Is’ business processes. However, this may take considerable effort so it is important this is considered and it is decided there is benefit before it is undertaken.

There is value in undertaking ‘As Is’ process modelling for the following reasons (there may be other reasons):

  • existing processes are poorly understood and will be impacted by new project
  • business units understand only their part of the process
  • existing processes are largely manual and project objective is to automate the existing process

Business process models provide real value on a project as they can engage the business stakeholders in a language they understand. They also provide the bigger context for a project which when presented in a diagrammatic form can generate insights which produce a better set of requirements and identify possible requirement gaps – for example, where handoffs occur between different teams.

Let me know your thoughts and experiences with business processes. Have you found them useful? Do you disagree with my conclusions?

About Alex Papworth

12 Responses to “Business Process Modelling – the basics”

Read below or add a comment...

  1. Anjala Fernando says:

    Wel this is really good. Sums up the basics of Business Process diagramming. Have a one concern though, When diagramming the Business process are we documenting only the User/ Team involvement and the process flow or do we have to document the System interactions as wel ??? and if we add the system interaction to the business process does it change the definition of the Business process modeling ?

    • Alex Papworth says:

      In my opinion, business processes are not suitable for including system interactions. This shows too much detail and can be confusing and unecessary for the typical reader (business person).
      HOWEVER, they should identify where one person is interacting with a system at one time to achieve a specific task.
      AND, this is a system requirement (perhaps a feature) and maps very easily to a use case where the detail of the system interaction can and should be described.

      Hope this helps Anjalo

  2. Tracey says:

    I always come back to this article again and again to re-establish where I should be in BMP! Sometimes we can get lost in the detail of processing and I use this as a way of bringing myself back out again and look at the wider picture. I'm sure this will happen naturally after a few years of practice.. but in the meantime, this article lives in my 'Process folder'! Many thanks. Tracey

  3. JohnOwensIMM says:

    Hi Julian

    Probably the most effective tool at the moment is Corporate Modeller from Casewise. It is repository based – has a database in which all objects are held for re-use on other diagrams – and can model all facets of the business.

    You can find out more about the Integrated Modelling Method at

    John Owens

  4. Julian Roberts says:

    Wow, I've been doing this for a few years as a result of an Oracle implementation, and Six Sigma, and Sarbanes Oxley compliance using MS Office products. I had no idea I was engaging in "Business Process Modelling" Nice! I'm gonna add that term to my specialties…lol. Nice remarks John! I agree that an enormous amount of time can be lost engaging in the As-Is, especially when users hate to let go of the established processes.
    So, I'm curious about the methods mentioned in the article. Is there a software package that is better than MS Office or Visio for BPM.

  5. Amir. Ibrahim says:

    Great Article.

    Thanks John.


  6. JohnOwensIMM says:

    A comprehensive article listing the benefits of the Process Model, which can provide vital business benefits. However, Process Modelling does come with some vital health warnings.

    Health Warning 1: Build the Function Model First
    All processes are derived from Business Functions so, before you start modelling processes, build your function model. This is far easier and faster to build and, in a single diagram if required, will provide you with a complete view of any business.

    Health Warning 2: Never Decompose Processes
    All decomposition should be done in the Function Model – where it can be done easily. Decomposing process models results in the need for up to three times more diagrams than are necessary. You can also miss out up to 30% of the business using this approach.

    Health Warning 3: Beware Building the "As Is" Model
    It is true that all businesses should have all of their essential processes modelled. However, if the business is about to undertake a major change, then modelling the "As Is" processes is a huge waste of time as it actually represents what should NOT be done in the business (if it was the business would not be changing!). Better at this stage to model what the business OUGHT to be doing, starting with the business functions.

    John Owens

    • alexpapworth says:

      Hi John

      I tend to agree with your last point on ensuring there is value in modelling the As Is. An example here would be where you are intending to automate the As Is process and the current process is poorly understood or understanding is incomplete and fragmented across several business units.


  7. A R Sudhindra says:

    Amazing article


  1. […] Business process modeling (this is the ‘go to’ tool for most business analysts. Listen to this recording of Be a Better BA webinar on using BPM for reqt gathering) […]

  2. […] Papworth, A ‘Business Process Modelling – the basics’, Business Analyst Mentor, viewed 01 May 2014, […]

Leave A Comment...