Monday, 27 October 2014

Betfair rejects SAP, Oracle and Workday in favour of Fairsail for HR

Article here.

This one has been floating around the UK tech press the last few days, as Betfair is London based.  I must admit, I'm not much of a betting person so was not previously aware of Betfair, but I'm fascinated that a 1700 employee company in 15 countries would have been running SAP, just based on my limited knowledge of other big companies who use the SAP product.

Highlights include this part:

"In total 11 vendors were evaluated, these included a cloud HR solution from Workday, as well as Oracle, but MacDonald felt that these were also "too big for what Betfair needed".
This became more apparent when the company looked at offerings from smaller organisations, such as Fairsail, TribeHR, SumTotal Systems and Aragon-eRH."

Of course I had to go have a nose around Fairsail's website.  Key pieces:
  • It's a San Francisco based company.  I found that one interesting, as we're an 8 hour difference from SF here.  I'm curious as to their support model as US west coast can be a challenge for Londoners.
  • They use the term 'Glocal' to discuss their global vs. local functionality.  I like it!
  • Their user interface has a very clean look.  It has the PeopleSoft functionality of menus up the left side, but reminds me of Workday on the main pages.  It's funny how all HRMS are starting to look the same to me these days.  I guess they're all using usability experts and designing better interfaces from what we've seen 10-20 years ago.

Thursday, 16 October 2014

Tracking exempt status in Workday

A reader recently sent me a note, asking about how to track Exempt/non-exempt status.  I thought this info might help others, so here it is.

Workday allows you to track exempt status on a job profile, as do most HRMS these days.  A nice thing about Workday, however, is that you can attach different exempt statuses to one job profile based on location:

In previous HR systems that I've seen, you'd be stuck creating new jobcodes, profiles, positions, etc., each time that an exemption status changed, in order to track that status.  Prior to version 11 WD was in a similar situation, so nice to have seen them build out this functionality.

A few things to keep in mind though:

  • You need to have your processes locked down tight, as to how you will use this tab.  Will you assume that any state values are exceptions to the country value?  
  • Who is pulling any government reports, and where do they come from?  The use case presented on this one is that employees in California may be in the same job as someone in Texas, but due to California legislation, they are non-exempt rather than exempt.  There are a variety of ways to accomplish this reporting....

1. Put the exceptions into WD.  Document that a country is the norm and only exceptions are documented.

2. Don't put the exceptions into WD.  Establish your procedures outside of the system to assume all California jobs of a certain profile (grade level x etc) are non-exempt--in which case put employee work location into your report.

3. You could always put ALL the data into 49 exempt states and 1 non-exempt.  I'm not endorsing it, but I'm saying it's an option.

There are lots of options here and WD offers a lot of flexibility on this front.  To be successful, you need to ensure that your data entry procedures are watertight and that the reporting folks are working off of them consistently.

Tuesday, 17 June 2014

Workday Custom Objects in Action

Workday Custom Objects (CO going forward here) are easy to set up and configure, but how about from a user or data entry perspective?  Here we go:

1. You can access from multiple points on the person's record (see red boxes, for Additional Data menu).  It's nice that you have multiple paths to the same place:

 2. Once you've chosen the menu, you are then given a choice of which Custom Object you'd like to use.  In some ways, this isn't intuitive for the user at this point.  It's basically a collection of all the active Custom Objects.  So the data elements themselves are not related to each other (Apparel, Commute, etc.).  It's just a collection of 'Workday doesn't have these fields so we've created them' and stuck them in one place.

In my perfect world, I'd want to put 'Commute' with the Address data, for example.  Why?  We use the 'Commute' CO to track distance from home to work.  In Europe it's often woven into taxable benefits, such as when someone receives a company car or fuel benefit.  The greater the distance, the bigger the taxable benefit.  So if the data entry person is entering a new address on an employee, they need to remember to come over here and update the Commute value as well.

The Data Entry Pages

3. Since we spoke about Apparel in the setup example, let's stick with this one.  So here is the CO on Apparel, from a user's perspective.  It's pretty easy to choose an apparel type and size:

Keep in mind, this is Workday delivered sample data.  It's helpful for seeing how Workday envisions the pages to work if you're in a demo environment.

I'd like to point out a weakness about CO functionality however, using this example.  While we all say how we support standardization and global processes, I'd be much happier with this page if we could limit or apply the values to only certain regions or countries.

As you can see, it's one field with one big dropdown list.  (CO security is driven when setting up the object, so I'm not worried on that front, that a data entry operator would not have unauthorized access).  However, looking at this Apparel example, sizes vary around the world.  For example, if i were to buy a pair of shoes, I'd have to know my size:
US:  7.5     UK:  5.5    Europe:  38
Sizing is not a universal concept.

Workday does not let me limit this pick list in any way, shape or form.  So data entry folks around the world are left with this big list.  The only thing you can do is to make sure you think ahead and apply smart coding when setting up the values.

So the shoe pick list would either need to start the values with a region or country code:
US 7.5
US 8
UK 5.5
UK 6
EU 37
EU 38

OR we'd need to make the mapping and plunk everything into one line, so that our pick list looked like this:

US 7.5 / UK 5.5 / EU 38
US 8 / UK 6 / EU 38

It's not the end of the world, but I seek to minimize data entry mistakes by getting clutter out of the way.

Error messages

Workday does come with built in functionality, it's smart enough to know when I'm trying to enter a duplicate.  Would be happier if it was a little friendlier out of the box, however.  With that dollar sign in the error box, it looks a little clunky.

User specified validation rules

Workday does allow you to put on validations, so if the data entry person enters a wrong value, you can trigger an error message to inform the person to enter more appropriate data.  This is the closest I can get to ensuring that correct data entry is done (since I cannot limit the list overall on the front end).

So let's say that a data entry person accidentally chooses an incorrect value from the pick list, here is the error message:

Here is how it gets triggered.  The functionality of setting condition rules is consistent throughout the application, so if you know how to do one of these from the business process page or reporting pages, you know how to apply it here too.  Same functionality.  On one hand, I like the consistency for the back office folks setting these up:

As well, you get to specify your exact message in such a scenario:

