Exhausted

We have restarted our European PeopleSoft to Workday implementation which was stopped back in 2013. My goodness I am tired.

One of the selling features of SaaS like Workday is, 'they're so easy to implement!' We did a first prototype with a limited population back in late December. Starting the first week of January I've worked every single weekend except for two. When I say I 'worked the weekend,' that means that I worked 10 hours per day instead of the usual 12-14 hour days that I do during the week.

I love implementation! I don't mind extra hours as I like the mental challenge of figuring out conversion topic. I worked for PeopleSoft as an implementation consultant. I've been implementing HR systems for 20+ years. This is honestly the worst implementation that I've ever known.

A few 'data things' that suck when you're implementing Workday:

1. The need to produce lots of load files.

Our Workday consulting partner has given us a list of files to produce from PeopleSoft. We're pretty basic, implementing the absolute minimum, but we still have 40 employee data files to produce. Setup is handled separately. I'm not sure about you other bright and shiny SaaS providers but 40 files is a lot to produce.

2. The need to populate data...or failure

I get that one of the advantages of SaaS is the built-in data checks and functionality. Over here in Europe and Asia we have a minimum set of data. We don't provide benefits to dependents so the dependent birthday is not required. 'State' is often not a required data element in Europe or Asia but it is required in WD and in the US.

I have physically cringed when I had to send data reports out to our shared service centers that they need to figure out 'required States' and 'require postal codes' for employee addresses when none currently exist in PSoft today (and it obviously isn't a concern for downstream systems, integrations, etc.).

The employees in our shared service centers work hard to add and update data and I just gave them 20k rows of data where they need to contact the employee or somehow get on google maps to figure out an employee's post code.

3. The amount of setup data stuff has just floored me

I mentioned marital status earlier. But it seems that I am setting up everything....name prefixes like Mr./Mrs., citizenship status like France native. I expected to have to set up things like our Contract types but I'm setting up lots more. 

SaaS limitations - marital status

One of the main selling points of SaaS and cloud solutions are 'it's so easy! Everything is there for you out of the box! It will be the easiest implementation ever!' Just for the record, maybe that's the case if you have no HRIS and do business by Excel, but no, it's not that easy. I have worked 10 of the last 12 weekends trying to keep up with our awesome SaaS timetable. Here is an example of why things are not as easy as they should be...

Workday does not deliver marital statuses, you configure them. Peoplesoft delivered them out of the box and then you added as needed. (Thank you PeopleSoft!)

So you're starting from scratch in Workday. Your Workday implementation partner will tell you to 'go and define them and let me know.' So off you go to set up 'Single' in every country where you do business....That's right, every marital status is tied to country of work. So if you're in 75 countries, you're setting up 'Single' 75 times.

This gets even more interesting if you have an acquisition.

As WD allows each customer to define their own marital statuses they won't match across the instances.  We acquired a company that tagged their statues with 'W1' for Wave 1, 'W3' for Wave 3 of their implementation.

Their code looks like this:

DIVORCED_ITALY_W3

Our existing code looks like this:
Divorced_ITA

If you're using these items in an integration you're re-coding as you combine instances and code sets. Or you're re-coding as you convert.

Just for the record I HATE SMART CODING and this is an example of why. A developer has to see that code list. As soon as it became inconsistent, then smart codes no longer matter, it may as well be sequential numbers.

If the consultant misses to enter a code then you get a random WD generated one to add insult to injury. 

The other company also entered 'local language' marital statuses where a US equivalent did not exist. So 'Duurzaam Gescheiden' is entered on people from the Netherlands. As we are a US headquartered company this becomes difficult to work with. If you were a Dutch company, I'd fully get it.

Finally, our recently acquired company was headquartered in Ireland. They entered the first codes for Ireland.  So 'Single' equates to the Single value for Ireland. You don't know that unless you bring down the whole table with the country to figure that out.  So now our developers are re-coding to where they sent 'Single' on a payroll interface, post implementation they need to select 'Single_IRL' or the data needs to have been converted correctly to the new company's code.

This is the kind of stuff that I think WD should be delivering!

I imagine, if I did a poll of European companies and asked, what is your marital status description for the UK, France and Germany I'd get pretty similar responses. If I asked for the codes though, I'd get a whole range of responses depending on who set up the codes.

THIS is the missed opportunity of SaaS! 

Dictate a code list to me, I'll take it and map to it. Companies evolve and acquire others. Every time you acquire a company you're going through a 'fresh' implementation even though you're on the same HRIS. It was not like this for PeopleSoft and it shouldn't be like this for Workday.

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}

