Archive for the ‘BPM Technology’ Tag

The Hype about Simulation and Optimization

Simulation and optimization are often touted as major benefits of BPM by vendors as well as industry analysts. The idea is that BPM systems (BPMS) with these capabilities enable business analysts to simulate the performance of the process through the computing power of software, identify bottlenecks, and optimize the process to best achieve the goals of the company. Even more appealing is a feature called “round-trip optimization”, which simply means that a BPMS can capture operational metrics from actual process incidents that have been completed, and then allow business analysts to use these real metrics, instead of merely good assumptions, for the simulation and optimization of the process. It is common for industrial engineers to do time-motion studies on the factory production line to improve the efficiency of work. Round-trip optimization, often simply called “round-tripping”, is the equivalent of BPMS doing time-motion studies automatically and making the metrics available for use in simulations. And then the simulation capability enables the analysts to optimize the process.

 

It is not surprising that analysts and some prospects are so hot on simulation, optimization and round-tripping. These are huge benefits that appear to be waiting at the finger-tips of the BPMS users.  For example, in a recent blog, Jim Sinur, the leading BPM analyst at Gartner, writes as follows:

 

“Most people think that simulation is hard and is for those gifted with deep math skills. Today nothing could be farther from the truth. Simulation is nicely embedded in process modeling and BPM engines and pretty easy to use even for business folks. Another big fallacy is that you have to set up lots of test data to make simulation work. Most of the simulators, today, will generate appropriate instances of process based on arrival rates.”

 

In my humble opinion and with due respect to Jim Sinur and Gartner, this is a big overstatement.  Yes, BPMS can do simulation. However the results of simulation will depend entirely on the assumptions the business analyst makes about a large number of parameters. For example the business analyst has to make assumptions about the following for each step in the process:

 

  • The Task Time, which is the time to actually do the task at the step
  • Number of resources: How many people are available to do the task, and are they dedicated or shared with other tasks
  • The cost of each resource
  • The probability that the step will be activated, in case it is conditional
  • The probability that the user will send the case backwards, because in real life things often go backwards instead of always going forward as planned.

 

These assumptions have to be made for all the steps in the process. So if there are 30 steps, there are at least 150 assumptions! That is no small task that “business folks” will engage in lightly.

 

If that is not enough, the business analyst has to make some assumptions about the overall process. For example:

 

  • What is the rate at which new cases or incidents are being started? It is unlikely to be a constant rate. What is the distribution of the incoming rate? And what is the best way to statistically describe this distribution?

 

  • What state of the process do we want to optimize? Most real-world processes have working gaps. People typically work during certain time periods, such as 9 to 5. When they start working, there is likely to be a backlog from cases coming in overnight. This is the “ramp-up” phase which occurs every day for most processes. Then there is the time in the middle of the day when workers have caught up and, hopefully, things are in a steady state. Optimization is totally different at the ramp-up phase as opposed to the steady state. Which state do you want to optimize?

 

  • What is the goal of the optimization? To reduce cost? To increase throughput? To meet some service level within specific cost constraints?

 

The results of the simulation will depend entirely on the quality of these assumptions. As the saying goes, “Garbage in, garbage out”. If the assumptions are erroneous, then, while one might feel good that one has optimized the process, in reality the process is sub-optimal. Making all these assumptions with reasonable accuracy is not easy, and not something that ordinary “business folks” do. It is a lot of work and requires a deep understanding of the process. And yes, some expertise in math and statistics is required.

 

There is another important reason why simulation and optimization is not easy and cannot be done easily by “business folks.” We know that many business processes cut across departments and each department has its own goals, requirements and cost structure. In fact the cross-departmental nature of BPM is one of its major benefits. So if you have a process that runs across departments, then it cannot be simulated and optimized by the business manager of just one department. The manager will have to collaborate with other departments, and his or her vision of the optimized process may be very different from that of the heads of the other departments. Alternatively, the manager of all the departments may engage in the simulation and optimization, but he or she will need a lot of complex input from all the departments. In all the companies that I know, this simply does not happen. Business folks delegate simulation and optimization to business analysts.

 

Finally, optimizing a process from a true business perspective is not simply about a lot of number crunching and discovering the optimal deployment of resources. This is a small but important part. The real requirement of optimization is sound business judgment and making choices based on what is important for the success of the business. In many cases, this requires value judgments, and software is blind to value judgments. For example, if the conclusion of the optimization exercise is that resources should be removed from particular tasks in order to reduce cost, someone has to make a value judgment about what to do with the redundant resources. Or if the response time to customers is decreased because of optimization of cost, what is the impact of that outcome on customer satisfaction and sales? Maybe it is significant and maybe it is not. The BPMS will not tell you that! Therefore, simply by doing a simulation and optimization exercise using BPMS will not produce the best outcome for companies. Simulation and optimization is at best one input to the business optimization effort.

 

Now let’s talk about round-trip optimization. Some will claim that I am wrong about the number of assumptions that have to be made in order to run a proper simulation. They will argue that modern day BPM systems are equipped with the capability to automatically measure these metrics from actual process data and quickly make them available for the simulation/optimization exercise. Not only that, these metrics are not assumptions; they are actual, measured results, which is even better.

 