From a front end user perspective though, I'd rather that the data entry operator not see the value in the first place, rather than have to go through a big dropdown and accidentally choose the wrong one, and then have to re-enter the data.  Fully understanding that this is sitting on the overall WD platform, however, so it needs to use their existing tools.  I'm just saying I'm not overly happy with the lack of limitation possibilities and having to build in validation rules after the fact.  But I get that this is how the application works.


  • It's a 'configuration' rather than 'customization' option, so good from that perspective.

  • The user experience isn't as slick as the rest of Workday.  Trying to incorporate COs into the app seems patchwork and haphazard.
  • You have the option to use Effective Dated COs, at least for Worker.  While it would be great to have additional ones, Worker is the most critical.

  • Big Disadvantage:  Currently you only get 20 of these per business object (such as Worker), unless you're a Big Data customer, then you get 100.  As someone pointed out on the WD Community site, this obviously isn't a technical application limit since it is granted to some customers.  There has been a brainstorm out since 2012 to increase those counts for us non-Big Data peons, and according to the site it's targeted for WD 23 (Aug 2014 in Production).  Fingers crossed that this will open up more possibilities for us.
  • Another disadvantage:  Lack of integration into the Business Processes from a data entry perspective.  My HR colleagues who are more on the front end of process design try to avoid these Custom Objects whenever possible.  They like a process to flow along in a logical manner and give much thought into how and where the data gets entered.  They like to set reminders and make things as foolproof as possible.  The location of this data under the 'Additional Data' menu leaves it as a bit of an orphan, a collection of 'extra' data items.  They prefer to instead cannibalize existing unused fields on the pages where data entry is occurring (shudder!) so that the data entry can be in one place.  

Any other options?

The eloquent Naomi Bloom suggested on Twitter that I think some more on this topic and WD's options.  Custom Objects are really WD's main mechanism in the way of user-defined fields.  As you can see, it can be a powerful option, in particular if you are used to a non-configurable environment.

There is one more option that we've been pulling out of our sleeve, using 'Custom ID' functionality.  If COs are the powerhouse of user-defined fields, Custom IDs are next best option if we want to cannibalize and re-purpose something.  I'll put together a separate post on that one.  To be honest I'm not really proud of how we're using that one, as we're stuffing data into fields in a way that was never its intended purpose, but in the interest of full disclosure, I'll show you what we're misusing.  In particular, we were afraid of using up our CO allotment of 20, so we've had to go the Custom ID route to store additional data, but from a systems standpoint, it's less than exemplary.

Thursday, 12 June 2014

How to set up a Workday Custom Object

Around a year ago, I had written about my initial impressions on custom objects (Workday's 'customer defined' field options).  Still worth a read if you're looking for an overview of 'user defined' field concept in Workday.

Now that we're live in North America and into our European implementation, time to revisit the topic.

Today I'd like to focus on the logistics of setting one up, as I think this is one of Workday's strong points, the ability to easily create company required data fields.  Then later this week I'd like to look further at the nitty gritty of actually using them.

Rather than starting from scratch, let's look one up as it's the same page layout to enter or view (smart from a Usability perspective, the consistency).  You have a few options when searching, to filter.  Often we'd look by business object (similar to a 'table' in a traditional database setting, it's a grouping of related fields):

Most of our Custom Objects are tied to the 'Worker' Object in Workday.  The Worker Object is where we track something at the 'individual Employee' level.

Let's pull up the WD sample data, for the object 'Apparel'.  This is actually a useful one for us, as we are required to supply work shirts, trousers, etc. at some of our manufacturing sites, and there are repercussions if we do not provide replacements on the appropriate schedule.  If we were setting up a new custom field, WD walks us through the same pages:

Some useful things on this page, is that you can define the object name, validations, the field order, as well as specifying the security domain.  It's probably a smart idea to name these carefully, in particular, the 'web alias', as that is something that is not editable once a custom object is in active use.

Another feature I like overall about WD is the orange box you see here.  When you are on a Workday page, you can use it as a launch pad to other actions that you can perform on this 'thing' (be it a custom object, a foundation value, an employee, etc.)  Then you get a list of 'available actions' that pertain to the item that you are reviewing.  So in the case of this Custom Object 'Apparel', I can look up its integration ID, I can go report on it, etc.  Not exclusive to custom objects, but deserving of a call-out in any event.

Also on the page is the nice little summary, again on the page, I like being able to instantly see the security domains where this item is assigned.  Other colleagues doing some other tasks prefer some of the other fields summarized here.

In addition, there is a 'Usage' tab which is especially helpful if you're into reporting.  If you're planning to edit a custom object, seeing that it is currently included in a calculated field, for example, is quite helpful for impact analysis:

Last but not least, lest I always sound like a curmudgeon on Workday's lack of globalness in some areas, I must admit, I appreciate this global feature, to translate the Custom Objects into local language.  Two thumbs up!

So a few thoughts on the setup of custom objects in Workday:
  • Very easy to do online!  It's 'customization by functional people'.
  • I like the linkages and the displayed details.
  • Overall, I think this is great functionality from the setup perspective, and recognizing that there is nothing existing in the PeopleSoft front in this area, except for proper customization.
Still to come:  Actually using the fields . . . is it still so easy?  Stay tuned . . .

Wednesday, 4 June 2014

A European solutioning example in Workday

As a global company, we have offices and employees in almost every country in the world.

Much of our North American Workday implementation was based upon US requirements, with a handful of Mexico and Canada business needs sprinkled in.  This design, configuration and use became 'the global footprint'.

Now that we're looking at European countries as part of our next wave of implementation, in general the current use is getting challenged.  In addition, the design is getting extended for business requirements that did not exist in the US, e.g. contract data.

What is European contract data?


First, I'm not talking about contractors.  :) In Europe, most countries have the concept of employment contracts, so prior to accepting an employment offer, the contract provides a contract offer to the candidate (i.e. future employee), and the candidate may choose to sign 'as is' or negotiate some of the contract clauses.  Then both the candidate and a company representative sign the contract to make it official.  Each country will usually have different things that they put into their contracts, depending on local business practice.  There is no 'Euopean contract'. 

For comparison, I've worked in three countries for the same company.  In the US I received an offer letter of 2 pages, it listed things like salary and work location.  In Germany, I received a 25 page contract with all of the employment terms and details spelled out.  In the UK, my contract was a little shorter, only 12 pages.

If you get a big promotion such as from non-manager to manager or to a high position, you may get a new contract.  Otherwise, for smaller promotions, your contract would just get an addendum with any new details.

