Operational, Transformation and Technical Roles for Successful BPM Projects

My first post from the Gartner BPM conference in Baltimore this week; to be honest, there hasn’t been all that much so far that has inspired me.

Michelle Cantara, who focuses on organizational issues related to BPM, spoke about the roles required for successful BPM projects. She had four main points:

  1. It’s difficult to find BPM-skilled resources: there’s a shortage of skills not just within some organizations, but in the market in general. In many cases, BPM is not a full-time job for someone within an organization, but a set of skills that they need to apply in the context of other work.
  2. Not all projects require the same BPM skills sets. If you look at the Gartner BPM “sweet spot framework”, which is a quadrant with frequency of process change (low to high rate) along the horizontal axis and responsibility for process change (IT to business) along the vertical axis, they show three main usage scenarios for BPM (the lower left quadrant is considered not necessarily a good fit for BPM). In the upper left quadrant, for example, where BPM is used for standardization and manageability, process visualization may be a key skill that is not as important in the other quadrants. In the upper right quadrant, which is the sweet spot for BPM, round-tripping capabilities and sophisticated process governance are important skills. In the lower right quadrant, where BPM is used for IT agility, model-driven development and other technical skills are most important.
  3. Those skills sets are not necessarily what you already have in house for other projects, although if you take a look around, you might find some of the required skills in unexpected places. For example, influential and collaborative people can be leveraged for transformational skills, while technical skills may be coming from the business community. There is a wide variety of skills and skill levels across each of transformational, operational and technical skills.
  4. Transformational and operational capabilities are critically important; too many organizations focus purely on technical skills.

She showed an ideal BPM organization:

  • A business process competency center (aka COE) reporting to an executive steering committee, and containing a business process champion, business process director, business process consultants, business process analysts and business process architects.
  • An enterprise architecture program office, also reporting to the executive steering committee (not IT), working together with the BPCC.
  • The process owner, who is responsible for improving business processes related to the corporate strategy.
  • One or more BPM project teams, informed by the BPCC, and including an executive sponsor (linked to the process owner) and a BPM project manager.

The most critical roles are the process owner (a senior businessperson responsible for the end-to-end process performance), the business process director (business or IT background, but with a blend of all skill types, responsible for leading the BPCC and ensuring its adoption throughout the organization), the business process architect (business or IT background, a transformational role that liaises between EA and BPM, and establishes BPM governance and standards) and the business process analyst (business or IT background, responsible for modeling, designing and documenting processes).

She also defines a business process consultant as a senior person who can fill competency gaps in transformational, operational and technical skills; although I often work in the business process architect role for clients, this is probably a better description of what I do, as much as I dislike the word “consultant”.

She walked through five scenarios for how BPM is used in organizations, outlining some tips and pitfalls for each. For example, in the “visualize and rethink the process” scenario that fits into the category of using BPM for standardization and manageability, she mapped out the key skills required from each of the roles, such as process modeling for the BP analyst.

She finished up with some best practices for hiring and managing BPM resources, including:

  • Overhire, since senior, experienced people can play multiple roles
  • Establish decision guidelines so that it’s clear which types of changes need to be approved by whom
  • Align to key business goals
  • Leverage executive influence to get things done expediently

Overall, some good pointers for any organization implementing BPM.

2 thoughts on “Operational, Transformation and Technical Roles for Successful BPM Projects

  1. That “ideal” organization’s model is pretty good. Usually see multiple individuals wearing multiple hats in those roles. As you’ve stated, that senior person “consultant” usually there bridging the gap on several of the roles. That “shortage of skills” aspect I suppose.

    Truth be told, I’ve only seen anything approaching that model once so far, even with all the sites I’ve been in to.

  2. Really interesting to hear Patrick’s comment that he’s seen only one example that fits with that model! A lot of work to be done to strive for that ideal it seems.

    Would be really interested to hear more about exemplar case studies!

    Also interested to note that whilst IT backgrounds seem to be important, that IT as a function appear to be a little left out of BPM excellence. Does anyone have any thoughts as to why this might be?

Leave a Reply