Building Process Skills To Scale Transformation

Connie Moore (or “Reverend Connie” as we now think of her 😉 ) gave a session this afternoon on process skills at multiple levels within your organization, and how entire new process-centric career paths are emerging. Process expertise isn’t necessarily something that can be quickly learned and overlaid on existing knowledge; it requires a certain set of underlying skills, and a certain amount of practical experience. Furthermore, process skills are migrating out of IT into the business areas, such as process improvement specialists and business architects.

Forrester recently did a role deep dive to take a look at the process roles that exist within organizations, and found that different organizations have very different views of business process:

  • Immature, usually smaller organizations with a focus on automation, not the process; these follow a typical build cycle with business analysts as traditional requirements gatherers.
  • Aspiring organizations that understand the importance of process but don’t really know fully what to do with it: they’ve piloted BPM projects and may have started a center of excellence, but are still evolving the roles of business analysts and other participants, and searching for the right methodologies.
  • Mature organizations already have process methodologies, and the process groups sit directly in the business areas, with clear roles defined for all of the participants. They will have robust process centers of excellence with well-defined methodologies such as Lean, offering internal training on their process frameworks and methods.

She talked about the same five roles/actors that we saw in the Peters/Miers talk, and she talked about how different types of business process professionals learn and develop skills in different ways. She mentioned the importance of certification and training programs, citing ABPMP as the up-and-coming player here with about 200 people certified to date (I’m also involved in a new effort to build a more open process body of knowledge), and listed the specific needs of the five actors in terms of their skills, job titles and business networks using examples from some of the case studies that we’ve been hearing about such as Medco. The job titles, as simple as that seems, are pretty important: it’s part of the language that you create around process improvement within your organization.

Process roles are often concentrated in a process center of excellence, which can start small: Moore told the story of one organization that started with four developers, one business analysts and one enterprise architect. Audience members echoed that, with CoE’s usually in the under-10 size, and many without a CoE at all. You also need to have a mix of business and IT skills in a CoE: as one of her points stated, you can do this without coding, but that doesn’t mean that a business person can do it, which is especially true as you start using more complete versions of BPMN, for example. There’s definitely a correlation (although not necessarily causation) between CoE and BPM project success; I talked about this and some other factors in building a BPM CoE in a webinar and white paper that I did for Appian last year.

She had a lot of great quotes from companies that they interviewed in their process roles study:

“These suites still required you to have [a] software engineering skill set”

“The biggest challenge is how to develop really good process architects”

“They [process/business analysts] usually analyze one process and have limited ability to see beyond the efforts in front of them”

“Process experts are a rare type of talent”

“We thought the traditional business analyst would be the right source, but we were horribly disappointed”

A number of these comments are focused on the shortcomings of trying to retrain more traditionally-skilled people, such as business analysts, for process work: it’s not as easy as it sounds, and requires significantly better tooling that they are likely using now. You probably don’t need the 20+ years of experience that I have in process projects, but you’re not going to just be able to take one of your developers or business analysts, send them on a 3-day course, and have them instantly become a process professional. There are ways to jump-start this: for example, looking at cloud-based BPM so that you need less of the back-end technical skills to get things going, and consider alternatives for mentoring and pairing with existing process experts (either internal or external) to speed the process.

Leave a Reply

Your email address will not be published.

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