What kind of data is in a European contract?


Often, you'll have some general and overarching principles that apply to all employees, such as an ethics policy or general details about working conditions.

A contract will often hold basic data, such as the employee's name, home address, and job data such as title/position, the title/position that the role reports into, weekly hours, pay frequency, pay rate, hire date, seniority date (if differing for benefits calculations), notice period, probation date, etc.

As well, you'll find some 'eligibility' items 
  • if a company provides a contribution to a pension on the employee's behalf, what is the percent
  • if a company car is provided, what is the level/budget or allowance in lieu of car
  • holiday entitlement
  • private medical scheme, if offered
  • what sort of sick pay you are entitled to
  • etc.


What is the Workday functionality?

Workday gives us a page for contract data, it looks like this:
  • Workday has the usual 'per country' configuration, so that you can set up your Contract Types per country, which is helpful.
  • The attachments and comments feature is also there, so that is useful if we want to attach a copy of the contract.
Some of the job-related data found in the contract will be on the 'regular' Workday job pages.  Other data such as pension or health, we can try to store on the benefits screens.  However...

Where we're challenged in Europe, trying to use Workday

There's a lot of great fields on this page, which we would definitely use.  But we're struggling to figure out where to put the rest of the contract data.  It's like we were invited to dinner and only served the appetizer.  My current thought is that this page was designed without European input.  Mexico does have more of a concept of contracts, so maybe that was the driver, who knows.

Here are some areas that are providing heartburn at the moment.  And specifically, our payroll systems in the countries do have the concept of contract data, and would like to receive it on an interface from Workday.  Our HR people as well would like to be able to store and view this data.  So where are the disconnects?

1. Notice period


This particularly pains me, as it's such a basic concept that any European based HR system would contain.  A notice period is included in your employment contract.  The higher your position, the longer it is likely to be.  None of this '2 weeks notice' in Europe!  My notice period in the UK and Germany has been 3 months.  High level executives may have 6 months or a year even. 

This applies to both the employer and the employee, and may differ, although if we could just get the employee one, that would be great.

Notice periods are often a 'date in words', for example:  3 months, 6 weeks, etc.  There is an added complexity to some, such as 1 month to the end of the quarter.  I've heard some other companies try to simplify and specify a number of day or weeks.

In addition, local labor law may specify a minimum statutory period, but as a company you may wish to put a longer notice period into place.

Workday has no functionality in this area!

There is a Workday Brainstorm (Workday's mechanism to make change requests to the application) from other companies to at least get a 'notice date' added.

2. Dual contracts


This comes up in various EU countries, in particular where we have better benefits than our NA counterparts.  :)  Often, an employee has a regular contract, and as a part of that may receive maternity benefits from either/both the company and/or government, depending on the country.

The employee on maternity may receive their regular benefits, but may want to work part time during maternity leave.  Usually in this case, the company will need to make a new contract with the relevant employment information.

Workday only allows for one active contract at a time!

Again, there's a Brainstorm to get this changed, or at least configurable to allow for two simultaneous contracts.

A workaround is to use Workday's 'multiple jobs' functionality.  If you put the employee into two distinct positions, the employee may have two active contracts at the same time.  However, that's a lot of work to enable, both from a functional and technical side, just to get some minimal contract data into place on a 2nd contract.

3. Contract renewal

In Europe, for better or for worse, it's more difficult to terminate an employee.  Often, we hire people on in temporary contracts.  Depending on the country, you are allowed to extend the contract a certain number of times, but after extension number x, it automatically converts the emp into a 'regular' contract (with all corresponding rights).

Workday missed to include this functionality!

Workday workaround:  Use the freeform 'Contract ID' field and get the data input folks to consistently put in '0001' for 1st contract, '0002' for 2nd contract, etc.  I don't like using freeform fields in this manner, as you end up doing extra auditing as people forget the 0's or make it length 5.

There's a Brainstrorm for this one too.

I could continue on here with my online gap analysis, but I think you get the idea.

Why is this especially irritating?


PeopleSoft has a lot more functionality!  Granted, we probably only using 10% of the fields on the pages, but they met our needs.  In my 'notice period' example above, we set up a contract clause for each notice period, such as the 'non competing' clause listed below.  As each employee has a contract, you then choose the relevant notice period clause for that employee.

In Summary

We're continuing to review the data against what our payroll systems need to receive.  As the contract data pages are not very robust in Workday, we'll be left having to 'MacGyver' it in, or not store it at all.

In discussions with our Workday certified consulting partner, the only thing they can tell us to do is: either don't store the data in Workday, or make custom objects, custom IDs etc. to accommodate it, recognizing that you don't have enough custom objects free to meet the needs.  As well, it would just be generally ugly from a data entry and reporting perspective, as well as not in harmony in one place, with some fields on the contract data pages and others independently as custom objects etc.

I think the irritation here is that we currently have a workable solution in PeopleSoft, and in going to Workday it's seen by the users a going backwards as Workday does not come to the table with a real solution here.

Monday, 2 June 2014

Pleasantly suprised: Workday's social media response

I occasionally take a break and log into Twitter, to see what is happening in other HR System topics around the world.

Last week, Workday had tweeted about an upcoming online event:

Announcing our 1st tweet chat! Join us on 6/19 from 10-11am PT using . will discuss Big Data for Better Recruiting

It sounded really interesting, but once again, I wasn't impressed with the lack of global thinking, from Workday.  So I tweeted a polite response to the timing of it.  6 PM on the European mainland, 1 AM Hong Kong next day, it's not great if you are seeking to reach a global audience.  Although fair enough if your focus is the US market.

I wasn't expecting much of a response to be honest (in particular as I'm not tweeting under some big company name, but as an anonymous blogger), but was please to see that Workday's Social Media Director quickly responded to me, in under an hour.

Thx for feedback. We plan to make this a recurring series, so future chats could be at other global times.

We'll also record & post this tweet chat via for on-demand viewing & to keep the conversation going!

Even though I'm still not impressed that Workday seems so US focused (especially when they could slightly back it up to 8 AM and get into the European workday), I was pleased to get a response.  From a customer perspective, while I'm not happy with the timing I am happy with how they handled my comment.

Tuesday, 27 May 2014

Undoing a Workday Data Load EIB

