Identity Management Series – HR as a Source of Record Part 5: Reliability and Accessibility
Weâ€™ve now gone through the employeeâ€™s full lifecycle and discussed how to interpret and manipulate HR data to facilitate automation in identity management for new hires, transfers, and terminations. We wrap up this this month with a focus on the accessibility and reliability of HR data.
At a minimum, you should know what to expect (or not) from the HR system, and how to get to the data that identity management will need. In some cases, changes may be needed to the HR system to really make identity management work.
Iâ€™ve touched on reliability already in the context of new hires, transfers, and terminations. At a minimum, the identity management team needs to be clear on how quickly (or not) an employment event gets entered into the HR system. Questions also need to be asked about how quickly administrative events get entered into the HR system. For example, in August, weâ€™ll discuss user recertification. In order to automate user recertification, accurate line manager information must be available for each employee at any time. Does said accuracy exist?
Any problems with the reliability of HR data are not the problem of the identity management team. Actually, it becomes their problem, but itâ€™s not theirs to fix.
This is where the identity management team may need to influence (or guide) HR through the process of improving their own processes. This could be tough for a variety of reasons, but mainly because there wonâ€™t be any intrinsic incentive for HR to optimize their system in ways that donâ€™t benefit them directly.
The good news is that in most cases, the HR system will be good enough for starters, and a lot more work will be needed on the identity management side to fully use what the HR system can initially offer.
If there is executive commitment to the maturity of identity management, there may come a time when identity management becomes limited by the HR system. The beauty here is that when identity management takes hold, various business units will start lining up to leverage identity management to do one thing or another. When they find out that identity management canâ€™t meet their requirements because the HR data isnâ€™t good enough, the issue of HR data reliability stops being the problem of the identity management team and starts being the problem of HR.
So my advice â€“ donâ€™t try to fix this problem from the get-go. Get your own house clean, and let others fix HR for you later.
Even if the HR data exists, where is it?
If the interface between identity management and the HR system has to go looking in every field and every table in the HR system to find what it needs, itâ€™ll make for one complicated interface. More likely, the interface will rely on one or more audit tables to alert it when something has changed on the HR side. But does the audit table track everything that changes? Hopefully, the answer is yes, but definitely ask the question. I once discovered the hard way that the answer was no. Itâ€™s important to have the HR team confirm that every change made hits the audit table â€“ including bulk loaded data.
Updating the requirements list
This monthâ€™s exercise should feed the requirements list with a few items:
- After identifying which HR system(s) will be interfaced with identity management, identify which protocols can be used (this may have already been done back in January, but Iâ€™m repeating it here just in case)
- If there are plans to interface with the recruiting system/module, identify those protocols, too
- List which HR tables contain information thatâ€™s needed by identity management, and begin laying out the data map
- Specify any requirements that identity management will need to address based on the reliability of the HR data
This monthâ€™s exercise was primarily to build a relationship with the HR team that administers the HR system that will integrate with identity management (remember, there could be multiple systems, but for the sake of clean writing, Iâ€™m trying to keep it simple). The goal of the relationship is to:
- Build an understanding of how the HR system works and how identity management will leverage HR data to automate provisioning and task assignments for new hires, transfers, and terminations
- Understand the potential limitations of the HR data and feed that into additional requirements for identity management
- Clarify the nuances in terminology and data usage between the HR system and identity management.
Next month, weâ€™ll talk about creating access roles and rules to populate into role manager, and do a permissions cleanup.
How can I help?
Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.