Tackle The Most Common BPM Challenges

Throughout 2010, I talked with a number of business process executives that are members of Forrester’s Business Process Leadership Board(BP FLB).  These leaders all drive large BPM initiatives in the US and Europe, focused on continuous improvement and business transformation.  I usually begin those conversations with a question:  what’s your biggest problem with business process management (BPM) in your organization? Invariably I get a list of the big issues keeping BPM from progressing within the organization, and interestingly, the list of challenges remains the same across industry sectors and geographic regions:

  • Gaining sponsorship– getting the buy-in from senior business (and IT executives in some cases) usually surfaces as one of the first challenges business process professionals encounter.  Without strong buy-in from key stakeholders, you’ll never proceed with large-scale BPM initiatives—although moving ahead with smaller projects may be possible if you get enough mid-level managers bought in to it. But senior executive sponsorship remains critical, if for no other reason than helping you with business change management. The trick to getting executive buy-in?  Avoid technology talk and focus like a laser beam on the financial case. The more senior the business exec, the more critical it becomes to talk in financial terms.  At the highest level of the organization—say the CFO, COO, and CEO—only two phrases typically resonate: 1) how much revenue does it create? and 2) how much profit does it add to the bottom line?  Without addressing those two issues head-on, it’ll be hard gain executive level buy-in.  Fortunately, we’ve got some numbers you can rely on:  BPM projects typically deliver 30-50% productivity gains for processes involving primarily back office, clerical staff, and they typically deliver 15-30% productivity gains for processes involving knowledge workers.
  • Overcoming 100 years of functional thinking—Most businesses and government agencies organize around discrete business functions, like marketing, sales, research and development, operations, finance, HR and so forth. This type of functional organization structure comes from the industrial age (1800s) when division of labor reigned in a non-automated world. In today’s highly automated organizations, business processes that deliver value to customers from an end-to-end perspective usually cross these organizational boundaries, or siloes.  Business process pros call business functions siloes because workers and managers within those functions rarely look beyond that organizational department to see how work that touches the customer gets done within other functions. While it’s possible to tackle projects within a single business function, usually high value business processes belong with a larger, cross-functional way of working.  Getting everyone on board to think about the value stream (a Lean term) from its origin to where it touches and provides value to the end customer remains one of the biggest challenges in BPM.  And getting organizations to overlay their functional thinking and org chart with a process mindset becomes the first step in shifting the organization’s structure to a true process-driven business. Often it requires prying back more than 100 years of encrusted, out of date, work patterns and practices from business executives who have never imagined any other way of getting work done.
  • Tackling business change management. If there’s one problem that gets cited repeatedly as the single most point of failure, it’s change management. The term itself has that touchy-feely connotation that completely turns off some executives, managers and workers.  But the lack of change management—and by that I mean “business change management,” not software change management—can stop a BPM project, program or strategic initiative dead in its tracks.  And guess where most of your change management expertise resides? (You’ll never guess.)  It’s in HR, most likely in the learning and development part of HR. The key becomes how to merge the high level change management approaches that HR knows about with the down-in-the-trenches BPM initiatives.  But, I cannot emphasize enough how important overcoming this challenge is.  By the way, Claire Schooley and I are currently researching Change Management for BPM projects; if you have ideas or suggestions, or want to be interviewed, please leave a comment and contact us at cmoore@forrester.comand cschooley@forrester.com. If you don’t know much about this topic and you want to get started on change management, we recommend reading: Leading Change by John P. Kotter, and Change Management, The People Side of Change by Jeffrey Hiatt and Timothy Creasey.
  • Developing and executing on internal communication plans. This BPM challenge actually belongs within the larger change management issue.  A comprehensive communication plan must start from the top of the organization, but not just stop there.  Instead, it has to trickle down through different management levels to eventually address individuals who have big concerns about how the changed process will impact his or her job.  Plus, the communication plan has to keep a steady drumbeat, not a one-time big bang.  It takes months/years for big changes to really take effect, and senior execs can’t just launch the communication and then disappear from action.  The most important aspect about the communication plan is to 1) incorporate it into your change management plans and 2) synchronize the communications plan with your BPM methodologies—making sure there’s strong alignment between your methodology and communication plan throughout key phases of the project.
  • Agreeing on tooling/methodology. If you equate business process improvement or process transformation with a major religion, then the various methodologies within that process religion are like warring denominations that believe in totally different dogma, think all the other approaches are wrong and cannot see how to possibly co-exist.  For example, you’ve got Lean converts, the Six Sigma fanatics and people who try to blend the two—the Lean Six Sigma advocates.  And you have the TQM adherents, as well as the perpetual discussion of do these concepts co-exist or compete with BPM. I’ll tell you a story I heard about issues surrounding a process methodology. Several years ago a company made a big effort to tackle Six Sigma by training several hundred green belts and black belts.  Senior management was totally bought in.  But the practitioners took a completely purist approach to Six Sigma by forcing everyone to learn “chapter and verse” the terminology and approach.  Ultimately, they failed miserably and disbanded.  Now the organization is pursuing BPM, and some of the Six Sigma experts got involved in this project too.  But they’ve learned their lesson.  The project teams have adapted all training materials to the company’s culture, rather than forcing a rigid approach down management’s and the workers’ throats. Needless to say, getting agreement on tooling and methodology really matters.
  • Expanding BPM knowledge beyond the CoE. Just about every organization you talk with either has a BPM CoE, has started a CoE or plans to develop a BPM CoE.   That’s great, because we’ve seen a correlation between BPM success and the existence of BPM CoEs. Sometimes the excitement about a BPM CoE becomes so loud (figuratively) that I try to remind everyone that the BPM CoE is not the end itself, but rather  a means to an end.  Still, I occasionally run into organizations that plan to build a huge BPM CoE, with 50, 75 or even 100 people in it.  I have to say--why?  Isn’t the purpose of a BPM CoE to perpetuate and spread BPM skills throughout the organization so that many BPM projects blossom?  That’s what I think the role of a BPM CoE is. A more appropriate way to think about the BPM CoE is to staff it with 2-3 business analysts, 2-3 developers, 1-2 architects and 1 executive (and that’s a big BPM CoE.)  Then, with these skills and people in place, the BPM CoE can help leverage other BPM projects or initiatives throughout the organization, help evangelize BPM throughout the enterprise, and focus on more company-wide issues like training and governance.
  • Determining “how big is a process?” – The British have a wonderful expression that pretty much sums up what a process is.  It’s “how long is a piece of string?”  You simply can’t answer that question because it depends on how much of the string was spooled out before you cut it.  Similarly, trying to get your arms around a complete process is really tough.  One person’s set of activities is another person’s process.  I know of one company in the 1990s that envisioned 3 processes:  1) get customer, 2) ship product, 3) get paid.  Very few, if any companies, view their processes that broadly. My own rule of thumb is to focus on the stream of activities that when done, end to end, add value to the customer.  That’s a great way to think about the size of a process because ultimately, selling BPM is a financial exercise.  If you take an outside-in perspective, and try to derive as much value as possible for the customer, that will help make the business case for how much BPM impacts metrics that matter:  market share, customer satisfaction, increase skills, etc.  If you have an internal view, then make sure you put together a stream of activities that will take significant cost out of the organization. Now, tell me again, how long is a piece of string?
  • Closing the process skills gap. I’m passionate about finding solutions and approaches for building and leveraging business process skills.  The reason?  If we are truly going to pursue BPM on a wide basis to deliver continuous improvement and business process transformation, then we will need many more business process practitioners.  Most of the people I’ve talked with say it takes about a year to fully train a BPM business analyst or process analyst, and it takes a long time to create a business architect too.  Some visionary B schools and engineering schools offer dual programs that graduate students with both technical and business skills, but it’s still a tiny minority.  And most companies I talk with find that traditional business analysts (up to 80% in some cases) don’t make the transition from their current jobs to BPM analysts. So where are we going to get these people, and how are we going to train them?  You can’t hire them because people with BPM skills are a rare breed and they get snapped up immediately when in the job market.  So far, the BPM CoE seems to hold the most promise, particularly a BPM CoE that draws on both business and IT skills.  We believe BPM CoEs are a big part of the skills development solution, and will also help BPM projects succeed. 

