International Process and Performance Institute

Time for an edgy article, one that challenges the status quo and upsets some apple carts...

BPM.  Business Process Management is a tool - but it is NOT A TOOL. For everyone, and I do mean EVERYONE, that thinks BPM is some form of technology or use of technology you have missed the boat, the big picture and the real opportunity. People who believe that BPM is the expression of process in technology are limiting their perspective to a very tactical aspect of BPM that is not transformational and that is often destructive. Those who are "implementing" BPM with software modeling tools, workflow execution software, BPMN, BPEL, or whatever haven't missed the boat, they have missed the ocean.

But that goes against an awful lot of leadership commentary and work in practice so what is the disconnect? It starts with an understanding of what BPM is - which is certainly a challenge because there is no common definition of BPM. Instead there are many opinions and pespectives. Let's try and remedy that with what may very well be the best definition of BPM to date:

BPM Defined

BPM is an understanding of the work that people do in an organization as related activities (or tasks) that often encapsulate or create experiences (customers or internal customers), that exist to achieve a result, that are optimized and managed against desired experiences, that are refined to eliminate non-value added work, and that are supported by technology in a way that makes all experiences (customers, internal customers, participants, managers,etc.) simpler, easier and more successful.

So BPM is a tool, because it is something we can use to accomplish many organizational benefits of great value. We can increase customer satisfication, improve customer value, reduce costs, improve employee morale, make less mistakes, create more consistency and get more work done.

BPM is not a tool because too often the term "tool" refers to technology, and as we can clearly see from the definition above technology is a suporting aspect of BPM but it is not BPM.

From the definition supplied we can also see that BPMN is not BPM. I pick on BPMN because of its hype as a "standard" when under no circumstances has it ever been "standard." BPMN is a complicated technical expression that has attempted to codify a bunch of analytical concepts from several decades ago along with process structure that partially aligns to workflow technology.

Of course, that aligns to all those people who have been coming out of the woodwork lately with "decades" of BPM experience when the term was only coined in the early 1990s. Huh? Reminds me of the guy who claimed that BPM is really just a part of the philosophy that lead to mass production and assembly lines...

What about Richard Norman? Have you heard that name before? He was the guy who coined the term "Moments of Truth" and produced major works in the understanding and leveraging of processes behind customer experiences and customer value. Moments of Truth aren't in any of these other things I have mentioned... well, that's not true. The concept of Moments of Truth isn't in any of these things but Moments of Truth are THERE IN SPADES.

The Magic of BPM

The magic of BPM is the opportunity to address human experience in process. Yes, that means dealing with subjective, emotional, unpredictable and often inconsistent behavior but that's what it means to be human. How can we possibly discount this if we are truly logical, rational and intelligent? Water and oil don't mix, and these concept refute each other. We cannot be logical, rational and intelligent if we ignore the human aspect of process. In fact, the human aspect of process - and of BPM - is the single most important perspective hands down in BPM. If you only get one piece of it, this is the piece you need to "get."

So BPM is in a mess but if you can wade through that mess and understand what BPM is really all about you can achieve great things. You can certainly use technology to aid you, and you may find that technology will empower you. But BPM - once and again - just isn't technology folks. It isn't BPMN, it isn't something you can buy in a box, it isn't mathematical and it refutes all attempts to create a singular executable expression form of it. It's essence rests in human nature, and anyone that suggests they understand and can codify that has failed to reach the state of wisdom.

While I may be bold enough to present a definition of BPM I am not fool enough to suggest that I understand all aspects of BPM. Instead, while I make observations that capture many important aspects of BPM I wisely understand that what I don't know easily outweighs what I do know.

The mess comes from believing that we we know, what we care about, or what we want to be true is a comprehensive - no, a complete and holistic - understanding of BPM. We aren't close to that, but some of us are farther away from the truth than others...

I had an interesting observation the other day that made me think again about how processes often really work and how people in process can make all the difference in the world...

The observation was a case where one person in a process - just one person - had a tremendously powerful impact on a core business process. This person, quite meticulous and very quality-oriented, was performing a role in the process that was never designed into that processs nor was there a real understanding in the organization that this person was having a specific impact. Well, that's not completely true. What the organization did understand was that when this person was there (they only worked at this company 3 days a week) things just naturally "worked better."

