Assessing BPM Maturity with @RogerBurlton

Roger Burlton held a joint session across several of the tracks on assessing BPM maturity, starting with the BPTrends pyramid of process maturity, which ranges from a wide base of the implementation level, to the middle tier of the business process level, up to the enterprise level that includes strategy and process architecture. He also showed his own “Burlton Hexagon” of the disciplines that form around business process and performance: policy and rules, human capital, enabling technologies, supporting infrastructure, organizational structure, and intent and strategy. His point is that not everyone is ready for maturity in all the areas that impact BPM (such as organizational structure), although they may be doing process transformation projects that require greater maturity in many of these other areas. At some level, these efforts must be able to be traced back to corporate strategy.

He presented a process maturity model based on the SEI capability maturity model, showing the following levels:

  1. Initial – zero process organizations
  2. Repeatable – departmental process improvement projects, some cross-functional process definition
  3. Defined – business processes delivered and measurements defined
  4. Managed – governance system implemented
  5. Optimizing – ongoing process improvement

Moving from level 2 to 3 is a pretty straightforward progression that you will see in many BPM “project to program” initiatives, but the jump to level 4 requires getting the high-level management on board and starting to make some cultural shifts. Organizations have to be ready to accept a certain level of change and maturity: in fact, organizational readiness will always constrain achievement of greater maturity, and may even end up getting the process maturity team in trouble.

He presented a worksheet for assessing your enterprise BPM gap, with several different factors on which you are intended to mark the current state, the desired future state, and the organizational management (labeled as “how far will management let you go?”). The factors include enterprise context, value chain models, alignment of resources with business processes, process performance measurement system, direct management responsibility for value chains, and a process CoE. By marking the three states (as is, to be, and what can we get away with) on each of these as a starting point, it allows you to see not just the spread between where you are and where you need to be, but adds in that extra dimension of organizational readiness for moving to a certain level of process maturity.

Depending on whether your organization is ready to crawl, walk or run (as defined by your organizational readiness relative to the as-is and to-be states), there are different techniques for getting to the desired maturity state: for those with low organizational readiness, for example, you need to focus on increasing that first, then evolve the process capabilities together with readiness as it increases. Organizational readiness at the executive level manifests as understanding, willingness and ability to do their work differently: in many cases, executives don’t want to change how they do their work, although they do want to reap the benefits of increased process maturity.

He showed a more detailed spreadsheet of a maturity and readiness assessment for a large technology company, color-coded based on which factors contribute most to an increase in maturity, and which hold the most risk since they represent the biggest jump in maturity without necessarily having the readiness.

With such a focus on readiness, change management is definitely a big issue with increasing process maturity. In order to address this, there are a number of steps in a communication plan: understand the stakeholders’ concerns, determine the messages, identify the media for delivering the messages, identify timetables for communication and change, identify the messengers, create/identify change agents (who is sometimes the biggest detractor to start), and deliver the message and handle the feedback. In looking at stakeholder concerns as part of the communication plan, you need to look at levels from informational (“what is it”), personal (“how will it impact my job”), management (“how will the change happen”), consequences (“what are the benefits”) and on into collaboration where the buy-in really starts to happen.

Ultimately, you’re not trying to sell business process change (or BPMS) within the organization: you’re trying to sell improvements in business performance, particularly for processes that are currently painful. Focus on the business goals, and use a model of the customer experience to illustrate how process improvements can improve that experience and therefore help meet overall business goals.

Finishing up with the maturity model, if you’re at level 1 or 2, get an initial process steering committee and CoE in place for governance, and plan a simple process architecture targeted at change initiatives rather than governance. Get standards for tools and templates in place, and start promoting the process project successes via the CoE. This is really about getting some lightweight governance in place, showing some initial successes, and educating all stakeholders on what process can do for them.

If you’re at level 3 or 4, you need to be creating your robust process architecture in collaboration with the business, and socialize it across the enterprise. With the Process Council (steering committee) in place, make sure that the process stewards/owners report up to the council. Put process measurements are in place, and ensure that the business is being managed relative to those KPIs. Expand process improvement out to the related areas across the enterprise architecture, and create tools and methods within the CoE that make it easy to plan, justify and execute process initiatives.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.