The Post Office has recently completed a migration from a 19-year-old SAP HR 4.7 system to SuccessFactors, saving the company money, giving employees the ability to self serve and decommissioning a whole range of manual processes for the HR department.
Speaking during the UK and Ireland SAP User Group conference in Birmingham last week Samantha Winstanley, SuccessFactors product manager at the Post Office, talked through the migration, including some key lessons learned along the way.
In 2016 the Post Office was made aware that its 19-year-old R/3 4.7 instance would no longer be supported. "We had no option but to move forward," Winstanley said.
For those that are new to the SAP product line: R/3 is the ERP predecessor to SAP ERP (ECC), which has now been superseded by S/4HANA.
With that motivation to move, the organisation embarked on a procurement process for new HR software, but ended up opting for a vendor it knew well in SAP by going with SuccessFactors, the cloud-based human capital management (HCM) vendor it acquired in 2011.
As can be expected that 19-year-old system was "starting to creak". The organisation was running eight modules for things like learning, performance and application tracking, all of which were "outdated and not linked," she added.
The Post Office was also paying 5,000 employees and 11,000 subpostmasters through this system, so there was no option of downtime.
The Post Office confirmed to Computerworld UK that this newly upgraded payroll and employee record system is completely unconnected to the beleaguered Horizon system, which is currently at the centre of a High Court case regarding accounting discrepancies which has seen staff accused of theft, fraud and false accounting.
Migration
Design workshops started in September 2016 along with some stakeholder management, conversations with external customers and suppliers and initial data gathering along with an implementation partner.
The plan was to move the employee central and employee central payroll modules over to SuccessFactors, before layering self serve capabilities like address changes and absence requests on top, with an initial go-live date of June 2017, which was quickly recognised as overly ambitious, according to Winstanley.
"It was impossible and the reason for some of that was: we closed our Royal Mail pension scheme in March and the data we were taking to do our comparison runs was that particular data," she said. So as the data didn't neatly map over the organisation "had to scrap all of that data and start again".
This did allow the Post Office to review its pay landscape however. "We found 400 wage types in the system, so this gave us the opportunity to reduce that by 60 percent," she said.
As well as moving from an older pension scheme, the organisation was in the process of moving all employees onto monthly pay cycles instead of weekly.
"We took the opportunity to move everyone to monthly pay, which didn't go down well, but it was something we had been planning for a long time, despite pushback from the unions, so this gave us that opportunity," she said.
"So we stripped our system down and started all over again using some clearer, better data and although that did throw out some defects it was a lot cleaner and better and we started to make some progress."
After three test 'comparison runs' the team decided to go live in September 2017, which was pushed back another couple of times to eventually land in January this year.
However, because the Post Office was migrating from such an old system "we couldn't just wrap everything up and upload it into the new system," Winstanley added. "So we had to download everything from the legacy system, check it, upload it to the new system and recheck it and there were 30 files all in all that had to be moved."
The Post Office eventually shut down its 4.7 system on 15 December. The integration team then started to take data and upload it into the new system on 8 January, meaning there was a data gap that needed to be manually filled by HR staff to ensure the January payroll was correct. "Luckily for us it ran through smoothly and we all sat in a room and patted ourselves on the back," she said.
The Post Office is now operating SuccessFactors employee central and employee central payroll for all staff, as well as learning modules, and the next stage is adding compensation, succession and development modules.
Benefits
By moving to a cloud-based system the Post Office is now able to calculate variable pay at the source, cutting down on human error by 50 percent, according to Winstanley.
"Over the years we were calculating that manually, so this has given us the opportunity to put those in through configuration and that is more accurate, so we are saving money that way as it is paying people correctly," she said.
The new self-serve system has also reduced pay queries by 70 percent, and removed a whole range of paper-based processes and lengthy control checks.
Moving to SuccessFactors has also reduced the Post Office's support bills. "I think it costs us less for our support," she said. "The cost for 4.7 was quite high but they did everything, and with SAP we don't get that."
The new self-serve capabilities allow employees to change their own address and bank details, see their pay history and request and track absences.
"That being said it has led to some very dissatisfied customers and has taken us a very long time to get them back on board," she admitted. "But we have now seen a change in attitude and people are starting to reap the benefits of having a self-serve system that they can just go into and see their payslip, grab their P60, change their details."
It has taken 10 months to get staff back on board, according to Winstanley, and that has involved a lot of retrospective work under a newly appointed change coordinator and a subsequent communications strategy.
"We didn't do a lot of communication and we also started to take the last payroll of December," she said, "which is our busiest month, so we aren't allowed to communicate at that time with our frontline staff.
"So we just didn't think about them properly and their technical abilities in a digital world. They weren't technically minded and we just pushed this system out and didn't tell them about the changes, how to get their payslips, how to access the system."
Lessons learned
Winstanley admits there are "many things I would have done differently" were the orgnaisation given the opportunity to run this project again.
"Communicate change effectively" was first and foremost on her list. "We are still retrospectively going back now to get our people on board. They were't going to get payslips anymore, they weren't going to be able to send an address change to us to change, it was all down to them, so make sure you have a change lead."
She also suggests sharing your blueprint with the software vendor to get their feedback. "We didn't and if we had spoken to SAP before, maybe we would have had a better idea of what would cause us those issues in the long run," she said.
Her next piece of advice was to have dedicated testing and integration leads in place to ensure the interfaces work from day one and that someone is responsible for all testing being successful.
She also recommended working directly with auditors as you go through this process to avoid having to go back and prove compliance retrospectively.
Speaking to Computerworld UK later on in the day, Winstanley added: "The biggest lesson for me was not to do everything at once. We launched employee central, employee central payroll, onboarding and recruitment, self-serve, all at the same time. I would have rolled it out and let the system embed before rolling out the self serve [capabilities]."