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:

            a. Identifying information:
                  i. Employee ID
                  ii. SSN
                  iii. DOB

            b. Information impacting Compensation/Pay:
                  i. Pay Rate Type
                  ii. Frequency
                  iii. Employee Type
                  iv. Job Profile
                  v. Grade/Grade Profile
                  vi. FTE
                  vii. Work Location/Home Address
                  viii. Compensation Plan Assignments (including Proration of base pay, Allowances, etc.)
                  ix. Benefit Elections
                  x. Pay Input Earnings/Deductions (e.g. 401k Loans, United Way, etc.)
                  xi. Direct Deposit Info
                  xii. Tax Elections

            c. Organization Assignments:
                  i. Supervisory
                  ii. Company
                  iii. Pay Group
                  iv. Cost Center
                  v. Business Unit
                  vi. Department

            d. Contact Information
                  i. Phone
                  ii. Email
                  iii. Emergency Contacts

            e. Other Personal/Historical Information
                  i. Gender
                  ii. Ethnicity
                  iii. Other IDs
                  iv. Service Dates

            f. Additional Data:
                  i. Education
                  ii. Custom Fields (Grad Year, Secretary Assignments, etc.)

             See relevant sample reports below
             Employee Compensation
             Employee Contact Info
             Employee Data
             Employee Personal Info
             Job Profile Setup
             Supervisory Organization Setup

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.

8. Take detailed notes of gaps and lessons learned during each build.

As always for my blog posts, I'd love to get some insights and opinions from others on their own experiences! Let's hear them!

Consulting Workday HCM Project Implementation Data Go-Live Risk


Jen Kuzmick Profile Picture
Jen Kuzmick

Jen Kuzmick has 9+ years of Workday experience across 50+ HCM, Recruiting, Benefits, Talent, and Reporting projects. She has worked for multiple Workday ecosystem partners going back to early 2009.


Additional Posts
Share This Post
Twitter Facebook Linkedin