International Process and Performance Institute

Here is my brief (though long for a blog) history of BPM...

Business Process Management (BPM) started as a management practice, coming from some of the more experienced practitioners of Business Process Reengineering in the late 80’s and early 90’s. From these people, Business Process Management was originally conceived of as a way to better manage the business operations of large commercial entities. BPM was seen at the time as a way to create both incremental and step-by-step process improvement as compared to BPR that was focused on radical improvement. Further, BPM took into account the perspective of people, a perspective that was lacking in a majority of some practicing BPR (even though this was not the intent of BPR thought leaders such as Hammer and Champy).
 
Since then BPM has been furthered defined by software products that support process operation and orchestration including the orchestrating of workflow. Workflow in software was in use by at least the early 1980’s and most certainly part of software development even before then.

The essential difference between workflow and BPM is that work orchestration in BPM is characterized by intelligent work routing such that work can be directed through a more complex and versatile process model based on business rules and real-time events; thereby orchestrating the flow of each work item through the process model. In this way, work items can be routed to specific people or specific activities based on the intelligence that is built into the process model itself. BPM software now offers many other features and functions beyond work flow orchestration such as multiple perspectives on process modeling, case handling, exception routing, complex business rule-set management, work analysis, document management, integration capabilities and many more. BPM products that include workflow orchestration are commonly referred to as being executable BPM software are fall under the acronym of BPMS, which stands for Business Process Management Suites. There are also BPM products that focus solely on modeling and simulation, often used by analysts and enterprise architects. Over time the BPMS software market has become by far the largest segment of the market supporting BPM.

Early entrants into the BPMS software market created new workflow tools that often required little code development to express business processes heavy with human interaction. The belief within the early BPMS software community was that by providing business users with a simple set of tools with which they could model these human-centric processes, the processes could then be orchestrated, dramatically improving the efficiency and quality of business operations.

The early adopters of BPMS products often applied their products to a unique subset of business processes indeed heavy with human interaction, often where little technology was in place, and where consistency in the process was poor at best. The case studies that arose from using BPMS software on these processes were offered compelling examples of what might be gained by employing this kind of software. However, BPMS products failed to achieve significant benefit or return on a predictable basis and overall business users did not pick-up on the opportunity of being directly involved in the modeling of processes that would become executable processes used by the people doing the work. Market growth was strong, though not as strong as many had predicted, yet it was strong enough to gain the attention of larger software vendors resulting in numerous acquisitions in the early to mid 90’s. Larger software companies including Tibco, Adobe, BEA (now consumed by Oracle), and IBM all acquired smaller BPMS software companies during this time.

Between acquisitions, product development and repositioning of existing products a fundamental shift started to take place in the mid 1990’s. This shift was to use the BPMS concept to solve a different problem, the development of automated business processes; work that occurs behind the scenes in our organizations generally referred to as the backoffice. However, this also created a significant split in the marketplace and in the Business Process Management community at large as the genesis of BPM was focused on human-centric processes while this new emphasis was focused primarily on IT automation and behind the scenes handling of processes with little, if any, human interaction. The split soon became reflected in the language of the market, with integration-centric BPM and human-centric BPM identified as separate classes of BPMS product.

This shift occurred for a number of reasons. The most important reason is that human-centric processes involve multiple stakeholders and require changing the behaviors of people in the organization; a task that can be quite difficult to achieve. Conversely, integration-centric processes are specifically an IT function, and as such are contained to those of technical mindset who already have significant domain knowledge regarding the problems to be solved. In fact, integration-centric BPM is often considered to be the next iteration of application integration along with SOA (Service Oriented Architecture).

Cost reduction is perhaps the most targeted benefit of BPM with case studies validating 20%, 30% and even 50+% reductions in the operating cost of a given process. Cost reduction with BPM is achieved through a mixture of automation, process streamlining, error reduction, elimination of duplicity, and better control over processes at both the work level (people doing work in the process) and management level (those overseeing and balancing demands against resources). However, cost reduction remains highly unpredictable in actual practice, with many organizations struggling to achieve demonstrable gains.

