Workday HCM - is it really that easy? Is everything really configurable?

I recently received a nice email via this blog (thanks for the emails and questions, keep them coming, it keeps me thinking), and it included the following question:

I have watched few demos and have gone through many articles and I am speechless when I see some of the them . However I dont know what is really happening in the backend and if everything is really simple and easy as they show in the demo?

Today I was thinking about this part:  is everything is really simple and easy as they show in the demo?

During our sales cycle, we had lots of questions while we watched the demos, and the answer to everything was basically, 'Yes!  You can do that via configuration!  It's flexible!'  As were finding out though, it's not completely 100% the case.  For example...

Configuring Org Chart functionality in Workday

Workday HCM offers some interesting 'organization chart' capabilities.  If you want more details of org chart functionality, here is a free job aid on that topic that I found while searching online.  Job aids posted by other companies can be quite useful, as mentioned.  :)  Here are a few screenshots from that document to illustrate...

When you're in WD, you can click on the blue 'org chart' button from a Worker:

Then, it brings you to the Org Chart page in WD.  From here you can navigate up/down and around the Org Chart:

It's nice looking functionality, especially if you don't have anything.  Of course like every other HRMS, it's not as great as the niche player software applications, such as OrgPlus.

How does it look from the backend/setup perspective?  It's quite simple to configure, actually.  There are multiple 'views' of the org chart, or various org chart options.  So you can have an 'Employee' org chart (as above).  Or you can have a 'location' org chart or a 'supervisory' or chart or a 'pay group' org chart.  Then, you can provide different data elements on these various views.

Each is quite simple to set up, just point and click to select the org chart fields to display, as well as whether or not to display the emp photo:

Looks great, easy to use.  However...

 

Configuration Limits on the Org Chart

 

1. You have a limited number of fields.  As above, you can see Lines 1-3.  Then you can add in the photo and the organization (such as in the Supervisory Org shown in the online functionality).  But otherwise--you cannot add more fields.  You cannot add a line 4 or 5, for example.  Our organization wanted to show more data, so then we started to consider workarounds, to make a calculated field to be able to squash more data into line 1, for example (which WD allows you to do).  However...

 

2. The org chart only allows you to choose/display 'public' fields or calculated fields based on those public fields.  Well sure, on one hand that makes sense.  If everyone is viewing the org chart, then it needs to be public fields.  However...in our case, we wanted to show BOTH job title and business title.  Business title is NOT a public field.  Therefore we cannot reference it in our org chart.  Sidenote:  someone on Community put in a Brainstorm for the exact same requirement, to allow them to show biz title in the org chart.  So far, it's not been picked up by WD for a future release.

 

3. The overall configuration is a little lacking.  For example, we often want some flexibility to not display people on long term disability leave.  Or in the specific case of Europe, where people have a termination reason of 'garden leave' (so they are released prior to their 'true' term date, often 3-12 months), while they are active Workers, they are no longer actively working for the company and therefore we shouldn't confuse people by showing this data.  There is no way to easily filter out 'active' workers in scenarios such as these from displaying in the org chart.

 

In Summary

 

Yes, Workday is configurable and flexible, however, I say this with a pinch of salt.  It may not be configurable to *exactly how your company wants it*.  And that, my friends, is the negative of a SaaS solution.  You must also be flexible in your business requirements to be able to use this functionality, and sometimes you must bend your requirements to meet how the software has been designed.

 

A tip

 

You just need to be aware of your business requirements.  It's like everything else when dealing with a SaaS solution (regardless of the vendor).  In this example, if you are evaluating WD, you need to be aware and document your requirements in advance.  If your requirement is just 'to have org charts' because you have little or no functionality currently, then no problem. 

 

If your requirement is to 'have org charts with 7 lines of data, and to be able to suppress certain data on certain levels of the org, along with hiding photos in Europe and on and on', then WD will not be able to meet your needs.  So it's important to know your requirements early on, such as in the sales cycle, rather than getting to the configuration stage and suddenly being disappointed that, 'I can't configure it the way I want'.

 

So 'is everything really configurable?'

Maybe--it depends on your requirements.  :) 



How to create a calculated field in Workday

