|
|
 |
Practical BPM: Executing a Process Model
|
|
|
|
|
|
|
|
|
"When people talk about having executable code after process modeling, exactly what are they talking about? Is this code that somehow does the automated aspects of the work or is it something else?"
Contribute to this Discussion
|
|
|
|
By Rashid N. Khan This is part three of a three-part series discussing business process modeling and analysis. Part one looked at why a company should implement business process modeling and analysis. Part two delved further into what modeling and analysis can achieve.
Business process modeling and analysis can be useful even if there are no plans to automate a business process. The modeling of a process starts after the business analyst has created a scenario. During the course of modeling, the BPMA software uses the information about the model and the scenarios to run a large number of imaginary incidents through completion in order to capture statistical data reflecting the performance of the process under the given scenario. The BPM software does so by playing three different roles: - The role of the individuals or applications performing tasks at each step of the process. The scenario assumptions pertaining to each step provide information about the lag time and task time. The software uses this information to determine when and how fast each step is performed.
- The role of the engine or BPM server. It uses the process map to decide the sequence in which the steps are executed, and the conditional event probabilities in the step scenarios to determine those that are to be executed on a conditional basis.
- The role of time. It maintains an internal modeling clock in lieu of real time. It advances the internal modeling clock as soon as an activity is completed so that the model can be completed much faster than it would be in real life. Furthermore, it uses a random number generator to determine probabilities for various events and the time taken for each activity.
By playing these different roles, the BPMA software can run a specific number of incidents through the process and mimic how each incident would be processed in real life. During the course of modeling, it captures data about how long it takes to complete each step, the overall process and the bottlenecks encountered during execution. This data is then used to generate reports or the data is exported to third-party applications for statistical analysis. Implementing Statistical ModelingThere are two primary methods of implementing statistical modeling: time-driven and event-driven. In time-driven statistical modeling, the software maintains an internal modeling clock (IMC) and increments the IMC by a specified constant value. After each increment, the software evaluates the process map, the tasks for each worker and the task time and lag time for each activity. It then takes all the actions that need to be taken at that given time. The IMC is incremented, and decisions are made and actions taken for the new time. This cycle is repeated until the number of incidents specified by the "incident count" setting is completed. Figure 1 represents a flowchart for time-driven statistical modeling. | Figure 1: Flowchart for Time-Driven Modeling |
|  |
|
|
Time-driven modeling is easier to understand since most events in life are driven by time. However, it is inefficient because the IMC increments have nothing to do with how fast events are happening in the model. Time-driven modeling, therefore, results in a large number of redundant cycles where precious time is wasted because no events are occurring. Furthermore, it requires the analyst to select the time increment. If the increment is too small, the modeling will go through a large number of unnecessary cycles and simply waste time. If it is too large, it is possible that modeling may produce incorrect results because critical events that fall within the increments may not be accounted for in a timely manner. Event-driven modeling is more complex. However, it is very efficient since it only involves as many cycles as are absolutely necessary to produce accurate results. In this technique the software begins by determining all known events that have to take place next for every step in the model, and the time when each event will take place. The internal modeling clock is set to the time at which the next event will take place. All decisions and actions at that time are taken and any new resulting events are determined and included in the list of events. The IMC is set to the next earliest event time, and the cycle is repeated. Since the IMC is incremented to the time at which the next event will occur, it involves only as many cycles as there are events from the start to the end of modeling. Furthermore, the analyst does not have to judge the size of the increment. The software determines the increment itself and adjusts it dynamically based upon what is called for in the model and the scenario. | Figure 2: Flowchart for Event-Driven Modeling |
|  |
|
|
Results of ModelingModeling is capable of producing a variety of statistical results that enable business analysts to analyze and optimize the performance of a process. Some examples of relevant reports include: - Incident elapsed time: This report provides statistical information about the total time it takes to complete a business process. It enables business owners to set realistic customer expectations about how long it will take the organization to process a loan, a claim or some other request. Or it can be used to measure the overall performance or throughput of the process as compared to the expectations of customers. It provides a histogram of the number of incidents that were completed in various time durations. The mean value indicates the typical time it takes to complete a process incident. The standard deviation provides a measure of the consistency of performance. If the standard deviation is small, it implies that the process is controlled and can consistently complete incidents close to the mean time. On the other hand, a high standard deviation means that there are large fluctuations in performance. This report is most commonly used to determine whether the process is being completed in the time desired. If the rates are substantially higher or lower than desired, or the deviation is high, then additional resources or more automation may be required to achieve desired time results.
- Incident cost: This report provides statistical information about the cost of processing an incident. It allows business owners to assess the benefits of the process versus its overall cost. The cost can be either provided as a single number for the entire process, or can be broken down by each step in the process. This allows business managers to determine the task or activities that contribute most to the overall cost of the process. By analyzing these costs, business managers may be able to redesign or modify the process with the goal of reducing the overall cost. For example, if the incident cost report indicates that a significant percentage of cost is incurred by tasks that have to be performed by a senior executive, perhaps the process could be redesigned so that fewer tasks are assigned to senior executives.
- Step task time: This report provides statistical information about the time it takes to complete a particular step in a business process. Since the task time for each step is one of the assumptions in the scenario, the step task report will closely match the step task time specified in the scenario with variability introduced only by randomness.
- Step lag time: This report provides information about the lag or dead time for any step in the business process. The lag time is a combination of the lag time specified in the scenario plus the unproductive time a user spends waiting for new tasks. The latter becomes the major factor in the lag time if the business process is not balanced. To be not balanced means that the process is designed such that some steps have a high workload so that the participants cannot keep up, while others have too little work and they are waiting for tasks.
- Step elapsed time: This report provides information about the total time consumed by each step in the business process. It is a measure of how long on the average it takes a task to be completed from the moment it reaches a particular step in the business process. The elapsed time is a combination of the task time and the lag time of the step. It measures the throughput of the step.
- Step cost: This report calculates the cost of a step in the business process. It is calculated by multiplying the task time with the rate cost for each step. It can be used to determine how much each step contributes to the cost of the entire process. This enables the business analyst to assess the cost of each activity in a process and weigh it against the benefit of the activity to the success of the overall process.
- Step utilization: This report displays the distribution of the time for a step that was consumed in performing the task (task time), waiting for tasks (wait time), or spent in other activities not related to the task (lag time). It provides insight in to how time is being consumed. If the wait time is very high, it is an indication that there are too many resources being used at the step, and these resources are not being effectively utilized. On the other hand, if the task time is very high and the wait time is negligible, there is too much work for the amount of resources. To address this, the analyst has to either add more resources, or decrease the lag time so that more time is available for this particular step.
- Process utilization: This report is similar to the step capacity utilization, but shows how time is utilized across all steps in the process. It provides an overview of how time is being utilized by all the resources used at every step. Again, if the wait time is high and task time is low, resources are being under-utilized and are waiting for new tasks to be processed. On the other hand, if the task time is high and the wait time is negligible, resources are being effectively utilized. In this case there is the risk that if the rate of incoming incidents increase, bottlenecks may develop in the process.
- Under utilization report: This report displays a pie chart of the wait time for all the steps in a process. This allows the analyst to graphically determine which steps in the process have the most under-utilized resources. The analyst can then zero in on these steps in order to reduce the wait time.
- Balance report: This report simply plots the incident number versus the total elapsed time for the incident. This provides a graphical view of the change in the total elapsed time to complete each successive incident of the process. It provides a good mechanism for determining if the process is stable and its resources are balanced. If the graph is flat and each value varies about some mean value, it means that the resources are balanced and the elapsed time of all incidents is not systemically increasing. If, on the other hand, the curve continues to increase it means that the process is not balanced and the elapsed time will continue to increase because there are not enough resources to perform the tasks. Work is backing up. When optimizing a business process, the first step is to make sure that it is balanced. Once the process has been balanced, then the business analyst can try to optimize cost or reduce the elapsed time while ensuring that it does not become imbalanced.
If processes are automated using a BPM system, BPMA allow actual process metrics to be used for continuous improvement of business processes. Looking at a project in both time- and event-increments allows a business to more clearly define its objectives and achieve significant results. 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
Ultimus
http://www.ultimus.com  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.
Copyright © 2003-2008 – BPMEnterprise.com, CTQ Media LLC. 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.
|
|
|