If you are interested in working on these types of issues, the Forrester Business Process Leadership Board provides a forum in North America and Europe for business process “change agent” executives to solve their key business problems through an exchange of ideas, experiences, lessons learned as well as Forrester analyst insight.  For more information about Forrester’s Business Process Council, please contact Jeanne Strepacki.


Great round-up, thank

Great round-up, thank you.

Regarding #1 of your list: is there any initative that doesn't complain about executive buy-in? Six Sigma, BI, ERP, CRM - you name them.

So the point is not lack of sponsorship per se but BPM loosing the competition for the sponsorship to other improvement initiatives.

From technology perspective, BPM and ERP have very little in common: to start with, the former is a platform while the latter is a ready-to-use (well, almost) application. But from executive's perspective they are direct competitors: both promise some improvements and both requre resources - almost the same resources, BTW.

From my experience, BPM today looses mostly to BI and ECM initiatives - these two promises may be less but they don't require the intellectual challenge like BPM does: just buy it, configure it, learn how to use it and get the profit.

Thank you


Thanks for your comment Anatoly. Yes, ERP and BPM as technologies are very different, but the intersection comes when you look at them from a process perspective. Historically processes were automated by applications that were custom developed. Along came ERP (and any of the other big enterprise suites) and businesses no longer had to build their apps from the ground up, or tackle big, complex processes using a handful of niche, packaged apps--ERP tackled the big, complex process. The question now is if BPM (the discipline, the platform, etc.) can automate complex processes, replacing the need for a big enterprise suite to be implemented. So, even though they are not the same, the technolologies are different ways to automate a process. I believe there's a role for both going forward, and I suspect the answer is that BPM will be used for differentiating processes and ERP will be used for core non-differentiating processes that benefit from having best practices built into the application. Make sense?

