HR officers often want to answer questions like ‘how long does it take to hire someone?’, ‘how much early turn over do we have?’, ‘what is the average time till promotion?’, etc. Getting longitudinal data out of Workday can be a challenge. To answer some of these questions we can take monthly snap shots of ‘top of stack’ data pulled from Workday. For other questions like time to hire, where the exact number of days may be prefered, we have a couple options.
Option #1 – Implement a change data capture (CDC) type solution, which I refer to as tracking by observation. We take the data from yesterday (or the last load period) compare it to the current data set, and then load the rows that have changed into our ETL staging area along with the date time at which the change occurred.
Tracking by observation works well when looking at the exact time something changed in Workday. It does not work so well when looking at when something is or was effective. In HR many processes are future dated or effective dated history is corrected. This means that someone could have been effectively promoted last week, but we just got around to entering into the system today (with an effective date of last week). In this case tracking by observation would show the promotion as happening this week (when the promotion showed up in Workday).
Option #2 – To see changes by effective date in Workday, you need to look at the processes themselves. You need to look at objects like Worker History and/or Staffing Events. Staffing Event object seems like it would work well, but I have found it to be missing processes I would generally want in this data set. Because of this, I generally I use Job History as a data source.
Job History comes with its own set of challenges.
#1. Job History only shows the data element(s) that changed with the process. All other data elements are left blank. For instance if a ‘data change’ process updates a job profile, the only data included in that row would be the position, worker, process, effective date, entry date, and job profile. Other data elements like supervisory org, location, etc. would be missing. You will need to create a process to roll down changes, if you want the data to appear as it would in a OLTP system or if you want to be able to select a point in time and see all the Job History attributes of a position.
#1b. You may need a ranking system as a tiebreaker. Some processes are tied together and have the exact same entry date and effective date. In these cases, I typically create an order of precedence based on the process type.
#2. Job History only comes with a limited set of objects (fields). It has most of the major elements you would expect, with the exception of Cost Center. I have mitigated this by building a calculated field on the Job History->Organizations multi-instance field. The point is, you will only see changes on the basic/major position related dimensions using this object.
#3. Beware of entry date. at first blush Entry date may seem like a system date created when a row is added to the object. When looking at Workday objects, Entry date is the date when the process was started, not when it was completed, and hence the change has NOT taken effect yet. This means the entry date may be a date before you even see this row show up in Job History. At first glance, this field may sound like a great datetime to use for incremental loading, but it is not. You should use ‘Completed Date’ or ‘Last Functionally Updated’ instead.
#4. Job history exists within both ‘Position – Position Management’ and ‘Worker’ primary business objects. Generally you will want to use both. The Job History object coming from ‘Position’ will give you Job History for workers with multiple positions. The Job History coming from ‘All Workers’ will give you details on Job Management positions that no longer exist. This is helpful for initial loads after conversion.
#5. You may need to supplement Job History with other data sets. I’ve noticed cases where Job History may not contain all outbound transfer processes. I’ll often times create an extract from Staffing Events that is filtered by outbound or inbound transfers to fill this gap.