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.

Configuring Workday HCM application security

We've been spending some time recently on our implementation, on defining Workday security.  I mentioned attending security class a few months back, here is an introduction to the key concepts.

If you are used to a PeopleSoft security model, just forget everything you know, this is a totally different world.  :) 

Functional Areas - Workday security comes pre-delivered with defined functional areas such as 'Benefits', 'Staffing', 'Jobs & Positions' or 'Compensation'.  Each of these areas is further divided into 'domains' and 'business processes'.

Business Processes - Each HR process in WD is set up as a 'business process'.  So the steps and the roles that can perform each step, as well as any approvals or notifications are defined.  Examples of a business process can be large like 'Hire' or smaller like 'Passport and Visa change'.  There's more to say about buisness processes, but we'll save that for another day. 

For today, imagine a swim lane flow chart in Visio with roles assigned to certain tasks.

Domain - This one can be difficult to grasp as it's quite foreign from anything I've seen in other HR Systems.  Basically, a domain is a collection of related securable items, such as tasks and reports.  WD delivers similar items together within domains, and you cannot change which items are assigned to which domains.  There are also sub-domains in some cases, but that's for a later day too.

To give you some ideas, a Domain would be 'Set Up: Jobs & Positions' and examples of sub-Domains under that would then be:

• Set Up Job
• Set Up Position

Other examples of Domains would be 'Job Profile: View' or 'Job Information'.

Domain Security Policy - This is where we can do some configuration.  While we cannot change what comes delivered in a Domain, with the domain security policy we control access to it.  So we control who can 'View and Modify' or 'View Only' or 'Get and Put'.

Within this security policy we address 'Securable Actions' and 'Securable Reporting Items'.  So for the Task 'Create Job Profile' or 'Delete Job Family', we say that it is a 'Modify' task rather than 'View' task. 

For individual fields that fall under this area, we can then define if those are viewable or not too.

So let's work with an example so far:

• In the Functional area of 'Jobs & Positions' we have a Domain called 'Set Up: Jobs & Positions'.
• We have Business Processes such as 'Edit Position' or 'Create Position'.
• We apply a Domain Security Policy to 'Set Up: Jobs & Positions' so that various tasks are given either view or modify rights.

We then attach the above to a 'Security Group' via configuration tasks, and this is how a user is able to view tasks, perform function, etc.

I realize the above is quite a complex topic--you can see why this can be a full training course from Workday!  Let's talk some more about the User piece on a different day...

Challenges of converting from PeopleSoft to Workday: data conversion topics

As we are three months away from go live, there are currently a lot of issues being worked.  Many of them are related to data conversion.  A few thoughts on this topic...

In any system conversion, you can expect to have data differences, and to accommodate for these differences via decisions on the data, mapping, and logic.  In some cases you may decide to drop data, or in others you set default values.  Doing a conversion from PeopleSoft to Workday HCM is no different.  A few things we learned:

1. Be prepared to build your organization structure from scratch.  The Workday org structure is very different from the PeopleSoft department tree.  Org elements are independent fields, rather than a top down data structure.  As a result, our company is having to build the organisational structure in Excel for each round of conversion (using the PeopleSoft dept structure as a basis) and building it up to represent future state.  It's quite a manual effort.

2. Be prepared for more data edits.  While PSoft does some editing of address data, for example expecting an employee's zip code to be a length five number, it doesn't go beyond that.  Workday has built in a checking feature that recognizes if you put in a postal code that does not match the state.  As we have thousands of locations, some of our incorrect post codes were then caught upon loading to Workday.

3. Be prepared for differences in fields (in all areas).  We were originally expecting that Workday's global address formats would be similar to the PeopleSoft delivered ones (keeping in mind that PSoft ones are configurable, the fields you turn on/off, but have defaults).  This was not quite the case, and we ended up doing a lot of mapping for international locations (Mexico, Europe, Asia, etc.) such as 'PS has 4 lines for Mexico address, WD only has 3'.  So we had to map data and then adjust interface specs to reflect the fields of the new system.  It wasn't the end of the world, but a bit of a surprise. 

