Modeling Business Processes
A business process represents a combination of tasks linked to each other to realize a business objective. The business process model will capture a definition of these tasks, the roles required to perform these tasks and the organizations within which the tasks are performed. This definition covers a broad spectrum, but doesn't provide a structured model to develop a business process model. Let's take work our way through an everyday example, and model a business process based on it.
A simple recipe
Fig.1: Example of a simple recipe
Let's start by taking a common process most of us will be familiar with, before diving down into some nitty-gritty business domain like banking, supply chain management, or insurance. Making an omelette is a process that is probably familiar to most of us. A simple recipe to make an omelette for 2 people involves chopping up some onions first, and then mixing it with the eggs and other ingredients, and then frying the mix on each side until cooked. This recipe is simple, and easy to understand. In fact, it could be the business process definition if all we ever wanted to do was to make simple omelettes using simple equipment to serve 2 people. If we want to make the omelette for more people, we need more ingredients, larger bowls, and bigger skillets. If we want to make different kinds of omelettes, such as Cheese Omelettes or Spanish Omelettes, we might have to add a few more steps in the process. Finally, if we start making the omelettes for several people, we will probably require more than one cook to speed up the process. Thus, a good process definition will address the ability of the process to scale (capable of greater output) and flexible for reuse (capable of variations. Let's start by creating a model for making omelettes that addresses these areas.
Tasks and Processes
One of the first challenges in modeling a process is to distinguish between tasks and processes. A task is an atomic unit of work, which cannot be sub-divided further into other tasks. A process is a combination of tasks used to achieve a business objective. For instance, "making an omelette" can be divided into the tasks of "cracking open the eggs", "chopping onions", "mixing the ingredients", and "frying the mix". At each stage, there are distinct actions (breaking, chopping, mixing, and frying) and entities with which the task is performed (bowls, eggs, pans, oil, knives, etc.). "Cracking open the eggs" and "chopping the onions" can be broken down into "break an egg" and "chop an onion". In this example, "making an omelette" is a process, and "crack an egg open", "chop an onion", "mix the ingredients", and "fry the mix on a side" are tasks. Each of these tasks can be repeated multiple times. For instance, if I have 3 eggs and 2 onions, I will perform the task of "cracking an egg open" 3 times, the task of "chopping an onion" twice, and "frying the mix on a side twice" (once on each side).
Fig.2: How to make an omlette
A useful rule of thumb in creating an atomic unit of work is to remove plurals from your task. "Chopping onions" becomes "chopping an onion", and then the task becomes scaleable, irrespective of whether I have a single onion or millions of onions. Well-defined tasks usually outlive the processes of which they are a part. I can chop an onion as a part of a process to make an omelette, but I can reuse the task definition when I want to make a salad with chopped onions, or any other meal which features chopped onions.
Roles and Functions
A role defines a atomic unit of responsibility. A function is an organizational position for a person who fulfills one or more roles.
Fig.3: Function to role mapping
As a rule of thumb, whenever you encounter human-resources (HR) defined position, it is likely to be a function. Positions such as "Customer Service Manager" describe a function, but tell you little about the tasks a person with this position fulfills. A "Customer Service Manager" is responsible for handling customer queries if they cannot be handled by a "Customer Service Representative", training inexperienced "Customer Service Representatives", and interviewing candidates who have applied to be "Customer Service Representatives". "Customer Service Representatives" are responsible to handling customer queries and modifying the information for customer's accounts upon request. A "Junior Customer Service Representative" is only allowed to handle customer queries. In this example, "Customer Service Manager", "Customer Service Representative", and "Junior Customer Service Representative" are functions, and they provide indications for the roles, organizational seniority, and pay-scale. Each of these functions can perform the role of handling customer queries. As functions incorporate concepts from fulfillment, hierarchy, and remuneration, they tend to change more often than roles, which only model fulfillment. Thus, when designing operational systems for fulfillment, mapping roles to tasks will result in a model that is more stable in a changing enterprise.
Tasks and information about fulfillment
Once you have started defining the tasks, it is usually useful to identify what you use to fulfill the task. For instance, "chopping an onion" in my rather humble kitchen is done with a chopping knife. I could model the task as "chop an onion with a chopping knife" and then both the task definition and the thing used to do the task are defined. "Chopping an onion" could also be done with a grater, a food processor, or within an industrial food processing unit, by a machine. If the process I am defining is only ever going to be used within my kitchen, and if I am never going to buy a grater or food processor, then the definition of the task as "chopping an onion with a chopping knife" will not be prone to change. If you are confident that the tools, infrastructure, equipment, people, and organizations used to fulfill a task will remain constant, do put in information about how the task will be fulfilled into the task definition itself. Otherwise, refrain from tightly-coupled definitions between a task and its fulfillment. Refer to Modeling Capabilities for more information.
Enhancing the process
A process essentially produces a product or result. Using the same process to produce other products and results is a common requirement. As modifications to the process to permit the production of other products can often be detrimental to the existing products produced by the process, so it is important to measure the impact of changing a process. When redesigning a process, there are 3 options:
1) Pretend the orange is an apple, and pass it through the apple's process: Odd as this may sound, most businesses usually opt for this course of action. If a process exists to create an onion omelette, and I need a process to create a mushroom omelette, I'll still execute the task to "chop an onion", but instruct my staff that what I really mean when I ask you to "chop an onion" is to "chop up stuff". The process definition remains the same. Typically, pretending oranges are apples lead to more confusion. People that are unfamiliar with a process, such as new staff, have to be handed a workaround sheet for a process, explaining the conditions under which oranges should be considered apples. Little workarounds add up, and the longterm costs of such workarounds can cripple an organization.
2) Modify an existing process to produce multiple results: This involves inroducing conditionality inside the process. The current process has a task to "chop an onion". I now want to introduce a new task to "slice mushrooms". "Chopping" and "slicing" can involve different types of knifes (equipment) and produce different results. The task can be made more generic, and be re-modeled as "cut a vegetable", where "cut" is generalization of "chopping" and "slicing", and "vegetable" is a generalization of onions and mushrooms. The result of executing the task is that a vegetable will either be chopped or sliced. The knowledge of whether a vegetable should be sliced or chopped can either be introduced into the task, or it can be managed as a "cutting instruction" to the task. Unless it is the case that a mushroom should always be sliced, and onions should always be chopped, it is best to keep that knowledge outside the task. The task's definition should only be focused on executing instructions, and part of the instructions can be "cutting instructions".
3) Create a new process: Don't be afraid to start all over again. If the original objective of the process is quite different from the new requirements, don't be afraid to redesign the process. For instance, in the supply chain management domain, a business process for procurement starts with an order being provided to a supplier (the entity supplying the items) from a procurer (the entity that wants the items). The order typically contains information about how the required items and how quickly the items are required (e.g. the next day, or within a month). A significant portion of the process is different for delivering items the next day, particularly the logistics portion of the process. Obviously, in this case, more than one process is required to ship the items within different delivery periods.
Optimizing the process
"Premature optimization is the root of all evil." Donald Knuth
Refrain from optimizing a process before you have tried it out in practice. Optimization best occurs when a process has been implemented, and you have feedback from the people that participate in that process. Let's re-visit the scenario of making an omelette. As a single male, I've continued to make my sunday omelettes by myself. Recently my girlfriend moved in, and now we'd like to make our omelettes together. Several optimizations are possible in order to scale-up the production of omelettes. She can slice the vegetables while I chop the onion. That will probably save us a few minutes. After that, we'd probably end up getting in each other's way, so we're probably better off with one person doing all the subsequent steps (mixing the ingredients and all the steps involved in cooking the omelette).
Fig.4: Modified omlette making process
Ultimately, is it really worthwhile optimizing the process to cook omelettes? Given the preference that "one person makes dinner", probably not. So while optimization is an enjoyable exercise, it is best to optimize a process once it has been used a couple of times, and optimizations result in better product or result value. In the example of the omelette, better value would mean a better omelette in a shorter period of time, while keeping all the participants of process effective.
