Today I’m going to expand upon this to walk through an example of a BPMN diagram and explain what automating the diagram looks like for any users of the system and finish off with some of the advantages that this can bring.
So in the previous blog post I explained a little bit about some terms that you may have heard about. Today I’m going to expand upon this to walk through an example of a BPMN diagram and explain what automating the diagram looks like for any users of the system and finish off with some of the advantages that this can bring.
A key concept about business processes is that they are measured and managed as you would look after any asset of the business which directly delivers value to your customer. So how does that work then? If you take the example of an energy company, you’d think that their main objective is to supply electricity and gas to people’s houses around and at a basic level it is, however the energy company exists in a market with other competitors. On the retail side there is no difference between the energy supplied by either of the suppliers, gas from one supplier will not fry your eggs any quicker than the others, it’s all the same stuff coming down the tubes.
So for the domestic customer, you’d think that the only driver would be price and that this should lead to a race to the bottom for the suppliers trying to gain market share. It’s not though, price is definitely important but at some point the customers will have to interact with the energy company that interaction will be part of a process. How the company organises itself to meet that customer interaction will determine the customer’s perception of the company and value they then associate with them.
BPM is about ensuring that these interactions are measured and can thus be managed to ensure that the customer perception of the company is consistently delivered to the customer and also aligned with the company’s strategy and longer term aims. It doesn’t make sense to shave off profitability to offer a cheap deal to your customers if some of them have to call five times to resolve a query on their bill.
So the following is a simple BPMN 2.0 model, often known as a swim-lane model as it looks like a swimming pool seen from above. Again, this is a BPMN diagram shown through BPMN.io
‘s plug-in which is a great on-line modelling tool, this allows you to zoom in and out as well as scroll across, very useful. This model shows an order fulfilment process.
The swim-lanes themselves represent actors in the process, the names of the actors are located at the left hand side, note that bpmn diagrams can go across horizontally or vertically, there isn’t one correct way, it depends on the modeller. There aren’t that many types of objects in the diagrams so it isn’t that difficult to begin to understand them. They are basically made up of Events, Activities or Gateways, these objects are joined together by black arrows which make up the ‘sequence flow’. The starting point for any BPMN is a start event identified by a concentric ring.
There are different types of start event but in this case we will use the the message one, so this means that an instance of this process diagram will be created when a message of some type is received by the Order Management department. A connection goes from the event to the next object which is a task object with an arrow indicating the direction of the flow. The best way to think about these diagrams is to imagine that for each time a customer calls in to place an order then one of these diagrams is created and a little red ball (or token) sets of rolling from the start event along the sequence flow.
When the ball reaches an activity task, the activity is executed. What that activity might be depends on the type of task object used.
The same as for the events objects there are different types some which are executed by some IT system, some which are performed by a user with the BPM system, some can be executed by users completely manually, in this case the task is a User task which will require the user to do something in conjunction with the BPMS. Once the task has been completed, the ball continues rolling to the next object which is a gateway.
Gateways are where the a particular path(s) can be chosen and as before there are different types of gateways to accommodate different situations. There are gateways where the red ball divides in two (AND or ‘+’ gateways) and both sequence flow paths are followed as well as exclusive gateways (OR or ‘X’) where depending on some data/event a particular path is chosen from a selection. In this case the availability of stock is checked, “Is there stock for all the items of the order in this warehouse?” could be what the gateway decision is checking, it’s an exclusive gateway which means that the red ball can only go one way or the other.
There is also an AND gateway further on where the ball splits in two and two activities are done in parallel and later on the gateway joins together. At the join gateway, the two red balls join together to form one red ball and the journey continues onto finance. But the join gateway enforces its own logic on the process, the red ball can only leave the join gateway when both the other balls have arrived, this stops the Finance task being executed twice.
Also note the non-interrupting message event which sits on the border of the Check Other Stores task. The event could be triggered by the condition of not finding all the items from the order in stock. In this case someone from the Order Management team would have to inform the customer and then the sequence flow would end, the little red ball would disappear down the end event. What about the red ball that leaves the Check Other Stores task when that task has completed? Nothing, it carries on as normal, the line items from the order become a pick list for pulling products from inventory to complete the order.
There are various criticisms that can be made about the model, such as “What if the customer decides to change or cancel their order?” or “Are pick lists created for the same warehouse even though the order checked different stores?” which are all valid however the purpose of the model was to show how a BPMN model is processed by a BPM process engine. How does this process look like when it is deployed as a work-flow?
Typically the BPMS will operate a portal through which different teams will access their work. By logging into the portal, the BPMS will have identified your group (in this case as being in either Order Management, Warehouse or Finance teams) and thus control and present the tasks to each group in the correct order as the customer orders are received. Someone from Order Management may log on and see the following:-
On the left are tasks that need to be addressed by the Order Management team, each task will be from a customer order. On the right hand side are the details of one of the orders, the team member has to check whether the line items are in stock, if they are then for user clicks on the ‘Available’ button otherwise they need to click on the other button. The BPMS will then control the flow of that order and work out whether to create a task to “Check Other Stores” or whether the Warehouse team need to “Pick Items”.
By the way the mock-up was created using balsamiq
, I absolutely love the lo-fi approach of this tool as you can get clients to look at the data on display and not focus on details of the UI design.
So as you can see the BPMN process diagram started off as a design for a workflow but with standards agreed with the Object Modelling Group, the model itself is deployed onto an engine and is now a workflow for teams in the company.
The main advantages of this approach are:-
- The design of the workflow can directly align with the business strategy
- No cases are lost in hand-offs between departments, every process instance is accounted for
- The agility is there to adapt to the changing market; change the diagram and re-deploy onto the process engine
- Truly customer-centric view, reporting and SLAs can highlight when individual cases need to be escalated.
Hope this helps.