Practical BPM: Modeling Business Processes

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Practical BPM: Why Business Process Modeling & Analysis An Overview of Business Process Modeling 10 Things You Can Do To Improve Your Business with BPM Right Now
	Discussion Forum "I am looking for opinions about process modeling programs. I figure that would be one way I could familiarize myself with the various BPM products available." Contribute to this Discussion

By Rashid N. Khan

This is part two of a three-part series discussing business process modeling and analysis. Part one looks at why a company should implement business process modeling and analysis.

Business process modeling and analysis (BPMA) is vitally important for the success of BPM initiatives, but the work involved is often underestimated in the rush to deploy solutions.

Developing and deploying process automation solutions are often complex and expensive IT projects. Therefore, it behooves a business organization to try to predict the behavior of a process after designing and documenting it, but before incurring the cost of development and deployment. This is analogous to the design of new airplanes whose development is very expensive. Aerospace engineers first build a model of a new airplane and test it in a wind tunnel. If it does not behave as expected or desired, it is time to go back to the drawing board to change and improve the model and test it again. Only after they are satisfied that the model behaves according to design objectives do they commit to its development and production.

The purpose of process modeling is to assess the behavior of a business process before it is actually developed and deployed. If the model behaves as expected, the project can proceed with development and deployment. Otherwise, the project team has three choices:

1. Change the process model to eliminate the bottlenecks or other factors that do not measure up to expectations.
2. Add more resources to improve the performance or eliminate bottlenecks.
3. Reset the expectations of the customers served by the process so that the expectations are consistent with what the model predicts.

All of these choices are acceptable as long as they are accepted and understood before the automated process is put into production. Doing so afterward causes frustration and disenchantment with the overall BPM solution.

BPMA software can perform workload and throughput analysis on a process prior to the development of a deployable solution. This capability enables business analysts to use the process developed by the process owner and provide estimates about resource availability and completion times for each step. BPMA software can then run a large number of process incidents through the model and produce statistical data indicating lag time, elapsed time and bottlenecks in the process. The results of modeling can be used by process owners and business analysts to change the process, or the resources used by the process, with the goal of optimizing its performance. Modeling enables business owners and analysts to predict the behavior of a process well before it is actually developed, deployed and used. By knowing this behavior, business owners can understand the benefits and the constraints of the solution.

Statistical modeling for optimization is not necessary for all business processes. It is generally useful only for processes that have high volumes and resource constraints, such as claims processing, order processing and call centers. For these types of processes it is necessary to optimize the process design and the allocation of resources in order to ensure that it is efficient and cost-effective. On the other hand, processes that are not resource constrained, or involve creativity by knowledge workers, cannot be optimized using statistical modeling. Creativity should not be constrained by strict time restrictions, and the creative process has its own dynamics that may not follow pre-defined paths and assumptions. Trying to optimize such a process through modeling will most likely be counterproductive. Likewise, many administrative processes that are not resource constrained will not benefit from statistical modeling techniques. For example, employee performance review processes are prevalent in every organization and are excellent candidates for process automation. A manager may perform ten performance reviews a year. The manager is not performing reviews all the time. If a review becomes due, the manager will have to find the time in his or her schedule to conduct the review. It generally does not make sense to use modeling to optimize such a process. And the company will most likely not hire another manager simply because a particular manager could not do reviews in time. The organization’s policies and procedures, and not the results of modeling, will determine how performance reviews are performed.

Modeling enables the business process owner or analyst to ask questions such as:

1. How many incidents of the business process can be completed in a week?
2. If new cases are coming in at the rate of 100 per day, how many new people should be added to various steps in order to ensure that every case gets processed in three days?
3. What is the cost of performing a particular step in a process?
4. If the number of claim appraisers is reduced to half, how long will it take to process a typical claim?
5. How long does it take the bank to process a loan? How much more will it cost to reduce the time by 50 percent?
6. What is the minimum amount of time a person will have to spend to perform a particular step in a business process without creating a bottleneck?
7. How much time and money can we save by automating a particular step in a process? Does that automation allow us to adjust resource loads elsewhere and still meet our goals?

Modeling Scenarios

Modeling is the domain of business analysts. They use their experience to define scenarios that approximate real-life conditions. A scenario is a set of assumptions about the resources used in a business process and the probabilities of various events that might occur during the course of a process. Some of the assumptions are about the process overall and reflect the business rules of the company that may influence the process. Other assumptions are about the resources and time used at various steps in the process. Finally, there is a set of assumptions relating to the probabilities of various events that might happen at specific points in the process. Each set of assumptions constitutes a scenario.

Process-Level Assumptions

Process-level assumptions are assumptions that are made about the business process as a whole. They include the following:

