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.  :)

Workday job aids - learning and using Workday

In the Workday sales cycle, one of the things they often emphasize is how easy it is for the users:  HR, managers, etc.  Once you're in the implementation phase, however, you realize that you need some type of help documentation--the system is not standalone and usable without some background/training.  Workday does not mention on their 'main' webpage, but there is plenty of discussion about this topic on the Workday community--they're called 'job aids'.

Job aids are 1-2 page instructional documentation, to help a user to perform a task.  They are meant to provide just in time information to a user or manager who needs to perform a task.  According to examples presented on the Workday Community site, companies are handling these in various ways:  Word docs, pdfs, instruction on internal company portals, etc.

Examples of job aids would be:

• Logging into Workday
• Changing your Workday password
• Create a position
• Create a requisition
• Separate an employee
• Delegate a task
• Hire an applicant

The interesting thing for me to see is how companies are approaching this topic.  Because WD changes three times a year, many people are trying to minimize the screenshots and just include the menu path.

For example, here is a piece of a sample from Community:

Notice this company is not using screenshots and minimizing the actual pictures/icons used.  Doing so makes upgrades easier, otherwise you'd be re-doing these docs three times per year potentially!

As a global organisation, our company is particularly interested in this topic of user training on Workday.  In particular, because we have very limited manager self-service capabilities in the current system.  We provide view only access currently.  In the post-Workday world, managers will be able to initiate transactions, such as pay increases, terminations, etc.

Where to find more info on this topic

IF you're a Workday customer, the Workday Community provides many job aids.  Search for 'job aid' in the search box and then select 'Shared solution' on the left under 'Filter by'.  There are at least 30 samples out there, probably 50+ if you search well.

IF you're not a Workday customer--there are still options and Google is your friend.  :)

Many customers post their materials and for whatever reason they are open to the world.  Type 'Workday job aids' into Google and you'll see what I mean.  Here are some examples of what I've found recently:

Cornell University transfer process
Activis goal setting
Tyco's hire documentation

Hope this has been helpful.  It seems that many companies are handling this training topic differently, so always great to hear what others are doing, so that we can all learn more and produce a better user experience.

Feel free to add any insight into the comments.  :)

Data loading in Workday HCM - a functional view

Having spent 14 years and counting in an HR Systems (or HRIS or HRIT, pick your favorite term) capacity, as we all know, data loading is a necessary evil, in particular for big processes, such as year end merits or performance review uploads. 

Background:

Working in a large company 150k+ emps, we load data every single day.  Mainly it's of a daily operational nature rather than the yearly processes.  When we acquire a new population, even if it's only 100 people, we try to save the data entry people the effort of loading.  As well, we have regular changes of coding, such as cost centers, we have increases in the data we're storing--so maybe a group needs to start storing a certain element.  Finally, we have data changes--so our job codes change, or grading structure changes, etc. 

Currently, my team performs this data loading in PeopleSoft, using Excel to CI functionality.  Previously, we loaded flat files using SQR or by having a developer write SQL.  In the new world, we'll use Workday's EIB functionality to load data and make data updates.

System Functionality:

You log into WD to generate spreadsheet templates.  You populate the templates.  Then, you upload the templates.  If you've using PSoft's Excel to CI, the user interface is extremely similar.  I've spent some time trying out this functionality in our test tenant; as well, I asked one of my analysts (who is a bulldog about the details of doing it right in our current environment) to try it out as well.  In addition, we had a demo yesterday by our consulting partner, who walked us through a new hire load.

 

My take:

As mentioned, we load data every day.  We're used to looking at data and codes and running reports to pre-populate Excel sheets for our HR data entry partners to fill out further before sending back to us to load.  The steps and overview of the process itself in WD is simple.  You can generate a template in minutes.  However--you need to know the data structures or else it will never work properly for you.

For example, when you choose the New Hire delivered option, it creates a spreadsheet with 20+ tabs.  There is an overview tab where you go through each line item and state whether it is 'required' or 'optional'.  So if you are not tracking visa or work permit data for a new hire, you'd mark that item 'optional' and not populate it with data.  In addition, once you start to look at each tab of data, you need to know what you want to load.  For example, if you look at the 'Names' tab, it gives you all the country variations, preferred names, legal names, etc.

Your only saving grace from my perspective is to go into the template creation step and manually shut off these tabs and fields before generating the spreadsheet.  Otherwise, it will be overwhelming to the end user.  This 'generate template model' is also nice, because it allows you to assign comment text which will then be on the Excel as help for the user.

It's a little tricky though, as you need to know what data will override other data.  For example, our consultant doing the demo had mentioned, 'you don't need to populate job title as that will come from the job profile, otherwise bla bla.'  Ou HR person asked how we should know that from this sheet?  'Uuuuuh,' was the answer.

