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.

Is Workday more complex that it appears? Or is the software not strong enough?

I've had a quiet week as my US HR colleagues are currently on an emergency trip to the HR Shared Service Center to try and sort out some Workday operational issues.  As you may recall, we had a soft launch in the US in December.  Now that everyone is back from their holidays and the first monthly payroll of January has run, it appears that post-implementation issues are larger than expected.  So a swat team of HR project members are planted in the SSC office to try and train them again and work through some issues.  A few key points:

1. It appears that some end-to-end processes really are not end to end.  So the processes work in the system, you can hire someone, transfer them, but at the end of the day, all of the dots are not connected on the process side, so they have orphaned tasks or recognizing that the WD process is a certain system data entry piece piece of a bigger functional process, such as a hire which requires non-system activity such as background checking.

2. Robustness of manager processes or lack of manager training?  My boss has been trying promote an employee using the manager self-service and it's required multiple HR people to help him to do this task.  Noticing online, there's not a lot of opportunity to provide dynamic help text, especially along the way.  You can enter help text into a transaction, but it's not smart enough to recognize what is wrong necessarily, which is the issue.  As well, the system is a little bit loosey goosey.  It's not as locked down as it should be for less knowledgeable or astute managers.

3. Change management/staffing.  In the sales cycle, it is insinuated that you can run the software with only trained monkeys, it's that easy.  Our SSC (who are bright data entry people, btw) are new to Workday as well as to the company.  The software is not so intrinsically easy that they can just pick it up and use it.  Further, similar to the above loosey goosey comment, it lets them do things online that they should not.  Not that WD is not an easy software, just that it's not so easy like looking at a web page, it's a software application like any other, so it requires training.  Further, with WD's updates, the pages change up to three times a year which does not help the people who are just learning it.

So I remain undecided whether the issue is:

• Workday isn't as easy as it is suggested to be.
• HR's training efforts were not good enough.
• The software is too flexible and open, so you actually need highly talented people to utilize it.
• Our implementation of the software is the issue, not the software itself.

Business Processes in Workday HCM

I was able to attend the Workday Business Process Fundamentals course a few months back.  It's an online only course, 4 hours/day for 2 days.  A few thoughts...

Business Process (BP) Functionality

Business Processes have been described as 'the heart of Workday'.  If you don't have the BPs built properly, you cannot function.  A BP in WD is the set of tasks that need to occur as a part of an HR process.  It is here that you establish and associate all the nitty gritty details such as approval chains, notifications, escalations, , validation, help text on the step, security of who is seeing what step, etc.

Examples of business processes include:  Hire, Propose Compensation, Create Position and Termination.  Workday delivers all the basic ones, and you just need to make the business decisions of how your process should work, defining the approvers, etc.

From a user perspective, they are easy screens to use--point and click, similar to using Excel.  Anyone can set up a BP...however, it requires some skill and businss understanding to set up the BPs in the most efficient manner. 

Considerations when setting up a BP

• Think about the future state process.  It seems that many companies are implementing WD in the US first, and then other countries later.  When setting up processes, you need to give it some thought as to:  Will you have 1 big global Hire process or duplicate the Hire process per organization/country/region, etc?  Otherwise, if you are not sure of your design, you will potentially need to change your BPs in a Production system when other countries come on board.  Of course, if you duplicate processes and apply country specific rules, this will cause one result with troubleshooting and maintenance.  If you build everything into one big one, it's a different result as far as troubleshooting/maintenance efforts.  Both solutions will require work--it just depends on how big your company is, how different or standard the processes are, etc.

• Standardise where possible.  This one goes without saying, as WD is built on the premise that your HR processes are standarized.  However, when we started to do some analysis of local processes, we found quite a bit of variation, as well as local needs.  For example, we had a lot of 'post-hire' activities, such as generating a parking permit in one facility vs. confirming that a safety training occurred in a plant with previous issues.  We made a decision that any 'localized' activities that did not involve system tracking would not be embedded into the business process.

• How many approvals do you need?  We debated this one quite a bit, as we had defined some processes with a 'Manager +1 approval' level, but then one part of the business wanted to add 'Manager +2'.  It would have impacted our process design and cause some if/then work in our processes.

Tips for designing your Workday Business Processes

• Build the process flow on paper first, rather than in the system.  Sometimes, it's helpful to see the process in action, in the system.  However, if your HR colleagues cannot agree in the first instance to a proposed process flow, then it's of little use trying to automate that uncertainty.
• Gather the requirements before you start to build them.  For example, knowing the user groups who can initiate the transaction, where help text is needed, etc.  I would suggest to use something basic such as Word, and to fill in the details before beginning any build activities.

Overall thoughts

It's helpful functionality, and will allow for a lot more automation than we are able to generate out of our PeopleSoft system today.  In addition, depending on how detailed you go with them--they will make for a nice user experience, especially for our managers, who will suddenly get a lot more visibility to data.  Not sure how much the managers will appreciate suddenly being initiators of HR processes though!

As well, for those of us who are worried about automating outselves out of a job(!) WD's BP's actually create more work, as someone needs to maintain or design new ones, as well to monitor the queue, for processes that have failed or are somehow stuck.  :)