1. Rate: A business process starts because of some event, such as the receipt of a new order, hiring of a new employee, or submission of a new claim. These events trigger an incident of a business process designed to respond to the event. The rates at which these events occur determine the number and frequency of the incidents. This will dictate the resources required to handle the work generated by these incidents.
2. Incident count: The purpose of modeling is to run a number of incidents of a process in order to gather statistical data that predicts how the process will behave under a given set of assumptions. Some business processes are not resource constrained and will achieve steady state behaviors after only a few incidents. Others might be more complex and achieve steady state behavior after many incidents. And yet other may never reach steady state. The incident count setting in a scenario specifies the number of incidents that must be run through the model in order to provide enough data that is statistically significant.
3. Pre-load incidents: The goal of modeling is to measure and optimize the performance of a business process when it is in the midst of operations. When a process starts, there is nothing in the pipeline. The first few incidents that go through the system are processed relatively quickly because people or applications are waiting to perform tasks and have nothing else to do. The true measure of the response time and efficiency of a model is when the pipeline is full. The "pre-load incident" parameter in BPMA tools allows the analyst to specify the number of incidents that are run before it begins to capture data for modeling. These incidents fill up the pipeline in order to provide a more realistic estimate of the responsiveness of the model. If the incident count is set to 100 and the pre-load is set to 10, the scenario requires that 10 incidents to be started and processed, but the data from these incidents is not used. The 11th to 110th incidents are used to gather the data for statistically determining the behavior of 100 incidents.
4. Day calendar: Modeling involves mimicking the behavior of individuals as they go about completing process tasks assigned to them. Companies have pre-defined work hours and break times scheduled for their employees. A scenario should include a specification of the work hours of the individuals involved in the process, and the break times during which they are not working. Specification of a working day calendar makes the model realistic. The day calendar has to span one day only, and not be concerned with weekends or holidays. This is because the model will replicate behavior over a specific number of business or working days only, and discounts weekends and holidays.
5. Task priority: When a user selects a task from the task list, the user can prioritize the tasks in two different ways. First, the user may simply decide to perform the first task that is in his or her inbox regardless of any other factor. This is the first-in, first-out (FIFO) approach. Second, the user may decide to do the task belonging to the incident that was started the earliest under the assumptions that the incidents should be prioritized in the order they were initiated – incident priority. The selection of one of these methods of prioritizing tasks can significantly impact the model, especially if the business process is not a simple linear flow. Incident priority should therefore be included in the scenario.
6. Method of generating random time durations: BPMA software allows the business analyst to specify expected times for completing various activities performed by users or applications. In the real world it is unrealistic to expect any activity to always take a precise time. To make modeling realistic, the BPMA software must enable the analyst to specify how to generate a random time for each activity within some range. This is accomplished by allowing the analyst to select either a "uniform distribution" or a "normal distribution" as part of the process level assumptions. If a uniform distribution is selected, the analyst has to specify a minimum and maximum value for the time duration of each activity. When the software generates the time for an activity, it uses a random number generator to generate a number between, and inclusive of, the maximum and minimum specified. In this way the software ensures that the probability of generating the time is evenly distributed between the minimum and maximum values. The likelihood of the time being at the "minimum" or the "maximum" is the same as every other intermediate value, as shown in Figure 1. A uniform distribution is easier to understand and implement, but is not realistic. In most cases the time estimated for any activity will be closer to some average or mid-point between the maximum and minimum. It is easier to estimate the mean average. Furthermore, a uniform distribution implies that the chance of getting any value within the range is equal to any other value. However, for any value outside the range the chance suddenly drops to zero, which is not realistic.

Figure 1: Uniform Distribution

A normal distribution can be used to make time estimation more realistic. If this method is selected, the analyst has to specify an estimated mean and a standard deviation (also called sigma or s). In a normal distribution the probability of randomly generating the time is the highest near the mean, and decreases further away from the mean, as illustrated in Figure 2. Furthermore, a normal distribution guarantees the probability of generating a time value in certain ranges measured around the mean.

Figure 2: Normal Distribution

These probabilities and ranges are shown in Table 1. Thus, if the mean is 10 and the standard deviation is 2, the probabilities of generating values in various ranges are as follows:

68.27 percent of the values will be between 8 and 12
95.45 percent of the values will be between 6 and 14
99.7 percent of the values will be between 4 and 16
99.99 percent of the values will be between 2 and 18

Table 1: Probabilities for Various Sigma Values in Normal Distribution
Sigma (s)	Probability Value Is Between (Mean-s) and (Mean+s)
1	68.27%
2	95.45%
3	99.73%
4	99.99%

From this explanation it is easy to see that most of the values will fall around the mean. The chance of a value being very far from the mean decreases, but it is always possible. The standard deviation is a measure of how close the values are likely to be in relationship to the mean. A small standard deviation implies that most of the values will be closer to the mean, whereas if standard deviation is large the values will be spread out. By using a normal distribution, the analyst can specify the mean or expected value, and also the variation about the mean.