When the focus moves to changing how work gets done in the organization, the market immediately moves away from software into the arena of business consulting and analysis. To help place this into perspective it should be noted that the process-based cost reduction focus is often lead by various improvement methodologies such as Six Sigma, Lean, TQM, CEM, Change Management, and so on.

The consultancy approach seeks to improve existing processes by refining how work gets done in the organization. This is why Six Sigma and Lean have quickly been crossed over into the process market as these improvement methods or philosophies are specifically intended to help organizations optimize existing operations heavy with human interaction.

However, this market has also fallen dramatically short of its perceived value creation. Like cost reduction achieved through the use of BPM software, process improvement through the application of specific improvement methodologies sports a number of compelling case studies that highlight the opportunity even while consistently achieving improvement results on a general basis remains elusive. Like BPMS products; Six Sigma, Lean, TQM, etc. are based on incrementally improving a process rather than challenging the process against how it might shaped to achieve maximum organizational benefit (as was the focus of BPR). The reason why this approach is so limited is that in general the philosophical approach for these types of techniques accepts the basic process shape (the AS IS) as valid, seeking to refine the process shape within the current constrained model of the process. In reality many processes are not currently based on a valid process model in respect to how work should get done, therefore they are not properly aligned to achieving the desired outcome of the organization in their current state. Applying techniques or methodologies focused on incremental improvement, by itself, yields at best a process that is streamlined against the wrong outcome and a number of experienced insiders have now come to describe this situation as making the same mistakes, only faster.

The other impact of significance is the issue of AS IS process complexity, where understanding the model requires a high level of attention and focus, leaving little to the challenging of the process as a holistic entity (like the adage that sometimes we can’t see the forest for the trees). Even though Change Management does seek to challenge the “status quo” it traditional falls prey to the complexity issue. CEM is the only practice in the market that deals directly with the issue of complexity.

No Bridge for the GAP

Much has been said about the need to bridge the gap between business interests and the application of technology. Business Process Management was originally believed to be a means to do just that, along with the cost reduction and quality improvements expected from it.

That has not happened – not at all. While in the early days of the BPM software market there was significant effort placed on helping to address the “gap” issue, the movement by the majority of the BPM market to primarily Application Integration has dissolved any gains made by early market leaders. Now, rather than being a bridge across the business-technology gap, for most of the Business Process Management software market BPM tools have become part of the gap - and a contributor to the dysfunctional affects that having the “gap” imposes on the organization.

 One of the most obvious movements in this regard is the now broad adherence to industry standards and best practices that have arisen purely out of the logical, rational, and structured approach required in the use and application of technology. What has now become for many the very “fundamentals” of Business Process Management are completely ignored by the business people on the other side of the gap due to the lack of relevance to their perspective, work activities, interests and concerns.

Another part of the change in the BPM market is the number of people involved in propagating certain beliefs. Because the software market and the adjunct markets it has spawned off (media, research, conferences, etc.) are extremely well financed there has been a tremendous amount of money spent in developing a large consensus of opinion in regards to a “BPM Market Message.”  This consensus echoes the technology viewpoint and has caused many business people to back away from any technology associated with Business Process Management.

The simple fact is that the gap between business and technology is now wider than it was 10 years ago and growing. More and more business people are turning a deaf ear to any discussion around BPM that includes technology. The commercial market has solidified on the split, with one side serving IT interests and the other side serving business interests. BPM as a commercial offering is no longer part of the solution to “bridging the gap.” Depending on the type of product or service consumed from within the BPM market, Business Process Management is either addressing Business Issues or Technology issues – not the disparity between the two.

Lessons Learned

