Wednesday 5 June 2013

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?

5 comments:

  1. Hello, Can you say more about the following?

    "The Workday org structure is very different from the PeopleSoft department tree. Org elements are independent fields, rather than a top down data structure."

    You say in a separate post that WD's Org Chart supports hierarchical relationships between orgs of the same type.

    Thanks

    ReplyDelete
  2. Hi Pete, I put together a few thoughts on your question here:
    http://aboutworkday.blogspot.co.uk/2013/08/organization-elements-in-workday.html

    ReplyDelete

  3. Howdy! I just want to give an enormous thumbs up for the great info you’ve here on this post. I can be coming again to your weblog for extra soon.
    ebook conversion

    ReplyDelete
  4. This is a really good blog on everything Workday. I have been exploring it myself for 6 months now and I would like to add another one. Historical data. In PeopleSoft world doing correct history can help you easily go through setup and employee history while this is really painful to do in Workday. Atleast thats what I found.

    ReplyDelete
  5. Hello! I was wondering what technology you used to manage the data migration from PS into workday? I have read about iLoad, but maybe you have other tips?

    ReplyDelete