Wednesday, 28 March 2018

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. 

Wednesday, 21 March 2018

Guest Writer 1 sends us another post!

I sometimes receive emails from people who are trying to transition from other technologies (SAP/SuccessFactors, Oracle/PeopleSoft, etc.) to Workday. Here are some thoughts from Guest Writer 1 on the topic. If you'd like the honour of being 'Guest Writer 2,' email me a post: helloworkday@gmail.com. In the meantime, enjoy the thoughts of Guest Writer 1:

I’ve been reading Vinnie Mirchandani's  excellent book SAP Nation recently. It points out that the economy (what software folks rather oddly like to call an ecosystem) around SAP is about the equivalent in size to the Republic of Ireland.  Quite a few SAP customers have contributed to the book, directly or otherwise.

I don’t know how Workday compares and I have neither the time, the resources nor the inclination to find out.  What is certain is that whatever the size of the Workday economy, they (Workday) have a very significant slice of it.

Very little detail of the detail of the contents of Workday applications leaks out - it’s quite remarkable in comparison to other software and services vendors.

At one level this is entirely understandable.

It’s a fierce world out there in enterprise sales - competitors will seize any chance they can to point out a lack of functionality or a customer who would prefer something added or something to work in a different way. Less scrupulous competition will even bend the truth and try to sow fear and uncertainty.

On the other hand, almost every other vendor has an active community beyond the bounds of its own websites and social media where people swap frank opinions about various aspects of software and services.

There are a few independent voices, Matthew Heminger, Ahmed Liman are two, but they are part of a rare but slowly growing breed of professionals operating in connection with Workday but remaining outside the tightly controlled world of Workday and their partners.

Time will tell whether the “grey market” in Workday Talent will become significant. What is certain is that ambitious and industrious folk in various parts of India are gaining Workday expertise through some official and some very unofficial means. For those of us who have been around long enough to remember PeopleSoft, this is a familiar picture.

Workday continues to restrict implementation access to those who have officially certified training - and outside of Workday this means partner employees only. Since becoming a partner is way beyond the reach of an individual or even a small company, this effectively rules out self-employed contract workers from working on implementations.

Again this is understandable from a Workday perspective - much has been made of the “Wild West” that exists in talent available for projects involving other vendors and Workday avoids this by the tight controls.

What is clear is that it's not just the approach to software that Workday does very differently.

Whether customers benefit from the official "partner only" lockdown depends upon who you talk to of course.

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.


Wednesday, 14 March 2018

A guest post

It's been a while since I've written anything. I have requests from companies who wish to pay me to put content on this site but I will always keep this site as an honest blog. Just my thoughts, opinions and perspective on Workday as someone who is learning things as I go. I always welcome the thoughts, opinions and perspectives of others and I am especially pleased that a guest writer has sent me the following post.

A guest writes...

I’ve been reading this blog since it started. It’s really interesting (and remarkably rare) to see a “warts and all” unbiased account of what it’s like being a Workday customer.

I feel a bit sorry for local UK (or anywhere else) providers - they can deliver peerless products for UK users, but they’ll be ignored by any company that wants a “global” solution. Anecdotally it seems that quite a lot of Workday’s UK business comes, as PeopleSoft’s did, from US multinational organisations who buy primarily in the US and then decide they can use the same solution elsewhere.

I can also see both sides of the “global” argument - Workday has delivered a lot more global (non US) functionality over the years (and with a considerable investment in Dublin recently this is set to continue apace). On the other hand, my reaction when I read the early blog postings and other musings online was “more fool the buyers”. In other words, don’t buy a product and then complain it doesn’t have a certain piece of local market functionality.

If UK (or elsewhere) customers rejected Workday because there wasn’t enough local market content, they (Workday) would have to act.

Businesses are assumed (certainly within UK law as I understand it) to be more “savvy” about the business contracts they sign than ordinary personal consumers - and are therefore expected to do their homework about products and services they buy, so I don’t have a lot of time for them complaining later that something doesn't do what they want - unless they were misled (and I don’t believe Workday does that).

It seems to me buyers balanced missing local content against a global single system (I heard one HR Director say so directly once at HT Tech in Amsterdam).

Personally, I rue the loss of some local colour (note the spelling) in the UK due to “American Cultural Imperialism” - but the blame for this lies in two places - and a considerable amount of it has to go to people in the UK just adopting a lot of idioms, spellings, business pricatises and cliches from the USA without question.

Guest Writer 1 and I welcome your thoughts about this post. If you'd like to see more posts from Guest Writer 1 and others, please leave a comment so that we know. Or if you'd like to write something for this blog, please send it over to: helloworkday@gmail.com

Monday, 1 January 2018

Name formatting in Workday

I am currently looking at Workday's name formatting. When a user logs to look at an employee's data or to enter a new employee they see a country-specific name format, like this one for the US:


Workday defines the name format for you by country. It is one of those 'it's SaaS you'll take what you're given' situations.