It's no magic wand, but data loading never is in an HRIS.  On the plus side, when you try to load the data, it runs through the data entry checks as if you were doing the entry online, so less cr*p data is making it into the system.  On the minus side, these Excels are a freeform adventure--you need to know your data structures and codes.  For example, if your employee ID starts with a leading 0 but you miss to include this, the sheet doesn't notice that you're a digit short.  It's only when you go to load that the file will bomb out and you can review the error log.

HR's take

This demo was the first time our HR colleagues were seeing this functionality, and there was some disappointment.  During the sales cycle, this functionality was very highly recommended as 'easy' and 'user-friendly'.  As a result, as a part of our HR transformation, this 'data loading' function was going to move to the data entry professionals.  It was seen that instead of them spending two hours doing manual entry, that in 10 minutes they'd be able to load data perfectly.  HR is now adjusting processes and personnel to take into account in the new world that this is not an end-user tool.  Those data entry folks would still be responsible to fill out the Excels, but it was recognized that it wouldn't be *these* Excels as generated from Workday.

 

How do other companies use this functionality?

We asked our consultant this question...mainly it sits with an HRIS, HRIT or whatever you call your IT-minded staff who support HR.  In a few exception cases they'd seen data entry folks getting this access.  In some cases they'd seen the opposite end of the spectrum, that companies built custom spreadsheets that HRIS or whomever would then massage into these templates.

Note:  Current WD 19 does not allow you to pre-populate the sheets when generating them.  So you would need to generate your sheet, generate a separate query and do some cut/paste work to get them pre-populated.

 

What should we ask about in the sales cycle related to this topic?

I would suggest, ask for a 'new hire' demo, with the consultant generating the sheet from scratch, so you can get an idea of how it looks, and ask to see the 'Names' tab.  (Granted, it is dependent upon how much demo time you have.  We had a week, so an hour was ample in our deep dive schedule). 

Alternately, ask for copies of a generated Excel workbook (with the 20+ sheets 'as is'), as well as a sample error log. 

In addition--ask to see the documentation that supports your team in performing this function.  I suggest this as:  1) the WD community documentation is not so great.  It gives a high level overview, but it's not in-depth enough.  My analyst spent days on a 'try this and see if it works' method of working.  Also 2) EIB training comes under the technical side of the house, as part of the overall integration framework.  So if you're expecting your business users to generate and execute the load, you won't be able to get them training, as this piece is embedded into the bigger integration training.

How good is Workday HCM?

Someone found this blog through typing 'How good is Workday HCM' into google.  I began to ponder that question, with 10 months of implementation experience behind me...

As a SaaS, it's as good as any other SaaS HRIS.  If you want the pre-built processes, fields etc along with heavy configuration/low customization, it's great.  If you have a highly customized environment or your business cannot fit the pre-defined mold of a delivered system, it's probably not the best option at the end of the day (nor would any other SaaS be a fit for your needs though).

If you're coming from *no system*, it's probably an easy way to jump quickly into an HR system, with little or no fuss.  Everything is pre-built and out there, you only need to start using it..

As far as functionality goes, the system offers the fields and processes one would generally need.  My major area of concern remains the 'global' pieces.  I noticed last week on the Workday community that one of the HR Consulting houses had published a set of reports into the Workday Solution area of the Workday Community.  This is the area where customers can publish their solutions, as a means to help others.  While it's great that this consulting firm created this set of country regulatory reports, I am a little surprised that WD does not pre-deliver this solution as a part of the base product. 

For the end user, the system does have a high degree of usability, and a well-designed user interface.  If you're used to a 'traditional' HRIS, you're used to a set of menus and training manuals that take you to various places.  WD instead drives everything off of the 'search box' functionality.  So if you're looking for an employee or setup data or a process--you simply type the keywork into the search box to be given a set of options that contain the keyword.  From a training perspective, it means that you don't need to focus the user of following a strict set of guidelines to follow a path to get to data.

Also, the interface has a 'webpage' look and feel.  When a manager is looking for data about an employee, or an employee is looking for data about him/herself, it's all available in dashboards and easy to find via following 'about me' links and such.  It's intuitive from that perspective, and much more like a 'web page' than a 'system'.

One topic that I have not yet discussed on this blog is the frequency of updates.  While it's great that WD is constantly evolving, it does equate to updates occurring three times a year.  On one hand it's great to have new functionality, on the other hand it requires you to then have a team that is responsible for testing new functionality, new configurations, testing and communication to the end users.  As well, if a  user is trained in doing things a certain way and they suddenly change, that may be confusing or even annoying at the end of the day.

Other thoughts anyone?

My review of the Workday Report Writer training

I recently attended virtual training on reporting from Workday. While you get a high level overview of reporting in the HCM Fundamentals class and run one report, Report Writer is the first reporting class that you can take to learn how to create your own reports.  It's a virtual class, 10 hours spread over two days. 

At first glance, the WD reporting product is not the easiest to learn on your own with no instruction (believe me, I tried!), especially if you're used to a relational database model.  In WD you can access the reporting tool from within a page, so you can click the 'related actions' from a hyperlinked field and choose to 'create report from here' or to view related reports.  However, if you don't have the report basics, you will soon be lost.