I was browsing the Workday Community site, catching up on the Customer forum postings.  This one caught my eye:

I am a new in Workday and need your help regarding EIB.
I have uploaded an EIB for Contingent worker but now i need to rollback the changes.
Can you please help me in this regard.

Yikes!  Can you imagine? 

We are a large company and currently load data every single work day in our PeopleSoft environment, using Excel to CI (with the files being prepared and loaded by the IT team).  Workday's EIB functionality is awfully similar to the PSoft functionality, using (bulky and cumbersome) Excels to prepare and load data.  Both systems offer 'validated' data entry through these load processes, so a cleaner way to load data than say, a SQL load.  Both offer equally cryptic data load reports so that you know where you've loaded data or had issues.

So where are we today in Production?


Our US colleagues have made the decision to give EIB to the newly formed shared services center.  They have backed off of their original intent however, of anything more than 10 rows should be loaded and have completely given up on doing any new Hire loading, as it's been deemed as 'too complex'.

It's interesting to me as historically we don't have the data entry people loading data, but HR Transformation continues to turn the world upside-down.

My two cents, as I continue to delve into Workday functionality and imagine our future state world in Europe...

Advantages of Workday EIB functionality over PeopleSoft Excel to CI


1. WD gives you the templates out the box.  In PSoft we need our developers to do some building to create the option to load.  So we made a prioritized list and gradually worked our way through it.

2. If the WD functionality is broken, it's on them to fix it, not your developers.

3. Workday allows you to 'define' the template--so you're able to remove optional columns at the get go to save the user the hassle of seeing non-used extras.  In our PSoft world we do a manual workaround (we give the users a skinnier version of the Excel, and then paste it back into our normal, bigger one).

4. There is a roll-back option!  (Ha!  Lucky for that fellow who asked the question to the forum!)  You can use the 'Mass Rescind Business Processes'.  In our PSoft world, we'd either do another Excel to CI in correction mode to fix the 'wrong' data or we'd send in the users to manually delete rows.

Advantages of PeopleSoft Excel to CI over Workday EIB functionality 


1. You can build whatever Excels to CI whenever you want, for whatever you want.  In WD you are stuck waiting for them to build the functionality.  So you make a Brainstorm and then hope people vote it up and that it's easy for WD to build.  For example, a company put out a request to WD to create an EIB for healthcare rates as they have 4k lines to enter due to their retiree plans.

2. If the WD functionality is broken, you're stuck waiting for them to fix it vs. having in-house resources fixing something as top priority.

3. A minor observation, but a continuing dark lining in the HCM cloud is that these tools are not always as intuitive as they portray during the sales cycle.  For example, if you want to load a blank value into PeopleSoft, you put a space (i.e. blank) into the cell in your Excel to CI, which is common sense.  In Workday, you put this into the cell:  {empty}

Monday, 26 May 2014

Workday IDs and codes

In our current PeopleSoft world, we have processes and controls around codes, how we set up codes (we don't use smart coding, but instead next sequential), and interfaces tend to use the same logic to select certain populations, so it becomes a copy/paste exercise for new interfaces.

Workday provides a lot more on the coding front, so a few thoughts here.

Some foundational data operates with these options:

1. Workday ID


When you set up a new value, let's say you're setting up a new value of 'New York City' in the Location table, Workday generates an ID for that automatically in the background when you save the value.  It looks something like this, length 32:

The average user does not see this value, but may view it (if granted security) to 'View Integration IDs'.  Some other key points I've picked up on this one:
  • It's a globally unique code across all customers
  • It's also unique across instances (so your Location will have different Workday IDs in your production vs. sandbox tenants)

2. Reference ID


This one is a customizable value, or you can let WD set it for you.  In this case we'd have:
Location_ID = New_York_City_site if we allowed it to default.  But you could override it to a value that makes sense to your company.  In our case, we have a code structure for locations that is set up by the facilities group and used universally at our company.  So our Reference ID is overriden when setting up a location, to be our company generated location code.
  • You're not required to have reference IDs, but can have one or many per item if you wish
  • This one will be the same across your tenants

3. External IDs


I am rather digging this one, as we built a custom page in psoft that does basically the same thing.  :) Let's say that you have your NYC location with a Reference ID of 12345, but your payroll system requires a leading zero there, so you need to send 012345 to payroll.  In a psoft vanilla world, you'd hardcode that into your SQR or app engine, to append a 0 as a part of the interface.  WD allows you to set up this code on the location itself, so your user online is creating the location and then adding a row to set up 'Payroll System X' = 012345.  Then, the developer only needs to reference the 'Payroll System X' row when building the interface.  

It's also nice that you can have multiple External IDs for various systems, so if you have 10 different downstream systems that want 10 different codes for our NYC office, we can set that up on the location.

4. Then other tables have different 'code' options.  

Let's look at Ethnicity.  WD delivers some sample values, but you're free to configure your own:

Interesting to me here is that you can set up the 'map to' option.

Overall thoughts on IDs

We're still in the early days of being live with WD in the US.  Most of our integration consultants seem to be learning WD as they develop our interfaces.  
In general, I suspect we're not setting things up in the most efficient manner.  Like often in WD, its flexibility appears to be our undoing, but we've only figured out after the fact in some cases how we actually *should* have set things up.
However, there are definitely more options here than in PSoft, so I like it from that angle.

It will be a bit of a learning curve as currently we're in the midst of HR transformation, so folks who never maintained (or knew about) the codes needed by payroll will now need to be aware of them in order to maintain them.

Sunday, 18 May 2014

Can HR Systems ever do Big Data? Workday?

'Big Data' is one of those IT buzzwords these days, with everyone jumping on the bandwagon.

Last week I was researching Custom Objects for our implementation, to see if there's anything new in the Workday world on this topic.  Custom Objects are Workday's 'customer-defined' fields, I previously looked into the Workday functionality last year.

On the 'Worker' data object, we're already up to 12 fields used out of 20, prior to starting our Europe roll-out.  Workday 'Big Data Analytics' customers, however, get 100 Custom Objects on the Worker!  This alone would be a reason to license the product, and I think that's why WD keeps the rest of us in check at 20.