I was having a discussion recently with someone, about the calculated field functionality in Workday.  I've previously posted about procedures and tips around using calc fields in an operational capacity, but I recently put together this quick example to explain the topic further, so thought I'd share it here too.

Once you're in Workday, the first thing to do is to define the type of calc field that you'd like to build:

There are many different options, more than I'm showing here, but the point is to know what you are seeking to do.  An average, untrained user would probably be stopped at this point.  Let's keep it simple and do a concantenation example.  It's also relevant to note--you need to know what business object should be invoked here.  We'll use the Worker object, since it's a main source for employee data.

On the next page, you're brought into a screen that functions in the same manner as the 'normal' reporting page.  So you can choose your fields, as well as add in the more intense logic if you're building something more complicated.  In my example, I just want to concatenate two fields together.  I'm using email+mobile just as a sample, so that I get a mix of letters and numbers:

Next after you save your new calculated field, you can use it in your reporting.  You need to choose the same Object (in our case Worker), to be able to find the field.  Then, your new calculated field will exist like any other field on Worker.

Then, you're ready to run your report.  Here's the example which I then ran into Excel:

 

 

A few points (and the reason I included a snippet of the output)...you'll see some workers have only a phone or some have only an email...so this is all you get.  So getting a good output on a calculated field will depend on what data you have to work with underneath it.  You can see where these can get tricky then as well, once you make more complex ones...is your bad output due to bad design of your calc field or bad data?

 

This was a quick and dirty two minute example.  WD offers a 3 day/15 hour training class on the topic, to get really in-depth with the logic of creating these special fields.  However, seeing how easy it is to create them, you start to get an idea of how dangerous they can become, if not regulated.  

 

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

Workday HCM security groups

I mentioned Workday security a while back.  Today, I'm thinking a lot about the concept of Workday 'security groups'.  In WD you assign users to groups.  The groups have various defined permissions.  If someone is in a group, they get those permissions.  A person can be a member of multiple groups.

 

A few key points:

1. Workday-delivered groups

Workday comes with some groups that get automatically assigned, based on WD's rules.  You cannot change/modify/delete etc. these groups.

Examples:  All workers, All contingent workers, All terminated people, All users, Employee as Self, Manager's Manager, etc.

2. Workday security groups get assigned a 'context'. 

This context is not changeable and it dictates what we'd consider to be 'row-level' security.  There are 3 types of context possible:

• Unconstrained - in such a group, the users have access to ALL data that the group allows. 
• Constrained - imagine a more limited group, a subset that is contrained--such as by organization.
• Mixed - a combination of the above two context.  A mixed group can be an 'intersection' or a subset of the two where they overlap, or an 'aggregation', so the two parts together, regardless of overlap.

It's a somewhat difficult concept to grasp by itself, but I found it starts to make a lot more sense once you look at the actual group definitions and configurations.

3. Security administration and on-going maintenance.

Excluding the system delivered ones, Workday groups can be manually assigned or auto-assigned.  More about this in a future post.  As well, user creation and termination of accounts can be automated.

Calculated fields in Workday

An interesting feature in Workday is the 'calculated fields' functionality.

 

To quote WD, 'Calculated fields allow users to perform simple arithmetic, date calculations, text manipulation, logical expressions, retrieval of related data, and transformations of their existing data. You can use calculated fields in reporting, business processes, integrations, scheduling recurring processes, and other areas within Workday.'

 

It's a nifty little feature, as

• it gives complex power to the users in reporting, via an online interface where you build them.  (As opposed to having to write complex expressions with if/then statements, for those of us from a PeopleSoft world).
• it allows for 'cleaner' development, as a developer is also using the online point and click functionality to build these items, rather than writing code from scratch.
• they are convenient, since you only need to build them once and then can reference them in reports, integration, etc.

So as a practical example, if you are interfacing to various systems, let's say 'gender' and one system needs 'M' or 'F', another system needs 'Male' or 'Female', another system needs '1' or '2' and another system needs 'M' or 'W' (male/female in German would be 'männlich' or 'weiblich').  So in each instance, you'd create a calculated field to allow for the M or F or 1 or 2, etc.  Then, if these systems ever changed their coding, it would be a simple online update to change the interface.  It's much nicer than other systems I've seen where hardcoded SQL needs to get updated.

 

