Understanding Roles And Responsibilities In BPM

Having just finished the dynamic case management Forrester Wave™ — it will probably appear in mid-January — I was struck by the variation in the approaches between the vendors; especially how they represent the organization, and the variety of wrinkles associated with work assignment. This was not so much related to an individual case management vendor, but it became apparent when you looked across the products. And that got me thinking and discussing with colleagues, customers, and vendors around the challenges of realistically supporting the organization as it looks toward BPM generally. Of course, there are many different issues, but the one I want to focus on here is around organizational structures, roles, skills, and responsibilities.

The central issue I want to highlight is one that many folks just do not see coming in their BPMS and dynamic case management implementations. Very often, there is only a loose concept of “role” within an organization. When the word “role” is used, it is usually equated to an existing job title (part of the organization structure), rather than responsibility (at least initially). It is further complicated by the fact that within a given job title, there are usually wide variations in the skills and expertise levels of those who work in that area. And while this is not a problem where people manually coordinate their work, when it comes to automating work routing (to the most appropriate person to deal with a given work item or case), there are often major complications. 

The problem with using the job title is that it is a poor approximation for the richness of the real situation found in many firms. Job titles alone do not help you deal with responsibility for action, versus accountability and control. Moreover, the structure of job titles are often not adequately represented in the LDAP or Active Directory mechanisms of the established systems environment. It is not uncommon to find that sysadmins have grouped everyone into just 3 roles — super users, managers, and workers. 

And when you do get to the BPMS, there are all sorts of implementations — where the vendor uses the word “role” but then means entirely different things by it. In some systems, it is really a representation of the organization structure (an abstract model of the org structure). Others use role to represent a simple work list; others use an entitlement system to enable access to these shared queues. Indeed, every vendor makes it up for themselves (I often argue that the product developers views on organizational are reflected in the tool).

So the question becomes how to get around these sorts of issues. As you drill in to the subtleties of the work situation, I find it is much better to focus on the responsibility side of the equation (rather than a job title). That way, the binding to the appropriate actor can be determined much later (at runtime, if the process is automated). Also, it helps you dodge the organizational politics earlier on in the BPM project as people in affected jobs won’t necessarily read into the model that their job is under threat.

Some of you will know I am a fan of Role Activity Diagrams (RADs), which provide a rich way of representing responsibilities in processes. Rather than merely modeling the order of the steps in a procedure and, potentially, the assignment of a step to an individual role (through swim lanes), RADs allow the BPM team to model how roles collaborate toward a common goal. Potentially, a RAD might contain fragments of several processes at once. Effectively, the team is modeling responsibilities and their coordination, rather than just who is holding the baby at any point in time. Furthermore, RADs allows the team to take a more customer-centric view. While a BPMN diagram is usually needed to support the implementation in a BPM suite, they have only limited utility when it comes to helping workers understand who does what, with whom, in support of the goal. The best reference for this technique is Martyn Ould's book, Business Process Management: A Rigorous Approach.

In this blog post, I tried to highlight one approach that I have found useful — but I am more interested in hearing about your own experiences and approaches (so chime in with a comment if this problem resonates).

Comments

BPMS/DCM Need WFO

Hi Derek,

I also found this to be the case during the 2010 BPM Suite Wave (http://bit.ly/dhCSzc). My take is that BPM suite and dynamic case management vendors need to provide better workforce optimization (WFO) capabilities (i.e., skills-based routing) in order to deliver richer context for roles and responsibilities.

Given the current employment situation, many people are doing the job of three or four different roles, and you're right a simple job title is not enough to cover the converging and overlapping responsibilities that must be filled by a single knowledge worker.

One of my predictions for 2011/2012 is that we will see WFO vendors (such as Verint and Nice) wade more into the BPM space and we will also see BPM suite vendors beef up their workforce optimization / skills-based routing functionality. We're already seeing BPM suite vendors like TIBCO move in this direction.

Cheers,
Clay

Enterprise Hierarchy vs Process Role

Hi Derek,

Ha! It's true - you are a fan of RAD. I remember your referring me to Martyn's work several years ago, and agree with your premise on RAD. You've been consistently promoting Dynamic Case for quite awhile.

In practice many conflate a position/title that articulates rank in hierarchy, from role, something you might be asked or required to do. The latter is far more fluid. Users might perform roles not normally associated with their position/title, and different lines of business might want to involve people in ways outside standard hierarchy definitions.

We've separated position(s) in group(s), set by enterprise, from roles on process, set by business owners, application designers, and users (delegation, collaboration, etc.). Positions defines File Server rights, while roles define participation. In this way you can respect enterprise concerns, while providing flexibility to the business.

Look forward to reading your DCM Wave.

Happy Holidays!
Dave