Background:
Working in a large company 150k+ emps, we load data every single day. Mainly it's of a daily operational nature rather than the yearly processes. When we acquire a new population, even if it's only 100 people, we try to save the data entry people the effort of loading. As well, we have regular changes of coding, such as cost centers, we have increases in the data we're storing--so maybe a group needs to start storing a certain element. Finally, we have data changes--so our job codes change, or grading structure changes, etc.Currently, my team performs this data loading in PeopleSoft, using Excel to CI functionality. Previously, we loaded flat files using SQR or by having a developer write SQL. In the new world, we'll use Workday's EIB functionality to load data and make data updates.
System Functionality:
You log into WD to generate spreadsheet templates. You populate the templates. Then, you upload the templates. If you've using PSoft's Excel to CI, the user interface is extremely similar. I've spent some time trying out this functionality in our test tenant; as well, I asked one of my analysts (who is a bulldog about the details of doing it right in our current environment) to try it out as well. In addition, we had a demo yesterday by our consulting partner, who walked us through a new hire load.My take:
As mentioned, we load data every day. We're used to looking at data and codes and running reports to pre-populate Excel sheets for our HR data entry partners to fill out further before sending back to us to load. The steps and overview of the process itself in WD is simple. You can generate a template in minutes. However--you need to know the data structures or else it will never work properly for you.For example, when you choose the New Hire delivered option, it creates a spreadsheet with 20+ tabs. There is an overview tab where you go through each line item and state whether it is 'required' or 'optional'. So if you are not tracking visa or work permit data for a new hire, you'd mark that item 'optional' and not populate it with data. In addition, once you start to look at each tab of data, you need to know what you want to load. For example, if you look at the 'Names' tab, it gives you all the country variations, preferred names, legal names, etc.
Your only saving grace from my perspective is to go into the template creation step and manually shut off these tabs and fields before generating the spreadsheet. Otherwise, it will be overwhelming to the end user. This 'generate template model' is also nice, because it allows you to assign comment text which will then be on the Excel as help for the user.
It's a little tricky though, as you need to know what data will override other data. For example, our consultant doing the demo had mentioned, 'you don't need to populate job title as that will come from the job profile, otherwise bla bla.' Ou HR person asked how we should know that from this sheet? 'Uuuuuh,' was the answer.
It's no magic wand, but data loading never is in an HRIS. On the plus side, when you try to load the data, it runs through the data entry checks as if you were doing the entry online, so less cr*p data is making it into the system. On the minus side, these Excels are a freeform adventure--you need to know your data structures and codes. For example, if your employee ID starts with a leading 0 but you miss to include this, the sheet doesn't notice that you're a digit short. It's only when you go to load that the file will bomb out and you can review the error log.
HR's take
This demo was the first time our HR colleagues were seeing this functionality, and there was some disappointment. During the sales cycle, this functionality was very highly recommended as 'easy' and 'user-friendly'. As a result, as a part of our HR transformation, this 'data loading' function was going to move to the data entry professionals. It was seen that instead of them spending two hours doing manual entry, that in 10 minutes they'd be able to load data perfectly. HR is now adjusting processes and personnel to take into account in the new world that this is not an end-user tool. Those data entry folks would still be responsible to fill out the Excels, but it was recognized that it wouldn't be *these* Excels as generated from Workday.How do other companies use this functionality?
We asked our consultant this question...mainly it sits with an HRIS, HRIT or whatever you call your IT-minded staff who support HR. In a few exception cases they'd seen data entry folks getting this access. In some cases they'd seen the opposite end of the spectrum, that companies built custom spreadsheets that HRIS or whomever would then massage into these templates.Note: Current WD 19 does not allow you to pre-populate the sheets when generating them. So you would need to generate your sheet, generate a separate query and do some cut/paste work to get them pre-populated.
What should we ask about in the sales cycle related to this topic?
I would suggest, ask for a 'new hire' demo, with the consultant generating the sheet from scratch, so you can get an idea of how it looks, and ask to see the 'Names' tab. (Granted, it is dependent upon how much demo time you have. We had a week, so an hour was ample in our deep dive schedule).Alternately, ask for copies of a generated Excel workbook (with the 20+ sheets 'as is'), as well as a sample error log.
In addition--ask to see the documentation that supports your team in performing this function. I suggest this as: 1) the WD community documentation is not so great. It gives a high level overview, but it's not in-depth enough. My analyst spent days on a 'try this and see if it works' method of working. Also 2) EIB training comes under the technical side of the house, as part of the overall integration framework. So if you're expecting your business users to generate and execute the load, you won't be able to get them training, as this piece is embedded into the bigger integration training.
No comments:
Post a Comment