Know the pitfalls of an HCM system built from acquisitions

Buying a do-it-all HR suite from one vendor does not always make a paradise of ease of use and seamless integration. The list of potential challenges is long, so be forewarned.

Human capital management systems vary in features, functionality and ease of use, but what people don't always...

expect are the challenges associated with administering an HCM system built through acquisitions.

When evaluating a new system, one consideration may be the benefit of selecting a vendor who can meet all of your current needs rather than having to use multiple vendors. However, just because one vendor can meet all your needs doesn't mean that all the modules in its HCM system will look and feel the same. Some vendors try to speed up the software development process by acquiring other companies to get modules that complement their existing offering.

While this strategy works well for the vendor, it may present the following unexpected challenges for the purchaser.

Inconsistent user interfaces. One of the most noticeable issues with acquired modules is the difference in the UI. Initially, the look and feel of the module will likely be different for both the employee and the system administrator. Over time, vendors may update the UI to make the user experience more consistent with other modules for employees, but the experience for the system administrator often remains different.

The need for plug-ins. The new module may require plug-ins that are not currently used by existing modules, such as Adobe Flash or Microsoft Silverlight. Similar to the UI, these differences are often resolved in a release or two for employees, but not for system administrators, who will continue to need the plug-ins.

Interfaces. One benefit of going with a single vendor is avoiding the need for interfaces that allow the modules in the HCM system to communicate. However, the reality is that acquired modules often have their own databases, and therefore the need for an interface may remain.

Updating the acquired modules to use the same database as the original modules usually takes a significant amount of work that may reap little benefit, and therefore is often given lower priority behind money-generating features. While interfaces typically work seamlessly, they are not perfect and may fail from time to time.

Multiple development tools. Many HCM systems provide users with the ability to update forms and workflows, among other things. While existing modules may be set up to use the same tools, acquired modules will likely have their own. This will require the system administrator to learn multiple applications to maintain the HCM system.

Roles set up in multiple places. Like many other administrative processes, setting up and maintaining roles may be done in multiple places in the software. Changing this is a big task for a vendor, and given the sensitive nature of HR data, one that may not be resolved until a future release.

In this case, the system administrator may have to maintain roles in two or more places, which requires them to learn how each module works to ensure permissions are set up correctly.

Legacy functionality. A vendor may acquire an HCM suite for one specific module and decommission the remaining modules. The vendor can work to remove all references to the decommissioned modules, but it will take time, since the references exist in numerous places.

For example, you may go to the help system and find references to features that are no longer applicable, or see settings related to modules that are no longer sold. While these may seem like small annoyances, you may end up wasting time investigating features that are no longer available.

Multiple usernames and passwords. While this may be an issue that's addressed early after an acquisition, it is not uncommon for there to be issues for years. The initial changes may fix many of the issues with username and password differences between modules, yet other issues will likely remain. If you have a large workforce, the result can be a large volume of support tickets and a lot of time spent by the system administrator.

Rebrand release. Once a vendor acquires a module, it may want to rebrand it to match its own brand. For desktop applications, this may include the location where files are installed, registry keys, the install and so on. Hosted applications may have similar needs, but because the application is not installed locally, the changes may be more cosmetic, such as logos, fonts and resources that need to be updated.

The downside is that this often leads to a release with limited new functionality because of the effort spent on rebranding.

Rebuild release. At times, the acquired module may have to be rebuilt so that it can be integrated with existing HCM system modules. This can happen, for example, when the acquired module requires a plug-in or was developed in a different programming language. It is often a huge undertaking for the vendor, but offers little in new features and may break existing functionality.

Different naming conventions. When incorporating a new module into an existing system, you may find that similar features and functionality use different terms. The system administrator and, potentially, employees will have to learn to differentiate the meaning of terms when going from one module to the next. An example of this might be the use of terms such as department, division, site and organization.

Multiple system administration sections. Often, acquired modules will have their own system administration section, separate from the one used for all the other modules. While this likely won't impact users, it will almost certainly affect system administrators. Since this will only affect a small group of employees, it will likely be low on the vendor's list of issues to resolve.

Localization challenges. Localizing software for different regions of the world can be a daunting task in any system, but adding in acquired modules makes it even more difficult. The HCM system administrator will have to go into many administrative tools to specify all of the areas that require localization.

Additionally, changes implemented for some modules will have to be duplicated for the acquired module for the foreseeable future. For example, localizing a string, like Employee, will have to be done more than once if the system has multiple administration pages.

URLs. While this might not be one of the bigger issues, often, software-as-a-service modules that are acquired will maintain their old URLs for multiple releases due to the complexity and small return on investment in changing it. IT will have to ensure that the URLs get added to the trusted sites list, which may result in issues if employees access the HCM system from home.

Technical support. Just as the system administrators need to learn the ins and outs of an acquired module, technical support must also learn how the module interacts with other modules. Be prepared for transferred phone calls, long pauses and challenges as you try to integrate new modules with the ones acquired by the vendor.

Reporting and analytics shortfalls. Because acquired modules often have their own databases, integrating reports and analytics may be hard. The existing modules may have been built to look at one database and one configuration.

While it may be possible for the vendor to incorporate other databases, the work may not be accomplished quickly and, perhaps more frustratingly, it may be done over multiple releases, providing only a portion of the functions you need.

Training challenges. Teaching employees how to use an HCM system can be difficult enough, but adding in a module that does not look or behave like other modules may add to the confusion. Training and documentation will have to be clear and readily available to help employees adjust to the differences.

While none of these individually are reasons to avoid a particular suite, each should be considered when documenting requirements and sourcing an HCM system.

Dig Deeper on HCM implementation