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.