This is the second post in the series of Business Process Management (BPM). Today, we get into the fun stuff — well, what I consider the fun stuff. This is where we take all of that initial hard work to understand the business’ needs, values, key stakeholders, operations, and how they are all interconnected, and draw it all out. Essentially, we are making a more detailed version of a block diagram. Before we get there though, let’s start with some of the basic (and limited) information so that we can all use the same terminology. From there, we’re going to do a brief example, and we’ll finish by modelling the As-Is information using Bizagi. It is a free piece of software, but quite powerful — I strongly recommend it, although there are other programs out there, i.e. Lucidchart.

Note: If you’re interested in some more information around BPMN, feel free to check this resource out. If you’re interested in exhaustive information around BPMN (because you’re a nerd), feel free to check this resource out (because nerds).

Objects and Definitions

• Events: represent things that happen simultaneously
  • A start event triggers a new process instance (it generates a token that traverses the sequence flow)
  • An end event signals that a process instance has completed (it consumes a token

• Sequences: implies an order of execution

• Activities: represents units of work that have a duration (tasks = atomic activities)

If we put those three together, this is the outcome that we see:

• BPMN – Good Method & Style
  • Event: noun + past-participle + verb (e.g. Insurance claim lodged)
  • Activity: verb + noun (e.g. Assess credit risk)
  • Avoid long labels ( < 5 words)
  • Avoid articles (“a”, “the”)
  • Avoid general verbs – replace with meaningful ones
  • Capitalise first word only
  • Process names in lower case
• BPMN – Branching & Merging
  • Process activities are not always sequential
  • Work can be performed in a mutually exclusive way
  • Work can be performed in a concurrent way
• Branching & Merging – XOR
  • An XOR Gateway captures decision points (XOR-split) and points where alternative flows are merged (XOR-join)

• XOR-split – takes one outgoing branch

• XOR-join – proceeds when one incoming branch has completed

Example

Let’s say you want to start a pizza shop. You’ve only got the money for a pizza oven, some manufacturing supplies, ingredients for a few different styles of pizza, but not enough for other employees. Simplifying the process down to a few steps, we could model your current approach to pizza making as the following:

1. You receive an order for a pizza,
2. You make the pizza,
3. You bake the pizza,
4. You deliver the pizza,
5. You take the money, and
6. Return to the store

Over time, you start to really get over this whole one-person approach to the pizza world, so you employ one other person — a delivery person. Since we have one more person in the process chain, this means we need to create another lane in our store’s pool. Since we’ve added an additional person into the process who will take on some of our previous tasks, this means we can map the new model that you have updated for the business:

1. You receive an order for a pizza,
2. You make the pizza,
3. You bake the pizza,
4. You pass the pizza to the delivery person,
5. The delivery person delivers the pizza,
6. The delivery person takes the money,
7. The delivery person returns to the store.

Due to your popularity over time, people start entering your store at random times throughout the day. Whenever someone comes into the store though, you need to stop making your current pizza and take their order, slowing down the process. Since you’ve noticed it’s difficult to keep up with this demand, you decide to hire an additional employee — customer service (and we’ll add another lane into our pool). This means we can update the model one more time:

1. Customer service representative receives an order for a pizza,
2. Order is passed to you
3. You make the pizza,
4. You bake the pizza,
5. You pass the pizza to the delivery person,
6. The delivery person delivers the pizza,
7. The delivery person takes the money,
8. The delivery person returns to the store,
9. Delivery person hands the money to the Customer service representative.

It’s been noted that there can be some issues with the pizza dough that you’ve been ordering. If you notice that a pizza dough isn’t of a high enough quality, you will throw that one out and replace it with another. 

As you can see, you can start to account for various different roles, different scenarios, and outcomes that either have happened in the past or could happen in the future. I don’t know why, but I just love thinking about and visually planning all of these scenarios — maybe making the uncertain certain. Who knows. If you’re interested in checking these processes out to more depth, here is the Bizagi file that you can edit in the way that you’d like.

Building the As-Is Model

Outlined in the first post in this series, we have conducted the necessary interviews and organised all of the information from the different stakeholders for their processes that they complete throughout it. Since we have all of those steps, my process for translating it into the BPM model is pretty logical. I like to step through sequentially and mark off each sentence as I go. Legitimately, I’ll read the sentence, locate it in the sequence, draw it, then cross off the sentence.

I’ve included the Bizagi file here, but here are the screenshots for the: 1. main process, 2. rendezvousing subprocess, and 3. ECI Process subprocess.

Next Steps

For the next instalment of this series, we will be combing through the processes, increasing time efficiency, and, essentially, taking out all of the unnecessary WASTE that the business is doing. Is there anything that you can see that appears to be redundant, or something that you’d do better? Leave it in a comment below.