Workday Global Payroll Cloud Projects: How to Prepare
Why is the effort on these projects so high?
If you’re on the web researching Workday Global Payroll Cloud (GPC) partners and projects, I’ll assume you’re already somewhat familiar with the concepts. Therefore, I’m not going to spend a lot of time arguing for or against specific GPC vendors or explaining the technology behind it. Instead, my focus for these articles is the Workday projects themselves.
With most integration projects, the focus of the effort is on writing and testing the integration’s code and behavior. But with GPCs, the vast majority of that is already resolved. Why, then, are GPC projects still so long and difficult? If the integrations are out-of-the-box, why do consultants still charge so much to support these projects? Why do they often take years to complete?
The simplest answer is time. Even though the integration is already built – often downloaded directly from Workday’s catalog – there is still a great deal of platform alignment and change management required. Often, there are so many impacted teams and groups that consultants spend dozens and dozens of hours on meetings, stating and restating the behavior of the PECI integrations, and gradually working the client through all the changes. Depending on the size of the client and the layers of bureaucracy in place, the analogy of turning a mega-sized cargo container ship is an apt comparison.
Ultimately, as a client, the best thing you can do is to set your organization up for a smooth and successful project, even before the kickoff. Many clients think that the key to success is bringing in the right consultant with the most experience. And while that is partially true (you always want experienced and capable consultants), much of the GPC project is completely outside the consultant’s control. At least 50% of the GPC project is dictated by the client’s company policies, SOX compliance requirements, Workday setup, local payroll traditions, intra-team relationships, departmental silos, language barriers, and differing assumptions. If you are preparing for a GPC implementation, even before selecting a consultant, there is a great deal you can do to get your organization ready before the kickoff meeting:
- Prepare Workday
- Identify and empower key project players who have cross-functional oversight
- Find out what your local payroll teams are actually doing
So much of the cost and challenge of these projects is spent just guiding the client through these three tasks. And they are by no means simple or small. A client that is able to own and execute internally on these items will have a smooth, successful, project at lower cost. By contrast, a client that struggles to take decisive ownership of these items will throw the weight of these problems onto the shoulders of the consultant, who is not in a position of authority within the company. Consequently, the consultant will struggle to drag the client across the finish line, guaranteeing a painful and difficult experience for everyone involved.
In this series of blogs, I’m going to dive into my personal experience supporting clients on global payroll projects, the lessons I’ve learned, and the mistakes I try not to repeat. I’m also going to advise you on what you can do to prepare your organization. Of course, no two companies are alike, and there will always be nuances to your situation that complicate your project. That being said, GPC projects are very, very similar from client to client. Each Workday customer must solve the same set of problems, and the PECI’s all run the same way, and do the same thing. After a decade of consulting on these projects, I am struck by how similar all these projects are. It is not the nuances and complexities that tend to derail these projects, rather it is the same usual suspects each time:
- Bad or missing employee data in Workday
- Heavily siloed project groups that don’t understand each other’s needs
- 11th-hour blockers from local HR and Payroll teams that nobody know about
Over the next few blog entries, I am going to dive into the details of the three usual suspects above, provide real-life examples from past experience, and steps you can take to prepare your organization prior to kick-off.
Preparing Workday
Hands down, the biggest client challenge for a GPC project is cleaning up the employee data in Workday. This may surprise you, but I have yet to support a GPC setup project where the client did not discover how weak the data integrity was in Workday for global employees. When trying to ascertain the quality of international employee data in Workday, one question can be asked to approximate the extent of the problem: is there any existing point-to-point PECI integration for that pay group today? If the answer is yes, then we can rest assured the fundamental organizational structures are in place (payroll companies, pay groups, schedules). We also assume that much of the basic employee data is aligned (positional, base pay, home addresses). And while it’s still not a guarantee, an existing payroll interface means that some amount of Workday employee data is already directly integrated, therefore Workday is already the primary source for any covered pay groups.
However, when the pay group does not have an existing integration, it means Workday is, quite likely, not the actual primary source for employee data, and therefore Workday is not the “source of truth.” Rather, it is the local payroll platforms themselves that have the most up-to-date information. When there is no integration from Workday, then it’s not really Workday that is the critical platform. If the payroll platform is not correct, then employees are paid incorrectly, and government reporting is wrong, or deposits are sent to the wrong accounts. Therefore, the payroll platform is the critical platform for employees and HR. Very likely, it is kept up-to-date by emails and spreadsheets. Workday is secondary, updated directly by HR only when necessary. There is usually no employee self-service, or if there is, it is never used. Employees probably don’t ever log into Workday because if they need to change their home address, it’s the payroll team that needs the update, not Workday.
When there is no integration in place today between Workday and the payroll platform, clients need to assume the following:
- Home Addresses are stale (at best), and therefore need to be fully audited to ensure they match what is in the payroll system. Oftentimes they are completely missing.
- National IDs are missing for many (or most), and you will probably need multiple national IDs in many countries. Spain, for example, requires up to three National IDs and employees (if they are using self-service) are not adding everything they should.
- Personal Information will be spotty. Using localization settings, you can activate more personal info for specific countries but it’s probably not marked as required, or employees and HR are skipping what is not required.
- Bank Accounts, if left on the default mapping, have very little required data. In some cases, Workday’s default country settings will not match what the payroll system requires. For example, in the UAE, Workday asks for the Employee’s account number, but the payroll system may want it sent using IBAN. Unless blocked by validation, employees can also skip the step asking them to provide a direct deposit.
- Compensation may correctly reflect the employee’s total compensation package (for headcount and cost reporting), but it will need to be broken out for the payroll integration. For example, in numerous countries, compensation is a combination of base pay, allowances (Housing Allowance, Food Allowance, Shift Allowance, etc) and Period Salary Plans (13th/14th Month), and it’s very common for clients to choose not to track all these elements in Workday. Instead, clients simply aggregate all the different earnings elements into a single number and assign it as the Employee’s salary. The payroll platform will require that each element of recurring pay you wish to send from Workday be structured correctly as a compensation plan on the worker’s profile, and the salary cannot be an aggregate of pay elements, it must be strictly base pay.
I cannot emphasize enough how long and difficult the data audit and clean up on these tasks is, and how much of it will rest on the shoulders of your local payroll teams. They are the only ones who can provide you with the payroll data that will be used to audit Workday, since they must extract it from the local platforms. Depending on how siloed the payroll team is from the HR team, identifying the Workday compensation elements that exist or are missing, and how they align to the payroll elements, is a very long and arduous process. And it will be different for each country, though the exercise should speed up with repetition.
All that hard work will amount to nothing if you don’t ensure that new data entered into Workday is clean. You can clean everything up, but you need to put controls in place so that new hires, and new changes don’t simply re-do all the same problems as before. Using localization settings, business process validation rules, bank account country overrides, and compensation eligibility rules, you can ensure new hires aren’t permitted to skip processes in onboarding, or complete the Edit Government ID step without providing both of Germany’s required national IDs, or add a direct deposit with IBAN but forget the SWIFT code.
Not every client will need to clean up every item above. From my experience, there are a few categories that clients fall into:
1. North American company with several small pay groups scattered throughout EMEA, APAC, and/or LATAM
Because this organization is primarily based in North America, the heavy emphasis of the Workday deployment went to US and Canadian employees. This type of client may even be using Workday Payroll for the USA and or Canada. During deployment, a conscious decision was made for international employees and pay groups to be set up only with the bare minimum to get them into Workday for headcount accuracy and total compensation reporting.
For this type of Workday customer, there is a high likelihood that international employee data is extremely stale, is not kept up to date in a timely manner, or is missing completely. During Workday deployment the emphasis was on the USA employees, and international employees remained mostly manual. In fact, there may be only a single “International Pay Group” to house non-US workers. If this is the case for you, then you are about to go through a mini-implementation for your Global employees. You will need to systematically review and collect every employee’s data. You will need to finish configuration for global pay groups that was intentionally bypassed during Workday implementation. This means pay groups, pay group assignment rules, schedules, payment election rules, localization setting, and a complete overhaul of compensation plans. You should anticipate needing a suite of Period Salary plans, one-time payment plans, and allowance plans that do not exist in your Workday tenant today. In short, you should expect a lengthy project.
2. Big global company with several large pay groups, and some of the larger pay groups have some type of integration to local-country-specific payroll vendors
In this scenario, the large global client already has much of its global population on some sort of integration. For those integrated pay groups, we can reasonably assume that much of the Workday payroll interface configuration is in place. But while this is good news, we cannot rest on those assumptions. You should take a few hours in a meeting with local payroll operators and step through their per-pay-period processes to find out what data is passing via integration, and what is not. It’s very common to find that an integration is running, but sections of it are being ignored by the payroll team.
Based on the payroll team’s feedback, it will provide useful guidance for your new GPCs. You will already know what worked or didn’t with the previous setup. If you find that the integration is working reasonably well, then it’s also likely that local HR processes and self-service are functioning. You can then focus your attention on the non-integrated pay groups.
3. Big global company with an existing GPC setup but are now switching over to a new GPC vendor
If you’re making a vendor change, switching from one GPC vendor to another, you can be reasonably confident that your data and pay group setup is pretty solid. Since you are changing vendors, I’ll go ahead and assume there were major reasons driving that decision, both performance and cost. Not all GPC vendors provide the same quality of service. In your case, the focus of the project should be on identifying performance gaps and current integration problems and making sure the new GPCs solve these old headaches. Even though it sounds like Workday is already ready, you still have to test out the platform and run parallels.
And finally: Local Payroll Data
There is one more discussion point that always comes up: “local payroll data” AKA “country specific data.” Every country in the world requires a unique set of data points to process payroll and Workday does not naturally collect all of it. Anything that can’t be transmitted from Workday over the PECI file format has to be maintained manually by the payroll team.
When this topic first comes up, the payroll team often pushes hard for Workday to provide all this information. Depending on the GPC vendor, it may be possible to configure field overrides to send it. However, just because the GPC has field overrides for customization does not mean that Workday has a native or natural place to capture the info. When considering local payroll data I usually run through the following decision tree:
A good example of the above is “Citizenship Status”. There is a native spot in Workday for citizenship per country that can be turned on through localization settings and made required for specific countries. It can be collected during onboarding on the Personal Information step. It’s a good example of country specific data that can be added to Workday to benefit the payroll team.
A different example is something like dependent children for the Netherlands. If benefits are not configured in Workday for Netherlands employees, then dependents cannot be easily collected, tracked, or maintained in Workday through self-service. Yes, it could be added into the Workday dependents section, but there’s no good or natural process in Workday (outside of HR administration) for adding new children or removing children that age out, when benefits management is not also present. Yes, it can be done in Workday, but does it actually add value?
An example of data that should remain in the payroll platform is anything which would require creating a custom field in Workday. Custom Fields are not available through self-service, and most likely they need to be effective-dated in order that change detection works for them on the PECI. If you start setting up custom fields you have to ask yourself if anyone is really benefiting from them. HR must manually maintain these custom fields in Workday, there is no natural process in Workday for them, and no real “clicks’ are saved. All that’s happened is the data entry has been shifted from payroll to HR, but it’s really the payroll team that governs and uses this data. When I run this analysis back to clients, they usually admit that the push for doing this type of country data in Workday is not about efficiency but just a belief that “Workday must always be the point of entry for everything.”
This should provide you with a solid overview of how and why Workday data is always a major part of GPC implementation projects. Nearly all of the above can be done in Workday long before the project begins. Next up in this series, we will dive into project roles, and what happens when client teams live deep within their own departmental silos. Make sure to follow #kogblog on LinkedIn and contact us if you have any specific questions.
