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?