For some technical reasons I have moved my site to a different location. Please visit:
Please change all your links to this new blog site
.. and continue to send me your great feedback.
All the content from this side has also been moved there.
I have made a new post there by the title: “What BPM can Learn from Robotics”
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 )
After the global financial crisis started dominating the news in the Fall of 2008 I have read several press releases, blogs and statements from BPM vendors that the BPM industry is counter-cyclical. They claim that when times are tough and companies are forced to streamline or cutback their operations, the demand for BPM increases–or at least does not fall as dramatically as the rest of the market– because companies see BPM as a way to help reduce cost and become more efficient.
On the surface this optimistic argument appears to make sense. Tough economic times demand that companies cut cost while continuing to deliver adequate amounts of goods or services. BPM provide the means for companies to optimize their processes that can help achieve this goal. Beyond optimization, BPM also provides the means to automate processes that can greatly reduce cost while at the same time making the processes more efficient. It can enable companies to do more with less, which is exactly the medicine the companies need during tough economic times.
However nothing is ever as simple as it appears on the surface. The economic crisis that the world faces is going to impact the BPM industry negatively and the BPM vendors are not immune to the severe pain that the rest of the market is going through. There are several reasons for my pessimistic view that the BPM industry, especially in its current state of development, is not counter-cyclical.
First, BPM is not simply a technology that can be purchased and deployed, and suddenly companies can start reaping its benefits. Instead, BPM is a discipline – a way of conducting business and a cultural mindset. Technology is only a part of BPM, albeit an important part. Success with BPM is not the quick short-term fix that companies are seeking at times of economic crisis. BPM requires cultural change which takes time. Facing crisis, management generally does not have the luxury of time needed for BPM initiatives to bear fruit. Indeed, in a period of economic crisis, when employees are concerned about job security and their personal well-being, BPM is more likely to be perceived as a threat rather than an opportunity. This perception is not conducive to the kind of cultural change that BPM needs in order to thrive. Therefore, faced with the need for immediate action and reduced demand for goods and services, management is unlikely to invest in BPM which has a long term promise. BPM projects that are already well in progress are likely to be continued if their results are visible and significant. Mediocre projects are more likely to be canned, and new projects are less likely to be funded.
Second, BPM projects still rely heavily on professional services for the discovery, design, development, testing and deployment of processes. Because of this reliance on professional services, the deployment time for meaningful BPM projects ranges from two months to over a year depending on the complexity of processes and the amount of integration that is needed. This lag between making a decision to invest in a BPM project and when results can be ascertained, is another reason why management, facing the dire need to reduce cost today in the face of dramatically reduced demand, is less inclined to invest in new BPM projects whose payoff is months away.
Third, most organization have complex processes. They all look simple on the surface, but as one starts peeling the layers one finds the ever-present exceptions. The number of exceptions is generally proportional to the size of the organization. These exceptions are what make seemingly simple processes complex. And in many cases the processes are interlinked with each other. Simply automating one or two processes is unlikely to produce a major impact on the bottom line of a company. For tangible bottom line impact a company has to automate many processes which takes a lot of time. And management simply does not have the time or the patience when facing dire financial crises like the one we face today.
BPM cannot be rushed for the three reasons that I have listed. The financial crisis that the world is experiencing today will force management to make decisions that have a quick and short term impact. This does not bode well for increased investment in BPM and the prospects for the industry. Equally troublesome is the current state of the pure-play BPM vendors who are the driving force for innovation in the industry. Most of the pure-play BPM vendors are relatively small companies who do not have the deep pockets to survive a major downturn. In almost all cases, these companies have raised a substantial amount of venture capital investment with plans to either go public or be acquired by larger software companies seeking a slice of the BPM market. Prior to the current financial crisis Metastorm had already filed with the SEC, and Lombardi and Savvion have made noises in the past of going public. Most of these companies have already tried the M&A route and have been unable to find suitable acquirers willing to pay what they expect. Now with the state of the capital markets, the prospects of a public offering are nill. The pure-play BPM vendors will face tough times in 2009 with reduced demand for the reasons stated above, no prospects of going public and reduced prospects of acquisitions. Like many other companies, the BPM vendors will also have to take drastic actions to reduce cost and survive. Innovation will be impacted and there will be further pressure for consolidation on unfavorable terms. The larger software vendors eyeing the BPM space who have the financial wherewithal to ride the crisis will become even more dominant. While some may argue that consolidation is probably good for the industry, I have doubts about what it will do to innovation and agility for the industry.
Note: This blog is adapted from my recent column in BP Trends (www.bptrends.com )
About four years ago when the importance of BPM and process management spread to a wider group companies seeking process excellence, the role of the Chief Process Officer (CPO) emerged as an important senior position in organizations. I was among the many proponents of this new role. The rational was simple. Processes are key to the performance of organizations. BPM enables companies to capture the best practices for processes and use the power of software to execute them consistently while at the same time providing transparency, accountability and visibility. However BPM technology is still relatively complex, there are cultural changes that accompany its adoption which can have a major impact on its success or failure, and this change needs to be marshaled from a high level in the organization. The position of the CPO reporting to the CEO was designed to accomplish this.
At first blush the role of a CPO looks like a good idea. However some further thinking, evaluating my own experiences and recent discussions with BPM customers has made me rethink this approach. My thinking has evolved because of the following considerations:
i. If BPM is as important to an organization the top management of the company including the CEO and functional managers must take the lead and become champions and true believers in a process-focused organization. This important responsibility should be delegated to a new role of a CPO.
ii. Functional managers must become owners of processes in their departments. Their performance and the performance of their department must be measured by the effectiveness of their processes. Functional managers have the most domain expertise in their area and are in the best position to know the business process requirements that will lead to success.
iii. If a new role of a CPO is created it will add another department in the organization. This will not only add additional cost, but there is a strong probability that friction will develop between the office of the CPO and other departments in the organization. While the CPO owns processes, or facilitates the development of processes, the BPM system (BPMS) still relies on the IT infrastructure that is owned by IT, and much of the technical expertise to make the BPMS technically successful also most likely resides in IT. Likewise, functional managers have the responsibility for processes in their areas and also the domain expertise to make these processes effective. It does not make sense to make the office of the CPO responsible for processes in different functional areas, and yet have management of the functional areas be measured and rewarded by processes which they do not fully control.
For these reasons I believe that functional managers must own the processes in their departments and must be evaluated and rewarded based on the effectiveness of these processes as measured by KPIs that the organization agrees upon. However, while BPM systems are becoming more powerful, their underlying technology is also becoming more complex. Functional managers need help from IT to cope with the technical complexity. IT on the other hand does not have the business knowledge necessary to understand the complexities of business. So what the organization needs is a new breed of business analysts who also have sufficient process analysis skills. Let’s call them Business Process Analysts, or BPAs. The BPAs should have the following skills and attributes:
BPAs should belong to the IT organization and report to the CIO, but they should be assigned to work with specific functional managers for automating business processes that are vital to the latter’s department.
ii. BPAs must become the bridge between business (functional mangers) and IT. They should know enough about business that they can understand and empathize with the process requirements of the functional areas they are assigned to. They must also have strong knowledge of IT insofar as their ability to understand the benefits and drawbacks of various technological choices. Empowered with the knowledge of business as well as IT, the BPAs become facilitators of business processes owned by the functional managers. They should be rewarded for the success and effectiveness of the processes they facilitate
iii. The BPAs serve as the bridge between the functional process owners and IT. As the bridge, they must diplomatically play the role of champions of each side and the developers of compromise in case of conflict between the two.
iv. BPAs must be trained not only in the modeling of business processes, which is really the activity for documenting business requirements, but also working with the functional managers to optimize resource allocation and the more complex art of process optimization using modern BPM tools.
The Business Process Analyst will become a vital role in an organization and in the success of BPM. An educational background that combines business and IT skills will provide an excellent foundation for Business Process Analysts to be successful.
In this post I want to address some address the points raised by Mr. Ismael Ghalimi in his latest post “Developing a True BPM Ecosystem” in response to my post “Don’t Forget the BPM Ecosystem”. Mr. Ghalimi apparently has serious differences with me and I understand where he is coming from. However, I think it is important to address his misconceptions and apparent belief that standards must be applied universally for the success of the BPM industry.
Mr. Ghalimi major contention is that I was looking too macroscopically when I used the example of the transportation industry. He argues that a more sensible approach would be to look at sectors within the transportation, such as autos and airplanes. He claims that if we do that we will find much more standardization and similarities across the sector, and he gives several examples of that in his post.
While I do not agree with his argument, for the simple reason that the term BPM is very broadly used for everything that has the semblance of a process, let us say for the sake of the argument that he is right and look at individual sectors such as autos or airplanes. While Mr. Ghalimi sees similarities and standardization, I see great diversity and lack of standards in these sectors which are much more mature and larger than BPM. For example:
i. There is no “standard” that I know for the design of the cockpit of an airplane or the dashboard/controls of a car. The cockpit of a Boeing 777 is totally different than that of a Cessna. The pilot’s “user interfaces” are all are different!
ii. There is no standard that I know for the engine of an airplane or a car. Yes they sometimes look similar, but they are different from each other. You cannot take the engine of one car and drop it into another car. There is no “portability” of the engine. For airplanes of different sizes (a Cessna versus a Boeing 777) even the technologies used are radically different, even though they have many similarities (wings, rudder, landing gear, tail, etc.). The “engines” are all different!
iii. Mr. Ghalimi mentioned the FAA in his post. I am sure the FAA uses very different standards to determine the air worthiness of a Boeing 777 versus a Cessna. So the quality and inspection standards are also different!
iv. You cannot take a pilot of small plane and put him in the cockpit of a Boeing 777 without a lot of training. The training is different!
Surely Mr. Ghalimi is not arguing that the aerospace industry would be much better off if it had one set of standards across the industry for all types of airplanes! Doing so is not only unthinkable, but even if someone succeeded in imposing standards by diktat the industry would be stifled as compared to what it is today. The same is true for the BPM industry. One set of standards for cannot be applied across all types of BPM systems that are very different from each other in terms of their goals, transaction volume, criticality, cost and numerous other characteristics.
I do not want to leave the impression that I am opposed to standards. Far from that, I believe that standards are necessary for all industries to be successful. However, standards must be used judiciously where they make sense. Otherwise they lose their value and the market rejects them by never adopting them to begin with. The two guidelines that come to mind for the judicious use of standards in general, and BPM specifically, are:
1. Standards make sense when they apply to specific products that do very similar things. The more specific the product the higher the chances of adoption and success of standards. For example, in the airline industry one can have one set of standards for jetliners, and another set for commuter planes, and yet another set for small planes. Likewise, in BPM, one set of standards across the BPM industry will not suffice and will not be successful. However, one could have standards for different categories of BPM such as human-centric, system-centric, etc.
2. Standards make sense when they are applied to “components” and “user interfaces” but not “systems”. Batteries, screws, tires, parking space size, fuel, street signs are all components and user interfaces. The design of the car itself and the engine is a “system”. BPMN is a “user interface” and that is why it is more successful than any other standard in BPM.
I would like to note that the BPM industry does use a large number of standards for components and use interfaces. These include relational databases, Web Services, the Internet browser, e-mail, portals, AJAX/Web 2.0 and numerous others.
Finally I note that markets (consumers and vendors) adopt standards when their value becomes self-evident to a sizable segment of the market. This implies that the standards have to be relatively simple otherwise the value will not be self-evident. That is why it is more likely to have standards for simpler components rather than complex systems, and BPM falls into the category of complex systems. The BPM industry will be better off if it were to focus its energy on standards for “interfaces” and “components”, many of which can be adopted from standards widely used in the broader software industry.
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.
After reading numerous articles, blog posts and definitions of Web 2.0, and separate hype from reality, I have concluded that there are three essential ingredients of a Web 2.0 application:
i. A rich user experience in an Internet browser.
ii. “Mashups”, or the ability to pull together information from various sources that is relevant to collaboration.
iii. Strong emphasis on collaboration, or sharing information and ideas.
When I look at Web 2.0 and BPM, and the underlying objectives and challenges of each, I find a perfect match that can greatly boost the acceptance and usefulness of BPM.
First, let’s look at rich user experience for Internet applications, also called Rich Internet Applications (RIAs). RIAs are developed using new technologies such as Asynchronous Java Script (AJAX), Adobe Flex or Microsoft SilverLight. Every BPM product in the market today does not use these technologies. Only a few do. However, there is no doubt in my mind that BPM vendors, like other software vendors, will all rollout new versions of their products that use these technologies. I can safely predict that in the next 2 years or so, most vendors will have their user interfaces as RIAs, some moving faster than others. Indeed, the sheer benefits of an RIA from a usability and customer satisfaction perspective will make it a competitive advantage, compelling BPM vendors to accelerate their development efforts so as not to be left behind. As I pointed out in another blog “What it will take to deliver BPM SaaS?” (https://leadershipbpm.wordpress.com/2008/10/06/bpm_saas/), if BPM SaaS is to be widely adopted some key components of BPM have to be exposed in browsers so that users with rights can not only participate in processes but also configure and adapt them to their changing needs. Converting these components of BPM into an RIA will go a long way towards BPM SaaS.
Second, with respect to mashups, I would strongly argue that BPM is one of the first application categories to offer mashups even before Web 2.0 was popularized. Think of the modern BPM “client”, or the application that users use to participate in a business process and do their work. The BPM client is a classical example of a mashup. It pulls information from a number of sources such as databases, Web Services, EDMS (for document attachments), the BPM server (for status information), and often from other enterprise applications such as ERP and CRM. This information is collected in real-time and then presented to the user in a manner that is conducive to quick decision making and getting the job done. Of course, the ease and flexibility with which BPM applications allow these mashups to be created depends on the capabilities of the underlying BPM software that is used. However, the point is that the BPM client is a mashup used by all the participants in a process. Likewise, other BPM suite components such as BAM/reporting and administration have attributes of a mashup.
Finally, with respect to collaboration, I think it is clear to everyone that BPM for system-centric processes, also called straight-through processes, is optimized for speed and has little human involvement. By their very nature, these system-centric solutions are not collaborative and they do not need to be. They are automated production lines which are fully robotized. Then there is another class of BPM solutions, called “production workflow” in the 1990’s, that do involve humans but are for high volume, fairly rigid processes for claims processing and call centers, etc. Again there is not much need for collaboration in such applications, and the focus is on structure, compliance and speed. So neither of these two types of BPM solutions need Web 2.0 characteristics.
On the other hand, there are a large number of business processes that involve humans, and especially knowledge workers. In the early days of BPM/workflow, these processes were classified as “administrative/ad hoc”. The word “ad hoc” tried to capture the collaborative nature of these processes, even though technology at that time did not provide much opportunity for collaboration and ad hoc flow of processes. These human centric processes is where BPM truly has the potential for becoming a stellar Web 2.0 application for the simple reason that humans work in extremely complex ways, and the way they interact can often not be anticipated and programmed in advance. Here are some uniquely human things that people do when they work together:
i. Confer: Knowledge workers often want to discuss an issue with others before they make a decision
ii. Inform: Knowledge workers want to let others know why they made a specific decision.
iii. Assign: Knowledge worker often wants to assign tasks to others in the case of work overload or absence.
iv. Reject: Knowledge workers often reject a task they are assigned because it has incorrect of incomplete information.
v. Validate: Knowledge workers want to review other information in order to validate and support the decision they are making.
vi. Share and Assimilate: Knowledge workers want to share the decisions they are making or the information they have gathered, not only with the participants of the process but with a larger community or co-workers. This sharing and assimilation fosters organizational learning.
All these actions, and you can probably think of others, are ad hoc and collaborative in nature. Many BPM clients offer some of these capabilities. However if BPM is to truly address the needs of knowledge workers, the BPM client will have to offer all these capabilities in the future. The rapidly growing popularity of Web 2.0 applications such as blogs, wikis, instant messaging, forums, Internet document sharing etc., means that BPM solutions can leverage these technologies to provide similar capabilities to BPM users.
So my bottom line is that Web 2.0 is a perfect match for human-centric BPM. By the very nature of their core purpose of enabling people to work together, human-centric BPM solutions must become even better in collaboration, mashups and RIA technologies. Vendors who are nimble and deliver BPM as a Web 2.0 solution will have a significant competitive advantage, and will have the best opportunity for transforming their end customers and creating sustainable value.
NOTE: This post is an adaptation of my October 2008 column in BP Trends (www.bptrends.com )
The sub-prime driven economic meltdown has become a global crisis that is on the minds of everyone, including those of us in the business software community. Some of us, enamored by the potential and logic of software, strongly believe that the way to prevent such crisis in the future is through greater investment in software and automation that not only improves productivity but also provides a consistent application of rules. I recently heard the CEO of a major BPM vendor wishfully proclaim that if only the mortgage companies had more and better automated mortgagee processes, the world would have been saved from the sub-prime meltdown. On first blush this sounded reasonable and a good rationale for more investment in BPM. Mortgage applications are excellent candidates for automation as we all know.
Sit back and think about this, however. The sub-prime mortgage problem was created neither because the mortgage processes were inefficient nor because the rules were not consistently applied. The problem was that the rules were bad, and no BPM software that I know of has the capability to detect or correct bad rules. Bad rules, dictated by greed, produced a large number of bad mortgages. If there had been more automated and efficient mortgage processes, the result would have been even more bad mortgages and the problem would have been far worse! In fact in this case, less efficient processes would have been better in retrospect. If you automate something bad, you simply get more of it more effeciently!
This is not a slap on BPM. It is the classical problem of technology. Technology is a double-edged sword. It can do wonderful things if the rules that drive it are designed for a wonderful outcome. However, if the rules are screwed up or are trying to optimize the wrong thing, the consequence is wrong. In the case of the sub-prime mess the rules were relaxed to encourage more and riskier mortgages and that is what we ended up with. Some of you will argue that OK, but only if he processes were agile and the bad rules could have been changed early on we could have avoided the crisis. The problem is that the sub-prime crisis took years in the making, which is much longer than the lifecycle of a typical 3-4 week mortgage process. When the world woke up to the fact that the rules need to be changed the damage was done. The mortgage companies had sold millions of sub-prime mortgages to the banks, who had sold them to Wall Street, who in turn had sold them to the Chinese and Saudis!
My bottom line is that the world cannot depend solely on great technologies such as BPM and BI. Technology must be used wisely, with proper governance and good rules that optimize the outcome for all the stakeholders. The world we live in is very complex. Technologies such as BPM are relatively new. So let us use BPM and related technologies wisely on problems that we can grasp and comprehend before we use it to solve the more complex problems. And when we do solve the more complex problems, the world will have moved on to even more complex problems!
I have noticed three constants in my 14-years in the BPM/workflow industry. First, every BPM market forecast prepared by reputable firms has estimated a market size of anywhere from $1 to $3 billion, and a growth rate ranging from 10% to 20% per annum. Even if I take a conservative forecast and assume that the market was $1 billion in 1998 and growing at 15% per annum, it should be at least $4 billion today. But the most recent forecast continue to put it in the $2 billion range. So where does all the growth fizzle away? Second, every BPM vendor and analyst can provide a number of actual case studies of BPM deployments that demonstrate remarkable ROI and productivity benefits. And it is relatively easy for senior management to understand why BPM can deliver such results. Yet the penetration of BPM in organizations is still small and I would venture to say that less than 10% of processes are automated despite all the ROI and productivity proof points. Third, every year BPM vendors claim impressive growth and publish a roster of new customers. Yet most pure-play BPM vendors are relatively small companies and none have been able to go public despite the claims of growth and the fact that many of them have raised tens of millions of dollars in venture capital.
It seems to me that the BPM industry is stuck in a no-man’s land. The pure play vendors neither have the flexibility of really small companies, nor the resources or clout of large companies. While BPM has tremendous potential, the challenges which these vendors face are very significant which makes growth akin to progress in trench warfare. First, BPM sounds glamorous, but it is not easy. This is because human beings work in extremely complex ways. Developing software that caters to all these ways is not easy. The “human interface” of BPM is complex and challenging. Second, the IT environments in which BPM has to thrive are very complex, varied and in constant flux. BPM cannot be successful without seamless integration with the rest of the IT infrastructure. The “application interface” of BPM is complex and challenging. Third, as the size and impact of BPM projects becomes larger, buying decisions gets escalated to executive leaders. Executive leaders prefer to deal with large platform vendors such as IBM, SAP, Microsoft and Oracle, and this preference limits the opportunities of pure play vendors. The “market interface” of BPM is also complex and challenging.
I believe that pure play BPM vendors are stuck in the no-man’s land because of the challenges of the “human interface”, the “application interface and the “market interface”. However, I am still optimistic about the market and its opportunities. I am optimistic because extreme focus and technology changes generally benefit the smaller and more agile companies. We are again going through a period of technological change that can be leveraged by the pure play vendors. Web 2.0 provides an excellent opportunity for pure play vendors to attack the “human interface” challenge. The increasing maturity of SOA provides an excellent opportunity to address the “application interface” challenge. And finally, time, relentless focus and persistence provide the means to address the “market challenge”.
What do you think?
An increasing number of BPM vendors are starting to talk about offering BPM software-as-a-service (BPM SaaS). These include Appian, Lombardi, Savvion and Ultimus. Given the buzz around SaaS, this is understandable as these vendors are trying to position themselves for a growing opportunity despite the fact that the SaaS model has serious challenges from a business perspective. So the question for users of BPM is what does it really means to have BPM SaaS?
Let us first make clear what BPM SaaS is not. First, the ability to run a hosted version of one aspect of BPM is not BPM SaaS. BPM is a combination of applications used by different stakeholders. Offering only one of these in a hosted, subscription-based model is not SaaS. For example, offering process modeling tools in a subscription-based hosted model is “process modeling software-as-a-service”; it is not “BPM software-as-a-service.” However this would be a very good first step towards BPM SaaS which can offer customers as well as vendors not only the benefits of SaaS but also the experience necessary to move towards full-fledged BPM SaaS. Second, creating customer-specific automated processes and then enabling the end-users of the customer to participate in the process using a browser/Internet is also not BPM SaaS. There is nothing new about this and customers and vendors have been doing this ever since the early days of the Internet.
In my judgment BPM SaaS has to have the following characteristics as a minimum. First, it must have the ability to model and modify executable processes in a hosted application. The ability to design executable processes, in contrast to simple flow diagram, is pretty challenging. Many vendors will start by offering pre-designed process templates and then allowing users to modify them in a hosted model. This is a good way to start and over time an increasing number of parameters (rules, flows, user interfaces and integrations) can be exposed to modification by users. Second, BPM SaaS must have the ability to allow customers to integrate with their inside-the-firewall data and other applications. This is crucial because BPM deals with company’s data and interacts with other applications. Without effective integration only the very simplistic BPM processes are candidates for SaaS, and CxOs are reluctant to invest money or mindshare on simplistic processes. Integration is the Achille’s heel of BPM SaaS and solutions for this will evolve only gradually. Perhaps the best approach for BPM vendors is the emerging class of “application appliances” that leverage virtualization technology to deliver inside-the-firewall solutions on a SaaS basis. This has the potential of solving the integration problem. I will discuss it in another blog as this is a topic on its own. Third, and easiest, is the ability for end-users to participate in business processes using a browser. This is easily accomplished by most vendors and the growing using of AJAX and Rich Internet Application (RIA) technologies will make it even easier and richer for end-users. Fourth, BPM SaaS must provide a means for customers to monitor and administer their processes over the Internet. Again, with the emergence of AJAX and RIAs, this is not a challenging obstacle. And fifth, BPM SaaS must provide some web-based reporting, BI and BAM capabilities.
With these five capabilities, BPM SaaS can empower customers to design, integrate, deploy, use, administer, monitor and measure their business processes. It provides the full value-proposition of BPM in a SaaS model. Vendors will move towards this in small steps and the more agile ones, who adopt SaaS and new technologies such as RIAs and application appliances, will have the competitive and time-to-market advantage. The key challenges are modeling/design of executable processes and integration. I will use other blog posts to elaborate on likely approaches to tackle these challenges.