Can HR Systems ever do Big Data? Workday?

'Big Data' is one of those IT buzzwords these days, with everyone jumping on the bandwagon.

Last week I was researching Custom Objects for our implementation, to see if there's anything new in the Workday world on this topic.  Custom Objects are Workday's 'customer-defined' fields, I previously looked into the Workday functionality last year.

On the 'Worker' data object, we're already up to 12 fields used out of 20, prior to starting our Europe roll-out.  Workday 'Big Data Analytics' customers, however, get 100 Custom Objects on the Worker!  This alone would be a reason to license the product, and I think that's why WD keeps the rest of us in check at 20.

What is 'Workday Big Data Analytics' (BDA)?

 BDA is a newer, separately licensed product that enables a customer to analyse Workday and non-Workday data together in one place.  You put non-Workday data into the 'Big Data Store' and use 'Big Data Explorer' as your interface to upkeep (i.e. load) your data and perform analysis.  (In some ways it reminds me of the promise of ERP in the late 1980's...your Financials and HR data, all in one system!)

Advantages?

As I'm curious, I've been looking at the WD presentations on this topic and reading through the forum posts by other customers. 

• It sounds like it offers pre-defined templates and reports to help you to analyse large volumes of data more easily.
• You can incorporate this data into your manager dashboards in WD, so a 'one stop shop' for a manager.

Can an HR System really deliver on 'Big Data' benefits?

When it comes to data in the HRIS world, I find a few main hurdles:

1. Getting data
2. Maintaining data
3. Working with data so that it becomes a source of better decision making

I'm not sure how much Workday (or any other HRIS or HCM system) is really able to capitalize on Big Data, for a few reasons.

1. Getting data and linking it across systems can often be a challenge.  Not all systems have a unique key structure that matches other systems.
2. Other systems roll up data and define data in a different manner--it becomes an 'apples to oranges' exercise to compare it.
3. Even when you are able to match data, it's often a one time exercise.
4. HR data is not always maintained.  Someone may have a great idea to keep company property or driver licenses for company vehicle drivers in the HR system, but on-going maintenance can be an effort if systems and processes are not robust or meeting local needs.
5. Even if you have the best data in the world, it can be a struggle to define a common set of reports or to figure out how to configure manager dashboards automatically at a highly detailed level so that you are providing targeted information at a manager's fingertips, on demand, rather than a 'general manager dashboard' which is the same for all managers.

When I think Big Data, this is how I think of it

Here in the UK, we have a large supermarket chain, Tesco.  They do some 24 hour supermarkets, some mega-stores that carry clothes and electronics, as well as having little stores tucked into train and bus stations and in neighborhoods.  Tesco appeals to a variety of customers as they offer foods from value through to upscale.

Most people (including myself) have a Tesco clubcard.  You can scan it when you pay and get discounts, rewards, and every other month, they send targetted coupons based on your spending habits.  Yes, it's very big brother, but no one is forcing you to take or use a card.

Tesco knows that I bought bananas at 6 AM on a Sunday, wine on Friday, and that I buy cat food from them.  Tesco has a super big database somewhere, and I suspect their analytics team is gigantic.

Big Data can change behaviour

A few rounds back, they sent me a cracking good coupon for 1.10 off cat food, so I used it.  In the last round of coupons, they sent me 75 p off of cat food.  I didn't use the coupon but bought my cat food elsewhere.  In this round of coupons, they've now raised the ante, and are offering me 95 p off.  Will it change my behaviour in cat food buying?  It might, as they're now making it more valuable to me. 

Big Data knows what I need before I know that I need it.

The bottom coupon absolutely tickled me!  I am a US person living in the UK.  Those very smart data crunching computers (or the smart IT wonks programming the logic) have analyzed the data and are thinking that they can woo me into their USA product range.  I can only assume that they put together the data facts, that I don't buy tea and milk, but instead coffee and a variety of other tidbits that lead them to this conclusion.

So why can't HCM, HRIS, HR Systems, etc. be this smart too?

I see a lot of hype from the HR data solutions that they're harnessing the power of Big Data, but I'm not sure that they're there yet. 

1. I don't think that they have the data volumes necessary to fuel Big Data, even if you can combine data from other systems such as T&E or Sales.
2. You'll never be in the 'daily, operational, transactional' level of data needed to get the deep data insights.  For example:
1. An average HRIS may give you a report of terminations in the last fiscal year and an exit reason cited by the employee (where existing)
2. Big data HR Systems may bring in data from other systems--what was the sales volume of the emps leaving?  Did you lose a top performer or underachiever?
3. A Business Intelligence or Management Information team may use either of the above two sources to spot data trends...and then provide a further level of insight.
1. An increase in terms at location X coincides with the HR policy changes to not match 401k and to reduce company contributions to benefits.
2. Recommendation:  adjust the policy to influence the future term numbers.
3. Check after six months, any impact?  Rinse/repeat.

However, we'll never get to that Big Data level of detail...without having the full data set, for example, knowing the compensation and benefits received at the new company, we're just making a one-sided, best guess, based on the data that we have.

Tesco doesn't know what I'm buying at the competing supermarkets...but it has an idea based on what I am buying and not buying at Tesco.  It knows that I have a cat based on all the cat related things that I buy, but I don't buy cat litter there (Her Excellecy prefers another brand that I buy elsewhere).  Those data gurus at Tesco periodically shoot me a fabulous deal on cat litter, knowing that it's a *missing* item on my list. 

We'll never get to that level of data in the HR systems world, regardless of how good the product may be at providing templates, reports and analysis tools and that is why we'll never do Big Data properly in an HRIS setting.

Of course, very happy to be proven incorrect on this point, be it on Workday on another HCM.  :)