4. Get used to not seeing codes.  PSoft is a traditional ERP, so when you set up a location, for example, you give it a code.  Workday keeps any coding in the background, so that the user does not need to worry about it.  Granted, you can still search for a location by the code if you know it, but you're not seeing it on the screen.  In some cases we've had to accommodate our codes as 'integration IDs' or 'custom IDs', so additional data elements that you can attach to core objects.  Not a big deal, but a different way of thinking for us, an additional bit of complexity in configuration and conversion, and a little bit more of an effort to check converted data.

Any conversion tips from your side?

How to learn Workday

It seems from the stats that a few people come here wanting to find out:  How can I learn Workday?  A few thoughts...

1. Join a consulting company - Here in the London area, Workday is a very hot skill.  Even if you do not have actual Workday experience, as long as you have some other ERP or SaaS experience, companies are willing to hire you on (especially consulting companies), on the premise that it's easy to train you on this new software, as long as you have some HRIS experience.

2. Take an entry level position in HRIS - As well, companies that have already implemented the software are looking for people to maintain it, in HRIS analyst roles.  If I was an entry level or junior person, I'd take one of those positions to build up some experience.

3. Take the training/get a look at the training manuals/get access to a test tenant/get access to the Workday Community - It can be difficult to get started in this area as you cannot get access to a test tenant or to the WD Community unless you are an implementation partner or a customer.  However, once you are, the Workday training provides a good foundation to get started.  As well if you are a self-starter, there is a lot of learn from the documentation, if you can get access to it.

4. Join LinkedIn groups - There are a variety of LinkedIn groups that discuss Workday functionality.  Join them all.  :)

5. Apply for positions at Workday itself - Having worked for PeopleSoft, I understand the Workday work environment is similarly quite good--sharp and dedicated people, a fun place to be.  I've heard what they might lack in compensation they make up for in intellectual stimulation and a pleasant work life balance.  Try here to apply.

6. Read blogs - There's not a lot out there (yet), but some good info is starting to emerge, if you search for it on Google, etc.

Other ideas?

How good is Workday HCM?

Someone found this blog through typing 'How good is Workday HCM' into google.  I began to ponder that question, with 10 months of implementation experience behind me...

As a SaaS, it's as good as any other SaaS HRIS.  If you want the pre-built processes, fields etc along with heavy configuration/low customization, it's great.  If you have a highly customized environment or your business cannot fit the pre-defined mold of a delivered system, it's probably not the best option at the end of the day (nor would any other SaaS be a fit for your needs though).

If you're coming from *no system*, it's probably an easy way to jump quickly into an HR system, with little or no fuss.  Everything is pre-built and out there, you only need to start using it..

As far as functionality goes, the system offers the fields and processes one would generally need.  My major area of concern remains the 'global' pieces.  I noticed last week on the Workday community that one of the HR Consulting houses had published a set of reports into the Workday Solution area of the Workday Community.  This is the area where customers can publish their solutions, as a means to help others.  While it's great that this consulting firm created this set of country regulatory reports, I am a little surprised that WD does not pre-deliver this solution as a part of the base product. 

For the end user, the system does have a high degree of usability, and a well-designed user interface.  If you're used to a 'traditional' HRIS, you're used to a set of menus and training manuals that take you to various places.  WD instead drives everything off of the 'search box' functionality.  So if you're looking for an employee or setup data or a process--you simply type the keywork into the search box to be given a set of options that contain the keyword.  From a training perspective, it means that you don't need to focus the user of following a strict set of guidelines to follow a path to get to data.

Also, the interface has a 'webpage' look and feel.  When a manager is looking for data about an employee, or an employee is looking for data about him/herself, it's all available in dashboards and easy to find via following 'about me' links and such.  It's intuitive from that perspective, and much more like a 'web page' than a 'system'.