There is, however, what could be the beginnings of a silver lining in the BPM clouds beginning to emerge. From lessons learned in attempting to address business issues and bridging the business-technology gap certain things have been learned, and some steps to address these issues have begun to emerge in the software market.

1) Lessons Learned – The Need for Individual Process Orchestration

What have we learned? We have learned that business activities do not conform to the traditional work flow technology paradigm. What really happens is that the “processes” business people are engaged have a high degree of individual variance and adjustment to contextual influence that affects how work gets done on a daily basis. We now know that in general business processes (as the concept was originally defined) are fraught with the high degree of variability that occurs anytime people are the primary performers in the actions of a process.

Therefore any technology used to support these processes must also have the ability to flex and change on an as needed basis. This includes the ability of supporting technology to flex and change per individual as they are doing their work – enabling people to “orchestrate” their own behavior in the process.

We also know that for this kind of individual process orchestration to work within supporting technology the individual orchestration cannot impose additional “work” on the individual. This means that supporting software for these business processes must grant individual users the ability to “do” their individual process orchestration by simply doing their work their own way. Several niche players in the BPM software market now offer this ability in at least some form within their products, primarily from vendors that are focused on solving specific business issues faced by their target market.

2) Lessons Learned – Work Flow Queues are Extremely Limited

One of the common approaches in BPMS products is to build work flow models of processes and then present the work each person is supposed to “do” in a work queue interface. While this works well when the general concept of a task list is already part of the existing work metaphor it does not work well at all when the task list metaphor is not already in place.

What we have learned is that presenting new software interfaces to people in general creates a change issue that must be dealt with. When changing an existing interface from a design that is difficult to use and unwieldy for the people it serves - a simple, well designed and more useful interface will present a change impact that is very low.

When changing from an existing interface to a new one that is not obviously simpler and easier to use (to the people using it) the change impact increases dramatically. Basically, when we change these interfaces in a way that the people using them immediately can see the benefit, the change impact is very low. As soon as we expect people to learn something “new” before the “benefit” becomes noticeable the change impact becomes significant.

Where no task list metaphor exists, imposing a new interface on the people doing the work represents a very high change impact. Again, if the benefit to the people who must use the new interface is obvious to them then the change impact becomes low but if that benefit is not obvious the challenge in getting people to make the change will be very high, very costly, and is highly likely to significantly reduce the benefit expected from the implementation of the underlying technology.

What we now know is that somehow Business Process Management technology for business users must move away from the general concept of “work queues” and “work queue interfaces.” What business users need is something that works within their current technology comfort zone to help them stay “in sync” with their work in a way that does not impose new activities on them. Because this can take many different forms and be supported through many existing technologies already in use by the business the means by which this is accomplished is highly variable. Numerous BPM vendors have approached this as an extension of their basic concepts of queues and work flow with interfaces into email, email clients, and mobile devices but there is still a long way to go in really solving this problem.

3) Lessons Learned – The Need to “Capture” Reality

As discussed earlier, the processes business users engage in are highly personalized and variant. When we “solve” the issue of how to enable them to engage with underlying BPM technology in a way that allows them to self-orchestrate their behavior in a process (without thinking about it that way) we will have the opportunity to start capturing behaviors of our people that we can learn from to improve our overall business operations.

This is actually brushing against something entirely new in the world of business software. Rather than embedding “domain knowledge” into a process so that we can impose “best practice” on everyone in our organization there is the potential to capture significant behavioral information that can be related to both context and results.

This behavioral information related to context and results represents a wealth of learning we can tap to improve our organizations. Why did one sales person achieve such high results in a given market during a time when others did not? Why does one department, shift or group get numerous complements from our customers when others don’t? Why are certain people always on time with their work when others are not? These types of questions can start to be answered when we reach the place where our underlying BPM software is capturing individual behavioral nuance within context and in connection with results.