What is 'Workday Big Data Analytics' (BDA)?

 BDA is a newer, separately licensed product that enables a customer to analyse Workday and non-Workday data together in one place.  You put non-Workday data into the 'Big Data Store' and use 'Big Data Explorer' as your interface to upkeep (i.e. load) your data and perform analysis.  (In some ways it reminds me of the promise of ERP in the late 1980's...your Financials and HR data, all in one system!)


As I'm curious, I've been looking at the WD presentations on this topic and reading through the forum posts by other customers. 
  • It sounds like it offers pre-defined templates and reports to help you to analyse large volumes of data more easily.
  • You can incorporate this data into your manager dashboards in WD, so a 'one stop shop' for a manager.

Can an HR System really deliver on 'Big Data' benefits?

When it comes to data in the HRIS world, I find a few main hurdles:
  1. Getting data
  2. Maintaining data
  3. Working with data so that it becomes a source of better decision making

I'm not sure how much Workday (or any other HRIS or HCM system) is really able to capitalize on Big Data, for a few reasons.
  1. Getting data and linking it across systems can often be a challenge.  Not all systems have a unique key structure that matches other systems.
  2. Other systems roll up data and define data in a different manner--it becomes an 'apples to oranges' exercise to compare it.
  3. Even when you are able to match data, it's often a one time exercise.
  4. HR data is not always maintained.  Someone may have a great idea to keep company property or driver licenses for company vehicle drivers in the HR system, but on-going maintenance can be an effort if systems and processes are not robust or meeting local needs.
  5. Even if you have the best data in the world, it can be a struggle to define a common set of reports or to figure out how to configure manager dashboards automatically at a highly detailed level so that you are providing targeted information at a manager's fingertips, on demand, rather than a 'general manager dashboard' which is the same for all managers.

When I think Big Data, this is how I think of it

Here in the UK, we have a large supermarket chain, Tesco.  They do some 24 hour supermarkets, some mega-stores that carry clothes and electronics, as well as having little stores tucked into train and bus stations and in neighborhoods.  Tesco appeals to a variety of customers as they offer foods from value through to upscale.

Most people (including myself) have a Tesco clubcard.  You can scan it when you pay and get discounts, rewards, and every other month, they send targetted coupons based on your spending habits.  Yes, it's very big brother, but no one is forcing you to take or use a card.

Tesco knows that I bought bananas at 6 AM on a Sunday, wine on Friday, and that I buy cat food from them.  Tesco has a super big database somewhere, and I suspect their analytics team is gigantic.

Big Data can change behaviour

A few rounds back, they sent me a cracking good coupon for 1.10 off cat food, so I used it.  In the last round of coupons, they sent me 75 p off of cat food.  I didn't use the coupon but bought my cat food elsewhere.  In this round of coupons, they've now raised the ante, and are offering me 95 p off.  Will it change my behaviour in cat food buying?  It might, as they're now making it more valuable to me. 

Big Data knows what I need before I know that I need it.

The bottom coupon absolutely tickled me!  I am a US person living in the UK.  Those very smart data crunching computers (or the smart IT wonks programming the logic) have analyzed the data and are thinking that they can woo me into their USA product range.  I can only assume that they put together the data facts, that I don't buy tea and milk, but instead coffee and a variety of other tidbits that lead them to this conclusion.

So why can't HCM, HRIS, HR Systems, etc. be this smart too?

I see a lot of hype from the HR data solutions that they're harnessing the power of Big Data, but I'm not sure that they're there yet. 
  1. I don't think that they have the data volumes necessary to fuel Big Data, even if you can combine data from other systems such as T&E or Sales.
  2. You'll never be in the 'daily, operational, transactional' level of data needed to get the deep data insights.  For example:
    1. An average HRIS may give you a report of terminations in the last fiscal year and an exit reason cited by the employee (where existing)
    2. Big data HR Systems may bring in data from other systems--what was the sales volume of the emps leaving?  Did you lose a top performer or underachiever?
    3. A Business Intelligence or Management Information team may use either of the above two sources to spot data trends...and then provide a further level of insight.
      1. An increase in terms at location X coincides with the HR policy changes to not match 401k and to reduce company contributions to benefits.
      2. Recommendation:  adjust the policy to influence the future term numbers.
      3. Check after six months, any impact?  Rinse/repeat.
However, we'll never get to that Big Data level of detail...without having the full data set, for example, knowing the compensation and benefits received at the new company, we're just making a one-sided, best guess, based on the data that we have.

Tesco doesn't know what I'm buying at the competing supermarkets...but it has an idea based on what I am buying and not buying at Tesco.  It knows that I have a cat based on all the cat related things that I buy, but I don't buy cat litter there (Her Excellecy prefers another brand that I buy elsewhere).  Those data gurus at Tesco periodically shoot me a fabulous deal on cat litter, knowing that it's a *missing* item on my list. 

We'll never get to that level of data in the HR systems world, regardless of how good the product may be at providing templates, reports and analysis tools and that is why we'll never do Big Data properly in an HRIS setting.

Of course, very happy to be proven incorrect on this point, be it on Workday on another HCM.  :)

Monday, 12 May 2014

Workday Training Schedules...still 'unglobal'

Way back in November 2012, I was whining about Worday's US-centric training schedule.  Here we are 18 months later, and I'm about to do it again...

I am very lucky that my company will pay for me to attend training.  While I've done most of the basic training early on in the project, our US colleagues are struggling post go-live with reporting topics.  I took the basic reporting class last year, but wanted to get my hands into the 'Calculated Fields' class, a 1.5 credit (15 hour option).

On the plus side, it's a virtual class offered over 3 days at 5 hours a day.

On the minus side, the timing is pretty poor.  For a company that claims to support global companies, I find it lacking.
  • There are 8 instances of this course scheduled between now and the end of July.
  • None are in the Eastern US timezone (which is somewhat palatable to London), but 7 are in Pacific or Central US.
  • One is in the 'London timezone' (from 11 AM - 4 PM) according to their website.  I cannot quite figure out why the Pacific and Central classes start at 9 AM, but Workday thinks that in London our workday begins at 11 AM??  For anyone on the continent, that's a noon-5 PM run.
  • That being said, the class does fall inside the European workday, a novelty from my friends in Pleasanton.
  • Most of the US classes are Wed-Fri, so even if you did want to bite the bullet and take the US-centric offering, you're stuck online until 11 PM Friday night if you choose the Pacific option.  As well, starting a course at 6 PM on a Friday after a long work week will not be effective for me.