So what role was this person performing?

The self-assigned role was that of the CORRECTOR. What this person did was CORRECT anything that was not done right on every piece of work they touched. When I gave this situation a closer examination, what I found was that the work in the process (actually several processes) in this organization naturally accumulated a number of (usually small) human errors as work was performed. The CORRECTOR, on their own, was effectively cleansing all work of these errors that they touched.

Let's think about this. If it is common, and I think it is, that work in a process will often accumulate human error as it is transacted then those errors will require additional work at some point. Some of those errors may spawn numerous additional work activities - including impacts directly on the customer. For example, a single typo on an address can cause mail correspondence to fail to reach the customer. Suddenly that single typo spawns another process which can be as onerous as cancellation of an account for non-payment because the customer never got the bill followed by phone calls, research, corrections, reinstatement and, of course, deep customer dissatisfaction.

So I then began to wonder, how many correctors are out there "fixing" our processes? How much does the quality of our processes and the customer experience we deliver depend on a single person or a small number of people that, on their own, scour work for accumulated human error and reinstate quality into our processes? How often does this happen and we don't even realize the important role these people play?

Part of the challenge here is the focus or emphasis we give to those who work in our processes. Focusing on outcomes - and imparting outcome ownership - to people actually doing the work in a process is a critical element in delivering on that outcome. Processes designed or acted upon as if they are assembly-lines are highly likely to produce accumulated human error. Assembly line processes may work well for phsyical assembly of products, but they are highly ineffective for subjective business processes. For these, outcome ownership is the key.

But I also wonder if correctors may need to exist in our processes. People have different personalities and behaviours and I think this is a skill that is simply ingrained in some people. In that case we should probably spend more time understanding the strengths and weaknesses of the people in our processes to help us understand and work towards a balance of abilities to produce the result we desire.

Of course, you won't find this discussion in the questions and comments on most all of the "BPM discussions" like linkedin (for example). I periodically answer questions there and attempt to inject some new thought into the old - and almost frighteningly narrow - perspectives given there. What I primarily see in the BPM discussion at large is a consistent - zero value - postulation of narrow perspectives that primarily seek to validate "what I do." The opportunity is to challenge the status quo and learn from our observations so that we can understand process better and use that understanding to improve the work we do and the results we produce.

Yet how many of us have actually observed things like CORRECTORS? How many of us understand the real importance that specific people, people types (personalities) and focus (outcomes) really have on our processes? I suspect (strongly) that none of us pay as close attention to these things as we should.

Meanwhile, the CORRECTORS keep doing their thing, instilling quality into our processes and often making the difference between business success and business failure. The sad thing is, we usually don't notice their contribution until they are gone...

NOTE - LAST OF A 3-PART SERIES

PART 3

Why – Why does the process exist?

Identifying who the process serves does not require significant work on our part – it is the passive part of the process reference model. Understanding why the process exists is not a passive activity.

Why does the process exist? What wants and needs does it fulfill for the consumer of its output? Do we know that? If so, do we have measures and goals?

Understanding the need or want a process fulfills – or is intended to fulfill – is absolutely critical to achieving business success from process management. This is an area where process management often runs into trouble as the measures and goals of the process – if they exist – most often exist as indirect KPI’s.

What is needed is some work around the goal of the process in respect to its customer. What does the customer want? What would cause them to think of the outcome of the process as successful versus what is not successful?

The degree in which we identify the measures and goals of the process in explicit alignment with what will make the customer’s life simpler, easier and more successful the more value we create.

That’s right, the better we are at identifying what the customer of the process really wants and needs the better the process will be. There are multiple levels to this and simply “asking” the customer is at the very bottom. Really great process management is able to articulate both the measures and the goals of a process that reflect what the customer of the that process really wants and needs better than the customer can ever do for us.

What – What shape should the process take to best fulfill that need?

The process shape is the set of high level assumptions that we make about a process – what activities are in the process and what must be done to produce the desired outcome.