Again, in a few cases there are BPM software products that have touched on these kinds of benefits but only at an extremely simplified level. The problem is complex, because to actually capture this kind of information the underlying BPM software must effectively be “unnoticed” by the user. This represents a fundamental shift in how we think about BPM software although it is the future of the product genre - though it may well be called something entirely different to help distinguish it from the Application Integration message dominant in the commercial market today.

4) Lessons Learned – Unstructured or Free-forming Processes

We have also learned that a number of our highest value processes are really ad hoc processes that form within a known framework of relationships. These processes do not have a predetermined start and end point, they form where they are needed, when they are needed and exist until they complete.

For example, a new product offering may start in a number of places such as product development, marketing, research, strategy or executive planning sessions. Depending on what the new product is and how it relates to the other products of the company the “process” may involve any number of functions, departments and activities many of which can be performed in parallel.

From a business perspective what we want is for these processes to operate as smoothly as possible, with timely communication, information sharing and event awareness. Because the relationships behind these ad hoc processes can be identified there can also be structure placed behind these kinds of processes that simplifies both the creation and execution of these ad hoc processes. The challenge though is that these types of processes do not fit the classic BPM work flow perspective of process and are ill suited to BPMS products. While there are a number of interesting technology twists that can help address this issue already in the market they are seldom even given the label of “BPM” and generally do not address all of the challenging aspects these kinds of processes create for the organization.

5) Lessons Learned – The Customer is Nowhere in Sight

The final lesson learned is that the BPM market (except for CEM) has abandoned the customer. What is meant by this is that those processes which represent what the customer experiences (the processes that are the customer experience) are not being dealt with by any of the commercial BPM market segments as end-to-end customer processes.

What we have learned is that these customer processes – the end-to-end processes that are what the customer experiences – are the relationship with the customer. It’s hard to believe that anyone would not consider these processes as the most important processes of the organization. Yet very few organizations have actually documented these end-to-end customer experience processes and even fewer have taken the steps to own them by shaping these processes to produce a known and desired experience for the customer that is specifically optimized to make the customer’s life simpler, easier and more successful.

Considering that these experiences are the business – from the customer’s point of view – and that these processes directly impact our ability to grow customer loyalty and expand the customer relationship it seems obvious that these processes would be first and foremost on our agenda for Business Process Management. That is not the case in the BPM commercial market with the exception of CEM* and specific one-off consultancy practices.

BPM Practice Guidance

While this report exposes a number of misconceptions about the BPM market including a significant amount of industry hype that is being used to promote sales, it also recognizes the value of each segment of the BPM commercial market.

The use of Executable BPM products is appropriate for Application Integration and existing practices that include the concept of “job-tickets” and “to do lists.” It can also create value in some cases where an existing process is very costly due to poor management that has failed to successfully address a known and costly issue in the organization.

Non-executable BPM software can certainly be used to document existing processes and to help improve them just as professional services can using any of the techniques available in that market.

Some Executable BPM products are focused on improving repeatable processes that truly are business processes. While these products are likely to create real value when applied in this way they are still limited to a pre-defined way of thinking about the process and their value creation potential is tightly constrained.

Executable BPM products can play a value-add role in agility (this is the BPM-SOA connection technologists’ care about) if the right decisions are made as to how that systems-based agility will break down within the organization. Tying this systems-agility initiative to strategic plans of the business through explicit milestones is a very compelling way to move this technology opportunity forward successfully.

Considering the economic challenges faced on a world-wide basis it is imperative that decisions on BPM at every interest level in the business be considered clearly and thoughtfully. Knowing what we are using a given commercial offering for, why it will create value and what it isn’t going to do for the organization are the necessary ingredients of successful BPM strategy. Employing a BPM strategy that does not include these ingredients is foolhardy in the extreme. And in an economic slowdown like we are experiencing now that kind of mistake can literally take a business “out of the game.”

Terry Schurter
Global Thought Leader
www.tschurter.com

*CEM training that uses IP from Terry Schurter is only available through the International Process and Performance Institute