As well, you can do traditional if/then or 'evaluate' expressions.  So if an employee's hire date is more than 10 years ago, put >10 or that sort of thing. 

 

From a reporting perspective, it allows you to build user friendly reports in an easier manner than I've previously seen in other systems.

 

Where are they not so convenient?

 

Like much of WD, the functionality is very flexible.  If you don't have your business processes in order to support this flexibility, you're in for some issues...

 

In our implementation (being lead by a mainstream consulting partner, but supported by multiple offshore consulting firms), the main parter says that best practice is to implement WD by 'an iterative approach'.  Basically, we keep putting data in, seeing how it looks, then tweaking here and there what we're doing.

 

When the topic of calculated fields came up, our traditional approach was to try to standardise and lock down the functionality.  (We have 150k + employees and a large part of our business is manufacturing, so we live by documented processes, otherwise it's a free for all mess.)  Our consulting partner directed us that 'best practice' is to not standardize, as that would cause a bottleneck, and instead, each developer should be creating any/all fields needed.  Not quite sure that was the best way, in retrospect.

 

We have 200+ integrations that are being built (many offshore) as well as local development of reports that are also generating calculated fields.  As there is no clearinghouse or rules, people just make a new calc field rather than hunting for an existing one.  The Data Governance and Controls team is now quickly working to implement standards and structures as the count of calc fields has soared to above 1000.

 

An example

 

To put it into a practical perspective, I've been working on some reports recently, to support our HR colleagues who are looking at the data.  I was seeking 'Business Unit Descr' so I searched for 'Business Unit'.  The top field is the WD delivered one (is it descr?  code?  who knows).  The ones after are all our calc fields.  This is not all of them, as others created them as 'bus unit' and all sorts of shorter versions such as 'BU':



 

You can see where the standards of the Data Governance team are starting to come into effect, such as using 'CF' as a prefix for calc fields or 'INT' when an integration is involved.  If you have only a handful of folks using this functionality or creating reports, it might not be such a big deal.  However, we will ultimately have hundreds of HR folks in the system using (if not creating) reports, so this willy nilly lack of standards will be confusing for them, even if they are only running reports and seeing disparate field names.

Looking online at the Workday Community site, other companies are grappling with these very same issues.  (Sidenote:  I'm a little surprised that WD itself does not issue more guidance).  There is a 'solutions' section in the community where other WD customers can post their top tips and documents, to share with other companies.  The group at Brown University put together some really great documentation, but just to give you an idea of how extensive this calc field naming can get, here is a snippet of their rules:

 

 

 

In addition, another customer (who has been live for a while) has developed a series of reports for more what I'd call the 'structural' aspects of the system--so basically audits to keep things tidy and more efficient.  He also includes calc field review in his list of 30 reports, such as keeping up with the following:

My tip of the day

As you can probably gather from the above, calculated fields can get very messy, quite fast.  Not necessarily WD's fault as it's a side effect of the flexibility of the technology, but you need to have strong business processes in place to control the creation of these things.  So I'd suggest:

• Define who will create calc fields in the future.  Read up on Community, various customers have defined different ways for this to happen (HR Business users, HRIS, IT, etc.)
• Develop your guidelines and structure of how these items will be named and categorized.  WD does provide things like 'tags' to help you in classifying them.  Again, the Brown University guidance is a good start.
• Be prepared to do auditing on calc fields in the future, to be sure that your environment is doing well against your rules.

Training on calculated fields

It's probably worth a mention, calc fields is a 3 day/15 hour online course from WD, to give you an idea of the level of complexity that you can get into with them.  The pre-req is the Report Writer class (2 days/10 hours)

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.

Configuring Workday HCM application security

We've been spending some time recently on our implementation, on defining Workday security.  I mentioned attending security class a few months back, here is an introduction to the key concepts.

If you are used to a PeopleSoft security model, just forget everything you know, this is a totally different world.  :) 

Functional Areas - Workday security comes pre-delivered with defined functional areas such as 'Benefits', 'Staffing', 'Jobs & Positions' or 'Compensation'.  Each of these areas is further divided into 'domains' and 'business processes'.

Business Processes - Each HR process in WD is set up as a 'business process'.  So the steps and the roles that can perform each step, as well as any approvals or notifications are defined.  Examples of a business process can be large like 'Hire' or smaller like 'Passport and Visa change'.  There's more to say about buisness processes, but we'll save that for another day. 

For today, imagine a swim lane flow chart in Visio with roles assigned to certain tasks.

Domain - This one can be difficult to grasp as it's quite foreign from anything I've seen in other HR Systems.  Basically, a domain is a collection of related securable items, such as tasks and reports.  WD delivers similar items together within domains, and you cannot change which items are assigned to which domains.  There are also sub-domains in some cases, but that's for a later day too.

To give you some ideas, a Domain would be 'Set Up: Jobs & Positions' and examples of sub-Domains under that would then be:

• Set Up Job
• Set Up Position

Other examples of Domains would be 'Job Profile: View' or 'Job Information'.

Domain Security Policy - This is where we can do some configuration.  While we cannot change what comes delivered in a Domain, with the domain security policy we control access to it.  So we control who can 'View and Modify' or 'View Only' or 'Get and Put'.

Within this security policy we address 'Securable Actions' and 'Securable Reporting Items'.  So for the Task 'Create Job Profile' or 'Delete Job Family', we say that it is a 'Modify' task rather than 'View' task. 

For individual fields that fall under this area, we can then define if those are viewable or not too.

So let's work with an example so far:

• In the Functional area of 'Jobs & Positions' we have a Domain called 'Set Up: Jobs & Positions'.
• We have Business Processes such as 'Edit Position' or 'Create Position'.
• We apply a Domain Security Policy to 'Set Up: Jobs & Positions' so that various tasks are given either view or modify rights.

We then attach the above to a 'Security Group' via configuration tasks, and this is how a user is able to view tasks, perform function, etc.

I realize the above is quite a complex topic--you can see why this can be a full training course from Workday!  Let's talk some more about the User piece on a different day...

Challenges of converting from PeopleSoft to Workday: data conversion topics

As we are three months away from go live, there are currently a lot of issues being worked.  Many of them are related to data conversion.  A few thoughts on this topic...

In any system conversion, you can expect to have data differences, and to accommodate for these differences via decisions on the data, mapping, and logic.  In some cases you may decide to drop data, or in others you set default values.  Doing a conversion from PeopleSoft to Workday HCM is no different.  A few things we learned:

1. Be prepared to build your organization structure from scratch.  The Workday org structure is very different from the PeopleSoft department tree.  Org elements are independent fields, rather than a top down data structure.  As a result, our company is having to build the organisational structure in Excel for each round of conversion (using the PeopleSoft dept structure as a basis) and building it up to represent future state.  It's quite a manual effort.

2. Be prepared for more data edits.  While PSoft does some editing of address data, for example expecting an employee's zip code to be a length five number, it doesn't go beyond that.  Workday has built in a checking feature that recognizes if you put in a postal code that does not match the state.  As we have thousands of locations, some of our incorrect post codes were then caught upon loading to Workday.

3. Be prepared for differences in fields (in all areas).  We were originally expecting that Workday's global address formats would be similar to the PeopleSoft delivered ones (keeping in mind that PSoft ones are configurable, the fields you turn on/off, but have defaults).  This was not quite the case, and we ended up doing a lot of mapping for international locations (Mexico, Europe, Asia, etc.) such as 'PS has 4 lines for Mexico address, WD only has 3'.  So we had to map data and then adjust interface specs to reflect the fields of the new system.  It wasn't the end of the world, but a bit of a surprise. 

4. Get used to not seeing codes.  PSoft is a traditional ERP, so when you set up a location, for example, you give it a code.  Workday keeps any coding in the background, so that the user does not need to worry about it.  Granted, you can still search for a location by the code if you know it, but you're not seeing it on the screen.  In some cases we've had to accommodate our codes as 'integration IDs' or 'custom IDs', so additional data elements that you can attach to core objects.  Not a big deal, but a different way of thinking for us, an additional bit of complexity in configuration and conversion, and a little bit more of an effort to check converted data.

Any conversion tips from your side?