The BPM Industry is not Counter-Cyclical!

 

 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 )

Don’t Forget the BPM Ecosystem- Part II

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.

 

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.

 

 

 

Human-centric Business Process Management (BPM) and Web 2.0: A Perfect Match

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 )

Is the BPM Industry stuck in no-man’s land?

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?