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

Seems like everyone in the IT world is talking about Clouds, and I'm not referring to those fluffy white things in the sky. The hype around Cloud Computing is in high gear, with visions of pay per use computing, elastic capacity and significant time-to-market improvements. In fact, many IT architectures are changing, or will be, as a result of this phenomenon.

Regardless of what Enterprise Architecture (EA) framework you like, they all supposedly start with the same thing; the vision and mission of the business. However, in looking around at various EA frameworks you'll find very little information on the principle driver of any business --- The Customer. This assumption can lead to Inside-Out thinking and a cloudy vision of where the business needs to go.

"If we want to know what a business is we have to start with its purpose…  There is only one valid definition of business purpose: to create a customer."
 - Peter Drucker

It's not too surprising that we lose sight of simple truths when the world around us is getting more complex. I recently read an article by McKinsey & Company titled "Why business needs should shape IT architecture" which stated,

"Complexity is rife in any growing business. … As application volumes grow in response to a fast-changing economic, regulatory and business environment, the issue of complexity is becoming acute for many organizations."

The growth in the number and complexity of business applications is causing a lot of analysis to be done about application characteristics, i.e., are they 'suitable' for cloud computing; but more analysis must be done to complete an accurate picture.

Cloudy Vision = Cloudy Future

It is not just architecture that's changing as a result of cloud computing, entire business models are changing as well. This screams for more focus on the external customers of the business; focusing on application characteristics alone may not be enough.

The McKinsey article went on to discuss Enterprise Architecture Management (EAM), as a framework to manage IT architecture. It also emphasizes the importance of the business in leading EAM initiatives, and establishing a Business Lane for your ITIL© Road Map is something I've been ranting about for some time now:

    Business Process Dependencies & Cloud Computing
    Is your IT organization driving the Bus?
    3 Days in the Bus Lane

One of the steps in creating an Enterprise Architecture is to establish a baseline model; the 'as is' state of your current business processes. The McKinsey article mentioned what can happen when IT/technical folks drive process documentation efforts:

"A weak linkage to the business creates a void that limits the quality of the     resulting IT architecture and the organization's ability to enforce and sustain the benefits of implementation over time."

However, even when individual business units take the lead in defining business processes they often restrict scope to their own functional unit. This encourages inside-out thinking and can blur the vision and mission for the business, since customer-facing processes routinely cross functional borders.

The frenzy to take advantage of cloud computing's benefits may lead some to place applications in the cloud without really understanding how they underpin Level 1 (customer-facing) business processes. This can increase risk significantly.

See clearly by looking through the eyes of the Customer

Concepts like Successful Customer Outcomes (SCO) and Moments of Truth (MOT), along with defining business processes in terms of how they serve (or do not serve) external customers are simple techniques that can be used consistently to ensure that you maintain an outside-in focus.

By defining business processes as Level 1 through 4, using the SCO and MOT techniques, organizations can create business process dependencies that are directly tied to how they serve external customers. This can improve decision making about when to use cloud services, but perhaps more importantly can provide a foundation for business process innovation.

Unless you take the energy to re-enforce these simple truths then the unrelenting pace of business and increasing complexity will blur your organizational focus.

Use of IPAPI's Education Program and the Customer Expectation Management Method can help you and your organization see clearly through the clouds that are ahead.

While I'm as excited about the potential that cloud computing may provide, I'm concerned that it may be one more thing encouraging us to take our eye off what really matters --- customers. The attraction of 'cloud computing' may be driven -- at least in part -- by a desire to take runaway complexity and place it in someone else's hands.

The importance of understanding your business process dependencies is likely to increase as we seek cloud computing, regardless of whether your direction is public, private or a hybrid approach.

One of the things I like about the Outside-In thinking and/or the Customer Expectation Management Method is how we can establish business process dependencies based on how they serve external customers. I think this is useful in may ways.

Level 1 processes --- those that encapsulate the entire customer experience --- provide a basis for establishing priority, uniformity of purpose and innovation. They are key to achieving and maintaining an 'outside-in' focus.

Level 2 processes --- those that have at least one Moment of Truth (direct customer interaction) but do not encapsulate the entire customer experience --- support Level 1 processes. Similarly, Level 3 processes -- which do not have any Moments of Truth but do link to at least one Level 2 process --- are supportive of Level 2 processes.

Many in the IT world are discussing this concept of dependency management. In fact, I like to mention this quote in many of my ITIL classes:

"The central challenge of IT governance is the simple dependency: application depends on database, database depends on server, server depends on switch, application depends on application and so forth. IT organizations deal with this critical data on a daily basis and treat it shamefully - essentially as a disposable commodity."

Architecture & Governance Magazine - Volume 1, Issue 1
The Last Word: Dependency Management: A Fundamental Challenge of IT Governance
By Charlie Betz, Author and Enterprise Architect

This quote could easily apply to the business as well.

Failure to understand and document critical business process dependencies, and how they serve the customer, is a fundamental business responsibility. Unfortunately, businesses are just as likely to treat this dependency data as shamefully as IT treats technical dependency information.

It is also just as common for business units to define processes from a functional, internal perspective. But external customers do not want to see 'business units' any more than than the business wants to deal with individual technology domains.

In fact, if business process dependencies are not understood based on how they serve external customers all the efforts IT makes on the business' behalf can in vain. It is not enough to know which applications may be suitable for cloud computing based on their characteristics, business process dependencies must be understood as well.

Proper design, ongoing governance, and managing IT for value depend on understanding customers and markets --- with or without 'clouds'. An outside-in understanding of business process dependencies is essential to this effort.

Location: Radisson Scandinavia Hotel, Düsseldorf, Germany

 

Web: www.performance-summit.com  

Bringing together the leading heads of business performance, operational excellence and continuous Improvement, the Business Performance Summit 2010 has been designed to assist you and your stakeholders in:

• The latest measurement and process improvement techniques to drive business performance.

• Integrating your performance information to execute change and reach your corporate goals.

• Adopting new management models and technologies

 

Examine different perspectives from a variety of public and private sector performance improvement case studies, including:

• Business performance in converging businesses at Sony Ericsson: using market insight and strategic planning to be agile and competitive
• Capitalising on “operational excellence DNA” and quality certification – GE’s continuous curriculum
• The continuing 'Beyond Budgeting' journey at Statoil
• Robert Kaplan’s approach to linking strategy to operations for competitive advantage.
• Improving efficiencies through group strategy and measurement: A BSkyB Ltd case study
• Transforming Essent to be a high performance organisation of excellence.
• Taking a lean journey to emerge from the lean economy with the guidance of Sapa Group
• Nationwide Building Society’s approach to implementing customer-focused improvements in an accelerated change programme.
• Measuring and managing a continuous cost reduction and efficiency programme in the context of Transport for London.

View the full programme at

 

http://www.performance-summit.com/downloadpdfx2.asp

 

IPAPI members are entitled to a special discount

 

Book your place now as a delegate for just £1295 and save £200 off the delegate registration fee at

 

http://www.performance-summit.com/Delegates-Offer

 

Or Contact: Laurence Allen – Event  Marketing Director on laurence.allen@wtgevents.com  or call +44 (0) 207 202 7690