One topic that I have not yet discussed on this blog is the frequency of updates.  While it's great that WD is constantly evolving, it does equate to updates occurring three times a year.  On one hand it's great to have new functionality, on the other hand it requires you to then have a team that is responsible for testing new functionality, new configurations, testing and communication to the end users.  As well, if a  user is trained in doing things a certain way and they suddenly change, that may be confusing or even annoying at the end of the day.

Other thoughts anyone?

My review of the Workday Report Writer training

I recently attended virtual training on reporting from Workday. While you get a high level overview of reporting in the HCM Fundamentals class and run one report, Report Writer is the first reporting class that you can take to learn how to create your own reports.  It's a virtual class, 10 hours spread over two days. 

At first glance, the WD reporting product is not the easiest to learn on your own with no instruction (believe me, I tried!), especially if you're used to a relational database model.  In WD you can access the reporting tool from within a page, so you can click the 'related actions' from a hyperlinked field and choose to 'create report from here' or to view related reports.  However, if you don't have the report basics, you will soon be lost.

I'm happy to say that the two day WD training cleared that right up for me.  The class starts with some background about the WD database structure and some high level details about how the reporting works.  Then, you start to run delivered reports, then you build basic reports (on one object such as the Worker object), and finally advanced reports where you combine objects and then some simple matrix ones where you run counts, similar to an Excel pivot table.

This class was probably helpful to me at this point, because I now understand the structure of Workday, and how there are various objects such as the Worker, Location, Company, etc. and how the data is clustered around these objects.  There were some people in the class who have never seen WD beyond attending the HCM Fundamentals class (a required pre-requisite for this course) and they were lost before the end of the first day.  If you are at least in the implementation stage and have some idea of how to navigate around the WD system on your own and hire someone, for example, you'll be fine.

WD offers Report Writer as an introduction to reporting, then you can follow it up with Advanced Reporting and Analytics (15 hours over 3 days) and/or Calculated fields (15 hours/3 days).  These are all virtual options, with Report Writer being the pre-req to the other two.  There is also the option to do the reporting suite in a classroom setting by taking Workday Reporting:  Basic to Analytics.

That being said, assuming that you have a test tenant to use and can get a hold of the manual, you could probably walk yourself through the training quite easily. 

Some of the things that confused me at face value, before taking the course:

1. The overwhelming plethoria of fields with the same name.  Every instance of a field is its own reporting field.  This differs greatly from a relational database, where if you have something like 'jobcode description', you'll have one jobcode table with a description and you tie your code on your secondary table back to your foundation table. 

If you type 'Name' into Workday to find the field 'Name', you'll quickly get confused as you'll get all sorts of Names (descriptions) for things.

2. The icons used in the reporting tool.  The icons are meant to give you short-cut details about a field without having to look into the details, but until you know what they mean, it's a bit confusing.  Sure 'T' stands for text and '#' is a number field, but what's the thing that looks like a spoon?  Or the fireworks?  Once you know that the spoon is the base table and the fireworks represents a one-to-many relationship, it becomes a little more clear.

Once you get a handle on those basics, it becomes easier to navigate through the tool.

The one odd thing to me--and granted I come from a mix of HRIS systems from basic homegrown MS access applications to more sophisticated tools like PeopleSoft--is that WD locks down reporting from the join perspective.  So if you're doing a 'basic' report, then you're only working on one object--say 'Worker'.  If you change your mind and need other data that is not on Worker, you need to convert to an advanced report (which is possible).  However, if you start your report on an object and discover that it does not have all of your fields, if a join does not exist, you cannot 'force' a join the way you can in other databases.  You basically have to begin again, this time using the 'right' datasource.  I can imagine that one causing some frustration at the user level.

To view my other posts on training, click here.

Customization in Workday - Custom Objects

As a SaaS solution, customer customization of the Workday application is limited to the delivered customization options that you as a customer can configure, and mainly that involves the use of 'Custom Objects'.