The design of the high level process shape heavily influences how well a process fulfills the needs of its customers. For example, while there may be many ways to get to the grocery store there is probably one way that is better than the others.

The process shape is our expression of what we feel we must do to produce an outcome. The high level process shape should always be as simple as possible and it should be carefully designed against the Why and the Who.

If we have a very good Why we are likely to get a very good What. Knowing why a process exists is required if we are going to craft a process shape that actually delivers on the promise.

This is where we challenge activities and rules that may still exist in our processes even though the original need they addressed has either changed or no longer exists. The reason why a process has a certain shape is not important. Identifying the appropriate shape of the process to support the goals of the customer of the process is very important.

This is where we look hard at the process (in its entirety) to make sure the overall shape of the process is an appropriate one for producing the outcome we intend for it to produce.

How – How do we support the process in the fulfillment of the need?

Once we now who the process serves, why it exists (wants and needs), and what its shape should be to deliver on those wants and needs we must now support the work of that process to help deliver on the promise.

This is where BPM (and other) software comes into play. The how is the part of the process management challenge that BPM software is designed to address.

Supporting the process can involve automation and workflow. It can involve document management and document creation. It can bring into place contextual information the helps people do their jobs better. It can include simple business rules that help avert or catch human err. It can include more complex business rules to help people (and work) navigate to the desired outcome.

Efficiency and quality can often be enhanced when processes are properly supported. Well configured supporting technology will make it easier for people to successfully complete the right tasks at the right time.

Supporting how work gets it done is the final piece of the process reference model.

Why BPM Fell Short of the Mark

The reason why BPM software fell short of the mark is that it does not address all four quadrants of the process reference model. The reason why consultants fell short of the mark is that they too failed to address all four process quadrants. Same with methods. The fact is; we all fell short of the mark in addressing all of the quadrants in the process reference model.

That is the problem just as it is the opportunity. As BPM moves forward it will evolve. Already the main BPM vendors have moved into severe stagnation in regards to any form of thought leadership. The BPM market in many ways has become the “me too” crowd with the caveat that “I’m better because.”

There are also beginning to emerge some new twists on the BPM angle in software vendors that are small, mean, lean and inventive. They are a symptom of market pressure that comes from a problem that has not been adequately solved.

The next evolution of BPM will come much closer to solving that problem. The chances that the next round of BPM software will successfully cross the chasm are actually quite high. The value proposition is far more compelling and the lessons learned carry a powerful message in respect to our understanding of how process management must really work.

In doing so, the market will be a flurry of innovative and creative output of compelling approaches to bringing our process management activity into the holistic state of addressing the entire process reference model.

Until then it is up to each one of us to understand and implement process management in the right way. If we don’t do it, who will?

NOTE - THIS IS A 3-PART SERIES

PART 2

The Bigger Process Picture

Let’s go ahead and grant that lessons learned are part of the way things work. The key is learned, and this is what we should have all learned from our experience with BPM.

We must have a common understanding of process and we must have a reference model to understand that other people’s perspectives exist. We also must understand enough about those other perspectives so that we can recognize why they are important to the central idea of process management.

Common understanding must be common. That means we cannot impose any need to understand terms, perspective or mindset on the conversation that must occur at this highest level of process. That means no need for translation – none.
 
Here is that reference model:

 > Who – Who does the process serve?

 > Why – Why does the process exist? What need does it fulfill?

 > What – What shape should the process take to best fulfill that need?

 > How – How do we support the process in the fulfillment of the need?

This may seem obvious now that I have stated it but remember the quote; the most difficult thing to observe is the most obvious. Based on the interactions I have had with people working with process I contend that very few process initiatives actually address each of these elements in the process reference model.

Let’s go a bit deeper into the model to discuss the common understanding it can give us when seeking to achieve business success through process management.

Who does the process serve?

Every process that exists serves someone or something. That someone could be our customers, internal customers, employees or the organization itself. We should always know who the process serves.

Think about it. Dr. Joseph Juran gave us a definition of quality as a contextual measure based on fitness of use for the intended recipient of work that we do. If you are the recipient of a process outcome, should that outcome be tailored to your wants and needs? Shouldn’t it be fit your use in a way that makes it easy for you to accomplish your work?