I wish I could have a better report out in this area.  I can only assume that Workday's customer base/focus remains heavily in the US market?

Sunday, 6 April 2014

Pleasantly surprised

A while back, I mentioned looking at address data.  While we mapped from PeopleSoft to Workday and made decisions to combine fields where we had to, we had a country where WD made the field required, while we would call it optional.  I spoke with our data entry expert in country to confirm it is not used and to confirm that it's not existing in local payroll.  I checked online as well and everything that I found aligned with this data being optional.

I put in a Brainstorm making this request to convert it to optional.  Three weeks later it had hardly any votes, but someone from WD responded to it and asked for the legal source, as their sources said that it was required.  I missed getting a notification at this point that someone had responded, so I did not respond.  However, the same WD employee then responded a few days after, that indeed it should be an optional data element based on new research, and that it was targeted for WD 21 to be updated.

On one hand, I have no idea how they can get to WD21 with no one else noticing this, except that we are not a pharmaceutical company, so maybe our global footprint differs from other big customers.

We had already programmed our conversion logic to stick 'unknown' in the field (no field validation), which was going to look ugly from a self-service standpoint.  Happy to be able to lose that logic and instead leave the field blank.

As a PSoft customer, our management made a strategic decision not to apply patches.  We don't run payroll out of PSoft in Europe, so we can do that.  Occasionally, when something is noticed by the users and it is deemed critical, we will extract that bit of code out of a project, and our developers will manually apply just that bit.  As you can imagine, whenever we would log a case with PSoft customer support, it would be instantly closed as you are not on the latest code line.

I realize this is a quick little fix by WD for something that should not have been wrong in the first place, but quite pleased at how this one has turned out.

Monday, 31 March 2014

Workday Rising in Europe

Workday has a customer conference called 'Workday Rising' each year.  This week will be the first European version of the conference, in London.  My company graciously is sending me there.  It is 1.5 days, which is shorter than the US version of the conference, but as I'm only going to London, it's not like I incur flight costs, which might make it too short to justify.

Many years ago when I lived in the US, I had a chance to attend the PeopleSoft customer conferences.  These were quite good, both the sessions and the chance to connect with others using the same software.  I'm hoping to have a similar experience this week.

My only disappointment has been that some of the sessions were full when I registered a month or so ago, so I did not get into my first choice for two sessions, leaving me with some random sessions on my agenda that I would not have chosen otherwise.

In particular, looking to connect with current customers who are live in Europe.  I've previously met a few during the London user group meetings and it has proved valuable to hear what worked for them and what did not in this space.

Monday, 24 March 2014

Workday and German Works Councils

Whenever you implement any HRIS in Europe, there's always questions around data privacy, works councils (WC), unions, etc. At our company, we have manufacturing sites in Germany and are covered by strong works councils there and elsewhere in Europe. As a result, the US based implementation teams are always concerned that this additional activity will add to their timing on projects. Having lived in Germany for many years prior to the UK and seen a few launches in this area, a few thoughts specifically on Works Councils which are prevalent in certain European countries. It depends on your company, what you need to do, but some perspective from here.

1. We are a multi-national and have implemented multiple HRIS over the years in Europe, both in-house hosted ERPs (PeopleSoft HCM) plus SaaS solutions (recruitment, training) and homegrown systems (succession planning) as well as various and sundry.

  • It does require additional efforts, in particular in the area of documentation. For example, a standard request from the WC is for a list of all fields that will be populated on an employee, and who has access to that data, and where it will be interfaced. From a systems perspective, I think this is a good business practice to have such detail regardless, but it seems to be an effort to get this in place. 

  •  I know WD offers some back office functionality of various reports, etc. but this will be a manual effort for us, to compile what fields we are using, and for what purpose. We may be able to utilize some of the reporting functionality to address which ones are being interfaced. 

2. The WC will want to see a demo of the system, and ours expect to see the screens in German. Fortunately WD has German screens, so we're ok there.

3. There is always some talk about the location of the server. In the past, we placed our Psoft server in Germany as we have a big data centre there, and it would alleviate some discussion. In the meantime, we've had other SaaS solutions hosted outside of Europe. It seems that as long as the provider has good documentation about their controls in place, this is no problem.

 4. Those 'comments' fields in Workday may cause some discussion.  Historically, our WC and other data privacy advocates are concerned about free-form comments fields as they have the potential to store a variety of data or other information that should not be held in a system. While our HR colleagues are quite keen to use the comments fields that are associated with the Business Process approval steps, it will be interesting to see how this plays out. In the past, we've had to agree with the WC to audit any comments boxes in PSoft to make sure that nothing was being stored in the for German employees.  Their preference would have been to make those boxes not available for entry at all.

5. What other customers in country X are using Workday?  This seems to be a common request from an in-country WC.  I have seen as well, that if a WC is nervous or against a software application, as a part of the process they will bring in someone on their side to provide input and help them to ask the relevant questions about the application.  As long as you have internal expertise in a software, this should be fine.

6. Expect everything to take additional time.  In our company, most WC have a good relationship with the firm.  However, this topic is also carefully managed as well.  For example, if the company has to make headcount reductions, they will time the new system introduction for a different meeting, so as to not provide leverage to the WC.  It's also a task to understand if your responsibilities; some WC require the right to be 'informed' while others require 'co-determination', which can slow down your process immensely.  When we first implemented PSoft, from a systems and business process perspective it would have taken three months to launch our German sites, it ended up taking us one year due to the requirements in this area and the permissions that needed to be obtained before we could capture data.

In summary, Workday is like any other SaaS HR application.  The fact that it is a US hosted solution should not deter you from using it.

Workday does like to point out its global awareness in that they do allow for certain key personal data fields (e.g. religion in Germany) to be displayed/hidden at the customer/country level.   That is a slight improvement over Psoft, where everyone saw the religion field.  (That being said, we only put setup values into it where we wanted it used, so the users were effectively blocked from using it where no setup values existed).

Monday, 17 March 2014

Custom Labels in Workday

I mentioned yesterday about struggling a bit to come to terms about Workday's functionality in this area, in relation to not being able to change labels and field behaviour as it relates to Address fields in Workday.  So as a follow-up today, a few thoughts on where Workday does have some Label Customization options.