I have a very simple answer as to why this is wishful thinking but devoid of reality. The most important parameter for simulation and optimization is Task Time, which is the actual time required to perform a task. One has to know the actual Task Time in order to run any kind of simulation.  However, there is no BPM software that I know of that measures Task Time, because it is simply not possible to do it. Consider the challenge. Most user steps in a process use some type of electronic form. If the software has to measure how much time the user took to complete the task, what does it measure? It cannot simply measure the time the form was open, because the user could have the form open and be having a conversation with her colleague. Or the user could open the form, understand the task, close the form and be thinking or researching the task with the form closed. There is no accurate way to measure Task Time. Therefore BPM systems simply do not measure Task Time because they cannot!

 

Most BPM systems that tout round-tripping capabilities measure one or two parameters and feed them back in to the simulation. They have accomplished “round-tripping”, but it is far from complete. And they have not measured Task Time.

 

My bottom line on all of this is as follows:

  • Simulation and optimization can be very useful if done properly
  • It is not easy, especially if your processes are complex which they generally tend to be
  • You need an experienced business analyst to do it. It cannot be done by ordinary “business folks”
  • The business analyst will have to closely coordinate with business folks for their judgment and priorities
  • Buyers beware of the hype about round-trip optimization.

 

In the comments of a subsequent blog Jim Sinur claims that 25% of clients are using simulation and optimization, up from 5% a few years ago. I think that number is way too high. The true number is probably still less than 5%. I dare to say that the true number of customers using round-tripping is closer to zero.  I have not come across any in my many years in the industry. However, if any of you knows of such customer, I would like to hear about them and be proven wrong.

 

To illustrate how overly enthusiastic some analysts are about simulation, I quote again from Jim Sinur’ subsequent blog where he extols the benefits of simulation and writes:

 

For instance, Arizona was forced to cut 1.2 billion dollars out of its state budget. These kinds of cuts are also mandated in the private sector, but are hidden from public view. Quite often the cuts are made arbitrarily based on large numbers and what seem to be discretionary spends. Some of these cuts have downstream effects that are never considered or underestimated. Simulation can be used to try different options of cost cutting and resource deployment to minimize long term damage thus encouraging intelligent cuts without randomness.

 

This is indeed a noble thought. But I have to ask Jim, how does one go about making a socio-economic-political model of the State of Arizona and its budgets, priorities, goals and commitments to the citizens? Surely, without such a model, one cannot do simulations. What will be the cost of making such a model, and how long will it take to develop and make sure it is accurate? And which software in the world makes such models of complex entities like an entire state with millions of people? I do not know, but I can tell you that even making a model of a small company is no simple task.

 

 

Note: This blog is adapted from my recent column in BP Trends (www.bptrends.com )

 

 

 

 

 

 
 
 
 

 

 

Advertisements

Don’t Forget the Business Process Ecosystem!

There is lot of angst about Business Process Management (BPM). Reading the blogs, press articles and analyst reports one hears the frequent complaint that different people and organizations have different understanding of BPM, BPM standards are lagging, the technology and the terminology is confusing, and that there are too many vendors of all different types who are vying for the market. The market seems to want uniformity and clarity. The lack of clarity and uniformity undoubtedly causes potential customers of BPM to be wary of making investments that could greatly help their organizations. No good business person will invest in any major new initiative if there is a cloud of confusion surrounding it.

This angst is based on looking at the BPM industry in the wrong way. There should be no expectation of uniformity across the BPM industry for the simple reason that business processes come in many different shapes and forms that cover a very wide spectrum of needs. A couple of years ago I wrote a column on  BPM Outside SAP. In it I argued that like any other man-made system, business processes of different types must coexist in an ecosystem to complement each other.  I used the example of a transportation ecosystem. There are many different systems that must work together in a complimentary manner in order to satisfy the need for transportation. For examples, if an employee has a business meeting in a different city the transportation systems he will use  are (a) an elevator to go to the ground floor (b) a taxi to go to the airport (c) an airplane to fly to another city, etc. These systems are all very different from each other. They use different terminologies and technologies. No one vendor offers all of them. It would be foolhardy to apply one set of standards to all of them. However these systems make up the transportation ecosystem and work together synergistically in order to accomplish the business mission.  No one expects the transportation ecosystem to be uniform and have the same terminology, technology and standards.

Business processes are also a part of a “process ecosystem”. There are many different types of processes in an organization that must work together in a complementary fashion. Each type has different requirements and terminologies.  The optimal automation of these processes will require different technologies, and it does not make any sense to apply the same standards to all of them. The mistake many observers of BPM make is that they assume that since BPM is dealing with processes, and that BPM systems (BPMS) are based on software, one should expect consistency and uniformity. The correct way of looking at it is that BPM is dealing with a process ecosystem characterized by great diversity. The BPMS that are best capable of managing and automating the different types of processes in the ecosystem will naturally be very different from each other, just as an airplane is very different from a car.

 

If we grasp the notion of a business process ecosystem and understand the diversity of processes in the ecosystem, we can readily understand the following:

         i.      One BPMS will not satisfy all the process needs of an organization

         ii.    One BPMS vendor is unlikely to meet all the process needs of an organization

         iii.   One standard will not be suitable for all types of BPMS

         iv.   A BPM competency center must have skills in the different types of processes in the process ecosystem, and the BPMS that are optimal for each type.

         v.   The different types of processes must be able to gracefully interact and co-exist with each other.

The BPM industry will have a cloud of confusion hanging over it till it comes to terms with the diversity of the processes in the ecosystem. Indeed, the best way of looking at the industry is to break it down into sub-industries around each type of process. So the overarching industry is the “BPM ecosystem” and under this are various sub-industries with their own vendors, standards, best practices and terminologies. Looking at it with this way will reduce confusion and accelerate the growth of the component sub-industries.