Most processes are really sub-processes in the bigger scheme of things. Even when the process is an end-to-end process, it is part of a bigger process somewhere. A compliance process is part of the larger process of protecting the operational viability of the organization. Customer service processes are part of the customer-business relationship process and are part of a higher level process the customer is engaged that involves some aspect of their life that they care about.

So we need to know who the process serves.

---to be continued---

NOTE - THIS IS A 3-PART SERIES

PART 1

There are many software, consultancy and method providers in the field of process management. They all share one thing in common. They claim to have uncovered the solution to process management. Yet they are all missing the bigger picture.

That includes the work I have been involved in – though I reserve for myself the recognition that I have at least indirectly referenced this fact on more occasions than anyone else I know. That said the gap still exists in how we can take process management to a new level of success. This paper addresses this issue and provides a roadmap to the future of what BPM will be.

Background

BPM came into vogue (mainstream awareness) in the early part of this decade. While I do not know the amount of venture capital infused into this market it is quite large – at least several hundred million dollars. There is a reason for this. What many venture investors saw in BPM was a promise to address issues that they know exist in most organizations.

While those issues can be paraphrased in many ways at the heart of the matter is the challenge of organizing the disorganized, eliminating much of the waste in how organizations do their work, simplifying how software systems support the business, and the creation of an infrastructure that is far more flexible than in the past.

Let’s turn that around a bit.

BPM is perceived as a way to help organizations increase their efficiency, quality and responsiveness to market demands. If you are a business manager there is a very good probability that you know the frustration of wanting – even needing – to adapt practices to meet new market demands and deal with operational weaknesses. If you have been around the block a time or two you know all to well how often the organization seems to be purposefully opposed to these adaptations.

Of course the organization is not opposed to your goals. But it is a somewhat loosely tied grouping of perspectives. I’m sure you remember the story of the blind wise men that went to see an elephant. They observed a portion of the elephant and drew their conclusions on the totality from that perspective (side, tusk, trunk, knee, ear, tail).

Understand that this is what happens in our organizations as well. Our context gives us an observational perspective on the organization that is not holistic. People are heavily influenced by their context – far more than any of us realize even if we have studied this trait of human cognitive behavior.

When BPM started to gain mindshare many of us (including yours truly) got very excited (include the venture capitalists on this) for we “saw” what we believed to be an emerging market of software products that would solve this problem once and for all. We were wrong.

How could so many smart people have missed the boat? I have made a statement around the challenge of innovation that sums it all up:

The most difficult thing to observe is the most obvious.

What I allude to here is that cognitive awareness is triggered by the abnormal not the normal. We (people) operate on autopilot most of the time, we have to or we would be unable to do anything. Only when something stands out as different does our cognitive awareness begin to rev up.

With BPM, we missed the fact that we were each assessing the potential of BPM software from our own context (or perspective) and that the basic concept of BPM and BPM software does nothing to address these differences.

So we each went away with our own interpretation of BPM. All we have to do is acknowledge the now obvious fact that multiple interpretations of BPM do exist and it becomes obvious why BPM software did not fulfill the promise we thought it had.

That’s not to say that BPM software, consultancy or methods have not been helpful because in many cases they have. Yet there is a much bigger value proposition still hanging out there and that is what we really want to realize.

---to be continued---

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

Greetings all, it is been far to long since I have shared some of my insights here at IPAPI. So let's get this show on the road and look at some of the finer points of great process that can help us all achieve greater success tomorrow than we did today!

Don't Expect what you Don't Deserve

Ouch - that's bringing it on right of the blocks isn't it? Yet this statement is deeply engrained to everything the Institute lives for because the real point is that you should not expect different results if you aren't doing anything differently. Same approach to process, same "solution" mindset, same result.

I point this out because even as I meet with senior professionals here in 2010 I am consistently finding that in a matter of days (sometimes hours) I can lead these people to uncover 40% - 70% process improvement opportunities that can be fully realized in 90 days or less, usually 30 days or less.

