How to learn Workday

It seems from the stats that a few people come here wanting to find out:  How can I learn Workday?  A few thoughts...

1. Join a consulting company - Here in the London area, Workday is a very hot skill.  Even if you do not have actual Workday experience, as long as you have some other ERP or SaaS experience, companies are willing to hire you on (especially consulting companies), on the premise that it's easy to train you on this new software, as long as you have some HRIS experience.

2. Take an entry level position in HRIS - As well, companies that have already implemented the software are looking for people to maintain it, in HRIS analyst roles.  If I was an entry level or junior person, I'd take one of those positions to build up some experience.

3. Take the training/get a look at the training manuals/get access to a test tenant/get access to the Workday Community - It can be difficult to get started in this area as you cannot get access to a test tenant or to the WD Community unless you are an implementation partner or a customer.  However, once you are, the Workday training provides a good foundation to get started.  As well if you are a self-starter, there is a lot of learn from the documentation, if you can get access to it.

4. Join LinkedIn groups - There are a variety of LinkedIn groups that discuss Workday functionality.  Join them all.  :)

5. Apply for positions at Workday itself - Having worked for PeopleSoft, I understand the Workday work environment is similarly quite good--sharp and dedicated people, a fun place to be.  I've heard what they might lack in compensation they make up for in intellectual stimulation and a pleasant work life balance.  Try here to apply.

6. Read blogs - There's not a lot out there (yet), but some good info is starting to emerge, if you search for it on Google, etc.

Other ideas?

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.

Customization in Workday - Custom Objects

As a SaaS solution, customer customization of the Workday application is limited to the delivered customization options that you as a customer can configure, and mainly that involves the use of 'Custom Objects'.

Custom Objects can be considered as 'free fields' which you set up to use however you want.  They are attached to the various WD objects such as the Worker object, Location, Company, etc.

An example:
We have a manufacturing location in Europe that is required by law to issue safety clothing to the employee on a certain schedule, so every 6 months they receive a new set of trousers, every 12 months a new set of safety boots, etc.  This clock starts as of the employee's start date, so every employee would have a different date to get new clothing.  (Workday has some business asset/company property functionality so we might put it there, but we're just using this as an example.)  Our goal is to put all of this data into the system, to avoid the need to have any data in Excel, etc.

So your Custom Objects need to be applied to the Worker Object.  We need 3 fields: 

1. Type of Clothing (boots, shirt, trousers, etc. choosing from a dropdown/validated list)
2. Size of Clothing - needed for HR purposes, so that we know how many size 40 trousers to order for next year
3. Date received - this is important, so that HR can run reports in advance, to see when they need to provide the employee with new items.  In particular, we have a night shift and while HR rotates to try and provide a presence during some of these hours on some days, they need to ensure that the supervisor receives the clothing in advance, to avoid any issues with the union that contractual obligations are not being met.

So in our case, our data entry person would get to any entry screen like this:

Date Received:
Uniform Type:
Date Received:

They're quite easy to set up and configure, once you make the decision of how your fields should be defined.  You only need to define things like:  Field Label, Field Type, Prompts, Validation, Status, etc.

The above example took about 5 minutes to set up.  The key is knowing your business requirements.

So in thinking further about Custom Objects:

Advantages:

• You can set them up to meet your business needs.  For example, if you need to track something which is not typically found in an HR database, this is the place to do so. 
• There is some flexibility in how you set up these custom fields.  For example, you can choose to set them up with some validation values, or you can make them formatted as a date, etc.
• It's 'easy' customization that doesn't involve any development--it's merely 'configuration'.
• You can do EIB loads into these Custom Objects, if you'd like, to be able to load data.

Disadvantages:

• You can only apply custom fields where they are delivered at the object level.  For example, you can apply custom fields to the Worker object, so associate custom fields at the employee level.  Or you can apply custom fields to the Location object, so for any custom fields you may need to associate with a location. 
• However, if you have a custom field that is not associated with Applicant, Company, Customer, Job Profile, Supervisory Organization, or any of the other objects available. but instead a different object that does not have Custom Fields associated with it, you will not be able to use it.
• There is a limit of 20 custom fields per custom object!  This is a big one.  It means that you may only store up to 20 custom fields at the Worker level.  In my above example, this would use up 3 of 20 custom Worker fields, leaving 17.  At a global organization, this is insufficient for our HR needs.
• You can store up to 100 instances of a custom object in each instance.  In my example then, let's say that we are storing 5 types of clothing for a worker, and that each worker gets a new set of 5 rows every 6 months.  At 10 rows per year, we'll be out of space in 10 years.  Of course we can archive the data to Excel after a certain time to make room for more, but it would be nicer if we didn't have this concern.
• The data entry for the user isn't so nice.  The user does data entry on custom objects in a stand-alone area for each object.  The fields are not able to be integrated into the 'core' object in a logical fashion.  In our Uniform example, we need to count on the data entry operator to go to the Custom Object area for the Worker to enter the needed data.  This is a different menu item from Job or Personal Data, so easy for the entry operator to forget.

Final thoughts:

• I like the functionality, and how easy it is to 'customize' the system.  In our old ERP such new fields would involve a customer request, request approval, a functional spec, development effort, testing, test documentation, and a production turnover.  Creating these fields in WD is a much smaller effort. 
• We need the option for a lot more custom fields, or we need WD to better enable the application with more regulatory reporting and global fields.  In our implementation we are not able to use the fields for 'business needs' because we need to utilize them to hold regulatory data which is not addressed by WD.  It would be great if WD would increase the limit to say--40 per object.