Dodging HRIS Disasters
Paying close attention to testing, using clean data and other strategies can help HR departments avoid overspending when it comes to replacing an HR information system.
By Tom Starner
When a Wisconsin state audit bureau recently uncovered overpayments of $33 million for health- insurance premiums and retirement benefits at the University of Wisconsin, it naturally caused quite a stir. So much so that last week a state legislative committee held hearings on how implementing a new HR system in April 2011 could have led to such a snafu.
Basically, the University's new HR system overpaid $15.4 million for health insurance premiums; $8 million of it covering 924 employees who had been terminated. UW's HR system overpaid another $17.5 million into the state retirement system, according to a fiscal 2011-2012 audit done by the state's Legislative Audit Bureau.
While the good news is UW has recovered all $17.5 million in retirement funds, it is still trying to recover $8 million in those health insurance premiums (as of October, it had collected $228,000, according to the audit report. UW administrators said they were "working aggressively" to recoup the rest of the money).
As they sort out the mess in Wisconsin, the question is how could it happen? HR experts say that while they are surprised that the amount was so high and the time to uncover it was so long, there likely are a few reasons for it happening -- all of which can be avoided with the proper approach.
"Most of the time, with new HR systems implementations, financial headaches come in the form of cost overruns due to the inability to lock down scope and other factors," says Kim Billeter, global Workday practice leader at Towers Watson in Atlanta. "You really need to focus on simplifying and streamlining business processes to fit into the configuration, so you can easily anticipate what might happen downstream."
While Billeter could not speculate about specifics in the UW case, she said a lack of adequate testing time could be one culprit.
"When implementing an HR system, don't shortchange yourself on testing," she says.
Also, she explains, you need to be sure what you are testing, so you can ensure it's actually working properly and data integration has been done right. There is always a chance data sets may not be reacting the same as they did with initial setup of the legacy system being replaced.
Billeter also advises that an employer make sure there is a solid governance plan in place, so that requirements are set and the scope is locked down as you get into the project.
"Naturally, much needs to be done ahead of time," she says. "You need to do full assessments of impact, usability, etc. You also need to have a good pulse on organizational readiness to take it on, involving managers and all broad stakeholders.
"In the Wisconsin case, I am surprised it got to that amount without someone noticing something was going on," Billeter adds. "In any HR system implementation, things can go wrong. But those are very large numbers."
April Escamilla, San Francisco-based director of product management at SilkRoad, which offers an HRMS called HeartBeat, says configuring the workflow to adapt to an organization's policies and procedures is critical. In essence, changing over to a new HR system is the time to improve, validate and confirm every business process.
"That includes everything, from how you approve changes to benefits to how you process a termination," Escamilla says. "There are smart ways to enforce and improve business processes, and that should be part of an overall best practices approach."
Escamilla says creating workflow processes with role-based security will ensure that the right people view and approve the right things. Also, for benefits administration, a good HR system should provide automation directly to carriers and other vendors. That way, as soon as an employee enrolls in a plan, or is terminated, the data is sent to the carrier.
"If it is a termination," she says, "the data is sent and it's done."
Apart from automated enrollments and terminations, bad historical data is also a likely culprit when it comes to situations such as the one in Wisconsin.
"You can spend millions to implement payroll and benefits systems, but if you don't look into the HR processes and garbage data, for example, you could find yourself in a similar boat. Software will not solve all of your problems," she says.
Justin Tuitt-Campbell, a Toronto-based senior vice president of the product development group for Xerox Services HRO&S business, says there are many times during the data conversion that information is in different formats in various places, and the effort to convert/gather that data is always underestimated.
He also cites what he calls the "big bang" approach, meaning that typical HR implementations are 12-to 24-months long, which is way too long.
"This length of implementation gets the problems of yesteryear solved; however, it doesn't address current business problems," says Tuitt-Campbell. "Agility is key."
Also, excessive customizations can sometimes make it difficult to let go of old ways of doing things, which in turn leads to trying to retrofit the new system with the old process. The solution, he says, is to upgrade processes at the same time as updating HR systems to take advantage of new industry proven methodologies.
Next, he mentions client resource availability as a potential danger area, explaining that HR systems involve complicated conversions/implementations that require an in-depth knowledge of the internal process.
"Assumptions are made that the vendor will figure out the 20 years of history and change management - this is not always the case," he says.
Finally, Tuitt-Campbell lists "scope creep" as another potential hazard.
"There are must-have features and nice-to-have features," he says. "Many clients spend too much time on the nice-to-haves, and because of time restraints they end up sacrificing some of the must haves."
David Ossip, Toronto-based president of Ceridian Dayforce, says cost overruns or overpayments usually mean an implementation has taken too long or an organization is buying perceived functionality but does not really know what it is getting. Typically, he adds, you see those issues with a more traditional license-based based delivery, where you purchase the software, provide a list of requirements, build the system, test it and try it out as a pilot.
"Enterprises have moved away from that license-based approach to cloud-based solutions," he says. "With that older approach, clients often believe they are buying functionality, but in fact they may be buying the wrong feature set. With cloud-based platforms, clients can try it and if don't like it, they can alter or cancel it. That already provides a natural hedge against things going bad on the back end."
Ultimately, Ossip says, the client is responsible for testing what the system is doing and what it is expected to do. In the case of UW, the university's HR department had the responsibility to make sure the system was configured correctly.
Ossip explains that with a cloud-based solution, clients can test immediately on a continual, real-time basis. Even if they do have a huge amount of testing to do, it is so much quicker than doing it at the end of the project. In the license model, you must wait until the end, and the volume of testing sometimes is more than the resources can bear. As a result, costly errors can result.
"Upfront testing greatly reduces the risk that this sort of situation can happen," he says.
"When you are talking about payments, the issue is how [to] minimize the risk," Ossip says. "You have to have a proper test strategy throughout the process, not just at the end. A license model forces you to test at the end, so you end up in a higher risk situation."