Consider this - at an executive dinner in London earlier this year that I was fortunate enough to be the guest speaker, we had a senior executive from Barclays that told us they have documented - documented - that 90% of the work their people do every single day is non value-add. What I was most impressed with in this conversation is the approach that lead to this finding was based on process task assessment against the creation of customer value. Basically, if a task didn't create customer value than it was considered non value-add.

So Barclays is now working to build a sustainable behavior of value-add change through process education focused on customer value - heart, soul and mind in alignment with what we preach here at the Institute! It will take some time to build that behaviour but I mark Barclays as a company to watch of the next few years. If the stick to it, we should see some amazing results. Of course this does beg one all powerful question: why aren't we all doing this? Remember, you can't get to that new place with the same old behaviors!

The Customer doesn't care about your Process!

Do we understand that the customer doesn't care about our process, that they only care about their experience? We should have that figured out by now...

But how far do we take that? Let's do a little test:

1 - Do you use words in your communication (phone, email, documents) with your customers that are meaningful to you but not to them? Almost every organization has its own common terms and language style. But often those terms are not common for our customers nor is our language style their language style. In fact, how many times do we use words - like the insurance industry that commonly uses the term "endorsement," a very uncommon word in general language style - and then expect the customer to understand what we are talking about?

Kind of sounds like a Moment of Truth doesn't it?

2 - How about the point of the communication? Like forms that look alike but one is a bill and the other is a statement when automatic withdrawal is setup on an account? Guess what, if it looks like a bill then it feels like a bill and I (the customer) must now check to see if it is a bill or not.

In addition, shouldn't the first and most prominent point be the purpose of the communication? Like:

WE HAVE ADDED A NEW DRIVER TO YOUR POLICY PER YOUR REQUEST!

instead of:

This is to notify you of the new endorsement on your policy

(and then include the added driver on the list of drivers on the second or third page).

Moment of Truth? You bet. This directly leads to customers contacting the company - confused, upset, worried, and often angry. Where is the value add here?

I'll close for now but I'll be working hard to share more here from now on. In our own way, we are changing the world... one Moment of Truth at a time.

Regards,

Terry

The recent IIRME Process Excellence Summit was a great event. Speakers were drawn from the local region and internationally with a number of compelling real world case studies and highly refined observational perspectives from industry experts.

I was very impressed with the caliber of speakers and the results produced in many of the case studies (no theory here folks, this was real results from life in the BPM trenches!). The EFQM presentation on their quality framework that is making such a big impact in Europe (and beyond) highlighted the focus of organizations as represented by event speakers where more and more we are addressing all of the stakeholders in our process approach-customers, the organization, employees and society in general.

If you were not able to attend this event, you missed a great opportunity to learn a lot about what others are doing, the results they are acheiving and the lessons they have learned. Oh, and the IIRME team did a great job of running the event leaving speakers and participants the freedom to engage in the learning experience, not in being distracted with "non value add" event details :)

For my opening presentation, I presented a simple model for Process Excellence but one that I think highlights the holistic nature of what process excellence is really all about. Much of what I covered was simple "not in our conversation" in preceding years, so I think it was a sign of the times in how we are maturing our approach to process excellence.

The model is presented here, and I'll cover it in quick overview to give you a sense for the perspective taken. But before I do, let me point out that without pre-event colloboration I found that my opening keynote was reinforced throughout the event by the other speakers and participants. I'll chalk that down to "synchronicity" as I certainly didn't influence the presentations of the other speakers-their presentations were prepared long before hearing my thoughts on the matter!

Focus - the focus of the process is an outcome, or better, a desired outcome. This is the strategic component of the process from which we can derive the organizational and/or process consumer's (customer, internal customer) KPIs. Focus often comes from an existing undesirable outcome however, regardless of why the outcome is identified it sets a stake in the ground for defining the process behind the outcome.

Alignment - if we know the outcome-actually, the desired outcome-then we can challenge the process behind the outcome to ensure that everything that is in the process (activities, workflow, rules, assumptions, data integration, automation, and so on) is aligned to achieving the outcome we desire. Alignment is a process improvement activity, and is essential to maximizing process value.

