Auditing Workday business processes

I've previously talked about Business Process functionality in Workday.  Today a topic near and dear to my heart is auditing those business processes (BPs).

Most companies have auditing or corporate governance in place to minimize risk; in the HCM world areas that often require auditing are processes and procedures that relate to hiring, pay changes and terminations.  These are areas where fraud can occur, such as the hire/term of a 'ghost' employee, or pay increases that are not authorized.

How do you audit business processes in Workday?

 

Similar to how there are many routes into a city, there are a variety of ways to get this job done.  In our case, our Compliance department decided that these 4 Workday BPs should be audited quarterly:

-Hire
-Change Job
-Request Compensation Change
-Termination

Our Compliance department does not state 'how' you need to do a job, but instead they have requirements of what is necessary to prove at the end.  Their requirement from us is to 'show that no unauthorized changes occur on the business processes.'

How do we do this? 

We have a set of Work documents for each process; they include a variety of details about the process, such as the process description, the participants, requirements, regulatory reports required from the process (if any) and importantly for us here, the business process flow broken down by steps (both internal and external to the system).

Our locked down Word documents are the 'golden copy' and our Workday business processes should always mirror the same tasks, performed by the same roles, with the same conditional logic, etc.

So for each audit, it's a matter of using the Excel button in Workday to download each BP and then bringing our Word documentation steps into this Excel and manually going line by line to make sure that they match on 'who,' 'what' and 'how'.

Isn't there an easier way?

 

You'd think there should be, as WD always highlights the audit aspects of their system.  So I set out to find a way to do this task in a more efficient manner than I just described.  In addition, back in the early days of my career, as an auditor myself, it was always easier to pass a process which was locked down systematically and performed automatically, as opposed to one that someone had to remember to do and where eyes can sometimes miss a line or a step.

Here are some items that I looked into:

 

1. Use the 'Audit trail' feature 

One of the nice things about Workday is that it has a built-in audit trail automatically turned on.  So while you're on a page, such as the Hire BP, you can click through to "View Audit Trail" and see an audit trail for the object:

Does this solve my problem?

Unfortunately, no.  While it will cover the 'big things' like if a step or notification is added/deleted it does not show the changes if a step is edited, for example.

2. Use the 'View User or Task or Object Audit Trail' report  

This one looked promising, like it would allow you to audit all BPs for changes at once, rather than individually per process.  (We'd like to be able to edit more than the four I previously specified, but using the manual method did not justify the risk.)

Here's what this one looks like:

When you run it in a Sandbox environment it looks quite interesting showing new value, old value, the operator who made the change, date/time stamp, etc.

  
Does this solve my problem?

Unfortunately, no.  When I ran this one in Production for a one month time frame, I got the message:  "The number of transactions found in the specified time range exceeds the report limit of 50,000. Please narrow the time range and try again."  Looking on Workday's Customer Connection, it seems that others have the same experience.  It seems that something is not indexed correctly or there is some other issue that you're filtering through all transactional audited data rather than only the BP audit data.  Those could perhaps be workable if you're a smaller company or have less transactional data or are only auditing on a very narrow time frame, such as a week.

So now what?

I turned to the trusted Workday Community, with the hope that some brighter mind than me has come up with an awesome solution.  It seems that the question has been asked many times in the customer forums over the past few years so I sifted through the responses with high hopes.

There are some newer features and customers have presented some ideas.  I will not bore you with these in the meantime, but the above was meant to illustrate the types of steps that you need to do as a Workday customer to meet a basic business requirement when it's not delivered out of the box.

But I just want a basic report!

We are currently trundling through our rest of world (non US, Canada, Mexico) Workday implementation. We are in the second round of test loading data.

As a part of our data validation our Workday implementation partner is issuing reports to us from the test system. I am combining these reports with PeopleSoft reports in Access. Then our HR community is reviewing the data to ensure that it matches.

One of the items that we need to validate is 'HR Partner.' In PeopleSoft we have an HR partner assigned at the department level. We're bringing that over to Workday and assigning an HR partner to a supervisory org (along with other roles such as Absence partner).

I have a report from PeopleSoft, it includes two fields: Department ID and HR manager ID.

Trying to get the equivalent from Workday is like trying to get blood from a stone.

First our Workday implementation partner ran me a report that looked something like this:


Our Workday implementation partner seems to be staffed with consultants who have never worked in-house. Fair enough, a lot of consulting houses are like this, as they've never done operational support they have no concept of how things actually work once the software is turned on.

I know everyone likes to say how great Workday is, that you no longer need to know codes you can work off of description but try matching on names from two different systems. People get married, etc. it's just inefficient.

Also, how am I supposed to parse all of the gobbletygook in the box?

I clarified the request and asked specifically for 'Supervisory Org code' and 'HR Partner employee ID'. In return I received this response:

Due to the Worker, Sup Org, and security business objects in Workday, we’re limited from splitting out a single org’s assignments into multiple rows when an org has multiple assignments. We’re trying one last effort during India time tomorrow to see if we can get it to work, but it’s not looking promising.

I mentioned a while back when I took the reporting class, how Workday reporting is not intuitive, but these folks are experts, Workday certified consultants.

I'm not quite sure if the problem is consultant knowledge or the Workday system itself. If I ever get to the bottom of it I'll let you know. In the meantime we'll just go on a wing and a prayer than our HR Partner data is being converted successfully.

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. 

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.

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.

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

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.