For my dear readers in India, the India name format is this:
  • Prefix, Given Name(s), Middle Name, Family Name, Local Given Name(s), Local Middle Name, Local Family Name, Suffix

For our friends in China, you'll see this when you enter a Chinese employee:
  • Title, Chinese Family Name, Chinese Given Name, Given Name - Western Script, Family Name - Western Script 
This structure looks great and you'll be consistent. No matter what company you're working at you'll always see the same fields per country.

Here's the name formatting challenges in Workday:

1. You cannot turn parts of a name on or off.

Some companies consider their payroll systems to be 'king,' especially outside of the US. If your payroll system only contains first and last name but not middle name, you'll need to add the middle name into the first name field instead.

When Workday does not let you hide the middle name field you'll be in a regular audit battle to get your self-service or HR users to put it into the first name field instead of the delivered middle name field.

Or you need to code around it, so that your interface to payroll takes the middle name field and concatenates it into the first name field.

In my perfect world the customer would be able to configure what fields they would like displayed per country.

2. Workday dropdown values are not delivered.

I had thought that one of the advantages of a standardized SaaS would be to deliver standard values such as the name prefixes like 'Mr.' and 'Mrs.' This isn't the case, they are defined locally in each tenant. In theory, you set these up during your initial implementation and never touch them again. It becomes interesting if you do an acquisition or merger of two different systems however...

For the United States company A has 'Mr' set up and so does Company B. Each company has had to set up these values on their own.

It becomes interesting because the references IDs are different.

Company A set them up consistently using the full country names:
Mr_United_States_of_America
Mrs_United_States_of_America

Company B used country codes instead, so they look like this:
MR_USA
MRS_USA

At one point they started to add a 'w2' and 'w3' which was probably 'wave 2' and 'wave 3', so that we had 'MR_CAN_w2'. In a few cases they missed to add any reference ID so the system generated one for them.

The end result is a patchwork mishmash of inconsistent coding for the reference IDs which are used by integrations.

Company A and B need to go through an exercise to decide which values and reference IDs will be used in the future state and integrations need to be reviewed and revised.

I just don't understand why Workday doesn't deliver some of this stuff right out of the box.

Wednesday, 13 September 2017

Workday's new user interface


One of the things that I hear frequently is that users *love* Workday's interface. I can see why, it's easy and intuitive to use and pleasant to view. So I'm quite surprised that they're bringing out a new version of it. Here is a preview, the left is the current version that we know and love and the right is the future version:



My initial reaction is 'ugh!' It's called the 'canvas user interface' rather than the landing page.

Why is Workday making this change?

According to WD it will make for a consistent branding experience between desktop and mobile users. It will also allow for more branding by customers in mobile. On the plus side the blue that you see in the canvas can be customized in color, so if your key company color is red you can change that. Users will be able to set whatever color they want on their mobile devices however.

Also WD stated that the darker text will be easier to read.

When?

Workday is handling the desktop experience separately from the mobile UI. Mobile is already in production. Customers can preview and use the new interface in desktop production but it's an opt-in. Everyone will be forced into using it as of WD 31 in Sept 2018. In the meantime your users are suffering through an inconsistent experience between desktop and mobile.

Customer impacts?

At least customers have a year to start changing any of their documentation, training materials or job aids. This is a major overhaul in the look of the software.

User opinions?

As I informally chat with HR systems people in my WD circle, no one is impressed. In the greater WD community people are seeing it as a step backwards. In particular people are wondering why WD is devoting so much time to making its product mobile friendly when so many users are desktop based. My personal favorite is the people who are comparing it to software of yesteryear like old Windows systems or *shudder* PeopleSoft 8. I actually see the PSoft comparison on the drilldown pages, plus the sample blue is similar to the PSoft blue.

Wednesday, 18 January 2017

Auditing Workday configuration - replication dates

I am receiving many emails in the past weeks about auditing Workday.  Workday offers courses specifically tailored for auditing professionals.  In case you are preparing for a WD audit, I'd like to share some of these solutions with you.

From the mailbox:

I am an Auditor and my client uses workday. I audited configurations on Sandbox and client mentioned that Sandbox is replicated from production environment but client was not able to show me how to see replication dates. 

Can you guide me , how to see replication date or configuration for replication (Prod > Sandbox)?

As a former IT auditor, these questions make my day.  Auditors are not dreadful people.  One of the key rules I've found with auditors is that 'there are many routes to the same city.'  Meaning:  as long as you can prove something to me, I don't care what method you use, as long as it is reliable. 

Question:  How do I prove when a Workday Sandbox was copied from Production?


1. Ask the customer to log on to Workday Community and print out the documentation that states mandatory sandbox refreshes once per week (it exists, including the timing).

2. Ask the 'Named Support Contact' (the person who can ask for/defer refreshes) to log on to Workday Community ad to go to the tenant management page.  Print this log.  It will prove that the customer did not put in any 'defer sandbox refresh' requests during your audit test period.  Therefore you can depend on the copy date as detailed in step one.