Bad data, lack of validation procedures, lack of attention to detail… as a veteran of over 50 Workday projects, it’s a theme I’ve seen repeated over and over again. On every project, there is a high level of focus on design and execution of configurations, whether organizations, business processes, or security. And rightly so: those areas are routinely referred to as “pillars of Workday”. The problem is, there is often not nearly enough focus on data conversion and validation.

It’s like outfitting your brand-new performance car with top of the line specifications: Upgrade that engine! Spring for the sport-tuned suspension! And why not, add the high-performance tires! Now… the lifeblood… the oil that with course through the engine and power that shiny new ride: meh, there’s got to be something on sale at the local dollar store. That’ll do, right?

I think you see where this is going – what’s the point of the high-end specs if we’re just going to flood it with poor quality input, which will no doubt produce poor output? Let’s talk about how we can avoid this precise outcome:

1. Are we validating the full picture? There are multiple potential points of failure with regard to data conversion and validation:

Given this, we need to focus on not just whether the data workbook provided matches Workday, but does the Source System data translate to Workday. (Example: Executives need to be in a separate salary “Distribution Plan” in Workday, but it is not tracked in the legacy system. This sort of item can be missed in the transformation from legacy system to the workbook, and because of this, yes, the workbook matched Workday, but the workbook was wrong.)

2. Be open to the possibility that the data validation process may expose existing holes in your legacy data and/or business rules. I’ve seen it more than once that a payroll calculation was first reported as a trouble ticket because it did not match the legacy system, but in actuality the calculation in Workday was correct.

3. Prioritize validating employee-level data over foundational setup data upon receipt of the tenant from your implementation partner. Normally (and outside the case of a lot of organizational changes during implementation) as the tenant builds progress, foundational data becomes quite clean and easy to move from tenant to tenant. Additionally, validating employee-level data is typically a more natural concept for the project team to grasp, and will normally expose any issues with foundational/setup data that need to be addressed.

4. Prioritize critical employee data. Utilize custom validation reports and Excel vlookup functionality to compare these data points. Be sure to include considerations like the example in point #1 above. Proceed from most critical to least critical:

5. Don’t forget about data supporting downstream systems. It’s not uncommon that data omissions/errors can get as far as integration with downstream systems to be discovered. During data validation, it’s a good practice to review the data required to support integrating to other systems.

6. Review Security Assignments. Security is critical to the way Workday functions, impacting what data users see and what tasks they can perform. a. User-Based b. Role-Based (be sure to validate that the appropriate users are assigned to the appropriate Organizations/Locations) c. Job-Based

7. Make the data conversion and validation process as repeatable as possible.

How many times have you been in the situation or heard about the scenario where a sales person quoted an integration for $10,000 only later to find out it’s actually 5 file feeds with 2 bi-directional ones and the new price tag of $50,000.