The Oracle Australia and New Zealand Middleware and Technology Blog.

Friday, February 22, 2008

Can your HR system be your central source of truth

If you have had any involvement managing employee's within IT, either in a File System, Database or a Human Resource Management Systems (HRMS) then no doubt the issue creating and deleting users has raised its head.

I have seen organisations that have such complex and manually intensive processes to bring on new employee's and grant access that it can take 6 weeks before that employee has access to all the relevant systems to simply be productive. Now you have the scenario of a new employee, eager to make his or her mark on the world. Wanting to show they mean business, only to be hamstrung by inefficient process's that stop them simply working. Let alone being productive.

The inverse of this is much worse, what happens if you fail to remove access to employee's when they leave an organisation. Could they still get access to critical systems, receive email, check the current accounts or download the latest marketing plan. If you think this is urban myth its not, in my career working for IT vendors i have personally experienced this. Of course i wont name the vendors but both are very established and have security credentials. Vendor A failed to remove me from a system of employee's that received Qantas Club Membership and kindly continued to pay for this membership after i left the vendor. Vendor B actually started paying me again after leaving the company for nearly a year, the outcome here was that my details didn't get removed from all systems involved with payroll. An upgrade on these systems resulted in Vendor B generously adding me to the payroll again. If only all past employee's had such generosity. These accounts that are not cleaned up when an employee leaves are often referred to as orphan accounts.

I am amazed time and time again when going into organisations how this problem isn't addressed. It is either deemed not an issue, to expensive to fix or more than likely they don't event know the problem exists. From experience i find that if an organisation has X employee's and that is in the several thousand. More than likely the number of orphan accounts is in the realm of 3 times X.

So what can you do to fix this ?, several options include
  • Review your manual process's
  • Implement a provisioning system - often referred also as Identity Management
  • Install an audit tool that will periodically review the accounts and identify the suspect accounts

One of the most elegant ways to rectify this is within HR. After all what department has a better grasp of who is employed and who isn't. HR employee's however don't have the admin skills to manage users within all the various systems. But it is possible to make HR the single source of truth. Then point your Provisioning system to the HR employee table. Once someone leaves an organisation and is deleted from the HRMS system then a automated workflow can be commenced that will trigger the provisioning system to start deleting all instances of this user.

The inverse of this can occur with employee's commencing, once they are identified within the HRMS system as commencing employment. The automated workflow can be kicked off, the provisioning system can identify what type of role the employee has and create the basic set of accounts so that person can be fully productive from day one.

Let me know your horror stories, or indeed if you have tried to set the HRMS system up as lead for provisioning and de provisioning.

Cheers - its 5pm on a Friday and "beer oh clock"

1 comment:

Steve said...

Yes Carl,

I have implemented two 'User Provisioning' systems where the HR employee is the source identity for events for provisioning and deprovisioning. Both implementations were when Oracle's Identity Management Suite was deemed by the project team to, at the time, be insufficient to meet the client's needs. I've also seen the Identity Management suite used for RBAC (role based access control) at a large retail customer here in Australia.

I've seen some basic RBAC implemented using HR - mainly employee type e.g. Employee, contractor etc, to provision a set of responsibilities like SSHR, with other job related responsibilities still added manually as required.

One of the biggest barriers to a full RBAC using HR e.g. using positions or jobs to control provisioning of responsibilites is the perceived overhead of maintaining the mapping between the positions and the sets of responsibilities. The other barrier being the corporate (usually HR or payroll) will to consolidate the positions/jobs to make that mapping maintenance an easier task to manage. (this consolidation can be at odds with the requirement of having the distinction between the roles necessary to provision fully an employees responsibilities). The use of 'secondary assignments' with different positions/jobs complicates this model still further while simultaneously giving more opportunity to help define the access requirements of any one person.

The provisioning and deprovisioning through user records and also thus now directly into an LDAP compliant Directory, where applicable, provides for a smooth end to end process and one where there are less chances of access events not being triggered as you alluded to in your post.

We have successfully implemented these solutions using Oracle 10gAS at companies in Australia with up to 35,000 employees and many, many staff and contractor movements each day.

These clients have typically used the resultant OID repository to then feed into an enterprise provisioning system which provides for provisioning potentially across all other enterprise systems e.g. n/w and other apps and tools i.e. outside the eBusiness Suite.

In summary, our experience is that HRMS systems provide the key structures to define the driving events of an identity management system.