Social Networking and BPM of the Future

A couple of months ago, I saw an online video by Google about their upcoming Google Wave platform for social networking. As I watched it, my mind raced back to the early 1990s when Lotus was the rising star and was introducing Lotus Notes as a revolutionary new groupware platform. Lotus was a pioneer and coined the term “groupware” to define Lotus Notes as it was a new paradigm in those days and could not be defined using the IT lingo of the day. Lotus defined “groupware” as a solution that empowers teams of people to work together by giving them three capabilities in a unified package, namely communications, collaboration, and coordination. Lotus called these “the 3 Cs of groupware.”  In those days, the hot technologies were primarily email for communication, document management for collaboration, and workflow for coordination. Notes provided a single platform for all three of these capabilities, which was its key strategic differentiator.

 As I watched the Google Wave introduction, I was intrigued by Google’s definition of Google Wave as a platform for real-time communication and collaboration. The fact that Google Wave offers very impressive communication and collaboration capabilities in real-time over the Internet was impressive enough. However, what was even more impressive and intriguing to me was the fact that Google Wave is offering two of the “3 Cs of groupware.”  What is missing from Google Wave is “coordination,” or workflow. If one could add coordination, it could become a true and rich groupware platform. Indeed the vision of the early pioneers of workflow/BPM, such as Ultimus, which I was starting at that time, was to provide this third capability for coordination, and complete the groupware offering. Digging deeper into the technical details of Google Wave, I found that it has an interesting feature called “Robots,” which are essentially “automation agents” that participate like individuals in Google Wave. Again, I was intrigued by the similarity in name and functionality to the Ultimus feature called “Flobots,” or workflow robots, which we developed in the early 90s and introduced with the Ultimus version 1 in 1995. Google Robots, like Ultimus Flobots, can do many automated things without human involvement. Certainly one of the things a Robot could be developed to provide would be “coordination,” or workflow capabilities. Google is not doing this, but there is nothing stopping someone else from doing it by using the capabilities provided by Google Wave.  This will result in a workflow/BPM solution built on Google Wave that leverages the full power of Google Wave.

 Social networking has become one of the most dynamic phenomena and technology in recent years, and the Internet provides a cost-effective and far-reaching network to facilitate it. While it started as a consumer phenomenon, social networking is now making inroads into the business world as corporations recognize its power for sharing information and enabling people to work together. Working in a modern organization is also “social” in nature, especially for knowledge workers who have to share information and ideas, and build value in a collaborative and iterative way. The increasing sophistication of social networking tools, as exemplified by applications such as Google Wave, certainly makes this even more attractive as a business solution.

 Participation in a business process, too, is “social” in nature. The participants of the process are members of a team who often want to discuss and collaborate with each other and want to know what other participants are thinking. In many case they want the ability to use the thoughts and feedback of others to change and improve their own actions in a process. Today, most BPM solutions provide a structured way of doing work, using a factory automation metaphor. But knowledge workers who participate in processes are not automatons working on a factory floor. Instead they are humans with the need to learn and to satisfy emotional needs.  They find too much structure imposed by rigid BPM solutions to be an impediment rather than a facilitator. When the process becomes an impediment, these knowledge workers will find ways to bypass the rigidity of structured BPM and work around it. This defeats the whole purpose of BPM.

 It is for this reason that we find more and more social networking type capabilities creeping into BPM offerings of different vendors. This includes the integration of instant messaging, Wikis, discussion forums, and collaboration. However, these are all patchwork; at their core most BPM offerings are highly structured in nature. These ad hoc collaborative capabilities are added on top of a structured solution to leverage some of the benefits. At the core, they remain rigid solutions that are difficult to change.

 I believe that in the near future we will see a new generation of BPM solutions that are built on top of social networking platforms such as Google Wave. These solutions will have some unique characteristics:

•  Rich, real-time communication and collaboration among participants will be a given, instead of something that is added on as an afterthought. 
• The solutions will be dynamic in nature in the sense that the process will define itself as it is being used. It will adjust and adapt to changing needs. Since the process will define itself, it will be continuously tested in real-life situations. 
• The solutions will use integrated BI capabilities to express the flow or map of the process and extract key performance indicators. The structure and the key performance indicators can be used to model and optimize the process, thus providing the ingredients necessary for BPM. 
• Since Google Wave and other similar products are cloud-based, these BPM solutions will be cloud-based. 

I am convinced that such solutions will be the predominant paradigm for BPM of the future.

 Note: This post is adapted from my columns in VP Trends (www.bptrends.com ) of the same name.

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.

 

 

 

Could BPM have saved the World from the Sub-Prime Debacle?

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!

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?