I'm happy to say that the two day WD training cleared that right up for me.  The class starts with some background about the WD database structure and some high level details about how the reporting works.  Then, you start to run delivered reports, then you build basic reports (on one object such as the Worker object), and finally advanced reports where you combine objects and then some simple matrix ones where you run counts, similar to an Excel pivot table.

This class was probably helpful to me at this point, because I now understand the structure of Workday, and how there are various objects such as the Worker, Location, Company, etc. and how the data is clustered around these objects.  There were some people in the class who have never seen WD beyond attending the HCM Fundamentals class (a required pre-requisite for this course) and they were lost before the end of the first day.  If you are at least in the implementation stage and have some idea of how to navigate around the WD system on your own and hire someone, for example, you'll be fine.

WD offers Report Writer as an introduction to reporting, then you can follow it up with Advanced Reporting and Analytics (15 hours over 3 days) and/or Calculated fields (15 hours/3 days).  These are all virtual options, with Report Writer being the pre-req to the other two.  There is also the option to do the reporting suite in a classroom setting by taking Workday Reporting:  Basic to Analytics.

That being said, assuming that you have a test tenant to use and can get a hold of the manual, you could probably walk yourself through the training quite easily. 

Some of the things that confused me at face value, before taking the course:

1. The overwhelming plethoria of fields with the same name.  Every instance of a field is its own reporting field.  This differs greatly from a relational database, where if you have something like 'jobcode description', you'll have one jobcode table with a description and you tie your code on your secondary table back to your foundation table. 

If you type 'Name' into Workday to find the field 'Name', you'll quickly get confused as you'll get all sorts of Names (descriptions) for things.

2. The icons used in the reporting tool.  The icons are meant to give you short-cut details about a field without having to look into the details, but until you know what they mean, it's a bit confusing.  Sure 'T' stands for text and '#' is a number field, but what's the thing that looks like a spoon?  Or the fireworks?  Once you know that the spoon is the base table and the fireworks represents a one-to-many relationship, it becomes a little more clear.

Once you get a handle on those basics, it becomes easier to navigate through the tool.

The one odd thing to me--and granted I come from a mix of HRIS systems from basic homegrown MS access applications to more sophisticated tools like PeopleSoft--is that WD locks down reporting from the join perspective.  So if you're doing a 'basic' report, then you're only working on one object--say 'Worker'.  If you change your mind and need other data that is not on Worker, you need to convert to an advanced report (which is possible).  However, if you start your report on an object and discover that it does not have all of your fields, if a join does not exist, you cannot 'force' a join the way you can in other databases.  You basically have to begin again, this time using the 'right' datasource.  I can imagine that one causing some frustration at the user level.

To view my other posts on training, click here.

Thoughts on the workday user interface

After sitting in many hours of workday demos and looking at the workday application a few thoughts on this topic:

• It’s intuitive and user friendly. As the user looks at the screen, everything revolves around the ‘wheel’ concept. So imagine a clock, where each of the numbers are a different subject area (benefits, payroll, comp, etc.) As you choose ‘payroll’, you then get another wheel with the various payroll tasks available around the wheel: w2 update, deductions, etc.
• The search functionality is divine. If you know part of a menu or topic, you type it into the search box in the top right and it brings up a list of topics that reference it.
• It has much more of a modern web-feel, in comparison to other HR systems that I’ve seen in the past. Perhaps that is due to the fact that it’s not a product that has been around for 20 years and thus evolving based on a previous platform. Or maybe because it’s been designed in recent years, where user centric design, usability and user experience (UX) are more common topics and the norm rather than the exception.
• Sidenote: if you are designing HR Systems or functionality from scratch (rather than implementing a SAAS out of the box like workday), Human Factors International is one of the best resources in the area of web design and usability.
• The Management Dashboard and the drilldown available in the dashboard reports seems quite impressive. Granted, it requires that you’re storing all of the data that is utilized in the reports (we won’t be). For example, we saw overall reports of total comp, and we won’t have all of that data.
• Also, there were concerns from our comp folks that the management reports went too far; so it allowed managers with employees in different countries to have currency conversions, to be able to compare employees around the globe. However, when taken only from a numbers point of view at face value, it makes the employee in Switzerland look much less attractive than the employee in Mexico, as the wage differential is enourmous. What the system doesn’t fully explain in such situations, is the whole topic in comp of paying market rates, and understanding where someone is in the band, etc. Otherwise, you get a knee-jerk reaction that all emps should be hired in low cost countries, if you are only looking at emp salary costs.
• It is possible to get a glimpse of the user interface from the workday website. They offer some recorded ‘product previews’. They’re only little videos, under five minutes, and you do need to provide some registration data in order to view them. Also, they move pretty fast, although you can watch a few times. If you’ve never seen the application, they’re worth a quick look.