Undoing a Workday Data Load EIB

I was browsing the Workday Community site, catching up on the Customer forum postings.  This one caught my eye:

I am a new in Workday and need your help regarding EIB.
I have uploaded an EIB for Contingent worker but now i need to rollback the changes.
Can you please help me in this regard.

Yikes!  Can you imagine? 

We are a large company and currently load data every single work day in our PeopleSoft environment, using Excel to CI (with the files being prepared and loaded by the IT team).  Workday's EIB functionality is awfully similar to the PSoft functionality, using (bulky and cumbersome) Excels to prepare and load data.  Both systems offer 'validated' data entry through these load processes, so a cleaner way to load data than say, a SQL load.  Both offer equally cryptic data load reports so that you know where you've loaded data or had issues.

So where are we today in Production?

 

Our US colleagues have made the decision to give EIB to the newly formed shared services center.  They have backed off of their original intent however, of anything more than 10 rows should be loaded and have completely given up on doing any new Hire loading, as it's been deemed as 'too complex'.

It's interesting to me as historically we don't have the data entry people loading data, but HR Transformation continues to turn the world upside-down.

My two cents, as I continue to delve into Workday functionality and imagine our future state world in Europe...

Advantages of Workday EIB functionality over PeopleSoft Excel to CI

 

1. WD gives you the templates out the box.  In PSoft we need our developers to do some building to create the option to load.  So we made a prioritized list and gradually worked our way through it.

2. If the WD functionality is broken, it's on them to fix it, not your developers.

3. Workday allows you to 'define' the template--so you're able to remove optional columns at the get go to save the user the hassle of seeing non-used extras.  In our PSoft world we do a manual workaround (we give the users a skinnier version of the Excel, and then paste it back into our normal, bigger one).

4. There is a roll-back option!  (Ha!  Lucky for that fellow who asked the question to the forum!)  You can use the 'Mass Rescind Business Processes'.  In our PSoft world, we'd either do another Excel to CI in correction mode to fix the 'wrong' data or we'd send in the users to manually delete rows.

Advantages of PeopleSoft Excel to CI over Workday EIB functionality 

 

1. You can build whatever Excels to CI whenever you want, for whatever you want.  In WD you are stuck waiting for them to build the functionality.  So you make a Brainstorm and then hope people vote it up and that it's easy for WD to build.  For example, a company put out a request to WD to create an EIB for healthcare rates as they have 4k lines to enter due to their retiree plans.

2. If the WD functionality is broken, you're stuck waiting for them to fix it vs. having in-house resources fixing something as top priority.

3. A minor observation, but a continuing dark lining in the HCM cloud is that these tools are not always as intuitive as they portray during the sales cycle.  For example, if you want to load a blank value into PeopleSoft, you put a space (i.e. blank) into the cell in your Excel to CI, which is common sense.  In Workday, you put this into the cell:  {empty}

Data loading in Workday HCM - a functional view

Having spent 14 years and counting in an HR Systems (or HRIS or HRIT, pick your favorite term) capacity, as we all know, data loading is a necessary evil, in particular for big processes, such as year end merits or performance review uploads. 

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.