What is the functionality?

  • Workday delivers Maintain Custom Label task, so for certain field labels in certain areas, you can choose to override those with your own company specific terms.


What are the areas?

  • It centers around three areas:  Global, Merit or Talent.

 So how does that work?
  • For these areas, WD allows you to override certain field labels with your own field labels.
  • 'Global' includes these three items: 'Workers', 'Contingent Workers' or 'Employees'.  So if your company calls them 'Team Members', 'Temps' or 'Minions', you can replace these terms globally in WD with your own terms.  'Global' does not include any other terms/labels, aka address labels. (boo-hoo!)
  • You also then have to include the possessive and plural forms too.

 My thoughts:
  • We have not changed any 'Global' labels, as we currently use the terms of Employees and Contingent Workers, and we'll get people used to the new 'Worker' term over time.
  • Merit and Talent are a little more useful as some of the fields in this area ('merit', 'competency', 'target', etc.) are ones where we use company specific terms such as 'year end process'.
  • Although some of their other terms in this area such as 'development' or 'goal' are fine for us, but recognizing how other companies often have specific terms in these areas.

  • It's easy functionality to use.  It's just a list of fields and you can choose to fill in overrides where you want to have them.
  • It is multi-language enabled, so you can do label overrides in multiple languages.  That being said, when we have a company-specific term, we tend to keep the English version. 

 Following the Debate
  • I see that customers have requested the ability to change the above listed labels and these have been added over time.
  • Some customers think that there should be more of an option to make these changes across the application.  As an example, it can be confusing if you have multiple HRIS for recruitment vs core HR and use different terms for 'employee' and 'worker'.
  • Other customers think that different label options dilute the application's power of standardization.

 The Workday technology behind the scenes?
  • I wish I knew what it was or why this is so complex to do.  As a counter example, we have another major SaaS provider as our recruitment system, as we can change label names and even had the option to provide an Excel of label translations.
  • When researching the address option I mentioned yesterday, and looking at the Brainstorms out on Customer Community, I see that someone had requested that 'Postal Code' be renamed as 'Zip Code' when the country is US.  The response from Workday was to clarify whether a Label Override for customer entry was being requested, or rather that Workday should make that change overall in the application (so that every customer with a US address would see 'zip code' instead of 'postal').  
  • So I guess address label overrides are not as pressing a need as some of the development or performance ones.  

But I'm still curious as to whether this is a technical limitation of how the application is built, to not open up labels globally for customer entry, or more of a strategic direction to lock down this option.

Sunday, 16 March 2014

Address Data in Workday - SaaS vs non-SaaS

As a large multi-national employer, we have employee, location and emergency contact addresses from virtually every country in the world. 

Workday defines country address formats for you.  Looking back through the historical updates, I can see that they have evolved over time, to add more state data, update to make fields required/un-required, etc.

We have other HR SaaS systems in the areas of recruitment and training data.  I am struggling with the move from an ERP to a SaaS in the core HR space however.  As we've been running through our pre-conversion run, a few thoughts here, specifically about address data.  Both applications offer specialized, per country address formats.

Workday (SaaS) advantages:

  • WD delivers data such as states, so we don't have to worry about getting that setup data.
  • WD has done the leg work to figure out an appropriate address format per country.  Not sure that it's 100% there, but we are able to map to equivalent fields, so fingers crossed.
  • WD has some validations in place, such as US postal codes are matched against US states, so the user gets an error if something is amiss.

PeopleSoft (ERP) advantages:

  • You can (through normal, online configuration) hide and unhide fields.
  • You can (through normal, online configuration) change the label names.
  • While a core list of states are delivered in major countries, you can add more, change the existing ones, etc.
  • You can, via customization, make a field required or un-required.


My wish list...

I envision the next generation of SaaS tools will become a little more flexible on some of these fronts.  Or maybe it's more wishful thinking, but here's where I'm seeing some challenges:

  • We have configured PSoft to replicate the address formats needed by our downstream payroll systems.  Like many other companies in Europe, we have many payroll systems, often 1 (or more) per country.  IF we do not configure the core HR system to match payroll, then potentially people are putting data into fields that do not get interfaced.  While it might be tackled via training...
    • We're moving toward more of a regional centralized shared services model.  While the teams cover a handful of countries now, in the future, it will be a mega back office operation covering 50+ countries so we need the system to be smart, rather than expecting an entry person to be on top of the details or to have to look them up.
    • Employee self-service will allow an employee to say, use Address 3 in WD, but payroll only has Address 1 or 2.  So it becomes an audit after the fact or a very complex business process if you invoke validation.
  • Due to said payroll systems, we'd like to control the required fields in the HRIS in the same manner as payroll.  So if payroll requires city, then we need to have it required in the HRIS.  With WD, we have no possibility to do so and they are supposed to be our source.

  • We'd have a way to impose field length limits on address data elements in WD.  As those payroll systems downstream all have field limits, it would be nicer if we could impose the same in the HRIS at the data source, rather than losing data in the interface process when it will just cut out those values that are longer than the receiving system can handle.
  • WD has post code validations for the US, but not for us in Europe.  I've seen some customers request more functionality in this area, and assuming they can find a source, seems like this will get there in time.
  • I wish it would get really smart for us and use the address data in related processes.  For example, in Europe, when you receive a company car, you are taxed on it as a benefit.  Some countries take into account the kilometers between your home address and the office address (a longer distance = more benefit = higher tax rate).  Currently in our pre-WD world, an HR person goes to Google maps and types in the details to figure out the kilometers and enters it into the payroll system.  While WD delivers a field for this data (score 1 WD, as PSoft does not have a home for this data element), in my perfect world, the system would do some connecting in the background and figure out that your address has changed and call up a link into google to figure out the km for you.   My perfect next generation SaaS would have things like this built in from the get go.  :)

Thursday, 13 March 2014

Workday overlapping responsibilities

We are a large US company covered by SOX regulations, so we have a lot of checks and balances built into our current HR system processes.  We have various groups who have defined responsibilities and they are granted system access based on these responsibilities.

Implementing Workday, however, has caused some interesting discussions.

Who owns calculated fields?

On the topic of calculated fields, we have overlap and confusion over who 'owns' this area. 
  • IT wants to claim it as calc fields are often part of an integration.  If you change one of their calculated fields, potentially you impact or break an interface to a downstream system.
  • The HR reporting team consider them to be an HR owned item as they are also creating them for their complex reporting needs, and if you modify one of their fields, potentially the reports to top management will be wrong.