Custom Objects can be considered as 'free fields' which you set up to use however you want.  They are attached to the various WD objects such as the Worker object, Location, Company, etc.

An example:
We have a manufacturing location in Europe that is required by law to issue safety clothing to the employee on a certain schedule, so every 6 months they receive a new set of trousers, every 12 months a new set of safety boots, etc.  This clock starts as of the employee's start date, so every employee would have a different date to get new clothing.  (Workday has some business asset/company property functionality so we might put it there, but we're just using this as an example.)  Our goal is to put all of this data into the system, to avoid the need to have any data in Excel, etc.

So your Custom Objects need to be applied to the Worker Object.  We need 3 fields: 

1. Type of Clothing (boots, shirt, trousers, etc. choosing from a dropdown/validated list)
2. Size of Clothing - needed for HR purposes, so that we know how many size 40 trousers to order for next year
3. Date received - this is important, so that HR can run reports in advance, to see when they need to provide the employee with new items.  In particular, we have a night shift and while HR rotates to try and provide a presence during some of these hours on some days, they need to ensure that the supervisor receives the clothing in advance, to avoid any issues with the union that contractual obligations are not being met.

So in our case, our data entry person would get to any entry screen like this:

Date Received:
Uniform Type:
Date Received:

They're quite easy to set up and configure, once you make the decision of how your fields should be defined.  You only need to define things like:  Field Label, Field Type, Prompts, Validation, Status, etc.

The above example took about 5 minutes to set up.  The key is knowing your business requirements.

So in thinking further about Custom Objects:

Advantages:

• You can set them up to meet your business needs.  For example, if you need to track something which is not typically found in an HR database, this is the place to do so. 
• There is some flexibility in how you set up these custom fields.  For example, you can choose to set them up with some validation values, or you can make them formatted as a date, etc.
• It's 'easy' customization that doesn't involve any development--it's merely 'configuration'.
• You can do EIB loads into these Custom Objects, if you'd like, to be able to load data.

Disadvantages:

• You can only apply custom fields where they are delivered at the object level.  For example, you can apply custom fields to the Worker object, so associate custom fields at the employee level.  Or you can apply custom fields to the Location object, so for any custom fields you may need to associate with a location. 
• However, if you have a custom field that is not associated with Applicant, Company, Customer, Job Profile, Supervisory Organization, or any of the other objects available. but instead a different object that does not have Custom Fields associated with it, you will not be able to use it.
• There is a limit of 20 custom fields per custom object!  This is a big one.  It means that you may only store up to 20 custom fields at the Worker level.  In my above example, this would use up 3 of 20 custom Worker fields, leaving 17.  At a global organization, this is insufficient for our HR needs.
• You can store up to 100 instances of a custom object in each instance.  In my example then, let's say that we are storing 5 types of clothing for a worker, and that each worker gets a new set of 5 rows every 6 months.  At 10 rows per year, we'll be out of space in 10 years.  Of course we can archive the data to Excel after a certain time to make room for more, but it would be nicer if we didn't have this concern.
• The data entry for the user isn't so nice.  The user does data entry on custom objects in a stand-alone area for each object.  The fields are not able to be integrated into the 'core' object in a logical fashion.  In our Uniform example, we need to count on the data entry operator to go to the Custom Object area for the Worker to enter the needed data.  This is a different menu item from Job or Personal Data, so easy for the entry operator to forget.

Final thoughts:

• I like the functionality, and how easy it is to 'customize' the system.  In our old ERP such new fields would involve a customer request, request approval, a functional spec, development effort, testing, test documentation, and a production turnover.  Creating these fields in WD is a much smaller effort. 
• We need the option for a lot more custom fields, or we need WD to better enable the application with more regulatory reporting and global fields.  In our implementation we are not able to use the fields for 'business needs' because we need to utilize them to hold regulatory data which is not addressed by WD.  It would be great if WD would increase the limit to say--40 per object.