Step-Level Assumptions

A scenario also contains assumptions about each step. These assumptions are related to the time it takes to perform tasks at the step:

1. Task time: This is an estimate of the amount of time it takes to perform the task for a step.
2. Lag time: This is an estimate of the minimum dead (or away time) between tasks. It is based on the assumption that when a person completes a task, he or she does not immediately start working on the next task. This is especially true if the assigned task is not the primary responsibility of the person; this individual might have other duties to perform that have nothing to do with this business process. On the other hand, if a person is totally dedicated to performing this task and has no other responsibilities, the "lag time" property can be specified as "0." In this case, the person will start a new task as soon as the previous task is completed. However, if the lag time property is not set as "0," it is assumed that the person will spend a minimum time equal to the lag time after the completion of the task: performing other duties before starting the next task. The emphasis is on the word minimum, because after this time has elapsed the person can start the next task only if there is a new task in his or her inbox. If there is no new task in the inbox when the lag time has expired, the next task will start as soon as it arrives in the inbox.
3. Number of resources: More than one individual may be assigned to perform a particular task in the business process. Therefore, for each step, the number of people assigned to the step must be specified. If a step involves computer applications or machinery instead of people, then this parameter is used to specify the number of applications or machinery available to perform the task at that step.
4. Task rate: This is the burden or overhead rate of the users assigned to completing the task for the step. By multiplying the overhead rate with the task time, the software can calculate the cost of performing the step.
5. Percent (%) returned: A certain number of tasks for a step may be returned for lack of information or some other factors. The "percent returned" variable in a scenario can be used to specify the probability of a task being returned.
6. Percent (%) resubmitted and resubmit time: After a task has been completed, it is sometimes necessary to open and resubmit the same task again because of the availability of new information or some other external event. For example, if a customer places an order it may trigger a business process when the order entry clerk enters the order form. However, at some point after the order has been placed, the customer may change his or her mind about some aspects of the order (such as the quantity to be purchased). Instead of canceling the entire incident, the order entry clerk may simply resubmit the order with the new quantity. This ensures that tasks that are not impacted by the change are not affected, whereas those that are impacted can be performed again. A scenario, therefore, should provide a "percent resubmitted" setting that allows the analyst to estimate the probability that a task may be resubmitted. Furthermore, if a task is resubmitted, there is another variable called "resubmit time" that allows the analyst to specify an estimated time duration after which the step may be resubmitted.

Event Conditions and Probabilities

Each step in the process map may have event conditions and actions associated with it. These event conditions and actions allow the process map to incorporate business rules that change the flow of the process when events occur under specific conditions. While modeling a process and defining a scenario, the business analyst has to make assumptions about the probability of a particular action being taken. For example, a business process may have a rule that the department manager must approve a purchase order if the amount of the order is more than $1,000, or if the item being purchased is hazardous material. In real life, the business process will be driven by the actual value of the order or the type of the item being purchased. However, while modeling the behavior of the process, the business analyst must make assumptions about the probability of occurrence for these events. BPMA software allows the business analyst to enter probabilities for conditional events in the model. These probabilities become an integral part of the scenario and impact the routing and performance of the incidents during modeling.

Modeling the process – and predicting a process’s future – is an important step to saving time and money once a formal business process is launched.

Useful Links

This article is an excerpt from Rashid Khan's Business Process Management: A Practical Guide. Order your copy here:
http://www.bpmenterprise.com/yDQ

About the Author:

Rashid N. Khan is the founder and Chief Technical and Strategy Officer of Ultimus Inc., a pioneer in business process management and workflow automation. Prior to establishing Ultimus, founded Sintech Inc., a leader in advanced software for mechanical testing. Rashid sold Sintech to MTS Systems in 1989, where he worked for a five years as a vice president and general manager. During this period he took the company through ISO 9000 certification. This experience made him aware of the need for business process management and workflow automation. Rashid obtained two undergraduate degrees from MIT in computer science and political science. Khan is the author of Business Process Management: A Practical Guide, has published numerous articles and spoken at a number of events. Contact Rashid N. Khan at info (at) ultimus.com or visit http://www.ultimus.com.

Rate This Article:  Current Rating: 3.80   Poor    Excellent                1    2    3     4    5   View all top-rated articles

Copyright © 2003-2008 – BPMEnterprise.com, CTQ Media. All Rights Reserved
Reproduction Without Permission Is Strictly Prohibited – Request Permission

---

Publish an Article: Do you have a process management tip, learning or case study?
Share it with the largest community of Business Process Management professionals, and be recognized by your peers.
It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.