Relevancy - this is a new area for some of us, but it is growing in our awareness a critical aspect of process. Is our process relevant to ALL of the process participants? The PEOPLE who consume the outcome, do the work, conduct analysis, manage operations, make strategic decisions, and develop ongoing strategy? Is the information we provide directly pertinent to their needs and wants? Are interfaces intuitive to their purpose? Does the process make it easier for them to succeed? Relevance is a critical apsect of process; what effectively determines if a process is "functional"or "disfunctional." This is the "place" where work gets done, and relevance to process participants-in many ways-determines whether (or not) our preceding work yields real value (or not.)

Support - finally there is support, which inlcudes our use of technology to support process and when done sucessfully will directly support-and augment-the focus, alignment and revelancy of our processes. This is really where the "gap" between operations and technology exists that is talked about so often, and it (as with each aspect of the model) it is either done right or we subject the entire process plan to a level of risk that could preclude the creation of value from our process initiative.

I know its a very brief overview of the components of process excellence, but I think it helps us place our process intiatives into perspective. The opportunities to achieve significant gains from process practices remain the best place for us to improve our organizational success and I think this model helps us understand what we must do to achieve that success

I recently had some interesting conversation on business rules - how the way we think of business rules has actually created many of the challenges we face in business process management. The essence of the conversation is that there are two categories of business rules that exist in most organizations; those that act to control work and those that act to direct intent.

While I believe the distinction between these two categories of business rules is not something we formally recognize, there is little doubt that they both exist in every organization.

Control

Business rules used for control, as I would define them, are those business rules we expect our organization to follow rigorously. Exceptions for control rules require formal acknowledgement, via a programmatic exception handling sub-process or approval. For the most part, control rules are inviolate. They are the rules we expect the people in our organization to follow based on what each rule tells us we must do.

BPMS, BRMS and enterprise applications products are often used effectively for these rules, creating executable software with these rules embedded within them. For example, the quoting of customized goods or services could follow a specific rule set to determine product price. Exceptions for pricing other than what the rule set dictates, if this option exists at all, would likely be handled through a formalized exception sub-process.

Intent

In contrast, a set of documents that provide a pricing matrix could exist instead of a formalized pricing rule set in software. A given company could operate under an adapted rule that is driven by sales goals, with exceptions (pricing adjustments) commonly ‘ignored’ as long as sales goals are met. I have seen this before, many times, where the organization has a set of unwritten rules that people know and apply on a regular basis.

The intent of the pricing rules in this case could be interpreted as ‘we need to make sales goals and our pricing should be as close to this as possible.’ Exceptions to the pricing rules are driven by what is accepted by management. These exceptions suggest that the definition of the real rule in place is more complex. The rule is really “we need to make sales goals, ideally at a certain level of profit but at the same time to keep a certain volume moving and with the caveat that volume can offset profit percent, and this pricing is what we really want to be as close to as possible.”

What I want you to observe is that this rule can be almost infinitely complex. When sales are down, the rule may be relaxed more. If sales are up, nearing production capacity, the pricing matrix may be more strictly enforced. Closing business with an important new client might skew the pricing model even to a loss. It is, in affect, a subjective rule that acts as a guide line to achieve an outcome of sales levels and related profit.

Another example of intent-based rules relates to operating procedures. It amazes me that all organizations have rules in place that tell us how to do things, yet they are largely ignored and rarely enforced. The intent may be to comply with external regulations or it could be how the organization has decided certain things should get done. These rules are always documented but often times they are not enforced, or if they are enforced that enforcement is the creation of “documentation” to support rule compliance. Let’s face it, when anyone reviews adherence to procedures, how do they do that? They don’t take the time to observe people at work, the audit the “paperwork.”

A rule of thumb

The takeaway I have from this is that codifying control rules makes complete sense while codifying rules of intent has the potential to produce serious negative consequences. While it may seem logical that codifying rules of intent is beneficial, the realty is that doing so will immediately create a need for organizational change and the consequences can negatively impact performance and morale.

Where rules of intent need codification, i.e. “we need to follow that rule,” then there is a need to factor in education and training to the people affected so that we can successfully go through the change process with at worst a temporary negative impact on performance and morale.

