RBAC is like Communism: It sounds really great until you try to implement it,
David Griffeth, Vice President of Enterprise Identity Management, Citizens Bank at Catalyst Conference 2009.

In my previous post in this series, I covered the ROI for improvements in provisioning processes and I began to walk through the employment lifecycle to show how provisioning relates to specific employment lifecyle events. In this post, I finish my discussion of the employment lifecycle and talk a bit more about the limitation of role-based access controls.

RBAC and Communism

I didn't attend last week's Catalyst Conference 2009. However, when I saw David Griffeth's quote about role-based access control (RBAC) tweeted from the conference on Friday afternoon, I thought it captured quite nicely one of the points I'm trying to make in this series of posts. Managing access and entitlements by role gets complex quickly. It is not to say that roles aren't useful in managing provisioning, but starting with a table of events relevant to provisioning and de-provisioning is likely a better way to begin your planning. Increasingly, HR service delivery is distributed among multiple SaaS providers. Roles and sub-roles are likely to be tied to particular SaaS offerings. So lifecycle events - such as those covered in this post and the previous post - are a better starting point than roles. Build your table of lifecycle events, look at target systems, then perhaps look at whether and how roles fit into the provisioning and de-provisioning operations.

I plan on making a few posts on the topic of "talent management system provisioning." I want to cover the topic at a high-level before focusing on integration of competency content and other details.

Here, I'm using "talent management system" to refer to integrated TM suites as well as discrete TM components, such as performance management, compensation, learning management systems, succession planning, etc. "Provisioning" broadly describes processes for providing systems the data they require before they can be used productively. This data can be thought of as the "inputs" to talent management processes.

There is great variation in requirements around TM system provisioning. Requirements vary based on the particular TM components that an employer has deployed, the degree of built-in integration among components, and the sophistication of the particular employer's TM programs. However, the major categories of data of concern in TM system provisioning are:

• Organizational structures. This includes information describing an organization's sub-entities or "organization units", relationships among organization units and between organizational units and parent entities, the positions within each organizational unit, reporting relationships among positions, and the sometimes identifiers referencing position incumbents.
• Position profiles. A position profile (or sometimes "position competency model") associates a collection of competency and process accountability information with a position. A position profile includes references to individual competencies and to groups of competencies that are associated with a position. For each competency group and individual competency, proficiency levels (required or desired proficiencies) and weightings among competencies/groups can be specified.