In my last article, I introduced the importance of understanding the HR system and putting that into the context of using HR data to manage identities. This is a big challenge because while the HR system is a technology, it is rarely managed by IT â€“ more typically it is managed by an HR-owned administration team. And, since there are so many legal restrictions on HR data (from privacy laws to payroll laws to labor laws), identity management teams may find their HR contacts to be reticent to share information, offer integration capabilities, or change anything in their system to accommodate identity management.
This underscores the importance of engaging in this conversation now. Large organizations often find it may take months to build the inter-team relationships and map the data.
So letâ€™s start at the beginning of the employee lifecycle â€“ new hires.
But before we begin â€“ was that HR system, or systems?
I keep using the term â€œHR systemâ€ implying that there is only one. The reality is that many large organizations have more than one. Worse, organizations that have multiple HR systems donâ€™t always have multiple instances of the same product â€“ they actually have different products.
If you find yourself in the multiple HR system boat thereâ€™s actually an organizational decision that needs to be made, and it will depend on HRâ€™s technology roadmap: should identity management be integrated with all HR systems, or is there any plan to consolidate the HR systems?
The rest of this monthâ€™s articles should apply to the HR system(s) that will be integrated with identity management. If there are multiple systems, hopefully theyâ€™re set up kinda sorta similarly so that thereâ€™s at least a lot of reuse in the processes and data mappings.
What about recruiting?
Something else to consider: are job candidates tracked within the HR system, or is there a separate recruiting system? If itâ€™s separate, does it interface with the HR system?
More on this in a minute.
Some companies track their non-employees through the same HR system as employees. Others have a separate database. Still others have nothing.
If your non-employees are tracked through the same HR system as employees, consider if itâ€™s easy enough to include non-employees in the first round of effort, or if itâ€™s best put off for a release 2 effort.
If there is a separate database, it should definitely be a release 2 effort. If thereâ€™s no repository, this is a can of worms that weâ€™ll discuss later this year â€“ leave it alone for now.
Getting back to new hires
Getting a new user set up can be pretty complicated â€“ computer, access, cube/office, desk phone, wireless device(s), badgeâ€¦ If there is a standard request process, itâ€™s at best a long consolidated form to fill out and at worst a ton of phone calls. There is added complexity from things like:
- Knowing the correct spelling of the new personâ€™s name, as well as their preferred name(s)
- Knowing exactly what access they need
- Knowing what â€œthingsâ€ theyâ€™re entitled to (do they get a cube or an office? laptop or desktop? buy the computer new, or use the one that was turned in by the previous employee? cell phone or pager?)
Submitting new user requests is a time-consuming process that can waste cycles for others if the wrong things are requested. Having new users sit around and wait for their stuff (either because a request didnâ€™t get submitted soon enough or because the wrong request was submitted) is also a waste of time â€“ and money!
As such, new user provisioning is a great opportunity for automation â€“ auto-provisioning what can be auto-provisioned and auto-assigning tasks to teams for whatever manual provisioning needs to be done.
How much auto-provisioning and auto-assignment of initial access and equipment can be done for new hires will depend on how much information can be made available to identity management on or before the personâ€™s first day of work.
Is the employee entered into the HR system on or before the first day of work?
If yes, great! When exactly?
- If itâ€™s as soon as the employee accepts the offer, thatâ€™s ideal â€“ normally that will be enough time for all manual tasks to be completed comfortably.
- If itâ€™s on the first day of work and the employee is expected to go through some sort of orientation, the teams that do manual provisioning may have to scramble, but thereâ€™s still an opportunity to get initial access and equipment provisioned before the user needs them.
If no (or it happens on the first day of work but the employee doesnâ€™t go to orientation), there are two options:
- Create a new (or use an existing) request process that will allow identity management toÂ manually receive the new userâ€™s information, and let the workflows kick in from there
- Consider leveraging the recruiting system (whether itâ€™s a module of the HR system or a separate system) to get the information sooner. Since identity management will need to know some information that does not normally pertain to HR, it might also be beneficial to look into adding some fields that will facilitate auto-provisioning, like what the userâ€™s cube/office or phone number will be.
Both options have their pros and cons:
- Option 1 is easier to set up, but it requires manual intervention from the end-users submitting the requests, which can be error-prone. It also results in orphaned accounts in identity manager that then need to be linked with the corresponding HR record. The linking process can also be error-prone, with potentially disastrous results.
- Option 2 takes a lot more up-front effort, both in terms of adding fields to the recruiting module or system to accommodate identity management needs (if applicable) and certainly in terms of interfacing the recruiting module/system to identity management in addition to the HR system to automate the linking process. Updates may also need to be made to the interface between the HR system and the recruiting system, if theyâ€™re separate. On the other hand, the accuracy of linking is guaranteed, and user error and time are eliminated from the process.
Of course, Iâ€™m omitting a big piece here â€“ for any of this to work, there need to be roles and rules created for identity management to ensure that the right auto-provisioning and auto-assignments happen. But thatâ€™s next monthâ€™s topic. 🙂
To be able to manage new hires in an automated fashion, some pre-work needs to be done with the HR system and administrators, as follows:
- Build the relationship, but expect resistance â€“ HR functions are so highly regulated that they wonâ€™t jump at the opportunity to change their processes or data
- Determine if identity management will interface with one HR system, or several
- Determine if employees are entered into the HR system in a usable timeframe for auto-provisioning/auto-assignment
- If not, determine how the recruiting module or system could be leveraged to fill the gap
- Decide if non-employees could and should be handled as part of the initial implementation, or if they come later
- Determine if itâ€™s possible to add fields to the recruiting module/system that can drive auto-provisioning/auto-assignment
In the next article, weâ€™ll cover the largest and most complex part of the employment lifecycle: transfers.