Posted by Derek Miers on December 17, 2010
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).