Purpose of article:
- To explain the reason for business process modelling and provide guidance on techniques for doing it.
Purpose of process modelling:
- Required to understand the business processes that need to happen to make improvements for a new process or discover inefficiencies. For example if there is a “as is” process showing many hand offs or duplication of tasks unnecessarily then this could indicate improvements needing to be made in a “to be” process.
- To understand the scope for gathering requirements. Some requirements may have business processes that need new IT solutions whilst others may need to be manual. A process diagram can be designed to highlight which process falls into which categories and what actions are required of a project as a result.
- To identify requirements. It may be difficult for stakeholders to provide requirements if they are unsure of what they need. However they are more likely to be able to describe their processes. This can therefore be used as a starting point to understanding the requirements.
Technique guidelines
- Identify business events for each process diagram required. These can also be described as goals. Examples of these are:
- I want to buy a book
- To pay a credit card bill at end of month
- Insurance company to send out a renewal notice shortly before the anniversary of a policy
- A bank to send statements on the fifteenth day of the month
- Identify the trigger that starts the business event, is it driven by a person or triggered by time. The last two bullet points of business events in the example above are triggered by time.
- Plan the number of workshops depending upon the number of business events identified. A minimum of two may be needed. The first to put the process together and the second to review it and make any amendments.
- It is important to go straight to diagrams in the workshops and make sure it is in front of the stakeholders so they can add and amend as going through the process. Use either diagramming software like Enterprise architect or Visio or use brown paper and sticky notes.
- Starting from when the business event is triggered ask them to describe their business process when everything is successful right up until the end event. Put all of their tasks in the order they describe. It is normal for the stakeholders to remember additional tasks as they go through the process which is why post it notes are useful if doing manually. If using this method write each task on a separate post it note so that it can be moved around if required.
- Go back through the tasks described in the business process and identify where decisions need to be made. These are often represented by diamond shapes.
- More tasks then need to be added to represent alternative outcomes to each decision.
- Different teams involved in a process can be shown. These are known as swim lanes by showing the teams vertically and aligning the tasks against each team. This is useful for identifying handoffs and showing all of a business process. If different teams are involved with a process they may only understand their part. This may be the first time they get to understand the whole process.
- Additional information can be added by:
- Gaining an understanding of which tasks are manual, require interaction between a user and a system or whether need to be fully automated.
- The length of time for each task.
- Any data inputs or outputs required for each task can be represented by document or database symbols.
Example
The above diagram is a first draft of what the business process could look like for booking a room at a hotel. This scenario assumes it is done via a travel agent and that a room is available. The process ends when both the customer and hotel reception have been notified of the booking being confirmed.
If investigating for improvements, then questions would be centered around which tasks create delays or problems.
If looking to scope a project questions would be based around which tasks fall within its scope.
If identifying requirements then questions would be around looking into more detail of what is behind each task, e.g. what data is required to get a booking, what interactions are required to check availability etc.
Summary
This article was aimed at providing just an overview or the importance of process modelling and to provide guidelines for doing it. There are many different modelling notations that can be used. Business process modelling should be towards the start of every project and ideally agreed prior to other artifacts being written.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