Apologies for the radio silence

It's been a busy few weeks here in the UK, and I'm currently working and traveling a lot for our project.

In addition, I haven't been overly pleased with the solutions I've been designing in Workday for our business requirements, so I have not felt compelled to list them out here.  As a little bit of background on that point...

We're heavily in the throes of gathering business requirements for our European countries.  My more HR-oriented colleagues do a great job of gathering the HR folks in the countries and they outline our new global Workday processes and inquire about the local processes that HR do in comparison to our scoped out list of global Workday processes, as well as gathering their field level requirements for those processes.  Then, for anything that does not fit into the global model or is not readily available through existing configuration, e.g. new event reasons, it gets forwarded over to me to provide some solution options and a recommendation.  I look at things holistically, so keeping things in mind like:

• Ease of use for the person doing data entry.  Will they enter it all on one page or have to go to multiple pages?  Are the labels good, or are we heavily mis-using a page (doing it Saas style, as I'm now calling it), so they'll need to ignore the labels and fill in the data entry boxes. 

• Can we interface any of the data in?

• Is this data going somewhere, such as a payroll system?

• How do all the pieces fit together in the process?  Can we get all of the data in a certain step or is this going to be a back and forth to collect data?

• Ease of reporting on the data

• Making is easy for the integration guys, for current as well as future interfaces

• Etc.

As I've been based in Europe for 10+ years, I often know the business needs/use better than my US-based HR colleagues, so some of the things they just throw over the fence to me to define requirements and solutions.  For other stuff, they're doing a great job of gathering data definition, especially where the business does not use PeopleSoft now to meet a need and the central team thinks that we should start to accumulate this data in Workday.

I was talking to a colleague of mine, he's a general all-arounder, understanding technology plus the business use of systems, although his area of expertise is recruiting systems.  He's been assigned a task to investigate a certain area of data that overlaps between the recruitment system and Workday core HR data, and to get a team together to figure out what data should be captured in the business processes.

I gave him a debrief today of the Workday functionality.  It's a common European set of data, but WD is very light on the ground in this area, as it's not data that is used in the US.  I was giving him an overview of:

1. Here are the business requirements that I have heard from the core HR calls in Europe.
2. Here is the data we currently store in our European PeopleSoft instance for this topic.
3. Here is the Workday functionality in this area.

So now we're counting on him and his team to define the business requirements, and I'll then solution them.

He was asking me questions to confirm that he understood the WD functionality and was a little surprised that the functionality was so light in this area.  In particular, it's basically a page with some dates and free form fields.

For anyone who has worked in an HRIS operational capacity, free form fields are the devil's handiwork:

1. They're a hassle for the data entry people who can't just do a few characters of predictive text/choose a dropdown value.
2. They're a hassle for the team responsible for auditing data, as they're always chasing up and having to get corrections to misspellings, etc.
3. They're a hassle for downstream systems, due to a lack of consistency.

Required vs non-Required fields in Workday

I've been looking further at the Disability data pages in Workday, and do these meet the need of the data required by the various country payroll providers.  Typical analysis tasks exist like you'd do for any system:

• Understand the business requirements, fit gap for the data elements
• Ensure that the data home is palatable for developers and report writers
• Make the data entry as easy, friendly and automated as possible for the data entry teams
• Think holistically, will this definition work across the countries?
• Consider long term, is the entry sustainable, will this be a self-service item, etc.

In essence, it's a balancing act of these various pieces, whenever I design a solution. 

Occasionally in PeopleSoft, an entry person has to put default data into a field to be able to get into a field that they must use, so be it.  On the flip side, if there is an important data element or one that if not populated will break an important interface such as payroll, we've been known to make the quick and dirty customization in PSoft to make the optional field required.  (Technically it's a customization, but an easy one to turn on the checkbox.  It's more of an effort due to our change management process to make/test this 'code change'.)

In looking at Disability in Workday, only the Disability code is required, none of the additional fields are required.  As a SaaS solution, there is no option to customize to make these fields required.  My issue here is that country-specific interfaces require a set of fields as mandatory for disability.

Where this is going to be a challenge for us:

• Like many companies in Europe, our Shared Services data entry team supports multiple countries.  
• Some data entry will always be country specific: Name formats, Addresses, Disability, Labor Agreements, Establishment for France, Brazil etc.  
• Often, it's consistent across a country, but the system just makes all the fields open.  Thus the 'Flexible' description.
• Fields can be entered/non-entered for a country
• Fields have no setup values behind them, they are free form

My concern is that in this example, Disability is not a daily entry task, and it differs greatly per country.  We cannot dictate entry at a system level, beyond giving an entry professional access to the page.  There are downstream, i.e. Payroll, impacts if the person does not do the entry correctly.

So we'll need to prepare entry documentation per country, that the entry person will need to look up and use each time they need to enter this data.  With WD's regular updates this will be a challenge to keep current.

While this item alone is not huge (we're not hiring a disabled person every day, although in some ways it would be better if they were doing the data entry every day, then the rules would be memorized), when you start to add up the various items that will require similar efforts, it starts to add up.  For fields that do not break an interface but are important for business reporting, it will become a matter of building audit reports and chasing up any 'required' fields when empty.

I realize this topic continues to come up on Workday's Community site, the ability to make a non-required field 'company required', and knowing nothing about the guts of Workday, I'm suspecting it's a pretty big ask since it's not getting picked up.  I am starting to get a little nostalgic for a non-SaaS HRIS though, as I consider:

1. Broken interfaces due to incomplete data
2. Additional auditing needed
3. Making extra documentation so that people know what fields are required.

Also fully recognizing that this is not a 'Workday' issue per se, but moreso a 'SaaS' issue overall, that configuration is limited to the vendor's offerings.

Names in Workday

We're starting to get into the data analysis phase here in Europe.  Something new I learned about Workday today--names are not configurable per country.  To put it another way:  if WD defines that country xyz has name format (first last) and country abc has name format (first middle last), then that is what you get.

Understanding WD is defining a global solution based on name requirements around the world, as they understand them.

Also sitting here looking at the analysis done by one of my analysts to compare our current PeopleSoft names data to the Workday global matrix (a helpful resource that lists out per country the various fields available for items such as names).

We have a mismatch in a number of countries.  :-(

So now, we'll need to look closer, per country, to figure out what to do with our current data.  A few options, of course:

• Delete the middle names from PS.  Don't store going forward.
• Concatenate into the first name field in WD.  Then, get smart coding that parses out the middle name part depending on the country/interface.  Deal with the fallout if Middle Names (located in the first name field) are pulled into a report by an analyst and distributed further.
• Put middle names into another solution such as a Custom Object.  Then build rules that 'if country is xyz, then concatenate this field with First Name when sending the data to downstream system 123.  Force the report analysts to reference it as well.

In a perfect world, WD would make this a configurable item for me, so that I could use checkboxes to select which name types apply to a country.  Just sayin'.

Once we start making the conversion decisions, I'll give you an update about how it all turned out...

Timezones, effective dating and Workday

I recently received an email about timezones in Workday, wondering how all the pieces come together regarding the timing of transactions, as it's a SaaS solution, hosted in the US.  In particular, when and how do things such as a hire become effective, particularly when it's a timezone around Asia or India, where today is already tomorrow?  A few points:

Workday gives you a few options, when it comes to timezones.  You can set timezone in 3 areas, or you can keep the delivered defaults:

• the tenant (default = US Pacific)
• locations (default = tenant timezone)
• on the user (default = location timezone)  Only an admin can set a user's timezone, a user cannot self-select.

Workday has this piece of guidance on Community:
Effective dates are in Pacific Time. When something becomes effective, it is effective all over the world, because all users are logged into the Workday servers in the Pacific Time zone.

I guess this makes sense, as California is the 'end' of the date around the world.  So by the time it becomes effective there, everyone else has already reached this date.  However, on a practical sense, this means that if you make a business process change active as of August 1st, for Austrailia and countries in this part of the world will be closer to the 2nd before the change becomes active.

We discussed this topic a bit in the HRMS Fundamentals class, as we were hiring employees and kicking off workflow approvals.  We noticed that if the initiator was in Singapore and the approver was in New York, the transaction was date/time stamped with the local user settings.  As a result, it looked like the transaction had been approved before it was entered.

So--the idea would be that you date things according to your location.  So if your new hire starts on August 1, then make the effective date August 1, so that your history on the person will be correctly displayed.

A tip:  If you are doing EIBs or other admin tasks--best to adopt the timezone of the impacted population, so that your event dates ring true.  Otherwise, you may end up with incorrect timing for mass transactions.

Converting data into Workday - why it isn't easy some days

I wrote previously on the topic of converting from PeopleSoft to Workday.  Since then, we've gone through another conversion cycle, so I thought it would be an interesting example of why converting into Workday can take longer than you expect some days....

Like many companies, we track Emergency Contact data.  In our case, it's in a PeopleSoft system.  Nothing fancy, just whatever the new employee wrote onto the paper form, which then got entered into the system.

During fit gap, we looked at WD and yep, it has Emergency Contact data pages too, so we should be good to go.  During data mapping, we looked at both systems and defined rules of what needed to point to the various WD fields....here is where it gets interesting, when we attempted to convert the data...

 

What we learned during the conversion exercise

1. WD has built-in formatting on the address and phone numbers, PSoft does not.  In particular, PSoft does not offer standardization on phone numbers, and it wasn't a high priority item for the HR users to keep formatted.  So we have phone numbers that have the required number of digits, but not in a consistent format:  (555) 555-5555, 555.555.5555, and 555/555-5555, etc.  Around 80% of them follow one format though, so we can try and squeeze the data for those into one format to convert.

2. WD requires one piece of contact information for an Emergency Contact, in order to save it--either email or phone number.  We do not always have contact details, and in particular, we do not store email for emergency contacts.  Perhaps not the best from an HR perspective, as it defeats the purpose of an emergency contact, but we do have a name, and it saved just fine into PSoft.  WD demands a little more in this regard.  So above, we lost 20% of the population due to the various odd number formats, and now we lost another 10% due to lack of any contact details.

3. WD breaks apart the name fields for Emergency Contact, PSoft has in it one text field.  This is a big one for us from a conversion perspective, because similar to the inconsistent phone number formatting, we also have inconsistent name formats.  In some cases it was 'First Last' in others it's 'Last, First'.  Then, we have the additional complexity of Mexican names, where a 2nd last name is involved, which is an additional broken out field in WD.  Divining the mapping on this one was painful and I am not confident of the correctness of the data once mapped.

4. As PSoft has that one text box for names, our HR users also used it for other pieces of data, in particular where they did not have a dropdown value for Emergency Contact type.  So in PSoft rather than putting 'Joe Smith' and choosing the type of 'father' and 'Mary Smith' and 'mother', our HR users put 'Joe and Mary Smith (parents)' in the name box.  Trying to break this out in any automated fashion is impossible.

5. PSoft has a 'same address as employee' functionality on emergency contacts.  WD has something similar, a checkbox that allows you to take the emp's data.  Our consulting partner, however, cannot convert this checkbox using their proprietary conversion/load program.  They can however, load the address, etc. data.  They gave me a big explanation, due to technical web services that are called on the fly, bla bla.  The end result, however, is that we do not have this checkbox enabled in WD for our loaded data.  Manually entered data will be just fine.  As a result, we've had to write into the process documentation, that if an entry person is changing an address for an employee, they need to check the emergency contact page and click on the same address box (if address is the same), to trigger the 'linkage' and so that we do not need to upkeep two separate instances of the same address/phone numbers. 

Based on all of the above, my recommendation was to open up this area to self-service and push it out to the emps as a 'to do'.  As this data is collected upon hire and many of our emps have 10+ years of service, I am not sure of the viability of the data in any event, nevermind the above conversion issues that will result in incomplete data and additional entry steps.  Our business owner, however, is insistent that we convert whatever we can convert, as she has little confidence that the employees will enter the system and update their emergency contact details.

In Summary

Workday offers Emergency Contact pages, and the functionality is suitable for the purpose.  Like all other pieces of data in your new WD system, you need to be aware of the future WD edits as well as the condition of your data, otherwise it can end up taking a lot more time than you originally expected.

Historical data and Workday HCM

Many of us who have spent years in HR systems—be it SAP, PeopleSoft, Lawson, Oracle, or some other HR ERP or HRIS—have gone through conversions and upgrades.  Many of us have gone through major releases or one ERP to another.  However—Workday is a different HRIS entirely. 

Should we convert historical data?  If so, how much should we convert from our legacy system to Workday?

Workday history functionality

Workday provides some pre-delivered functionality that allows you to track job and compensation history from a previous system.  It looks like this if you're viewing it online:

As you can see, it's not so detailed. 

Advantages of using WD Previous System pages:

• It is pre-delivered functionality from WD, so you only need to put the data into the system to use it.  You can enter the data manually online or via EIB.
• It's also available for reporting too.
• It saves you the hassle of keeping an archive HRIS or secondary system for reporting purposes.

 

Disadvantages of using WD Previous System pages:

• You are limited to the fields WD provides. You cannot choose to bring in other history fields.
• If you're trying to run a report of BOTH current and history data, it can be a little ugly as the structures are slightly different. 

 

What about 'recreating' our history in WD?

Some companies choose to replicate their historical data (or a subset of the data, or perhaps for certain employees) in Workday.  Then, they recreate all the transactions.

• It's cleaner from an end user perspective, when viewing the data. 
• ALL of your data elements can be used, so reporting is less manual as you can directly drive the reporting from WD
• It requires effort to set up all the supporting data though (supervisory orgs, locations, job profiles, security, reporting relationships, etc.)

Other perspectives

Fortunately, many companies have already gone through such analysis efforts, so it’s good to research online what others have done, to learn the pitfalls and advantages in advance.  Interesting reading:

• University of Southern California’s decisions on history in WD
• Cornell’s analysis of moving history from PeopleSoft to Workday 
• Some guidance from Towers Watson – check out the pdf

 

Our decision

We have 20+ years of history in our PeopleSoft system.  We're implementing WD as part of an HR Transformation though, so much of the data structures will be changing.  With that in mind, we'd prefer not to bring over any of our legacy data.  We'll be converting people with two rows:

• A hire row, with defaulted data
• A current row, with current data

We will not utilize the WD Prior history functionality detailed above.

 

Calculated fields in Workday

An interesting feature in Workday is the 'calculated fields' functionality.

 

To quote WD, 'Calculated fields allow users to perform simple arithmetic, date calculations, text manipulation, logical expressions, retrieval of related data, and transformations of their existing data. You can use calculated fields in reporting, business processes, integrations, scheduling recurring processes, and other areas within Workday.'

 

It's a nifty little feature, as

• it gives complex power to the users in reporting, via an online interface where you build them.  (As opposed to having to write complex expressions with if/then statements, for those of us from a PeopleSoft world).
• it allows for 'cleaner' development, as a developer is also using the online point and click functionality to build these items, rather than writing code from scratch.
• they are convenient, since you only need to build them once and then can reference them in reports, integration, etc.

So as a practical example, if you are interfacing to various systems, let's say 'gender' and one system needs 'M' or 'F', another system needs 'Male' or 'Female', another system needs '1' or '2' and another system needs 'M' or 'W' (male/female in German would be 'männlich' or 'weiblich').  So in each instance, you'd create a calculated field to allow for the M or F or 1 or 2, etc.  Then, if these systems ever changed their coding, it would be a simple online update to change the interface.  It's much nicer than other systems I've seen where hardcoded SQL needs to get updated.

 

As well, you can do traditional if/then or 'evaluate' expressions.  So if an employee's hire date is more than 10 years ago, put >10 or that sort of thing. 

 

From a reporting perspective, it allows you to build user friendly reports in an easier manner than I've previously seen in other systems.

 

Where are they not so convenient?

 

Like much of WD, the functionality is very flexible.  If you don't have your business processes in order to support this flexibility, you're in for some issues...

 

In our implementation (being lead by a mainstream consulting partner, but supported by multiple offshore consulting firms), the main parter says that best practice is to implement WD by 'an iterative approach'.  Basically, we keep putting data in, seeing how it looks, then tweaking here and there what we're doing.

 

When the topic of calculated fields came up, our traditional approach was to try to standardise and lock down the functionality.  (We have 150k + employees and a large part of our business is manufacturing, so we live by documented processes, otherwise it's a free for all mess.)  Our consulting partner directed us that 'best practice' is to not standardize, as that would cause a bottleneck, and instead, each developer should be creating any/all fields needed.  Not quite sure that was the best way, in retrospect.

 

We have 200+ integrations that are being built (many offshore) as well as local development of reports that are also generating calculated fields.  As there is no clearinghouse or rules, people just make a new calc field rather than hunting for an existing one.  The Data Governance and Controls team is now quickly working to implement standards and structures as the count of calc fields has soared to above 1000.

 

An example

 

To put it into a practical perspective, I've been working on some reports recently, to support our HR colleagues who are looking at the data.  I was seeking 'Business Unit Descr' so I searched for 'Business Unit'.  The top field is the WD delivered one (is it descr?  code?  who knows).  The ones after are all our calc fields.  This is not all of them, as others created them as 'bus unit' and all sorts of shorter versions such as 'BU':



 

You can see where the standards of the Data Governance team are starting to come into effect, such as using 'CF' as a prefix for calc fields or 'INT' when an integration is involved.  If you have only a handful of folks using this functionality or creating reports, it might not be such a big deal.  However, we will ultimately have hundreds of HR folks in the system using (if not creating) reports, so this willy nilly lack of standards will be confusing for them, even if they are only running reports and seeing disparate field names.

Looking online at the Workday Community site, other companies are grappling with these very same issues.  (Sidenote:  I'm a little surprised that WD itself does not issue more guidance).  There is a 'solutions' section in the community where other WD customers can post their top tips and documents, to share with other companies.  The group at Brown University put together some really great documentation, but just to give you an idea of how extensive this calc field naming can get, here is a snippet of their rules:

 

 

 

In addition, another customer (who has been live for a while) has developed a series of reports for more what I'd call the 'structural' aspects of the system--so basically audits to keep things tidy and more efficient.  He also includes calc field review in his list of 30 reports, such as keeping up with the following:

My tip of the day

As you can probably gather from the above, calculated fields can get very messy, quite fast.  Not necessarily WD's fault as it's a side effect of the flexibility of the technology, but you need to have strong business processes in place to control the creation of these things.  So I'd suggest:

• Define who will create calc fields in the future.  Read up on Community, various customers have defined different ways for this to happen (HR Business users, HRIS, IT, etc.)
• Develop your guidelines and structure of how these items will be named and categorized.  WD does provide things like 'tags' to help you in classifying them.  Again, the Brown University guidance is a good start.
• Be prepared to do auditing on calc fields in the future, to be sure that your environment is doing well against your rules.

Training on calculated fields

It's probably worth a mention, calc fields is a 3 day/15 hour online course from WD, to give you an idea of the level of complexity that you can get into with them.  The pre-req is the Report Writer class (2 days/10 hours)

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.

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?

Workday field lengths

One of the most interesting features that I’ve noticed so far in Workday is the fact that fields allow the user to enter unlimited content. There are no ‘field lengths’ like you might see in a traditional database. Name, Position Title, Org Title–doesn’t matter–unlimited text.

Coming from a traditional relational database environment, this is fascinating! However, I am struggling to see the advantages of this feature. In particular, if you are interfacing to any downstream system, most will have field lengths. Then, your interface is either truncating the field and losing data, or it’s blowing up the downstream system by sending data that is too big to insert. Or worse–you’re truncating to downstream systems but having a longer value in WD reporting, so a ‘mismatch’ of data, leading to distrust in HR data. Or you’re stuck with having to run audit reports to find incorrectly entered data after the fact in order to have it shortened…rather than just being able to impose data lengths on the field in the first place.

I am struggling to see the advantage of this feature…