You’ve chosen your new HR system. The vendor gets to work on the technical implementation, so it feels like the most important work is done. Until the first questions come up. How should your HR processes actually run? Who provides the data? Who decides on exceptions? Who will test? Lubomira Panaskova, digital HR consultant at worldofwork™, lists seven points that you as an organization need to get right yourself.
A new system puts your HR processes under a magnifying glass. How does onboarding work? Who starts a role change? Which approvals are needed? And why does that one exception still exist?
Once you map a process step by step, you discover the gaps in the description. One way of working lives only in an HR colleague’s head, another differs by department or country. Some agreements have been around for years without anyone still being able to explain why.
The processes also have to fit the new system. Maybe the standard setup works differently from your current way of working. Do you adjust the process, build an exception, or is customization needed?
In an international organization you face even more choices. What works in the Netherlands can clash in Germany, France or the US with local legislation, payroll or terms of employment. For every difference you have to decide: is this truly necessary or just how it grew historically?
Your vendor can show what the system supports. Which processes you want to keep, simplify or align worldwide is a decision for your own organization.
An HR project manager alone cannot get a system implementation across the finish line. For process choices you need HR, for exceptions payroll, for integrations IT, and for checking the setup the people who will work with it later. Input from functional administration, security, finance and communications is also valuable.
Meanwhile the regular work continues. A payroll specialist cannot prioritize the implementation when the payroll run has to be finished. An HR colleague with crucial process knowledge may also have recruitment or a reorganization on their plate. Decisions get postponed, input arrives late and test hours disappear from the plan.
Extra hands do not solve this automatically. A vendor can configure, but cannot decide which exception in a payroll process is business-critical. A consultant can map a process, but cannot decide which local way of working in France may disappear. For that you need someone who knows the content and is allowed to make decisions.
Make visible in the planning which expertise is needed when, how much time that requires, and who provides input, reviews, validates and decides. After go-live, management, changes and new wishes keep coming back. You need people and ownership for that as well.
During preparation for data migration the same employee file can suddenly contain multiple realities. An employee is registered slightly differently in three systems. Job titles vary. Historical data exists, but no one knows whether it is still needed.
Exporting and importing is the easy part. First you need to know which data moves, where the reliable version sits and what you do with the rest. Which history do you keep? Which fields will you use later? What can go to the archive?
Concepts also turn out less clear-cut than expected. What does every department mean by an ‘active employee’? Which date counts as the official start date? Which job title is the correct one? And which system will provide the leading data later?
The technical transfer can be done by the vendor. Deciding which data is correct and what it means can only be done by your own organization. Otherwise the pollution moves with you to the new system.
An implementation produces a long list of choices. One process for everyone or local exceptions? Which data moves? Who gets which rights? What happens if two countries want something different?
Such a choice can be small in content and still take weeks. The Netherlands, for example, wants a different onboarding flow than Germany. May the local team decide that? Is the global process owner in charge? Or does the steering group need to look at it because the deviation affects the standard setup?
If no one knows where the mandate lies, the topic keeps moving between the project team, HR, IT and the steering group. Governance here is very concrete: who decides what, what falls within scope and when something must be escalated?
These choices also return after go-live. Releases bring new possibilities, HR has new wishes and local teams ask for exceptions. Without an owner for the system and processes, decision-making starts from scratch every time.
Your new HR system ends up between existing systems: payroll, recruitment, finance, identity management, learning and possibly local applications.
Take a new employee. Where is that person entered? Which system provides the organization structure? Which data goes to payroll? Where are accounts created? And who notices if an integration fails along the way? Everything can go well inside the HR system while the employee never arrives in a system further down the chain.
In a best-of-breed landscape that chain becomes longer. Recruitment, core HR, payroll and learning may sit in four applications, for example. Each system can do what is expected of it separately, while the employee journey still stalls.
You therefore need to know how data and processes move through the HR landscape. Which system is the source for every piece of data? Which systems depend on each other? Who checks whether data arrives and who picks up an error?
If you only figure this out in the final phase, an earlier choice in the HR system can still block an integration or process further down the line.
For a user a new HR system is rarely just new software. A manager may now enter a change themselves, an employee handles more via self-service, or HR relies on an automated workflow where there used to be a manual check.
That is what people notice: what do I have to do differently from Monday? If you only tell them this just before go-live, someone suddenly gets a different task or responsibility without being used to it.
Key users can indicate during design and testing where a new way of working clashes with daily work. They know the exceptions, know which steps users quickly forget and hear which questions live among colleagues.
The communications department also has a role here. Not only to create a message about go-live at the end, but to think earlier about what different target groups need to know, when and via which channel.
An HR professional who works in the system every day needs different explanation than a manager who runs an HR process three times a year. After go-live it becomes clear where extra support is needed.
That a button works says little about whether an HR process works. Entering an employee can go without problems; getting that same employee correctly through payroll, authorizations and connected systems is a different test.
Use scenarios that resemble what HR actually encounters: an employee who starts mid-month, an international transfer, someone with multiple contracts and the ordinary employee without exceptions.
In such tests earlier choices come back. A process turns out to run differently than it was written on paper. A requirement is ambiguous. An integration misses a field. For an exception it turns out no agreement was made. Testing therefore also checks the thinking from earlier phases.
The best scenarios do not come exclusively from a project document. People who work with the processes every day know the cases that rarely appear in a standard script but do come in at HR.
Also reserve time for adjusting and retesting. A change in one process can have consequences for an integration, authorization or next step. After every adjustment, check whether the whole chain still works as intended. Otherwise you push problems through to go-live.
A vendor can build, configure and deliver the system technically. But that does not yet give you an HR environment that works well. Processes, data, responsibilities and integrations also need to be in order, users need to be able to work with the system and the whole chain needs to have been tested properly.
The underestimation is not in the software itself, but in the work your own organization has to do to make that software function well.
Need help preparing for and carrying out your HR system implementation? At worldofwork™ we are happy to think along with you, within your resources and budget.
We will reach out as soon as possible


