The right process will get you off to the right start
When adopting business process management (BPM) into your organization the first challenge you are faced with is where to begin. Even after you’ve selected your tools, and assembled and trained a team, you still have to decide which business process you are going to use for your first BPM project. Selecting the right process for your initial project is critical in enabling you to not only demonstrate the benefits of BPM, but to also show your organization the value in its investment.
One option would be to select a small, simple process so you can test the waters -- and also so you can be confident that the project will be a success. The downside to this option is that a small, simple process will probably have an equally small business impact. Besides, you might be hard-pressed to justify the business case for applying BPM to such a small standalone process. Beginning with too simple of a process, then, doesn’t usually make much business sense.
So, how about a large, complex process for your first BPM project? That would almost certainly provide sufficient payback to make a compelling business case for BPM. But with size and complexity comes an inherent drawback: a larger process will take longer to create, test, and deploy. With more steps and more services to invoke, more time will be required. Most businesses – especially today -- want to see an immediate benefit for their investments. If your complex process requires a nine month project, the business might grow impatient.
What type of process is a good candidate for getting started with BPM? Experience has shown that a good rule of thumb is: 90 days. If a process can be automated in 90 days, it is likely large enough to have a business payback, but small enough to be a practical first project. After this first project is a success and has shown the value of BPM to the business, you will then be in a position to tackle bigger issues and begin working on larger scope BPM projects.
When considering how you will apply BPM in your organization, it is important to remember that a BPM approach is incremental. The lifecycle of Model, Assemble, Deploy, and Manage is iterative. The first iteration of the process does not have to be the ideal process; you can begin with the easier parts, and expand with each iteration over time to improve the process.
Figure 1. BPM lifecycle
After you have initial success with the process, you can add more to it to improve it further. The insight you gain from business monitoring, along with areas you identify for potential process improvement, can be used to drive the next version of the process.
For example, you don’t need to start with a full end-to-end process. Instead, you can begin the initial iteration with just a subprocess within the larger scope. The steps in the process do not all have to be fully automated either; you can start with a simple workflow, then add in services later to automate manual tasks and add other improvements as well.
Allow me to illustrate how to apply BPM to a process in an incremental fashion using a straightforward business process as an example. This process obtains approval for a purchasing request. This is how the process (Figure 2) occurred before BPM:
- A purchasing agent validates the line items on a paper request form, verifying that the part number and price matches the internal catalog. The paper form is then delivered to the inbox of the accounting team.
- Accounting calculates total purchase price, based on the costs, discount level, tax rate, and shipping. The paper form is then delivered to the inbox of the purchasing admin team.
- A purchasing administrator decides which type of approval is required for the request, based on the total price and the current corporate policy. They mark the form depending on the outcome, and send it on to the inbox of the appropriate group.
- The request is approved or rejected by a vice president (for large request), a manager (for medium sized request), or by purchasing (for small requests). The paper form is then delivered to the inbox of the quality assurance group.
- The quality assurance group verifies that everything on the form is in order, and that all of the appropriate sign-offs have occurred. If something is not right, the form is sent back to the second step for rework. If everything is in order, the paper form is delivered to the inbox for the purchasing group.
- The purchasing group notifies the requestor of the status, then sends the order out for processing.
Figure 2. Example process
The process has been in place for many years, but the business has identified several areas where the process needs to be improved:
- Tracking the status of a request is difficult. Nobody knows for sure where the paper form is at any given time, and who last worked on it.
- A small percentage of forms get lost. Sometimes duplicate requests are filed, occasionally resulting in both orders going through.
- Due to reasons that include handwritten data on each form, the number of errors is higher than the business would like. Other errors occur when expired policy information is used, or when someone writes down the wrong number when looking up information. Currently, 12% of all orders have some kind of quality problem.
- The amount of time between order placement and delivery is too long.
- The business wants to reduce the cost of the process, but does not know for sure how much it costs per order.
- The business expects to grow, but cannot afford to hire more personnel. There needs to be a way for the current staff to handle a higher volume of requests.
These are typical challenges where BPM can be applied to improve a business process.
To begin, a model of the current manual "as-is" process was created in IBM® WebSphere(reg/> Business Modeler. To take into account the time for the paper to be physically moved, the task durations were set to be longer than the resource durations. For example, if a task took 10 minutes to complete, the resource duration was set to 10 minutes, but the task duration was set to 40 minutes. This prevents the next task from starting until the time for the resource and the time allotted for moving the paper has elapsed.
A simulation was run for a typical one-day volume: 1000 requests, with one request arriving every 2.5 minutes. The resource pool was sized with 10 accounting resources, 2 managers, 4 purchasing administrators, 15 purchasing agents, 4 quality assurance resources, and 1 vice president. The average duration was 10 hours and 40 minutes, with an average cost of $27.95 per request. The simulation results are shown in Figure 3.
Figure 3. Manual process simulation results
Some of the tasks ran more than 1000 times because some process instances failed the quality assurance step, and had to be sent back for rework.
A "to-be" model was created, based off the as-is model. This new model assumes that IBM WebSphere Process Server will be used to provide workflow, along with IBM WebSphere Business Monitor to address the business issue of tracking to avoid losing forms. IBM Lotus® Forms is included with WebSphere Business Modeler, which will be used to create an electronic version of the form. This will improve quality at the very least by eliminating hand-written data.
Tasks from the as-is process were converted to human tasks. Since there is no longer a need to add time for the physical paper to move between tasks, the resource time can be used as the task time.
The improvements from applying BPM solve many of the business challenges, while providing a positive impact to others. By applying these changes, the quality is improved, with an error rate going down to 6%. A simulation was run with 1000 requests, using the same resource pool size. The results show an average duration of 6 hours and 49 minutes, almost 4 hours less than the as-is process. As Figure 4 shows, the costs were also slightly reduced. You could also have assumed that tasks in the to-be process would take less time, which would have shown additional savings. However, the original times were kept, to keep the numbers conservative.
Figure 4. Process comparison analysis
The first iteration is not yet the ideal version of the process, but many of the business goals have already been met, including a reduction in time, an improvement in quality, and some cost savings.
In the second iteration, the business decided that the choice being made by the purchasing administrator could be replaced with a business rule. An automated decision will be much faster and will also have a higher accuracy rate. In addition, the IT department has created a new service to automatically validate line items in a request. The new service will be used instead of the human task for the first step.
By applying these changes, the quality is also improved, with the error rate going down to 3%. A simulation was run with 1000 requests. The simulation shows an average time of 5 hours and 35 minutes, with an average cost of $20.47. A comparison to the process from first iteration is shown in Figure 5. Even compared to the first iteration, the costs have been reduced by almost 30%.
Figure 5. Comparison of first and second iteration
In the third iteration, the human task to calculate the purchase total has been replaced with an automated service. This will further improve quality by eliminating the manual calculation. The error rate now goes down to 1%.
With so few possible errors remaining in the process, the human task to perform quality assurance on the request can be replaced with a business rule. Only in the case of a problem does the request go to a person for further quality assurance analysis. This further reduces the cost, and improves performance.
A simulation was run with 1000 requests. The average duration was down to 44 minutes and 3 seconds, with an average cost of $12.06 per request. Now the application of BPM is really paying off, with large cost reductions, time savings, and quality improvements. Figure 6 shows a comparison to the process from the second iteration to the third.
Figure 6. Comparison of iterations 2 and 3
The cost of the third iteration process is far lower than that of the original process, as shown in Figure 7. With 1000 processes a day, the savings of $15.88 per process instance provides more than enough business justification for the BPM project, not to mention the savings in time and the improvements in quality.
Figure 7. Cost comparison of as-is and third iteration
In the as-is process, the staffing levels showed that some roles were over-utilized, resulting in process bottlenecks, as shown in Figure 8. Only the purchasing agents were overstaffed.
Figure 8. As-is process resource utilization
In the fourth iteration process, the shortages were alleviated or eliminated, as shown in Figure 9. With the automated services, the resources from accounting were freed up to work on something else. Since most of the roles are now underutilized, more work could be processed by the same number of resources, enabling the business goal of growing the size of the enterprise, without having to add additional resources to support the business process.
Figure 9. Third iteration process resource utilization
Rather than trying to go from a manual process right to a fully automated process, BPM can be applied successfully in an iterative manner, as shown by the example process in this article. With each iteration, the process was improved to a greater degree, providing more business justification with each improvement.
The goal for a successful business process is to make sure that people are used in a process only where they add value. The "busy work" can be better done by a service, which will be faster and produce far fewer errors. When a person is needed, BPM should deliver the right information to the right person at the right time. It is not unrealistic to think of improving the time for a process from weeks down to days, and bringing a significant cost savings that is a direct benefit to the business.