Should the Business Process Administrator and Security Administrator be the same team?

  • We have a full-time person assigned to the project who covers things like Audit and Compliance.  This person is adamant that these two functions be split.  One person should not hold both powers.
  • The HR sub-team who have BP ownership would prefer to have security administration, as it would be more efficient if they could control domain security policy.
  • IT ended up with Security Admin responsibilities, but with a policy that HR approves/IT actions.

Who moves projects in Workday?

  • In our PeopleSoft world, we have a change request process, the usual type of thing, a customer requests something, functional approval of the request, functional specs, technical specs, a developer creates a project, then ultimately a non-developer database administrator moves the project to production, upon customer sign-off.  This DBA will take a quick look at the SQL before moving it and give it an overall sanity check, making sure that all of the objects referenced are there, and will run any database level SQL that is needed, etc.
  • We've replicated this same process in our new WD world.  So customer request etc. through to the DBA applying the move.  However, this DBA is not trained in WD and the equivalent of moving a project is more simple, choose the item to migrate and away you go.  
  • It gives us the segregation of duties that we need, but seems a little silly to have a Unix admin with this responsibility in WD.
These topics will become even more interesting when we bring in the European data and will need operational support in our timezones rather than waiting for America to wake up.

Saturday, 8 March 2014

Required vs non-Required fields in Workday

I've been looking further at the Disability data pages in Workday, and do these meet the need of the data required by the various country payroll providers.  Typical analysis tasks exist like you'd do for any system:
  • Understand the business requirements, fit gap for the data elements
  • Ensure that the data home is palatable for developers and report writers
  • Make the data entry as easy, friendly and automated as possible for the data entry teams
  • Think holistically, will this definition work across the countries?
  • Consider long term, is the entry sustainable, will this be a self-service item, etc.
In essence, it's a balancing act of these various pieces, whenever I design a solution. 

Occasionally in PeopleSoft, an entry person has to put default data into a field to be able to get into a field that they must use, so be it.  On the flip side, if there is an important data element or one that if not populated will break an important interface such as payroll, we've been known to make the quick and dirty customization in PSoft to make the optional field required.  (Technically it's a customization, but an easy one to turn on the checkbox.  It's more of an effort due to our change management process to make/test this 'code change'.)

In looking at Disability in Workday, only the Disability code is required, none of the additional fields are required.  As a SaaS solution, there is no option to customize to make these fields required.  My issue here is that country-specific interfaces require a set of fields as mandatory for disability.

Where this is going to be a challenge for us:

  • Like many companies in Europe, our Shared Services data entry team supports multiple countries.  
  • Some data entry will always be country specific: Name formats, Addresses, Disability, Labor Agreements, Establishment for France, Brazil etc.  
  • Often, it's consistent across a country, but the system just makes all the fields open.  Thus the 'Flexible' description.
    • Fields can be entered/non-entered for a country
    • Fields have no setup values behind them, they are free form

My concern is that in this example, Disability is not a daily entry task, and it differs greatly per country.  We cannot dictate entry at a system level, beyond giving an entry professional access to the page.  There are downstream, i.e. Payroll, impacts if the person does not do the entry correctly.

So we'll need to prepare entry documentation per country, that the entry person will need to look up and use each time they need to enter this data.  With WD's regular updates this will be a challenge to keep current.

While this item alone is not huge (we're not hiring a disabled person every day, although in some ways it would be better if they were doing the data entry every day, then the rules would be memorized), when you start to add up the various items that will require similar efforts, it starts to add up.  For fields that do not break an interface but are important for business reporting, it will become a matter of building audit reports and chasing up any 'required' fields when empty.

I realize this topic continues to come up on Workday's Community site, the ability to make a non-required field 'company required', and knowing nothing about the guts of Workday, I'm suspecting it's a pretty big ask since it's not getting picked up.  I am starting to get a little nostalgic for a non-SaaS HRIS though, as I consider:

1. Broken interfaces due to incomplete data
2. Additional auditing needed
3. Making extra documentation so that people know what fields are required.

Also fully recognizing that this is not a 'Workday' issue per se, but moreso a 'SaaS' issue overall, that configuration is limited to the vendor's offerings.

Wednesday, 5 March 2014

Workday's configurable fields

Workday's configurable fields is always an advantage mentioned in the sales cycle, so some brief thoughts on this topic as I've had a chance to try it out from a European perspective.  In conjunction with Workday, we are also implementing a managed services, outsourced payroll provider.  As a part of that the new mantra has become, 'if it's in payroll and not a calculated element, we need to make Workday the source and interface the data'.  So any employee demographic data or 'flat' data will need a home in Workday.  This differs from our current landscape where we have certain fields that could be housed in PeopleSoft, but the payroll system was really considered the owner of the data so data was maintained more consistently there.

So I'm doing a lot of analysis and solutioning these days of historically 'payroll' data.  Currently, as payroll implementation discussions are happening in each country, the teams are reviewing the data in payroll and forwarding over questions, as to where/how it can be stored in Workday. 

I've had a chance to review the Disability setup in Workday, based on various countries requesting this data for payroll.  In Europe, a lot more data is potentially tracked than in the US, and it differs per country.  There are government reporting requirements, and as I've heard from some HR in country, there are some tax benefits for the company if you employ people who fall under this classification.

In our current PS environment, there is one page with any relevant field, and a data entry person has to know which is relevant for the country.

WD lets us turn fields on and configure at a country level, so if your employee belongs to country X, then you get the relevant fields for country X.  Just a quick visual here, the first is a European country with all options turned on.  The second is the equivalent for a US employee.  There are more fields on both pages, but just wanted to give you a snippet of how the differences appear:

This will be quite helpful from a data entry perspective, as we'll be able to keep the entry screen clean, with only the relevant fields for a country.

From an analysis perspective though, this is why WD takes so long some days.  We don't have this level of granularity in the current system, so going out to compare to the payroll system, confirm with the relevant HR, payroll or compliance/reporting people the mandatory vs. optional fields then to document at a country level, do the configuration, define the data load, get the data from the current source, load, test, etc. all takes a lot of time. 

Overall, I like what I'm seeing, this is an improvement over PS.