Connie Sure there is room


Sure there is room both for ERP and BPM and these two are complimentary for each other. But it wasn't my point.

I tried to say that every corporate-wide initiative needs executive sponsorship exactly like BPM does (the #1 challenge of your post). But obviously an executive can't support all of them so they are ranged and only the most appealing ones get the support. Therefore it's not enough for BPM to e.g. demonstrate high ROI statistics - it must look more appealing overall than improvements promised by other initiatives.

From my personal experience, it fails to do so in many cases, loosing to BI and ECM project mostly.

Analysts use to investigate horizontal layers: e.g. measuring the percentage of enterprises doing BPM or considering, the average ROI and things like that. But it would be interesting to get the picture of average executive's preferences: what innovation is today's #1, #2 etc. and what is BPM's rank. And why they prefer one management/technological innovations to others.

Thank you

Process Discrimination

A great list of challenges, which is why BPM has failed to take off depite the obvious benefits.

One area which was not listed was Process Discrimination which I talked about in my blog http://iangotts.wordpress.com/2010/10/22/process-discrimination-and-livi...

When you say the word process to people what reaction do you get? Are you being discriminated against? Do people immediately get the wrong idea, jump to conclusions, put you in a ‘box’, and prejudge your intentions and actions?

Watch the video in the blog and think about whether using the word process gets the equivalent reaction in the people you talk to.

And then the discussion is, "What terminology should we use instead which hasn’t got years of ‘history’ associated with it?"

Hello Connie: Nice recap

Hello Connie:

Nice recap post.

Regarding how big is the process? For me is when all the outcomes are achieved. I've written about it on Peter's BPM forum here:




Hi Connie, I enjoyed reading

Hi Connie,

I enjoyed reading this post and many aspects I feel are spot on.

One of the big issues that BPM fails to deliver, is that of adaptive needs. Because BPMS is so rigid, it becomes hard for management and those in the trenches as you put it, to see how it applies to certain processes or work that has to be done (especially if their view of processes is very loose shall we say). BPM wont penetrate processes that are more loose, require more agility or adaptive capabilities. But if we deliver a highly adaptive implementation, something that need not enforce such rigid rules, rather it provided guidance and tracking, to processes and work, then management would see the value of this along with users. Add to this adaptive capabilities for process definition to change based on what actually goes on, and even adaptive capabilities to detect new processes and have users define them, and you have a solution that can penetrate all processes across the enterprise....I see APG (Adaptive Process Guidance) as an adaptive evolution of BPM, and its APG I would prefer to leverage.

Another point I want to touch on is that BPM is still a single silo. Yes we can integrate it, but from a business point of view, real value for BPM is only realised once we start integrating, especially with CRM and ECM. So an organisation does this in one department, but intergration needs are different in another, and another. This makes it hard to justify the integration spending, even more so for processes that are less structured and require more flexibility. This is where we need a far wider approach, business needs to take a holistic view on what they term as processes and services, and vendors have to be aware of this. Inter-connectors out of the box, professional services all help, but the real win is when platforms deliver holistic solutions....

Forward thinkers will have identified that a single platform for ECM, CRM and BPM, or even better, APG (Adaptive Process Guidance) in place of traditional BPM removes the integration nightmare and potentially delivers improved efficiency and customer services across the enterprise. Business then need not worry about integration needs of departments and particular processes, simply because its there, all in one. APG delivers all the adaptive capbilities an organisation needs to have it fully penetrate all processes and "work" that is carried out...This is where BPM type solutions really start to make a massive difference...

I have recently spoken about BPM agility, social needs and APG with eBizQ Peter Schoof. The pod cast is available here


Top Down vs. Bottom Up

Connie, you're right on the mark with these thoughts. We see the same things--but often in the context of a department or division that comes to us because the massively-scaled, top-down, centrally-mandated BPM effort is not meeting the specific needs of that particular business unit.

I discussed this briefly in a recent blog posting of my own:


That's why your story about the Six Sigma organization, and the comments about CoE size in your fifth bullet point ring true: big organizations too often approach problems with big, expensive, over-the-top solutions. BPM can very frequently scale more effectively through multiple targeted installations than through a single, top-down enterprise deployment.

8 Sources of BPM headaches

Spot on Connie. I can relate to all of these.
Can I suggest another? Sustaining a BPM programme beyond its initial success. Im my experience, too frequently the BPM programme is treated as a project and once initial targets are achieved, the project falls by the wayside and initial gains are gradually eroded. The key to dealing with this particular challenge is for managers to monitor and control business processes once they move into 'business-as-usual' operational mode. Unfortunately many managers are lacking these critical skills and BPM training mostly focusses on BPM analysts and architects for process implementation and improvement with little focus on management practices, measurement and control for sustaining and nurturing into the future.

Embarking on design,

Embarking on design, development, implementation of Business Process Management System (BPMS) application is a challenge for an enterprise. Surveys consistently show that BPMS is a top priority for Business organization. Yet after years of investment and implementation, BPMS has failed to become pervasive among business users; Estimates that no more than 20% of business users actually use BPMS proactively. This means that BPMS is not being effectivelly used to manage Business Performance. So, what is the problem and why are't Business organizations doing better with BPMS? I sees business organization facing challenges in several areas: Sort a standards practices to establish BPMS Processes and set themselves on the path to self-improvement.Global business organization use variety of frameworks, standards, methods and guideline principle to manage it. This research is to determine the most frequently encountered requirements in Process Approach of BPMS applications along with the recommended solution based to resolve these requirements using the Standardization of Best Practices on BPMS.