Will Your New HR System Run Itself?

The system implementation was successful, everything is working fine, and initial adoption is high – is this where the story ends?

With traditional implementations, project teams are disbanded and team members settle back into their previous jobs or the next project shortly after go-live. With SaaS technology, this approach no longer works – shortly after the implementation is complete, the system vendor provides you with details of the upcoming release, expecting you to have prioritised the features you want to introduce and to have planned for any mandatory updates.

That is when the realisation sets in: “who did we say was going to make these decisions, update the configuration, manage the testing and training? IT? HR? ... The vendor?” You are confronted with the uncomfortable realization that you have implemented the technology, but you did not set up the organization to handle these changes going forward.

With modern SaaS technology, frequent releases and flexible configuration mechanisms mean that functionality improvements create opportunities for HR to service new business needs and deliver changes almost instantly. Although these features have the potential to be great assets when managed well, they can quickly become a burden without the right skills and processes in place.  HR is often the first major application to move to the cloud. As a result, HR and IT teams are frequently unprepared, under-skilled, and under-resourced to keep up with the pace of change SaaS technology demands.

SaaS technology also forces another paradigm shift: the maintenance of HR systems has traditionally rested firmly in the IT sphere; in the new SaaS world, however, HR should own the responsibility of understanding new functionality, updating of configuration, and managing workflows. IT support shifts focus to supporting data flow, system interfaces, and security needs. On-going support therefore needs to straddle HR and IT – but instead frequently falls between the chairs.

If you recognise your company in this scenario, you are not alone. The increasing prevalence of SaaS technology has made this an all too familiar situation – providing a barrier to sustainable benefits realization for many organizations. To ensure your organization realizes its full potential from these systems, consider integrating benefits realization software.

Here are a few tips to get you on track to make sure your whole organization makes the most of your new system:

Assemble your ‘A’ team early

Seize the implementation programme as an opportunity to build expertise and transfer system configuration/ support knowledge to the future HR systems support team. The implementation team members have unique access to design and configuration decisions and should be developing system expertise to avoid the need for continued, costly system integrator support. Commit internal, permanent resources to the implementation and embed effective career paths and skill development frameworks to help retain and build talent after you are live.

Organise your post go-live support team effectively

The support team will be the "guardian" of your system once you are live and key to taking advantage of new release functionality and resolving more complex user issues and requests. A clearly defined governance framework is essential – defining and distributing the support roles between HR, IT, and functional process owners.

In order to create a seamless experience for employees and managers seeking support, accountabilities, escalation routes and hand-offs need to be clearly defined between HR and IT (and within the respective functions). It is important that your support team has a clearly outlined delivery model, seamlessly embedded into existing delivery structures. Tackle any potential overlaps to avoid confusion and establish clear escalation routes to the vendor.

Although there is no one-size-fits-all model, a central HR service delivery team with global process ownership is the prevalent design choice for the system support team.  To avoid the risk of this team turning into an “ivory tower,” the business needs to be given a well-managed voice to request changes and channel demand. An effective governance and decision support framework will allow you to assess and prioritise requests, manage release-driven changes, and align with the vendor roadmap.

Ensure sustained adoption

While the more technical aspects of release management may be new to HR professionals, the accelerated adoption implications are very much in the HR toolkit. The most common set-up after go-live is to establish a nucleus of accelerated adoption expertise within the systems support team. This individual and/or team is typically responsible for the effective management of release updates and implications, the introduction of new functionality, etc. – drawing on tools and techniques established during the implementation.

Ideally, the adoption network established during the implementation is maintained to help effectively land changes across the organization. Business leaders and HR Business Partners can play a powerful role as continued ambassadors of new ways of working – building a culture of shared accountability for adoption – permeating throughout the organization beyond HR.

Be sure to track your Benefits realization

Leading practice organizations clearly define their benefits realization strategy and plan, including a compelling case for change. A case for change outlines what the new system will bring to your organization and what it means for your workforce. Once you have gone live and completed your three to six month stabilization period, you can begin to measure your benefits realization through capturing hard data on your expected outcomes.

In summary, when managed well, the HR function can achieve a fundamental transformation – focusing on true Human Capital Excellence rather than transactional execution and tactical fixes. To deliver on the benefits technology can provide, your organization needs to be equipped to run your new SaaS HR system after go live — rather than it being an unexpected twist at the end of the implementation story.