Perhaps if we take the time to think about the rules in our organizations we will find that many rules of intent can remain as they are. I suspect that this is necessary, as people are not machines and they will develop unique work patterns as part of human nature. Control rules are relatively easy to deal with. Rules of intent are far more challenging, requiring us to think hard about the purpose of the rule and the best action we can take (which may be no action) to achieve the outcome the rule exists to serve.

[note - this article is provided by research/analyst firm Hydrasight who I am working with in respect to process technology research]

Hydrasight research confirms that business process management suites (BPMS) continue to be seen as an important component of functional process improvement in many organisations and, to a lesser extent, for cross-functional processes. However, we also observe that many organisations continue to be challenged by their own immaturity with implementing both functional and cross-functional process improvement. This is due to the difficulty associated in codifying processes that often lack sufficient detail or have complex exception handling requirements.

Hydrasight believes that the use of BPMS technology, on both functional and cross-functional processes, can be an appropriate application area for BPMS products. Most BPMS products now offer capabilities to support complex process flows, systems integration, authoring of business rules, automation, operations visibility and modeling standards needed to successfully implement these business processes. However, we caution IT organisations (ITO) and business professionals to recognise that BPMS products provide little support in respect to defining accurate process models where such definitions do not already exist or where processes may be unsuitable for codification (e.g., discretionary decision points).

Hydrasight observes that leading BPMS vendors offer ‘business friendly’ tools to aid users in functional and cross-functional process definition (e.g., Lombardi BluePrint, Metastorm Provision). However, we note that process definition for complex processes, and/or processes unique to the organisation, remains a challenge with all BPMS products. Our research confirms that developing a process definition that accurately represents the way work is performed and optimized to achieve desired process outcomes is the single most important factor in determining results gained - whether BPMS automated execution is utilised or not. Hydrasight further notes this is symptomatic of a larger issue where improvement practices such as Six Sigma and Lean also experience significant difficulty in producing desired results on processes not already clearly documented and understood. From our research, we believe this a key factor in limiting the potential of BPMS products to become the foundation of the integrated process enterprise and of process improvement initiatives in general.

Hydrasight research shows that organisations successfully adopting BPMS often focus on processes that are already well-documented or where best practice process models are readily available, diminishing the value of the dynamic optimisation capabilities of the automated suites. This is often due to greater availability of best practice models and the disconnect between ad-hoc business processes and those that are already codified/encapsulated in software applications (e.g., human resources management as one example). Hydrasight research shows that having access to best practice and/or existing process definition does not guarantee success. We further observe that even when extensive ‘as is’ research is performed before producing a process model, results may still not be consistent with how the process ‘really works’ due to the subjective nature of the people involved (e.g., both interviewers and interviewees).

We typically observe that cross-functional processes are rarely well documented or clearly understood in the majority of organisations. This is further complicated by multiple stakeholders with different functional perspectives. The rise of interest in business process management has prompted many organisations to begin looking at these processes with the intent to support them in a more programmatic way. While we recognise the value of this approach, and the efforts to bring cross-functional processes under programmatic control, Hydrasight cautions organisations that the challenges are great—and that outcomes often fall far short of business expectations.

Hydrasight foresees that the subjective elements of BPM, such as the interpretation of process definitions and/or execution decision points, will remain one of the greatest challenges for organisations to face in leveraging the potential of BPMS products. We caution ITOs and business professionals to ensure they pay close attention to the importance of designing process models that accurately reflect how work ‘really gets done’—or how it will be done if the process includes moving to a ‘to be’ state of improvement. Moreover, we advise organisations to thoughtfully consider the role of the tool versus the general benefit of process improvement, whether automated or not. In general, we recommend a proof-of-process approach as opposed to a proof-of-concept approach. This assists in avoiding project ‘failure’ being directly linked to the tool, rather than the way the tool has been implemented by the business [what's wrong with a proof of concept]. In either case, Hydrasight observes that codifying an inaccurate process model is likely to lead to failure that extends beyond the intended process goal into issues of diminished confidence with BPMS products, other processes in the organisation and the IT organisation in general—whether they are directly involved or not.