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. 

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...

Tenant Management in Workday

As many of us come from an ERP or non-SaaS HRIS environment, I'd like to highlight 'tenant management' as probably one of the biggest differences in going to Workday. 

What is a Workday tenant?

First--some terminology:  a 'tenant' is Workday's term for what many of us would call 'a database instance', such as your QA environment, Production, etc.  Workday has a pricing model as they host the customer tenants in their data centers.

Our HR Landscape

As an organization in the implementation phase, we've struggled a bit to get our arms around this concept.  As background information, we're a large (150k+ employee population) organisation.  Due to SOX in the US, as well as needing to manage systems, we have procedures of how implementation of changes happen in our current ERP.  It's a tightly structured process with defined roles and responsibilities; customers put in requests, they are assigned to developers, developers only have access to develop in a development environment, IT has an internal review before anything goes to QA, etc.  I'm sure it's similar to what many other companies are doing.

In the past when we've implemented, we had control over how many databases we needed and how we structured those.  So in an ERP upgrade we'd have various test copies for developers and configuration needs, we'd have a pristine test copy for payroll parallel testing, a separate database for training sometimes, etc.  Then, we'd have a gold copy where we'd copy or enter configurations and we'd migrate data and programs there.  If we want a database copy, we'd need to put in a request to our internal database team to make it (recognizing cost/space limitations).

 

How Workday updates databases

Here in the WD world, this seems to be a different procedure.  Not sure if it's WD or our WD consulting partner, but this is the first time I've seen migrations of code, configuration, etc. going in multiple directions, rather than in a linear fashion.  So we have a demo database.  We have 3+ copies of test databases, with our company test setup and employee data loaded into them.  We then have 1 for integration, so for the developers building our interface files.  We have another for solution testing.  We have one for the report team.  Then, configuration and programs are being moved to and fro, using EIB, iload, and solution migration.

I went to the Workday Community, so see what the WD delivered guidance on this task would be.  A few things I learned:

1. Customers in Deployment would have the following setup:
1. GMS tenant (demo data), Prototype tenant, Full dataload tenant, Testing tenant, Gold tenant.
2. So customers are typically provisioned 4 tenants during deployment.
2. Customers in Production would have the following setup:
1. Production, Sandbox, Update/Conversion
2. The Sandbox is to be used by both the customer+WD support.  It's not meant to be a training or implementation tenant though.  It's for testing out changes.

Workday provided the following visual, it's helpful as it demostrates the complexity of this topic:

 

 

 

So once we are in Production, then how do things work?  How are Workday Sandboxes updated? 

Workday updates the sandbox environments so that you can test out their new updates before production is updated.  It works like this:

1. Production is cloned.
2. Update to next version of WD.
3. Create WD Update sandbox for test environment.
4. Production gets updated to new version.
5. Sandbox gets deleted.

As a reminder, these updates happen 3 times per year.

Workday has a set procedure for managing these tenants, both during implementation and in production.  So you're managing online various tenant tasks, such as Convert tenant, Delete tenant, Exclude tenant (this one means that it is excluded from any upgrades).  There are set policies, such as requests must be entered by 2 PM Pacific time, etc.  All of those process details are clearly outlined by WD.

I recently noticed a position in London for a company who had implemented WD, and they had a newly created position called 'Tenant Manager'.  The person had responsibility of managing the above, as well as coordinating the testing processing during those 3x/year upgrades.  So while WD may be a source of cost savings as you don't need so many developers, there is hope for us IT folks that it will create jobs in other areas.  :-)

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.

 

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?