October 21

Identity Management Series – Termination and Transfer Gotchas Part 1: Transfers and Multiple HR Systems

In the previous series, we started prepping for the key workflows that make an IAM implementation worth the cost and effort. Implementing workflows effectively is critical to achieving the desired value in terms of time savings and effort/cost reductions. It also gets the organization excited about IAM and makes them willing to keep maturing the implementation and expanding its use.

To have truly effective de/provisioning workflows, however, we need to take a closer look at terminations and transfers. There are some “gotchas” that – while rare – can cause angst and give the IAM program a significant black eye. Namely:

  • Handling cross-HR system transfers
  • Transfers within a department
  • Termination of employment vs. termination of access

This series focuses on these gotchas and shares strategies to avoid them.

The reality of multiple HR systems

It’s not uncommon for large organizations to have multiple HR systems – especially when there has been merger & acquisition activity. It takes time to convert new parts of the company to the standard tools, and in some cases it never happens. Worse, multiple HR systems doesn’t necessarily mean separate instances of the same system, but possibly different versions of the same system, or even different brands of HR system.

Clearly, dealing with multiple HR systems – whether they are the same version, different versions, or different brands – adds a level of complexity to the IAM implementation because HR is such a critical interface. This situation can be handled in a variety of ways – some more feasible than others.

Options for handling multiple HR systems

The best solution (but also the least feasible in many cases) is to consolidate the HR systems in preparation for the IAM implementation. This may be a situation where IAM can help HR – if this is a desired HR project — but they might need help convincing management to go for it. The cost savings that will be achieved in the IAM implementation by having a single HR system may give the consolidation project just the push it needed (aside: this is an opportunity to increase “security” with a focus on operational efficiency).

If consolidation is either not possible, or likely too distant to be useful, consider keeping the systems that will be consolidated (and their employees) out of scope of integration with IAM, and focus only on the system that everyone else is consolidating to.

In this case, the non-employee management workflows described previously can help manage the out-of-scope employees until they are brought into the master system. Some modifications might be needed, but they tend to be straightforward.

For example, ensuring that the user input form has one or more appropriate user types to accommodate out-of-scope employees. It’s best to have one entry for each out-of-scope HR system to be able to easily identify which employees come from which system.

Another option is to manually enter and manage out-of-scope employees in IAM until the HR automation comes into play. This is the least desirable alternative, but it’s better than nothing, especially if the non-employee management workflows haven’t yet been implemented.

Dealing with cross-HR system transfers

Ultimately, the problem with multiple HR systems is properly recognizing and handling inter-system personnel transfers.

Typically, when an employee transfers from one HR system to another (and the systems don’t communicate), they show up as a termination in the first system, and a new hire in the second system. From a customer service perspective, there’s nothing worse than terminating someone’s access when they’re still with the company – especially if it happens to be a senior executive.

The best way to handle this is actually to request a modification in the HR systems.

HR systems typically contain reasons for termination – add one called “transfer to another HR system,” or even add one for each additional HR system (e.g., “transfer to HR system x,” “transfer to HR system y,” etc.). We’ve discussed that HR teams may be reticent to change their system – this is where the past relationship building with the HR team can really come in handy.

Having a flag to indicate that a terminated user is actually a transfer can really help – identity manager can be configured to read and understand that flag, and trigger a transfer process/notification instead of a termination. Even if handled manually by the access services team based on HR reports, this flag will alert them that special processing is required.

If changing the HR systems to add a flag is not an option, then a clear process must be established with the HR representatives that process terminations. Access teams must be notified when an inter-system transfer is about to take place. The access services team will also need to document a process for receiving and handling those requests, especially if it entails over-riding or pre-empting automated processes. Care in coordinating these two teams pays large dividends.

A special case of a special case

Transferring from employee to non-employee is one more special case to consider. This can happen if an employee retires or is laid off but is retained as a contractor, or when a portion of the business is outsourced so the employee becomes a non-employee. In most cases, the user’s job function – and access – stays the same. The problem is that they are terminated in the HR system.

The solution to this is similar to the solution for handling inter-HR transfers. Ideally, the HR system can be modified to include a termination reason of “converted to non-employee.” The other alternatives described above can also be applied.

Looking ahead – unique employee numbers

Another key challenge of multiple HR systems is unique employee numbers.

Separate systems may use the same numbering scheme, which could result in different employees in different parts of the organization having the same employee number. When consolidation occurs, this is a problem – both in the HR conversion, and the linking with identity manager.

If the IAM implementation begins before the HR consolidations are complete, it is critical for the IAM team to work with the HR consolidation project to obtain the mapping of employee numbers from old system to new in advance. Once the employees are converted in HR, their employee numbers can be bulk-updated in IAM, which will allow for smooth automated linking.

If out-of-scope employees are manually maintained in identity manager for any length of time before the HR feed takes effect, some cleanup will be needed – undoubtedly employees will have terminated or transferred without notice – that’s the nature of manual processing.

It’s important to fully clean up the users before attempting to update the employee numbers and linking them to HR to ensure a clean linking.

In the next segment, we’ll take a look at transfers that occur within a department.


Tags


You may also like

Are you using frameworks properly?

Leadership and communication are actually layers, not levels

Comments are closed.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!