How to model a business process
Introduction
Figuring out the business processes for complex systems can be complicated. For example, if the goal is to streamline an existing supply chain process, your investigation will cross multiple business units, perhaps starting with an online order, a retail store pick-up, or a telephone order. How does the current process work to replace items in inventory storage and on retail shelves? Computer systems make these processes faster but often increase complexity. As a business analyst, programmer analyst, or IT auditor you are likely to need a graphical technique to help investigate and document current processes and work with a team to determine where problems occur and what the best solution is. Graphical process models are a common part of Root Cause analysis to determine exactly where problems occur. Graphics help teams communicate what software needs to be created or fixed based on a view of what data must be processed to meet and fulfill system requirements.
Description
A business process flow is a drawing that is concerned with business activities that someone or something would do and transitions between these activities. Using 7 simple symbols, users can show developers their current system processes. By depicting the business process in a graphical manner, it allows the analysts and users to take a step back and more easily identify constraints or inefficiencies in the process. Business process flows can be used to model high-level processes or specify detailed operations of lower-level user activities. The 7 symbols are shown in Table A below.
Table A. Common Symbols for Business Process Diagramming
Business Process Flow
The diagram below is an example of a process flow for when a bike is issued (rented), where the customer is new to the system.
Figure A – Simple example of a process flow
Figure B Example of the process with decision points. NOTE: Please insert the text of the decision in the diamond to add clarity. In the example below the diamond should say, "Is this a new or existing customer"?
A further advantage of activity diagrams is that they illustrate where activities can be performed in parallel. In fact, the process of drawing an activity diagram often uncovers the possibility of performing in-parallel activities that have previously been carried out sequentially. See the next example below which shows the process flow used to describe how to bike returns are handled
Figure C-1 Process with Parallel Processes
The synchronization bar indicates that the order in which these activities are performed is irrelevant; the activities 'Check bike' and 'Check return date' are taken in any order. The bottom synchronization bar indicates that the single outgoing transition is only triggered once both these activities have completed. A synchronization bar that signals the start activities is known as a join. The transitions at the beginning and of parallel activities are known as a fork, and one that signals the end of the activities is the end of parallel activities must match; all outgoing transitions from known as a join.
Business Process with Swim Lanes
Finally, it is sometimes useful to add the key stakeholders involved into the flow so you can better see who performs which tasks. You do this with vertical zones call swimlanes. Swimlanes are separated from each other by lines and the top of each swimlane is labeled with the name of the person, organization, or object responsible for carrying out a certain task. Note this could also be a system or machine (i.e. not just a human).
As we can see from the example below, swimlanes are very useful for showing who does what in a workflow or use case, and how the processing in an operation is divided up between objects. Note how in this example there is even more complexity revealed in the logical decision points after the return date and possible damage are verified.
Assuming we now have a complete version of the current process used to check in a bike, we could now start to determine if and how the process should change or move on to designing the needed updates for the system. This will serve as a useful tool later on if we run into a case where we want to change the system in a way that also affects the process
Figure C-2 Figure C-1 with swim lanes added
Reminder: Label or add text to decision points for better clarity.
Related Readings
As-Is Versus To-Be Modeling | Modeling System Architecture | Rules for DFD Modeling