Sunday 18 March 2018

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.


2 comments:

  1. Sorry to hear that the basic HRI like Marital status is custom in workday, not sure what may be the additional effort for this. This way Successfactors definitely wins the race; even custom fields are easy to configure. One thing I came across in successfactors - The Title field available in EP (like CPA, PMP etc are not possible to use in any EC custom (HRIS) field either through Sync or Rule. This impacts supervisors Title if required in Employee's supervisor data.....

    ReplyDelete
  2. This could be tricky in Asia, where marital status drives benefits, tax or other statutory deductions. Defining it for each company is definitely a pain.

    ReplyDelete