Workday Compensation: What every Comp & Ben person should know

PARIS

Anyone implementing Workday, either its HR offering (Workday HCM) or the Financials suite, will inevitably come across the compensation bit. And that's when challenges start and questions fly. What is involved? How easy is it to implement? How good are the products?

Having implemented Workday for the past 11 years for an exact number of 11 companies (talk of some symmetry!), here are a few tips on how to go about all things Compensation , organized along four pillars.

I. CORE COMPENSATION
It is a safe bet that if you're thinking about implementing Workday, chances are that you will be implementing Workday HCM and starting with the foundation product Core HR. Another safe bet is that as you plan on implementing all data, processes, security and reports involved with hiring, moving, promoting and terminating employees you'll have to implement the basics of Compensation. That is a foregone conclusion since no employee record is complete without at least some compensation components: salary and allowances that are committed to the employee when they are hired and onboarded. 

With this module you can track all types of gross compensation (for net compensation, see Payroll below) usually set up via Compensation Plans. Those plans determine if an employee gets a monthly salary, some 13th- or 14th-month pay, some seniority, housing or transportation allowance or a one-time payment (for instance, a welcome bonus or severance payment.)

To decide how these plans are assigned to an employee Workday provides Eligibility Rules which can be fiendishly complex - if that's what you want. There's beauty in simplicity, so before you start making highly sophisticated rules to decide who gets what (belonging to company X, with a management level of Director but not part of Location Z etc.) do yourself a favor and think about the cost to the maintenance team. One thing I strongly advise against: Do not add employee ID in these eligibility rules. It's akin to making a law for just one citizen. 

How thorough should your compensation be in Workday? It really depends on what your objectives are and how integrated your HRIS is. Some companies only track base salary and leave the rest in local systems. Others decide to have a full-fledged compensation system in Workday as a reflection of their rewards policy: In which case you'll have all types of Compensation Plans (not only Salary but Period plans, Allowances, One-time Payments) including, for the more complex ones, Calculated Plans. This way, especially for global companies, your compensation policies can migrate from local payroll systems (often the only HR system of record for those local subsidiaries) and become part and parcel of you global system. What is then left in Payroll is discussed in the next section.

II. WORKDAY PAYROLL
To help make a decision on what to keep in local payrolls and what is best handled in Workday, I have developed an analysis which I first shared with United Nations agencies when they started implementing Workday (In my distant past I worked 5 years for the UN: 2 in New York and 3 in Madrid.) Below is the framework I developed and then fine-tune for every customer. Since it is my intellectual property and proprietary analytical tool, contact me directly if you are interested.

I developed this multi-criteria analysis based on different combinations of criteria depending on company size, geography, scope, industry and management complexity. Although in its simplest expression payroll deals with gross-to-net calculation, the challenge is to reach agreement on what gross items needs to be part of the global Workday system and which ones can safely be left in local systems. I have spent an inordinate number of workshop hours with various companies trying to reconcile different stakeholders' positions on this topic. Note that some companies for some cases use net data in Workday Compensation (not Payroll) using a feature called Eligible Earnings Override.

Adding to the challenge is that some subsidiaries of multinationals may be willing to move to Workday Payroll while others would rather stick (for the time being, at least) to their current vendor. Even more challenging is the case, which I was recently involved with, where a global company had the US subsidiary already using Workday. It was quite complex to convince them that they had to re-implement the tool but in a different way, because what was acceptable when you only had to deal with North America Comp & Ben policies no longer holds true when you become part of a new global design. And even if none of your subsidiaries are using Workday at the outset, which probably from an implementation makes it easier, half way through implementation you may acquire a major company which is already live on Workday with their own compensation approach and suddenly the painfully reached agreements with the other business lines and countries is thrown up in the air. Although this may affect any implementation of an HR system, when it comes to compensation people tend to be very touchy and jittery about change.

One of the criteria to take into account is whether/to what an extent you want to make use of Workday payroll. Unlike other compensation products (or other modules from other product families), you usually license Workday Payroll for the countries you're interested in...if those countries are available. Unlike its predecessor product, PeopleSoft, where I was Product Manager in the early 2000s and where in a period of 18 months we added payrolls for 10 countries, Workday's payroll approach has been of the drip-feeding variety. For its first decade, the vendor only focused on its North American turf and released US Payroll and Canadian Payroll. Only recently have UK and French Payroll been released with Australia even more recently. Unless you're particularly lucky to be operating in only these countries, you'll have to make do with your current vendors for non-covered countries. But if you can implement Workday Payroll along with your Core Compensation from the same system, then you'll benefit from the advantages of having a single integrated system (same data model, security, reporting etc.)

And just because a country payroll is available doesn't mean it makes sense for you. Again, another differentiator with PeopleSoft (a.k.a. Workday 1.0):  In France, for instance, the first PeopleSoft French Payroll customers were major companies (such as banking giant Société Générale); for Workday, large French companies which have taken to Workday HCM enthusiastically, have been strangely reluctant to test the payroll waters. So far, only mid-size companies like well-known retailer Franprix have adopted Workday Payroll whose implementation in France has been, shall we say, challenging. And I'm being charitable here. 

Finally, if you wonder what Workday Payroll UN agencies use, be apprised that they are the only customers who don't need a country payroll to implement payroll because as an intergovernmental organization they are not subject to local rules and regulations. To put in another way, they make their own labor laws meaning that they can implement Workday Compensation/Payroll/Benefits in a very tight manner to meet their quite complex requirements (UN member states' rule creativity is on a  par with national governments' legislative innovation -  if you get my drift 😊)

III. WORKDAY ADVANCED COMPENSATION
Disclosure: This is my favorite of all 4 Workday compensation products - half of my decade-long Workday experience has been spent implementing it and providing support on it when it goes live. Unlike Talent/Performance, which can be implemented with a limited Core HR (not something recommended by Workday, although one of my first clients infamously did just that as they moved from SAP to Workday); Advanced Compensation not only requires that you already have in place a robust Core Compensation but also Core HR - without them, the exercise is largely pointless.

So, what is Advanced Compensation about? It is about organizing a structured conversation between various stakeholders at the beginning of a new year to make decisions as to who should be rewarded for their work through a salary increase, promotion, stock or bonus awards. Both Core Compensation and Advanced Compensation (henceforward CC & AC) are based on compensation plans (AC plans are Merit, Bonus and Stock plans) but here the similarities end. 

If you see in an employee's file that they have been assigned a Salary plan or an Allowance plan (both CC) it means that the amounts at hand are guaranteed to be collected by the employee; however seeing that an employee was assigned a Stock plan or a Bonus plan (both AC plans) doesn't mean at all that they will receive company shares or a bonus. For that to happen, two more developments need to take place:               

-First, a specific process (called a Compensation Review) needs to be launched. Until and unless such a review cycle has been launched, those Merit, Bonus & Stock plans in the employee's file (Worker Profile in Workdayese) are merely decorative. Just because you have a 5% target in your merit plan doesn't mean that you will be inevitably get a salary increase the following year. After a review cycle has been launched, another development needs to take place.

-Second, through various stakeholders (usually managers, HR, Comp & Ben team) agreeing on it, a decision is made and confirmed that your salary will be increased with, maybe, a few company shares and lump sum thrown in as well if you have been deemed worthy of the attention. 

 

               Where it all happens: The Compensation Review Grid  

 

Please note that I mentioned earlier that AC needs two other modules to  have been implemented: Core HR and CC. A third product, Talent/Performance, is not necessary but an increasing number of companies have found it useful to link AC to Talent & Performance so that a compensation review process follows a performance review cycle and feeds it through an automation of the proposed guidelines. Thus, if an employee has achieved 100% of their objectives they get, say, a 3% salary increase, but if they exceed their objectives then the increase goes up to 4%. Other criteria may also be included such as equity or market position, but as you may suspect I could rant for hours on the AC module and I still won't have enough time and space to do justice to it. I therefore better stop here and move to the last piece in the Workday Compensation puzzle.

IV. WORKDAY BENEFITS
Just as any HRIS implementation will require an analysis and decision of what should stay in local payroll/HR systems and what should migrate to Workday/Compensation, the same thing applies to Compensation vs Benefits. Since practice, culture and regulations vary from region to region or even with a group of countries, any strategy will be different.

For instance, in the United States, Health, Retirement, Life and Disability can be provided to employees on a flexible basis, via an overall package whereby they pick what combination they are interested in. In continental Europe, on the other hand, most of these benefits are mandated by law and/or company/union agreements. This means that for US/UK employees, you may need strong self service benefits features, whereas in Europe these are not needed. 

Below are some criteria of an analysis framework that I developed for my clients when implementing Workday in order to decide what should be implemented for what features. As an example, a Dental Plan may need to be set up as part of the Benefits module in the US since coverage, eligibility and elections need to be tracked from employee to employee where they can differ. In Europe, on the other hand, all a company may want to track is that as part of your overall compensation package (Total Rewards in Workday jargon) employees are provided with a Dental Plan. If which case no need to use the Benefits module for that (which, remember, comes with a separate license): You can use some appropriate compensation plan to track the same type of data. 

 

Since obviously any approach has to be tailored depending on the specific situation of any company, for further information please reach out to me directly.

V. INTERFACE
Since most of what happens within CC and AC is irrelevant if it doesn't find itself paid to the employee, getting the data from Workday CC & AC is therefore key. This can be done in several ways.

-The basic way is to extract data via a report and, after having transformed it in the right format, feed it into the local payroll being used.

-Use the various Cloud Connect/Payroll Interface tools using specific protocols like PECI or PICOF that Workday offers. EIB (mentioned earlier) can be used as well (see below diagram.)

-You may also want to interface Workday Benefits to the various third-party vendors a company uses -> Cloud Connect for Benefits is probably your best friend especially for Cobra integrations int he United States. 

 Since this post is only about the four Compensation pillars within Workday, and Interface/ Integration warrants a separate post, I'll leave it at that for the time being.

(The blogger/consultant, after having spent most of 2023 implementing Advanced Compensation, is now providing operational support on a compensation review cycle launched this month for a global group with a 70,000+ headcount.)

Workday vs Oracle: A comparison of two cloud HR systems

PARIS
If Workday is the belle of HR systems, Oracle is undoubtedly her ugly sister. Having implemented both, let me share some examples to prove my point. (The Oracle system here is the one that Oracle actively sells, Fusion HCM Cloud, having retired its shoddy predecessor, EBS, and putting PeopleSoft on life support.)

OVERALL SYSTEM USER FRIENDLINESS
In the 20 years I've known Oracle, one thing has not changed: its scant regard for customers and the most obvious consequence, poor user friendliness, reinforced by a technology that seems always a generation behind others. Key example: In most consumer-grade platforms you can get further details and actions from a given object you're looking at by clicking on the dots that can be found around that object, usually at the upper-right corner (just check any Google page) which in addition you can check by opening another tab.

As expected from a modern HR system like Workday, if you're looking at an org chart and wonder who a specific employee is, all you have to do is right click with the mouse on the dots and that employee record opens in a separate tab for you to peruse their data. Once your curiosity has been satisfied, just close that tab and go back to where you were, the org chart, to continue the work you were doing there.

No such luck if you're using Oracle Fusion. This supposedly latest-generation tool will display a pretty average org chart (see below) and should you want to see the details of a given employee there's no capability to open a tab with that employee's file. You'll have to go back to the landing page, search for that employee and then open their record. And then if you want to go back to where you were (that is, if you still remember what you were doing) you'll have to start all over again, go to the org chart, enter the team you're looking for and the system will display the page you were on eons ago.

As for the search bar, Oracle technology is still stuck in a time warp: it is case and accent sensitive. So if you have an employee called Pénélope (in French) or Penélope (Spanish), and you enter "Penelope" you'll get no results. Obviously, no Oracle developer has ever used Google and other similarly ubiquitous internet tools. 

Menu jumbo-mambo
 

In Workday, action menus are organized alphabetically, which is the logical way to go about things on Planet Earth. The five most frequently used actions appear first, which is a great time saver. On Planet Oracle, actions appear randomly, making you waste quite some time going up and down and across the the screen in hot pursuit of the action you need. Nobody ever told Oracle that making life easier for the customer should be top priority.

 

 

 

 

 

 

 

 

SYNC ISSUE
We all know that "integrated" systems are rarely so, but what is amazing is that with Oracle even within a single module or feature thereof you still run into synchronization issues. Let's say that as a manager you perform an action in Workday (e.g., move an employee from your team to another) and this action requires an approval from another role (say, HR.) You log in as that HR person and here's the approval task awaiting you. Try and do the same in Oracle: you'll have a 3 to 5-minute time lag before the action travels from Manager to HR. In real life it doesn't really matter, but in project mode when you're constantly testing system setup and configuration it soon becomes bothersome and frustrating. 

Language enablement is another area where Oracle's sync'ing prowess is, shall I say, sinking? If you need to turn on a certain number of languages to go with your global deployments, with Workday it can be done in a couple of clicks and you see the results instantly. If you are unfortunate to have selected Oracle Fusion, you need to request language activation with Oracle Support. If you happen to do this on Monday, too bad, since this is done over the weekend. And since it takes half a day per language, your global implementation may have to wait an additional couple of weeks before you can go in and start checking translations.

SECURITY AND WORKFLOW
Whereas Workday can handle complex security requirements via domain and business process security, Oracle is very limited, often offering only global roles with no possibility to restrict per country/company or other criteria. In addition, whereas Workday proposes role names that are meaningful (Compensation Partner, HR Partner etc.) Oracle suggests roles with inordinately long names to remind users what that role can do (HRWithCompensationNoNotification). Can't get uglier than that.

Managing role conflicts is always an issue the more complex system implementation is. Whereas Workday has its own challenges, business process conditions work pretty well.  (Glossary: business conditions which allow you to decide how a specific role at a  specific step in a given workflow should behave.) Oracle, on the other hand, doesn't manage role conflict satisfactorily. A user case I struggled with during an implementation of Fusion  is the typical case of an HR user who is manager of an employee for whom he also plays the role of HR. If this manager initiates an action as manager and this action requires HR approval, you'd think since this manager is also this employee's HR they don't need to approve themselves. You'd be wrong! Oracle will make you do exactly that, which is absurd. You won't have this issue with Workday because its workflow configuration includes the possibility to exclude someone from approving a task if they are the initiator.

In summary, Oracle's  workflow capability can't hold a candle to Workday's which is extremely rich and allows for a level of granularity and sophistication Oracle customers can only dream of.

HALF-BAKED SYSTEM
Both Workday and Oracle provide various seniority dates to be used where relevant depending on whether one is interested in a hire date, or a company date, or time in a position etc. The similarities  end here: whereas Workday offers straight out of the box all these dates (as a user just go to an employee's record file and you'll see all the dates for that employee), Oracle will ask the user to launch a calculation for the dates they are interested in, otherwise they just remain empty not because some data is missing but because you haven't requested its calculation!!! Use case: You launch a promotion action on an employee and in order to help you make up your mind you need to know how long they have been in their current position.
In Workday, the data display effortlessly so you can continue with your promotion task.
In Oracle, you'll probably be met with an empty field, so you'll have to abort the task (remember you can't have two tabs or pages open at the same time in Oracle), go to the Seniority Dates screen in Quick Actions,  request a calculation, and then start the promotion task all over again. Awful user experience. Got forbid that at that moment you need to check another piece of information (say, compensation). You'll have to exit the promotion task one more time, go to Compensation, view the data and, if you still have not slit your throat in despair, launch a THIRD time the promotion task. One of the nuttier design decisions I've ever seen in my quarter-century experience of HR systems. 

Simple and available - the Workday way

DATA LOAD/MIGRATION
I could rant for days on how complicated data management is with Oracle, but suffice it to give one example: data inactivation. Let's say that you created a contract type which is becoming obsolete. To inactivate it you will need two rows: Start and End Dates of the period when the contract was valid and another row with the Start and End Dates when it is no longer valid. Now, since the End Date of Inactive is till the end of time Oracle requires you to put something like 4532. Why this date and not 9999 the way they do it at SAP? And why do we even need to put an End Date? Because Oracle is still run by the same people who created the relational database and keep on thinking along the lines of this technology that harks back to the last millennium. 

QUESTIONABLE DATA MODEL
Every vendor has their own data model which has been a perennial issue in system-to-system integration. None is worse than the manager data model as pursued by Oracle versus Workday. With Workday, a manager is appointed on an organization (or team) and any employee part of that team will share the same manager. Clear and straightforward - even if some first-time Workday users may be taken aback at the logical consequence of this choice: a manager will always sit in an organization above the one holding his/her team.  An employee is hired into an organization. With Oracle, things are illogical and a source of endless confusion to users: a department with 3 employees can have 3 different managers since employees are linked directly to a manager, and in this case each can have a different manager. A department manager can be assigned (as a system admin task) but only employees without a directly assigned manager will inherit that departmental head as manager. You can easily see how ugly this can turn with different employees having different managers, some sharing the same or having none whatsoever.

Calculated Fields vs FastFormulas
In short, both are ways to write custom rules such as a calculation of a compensation element or a condition/eligibility rule to apply to who should get that compensation component. And that's where the resemblance between the two stops. Whereas Workday has innovated with an easy-to-use feature whereby you assemble your rules from different objects Lego-like, Oracle is still stuck in last millennium's technology -hardly surprising when you know that FastFormulas are a transplant from Oracle's much-hated EBS HR system which only a database nerd can make sense of. See below screenshot from the two to get a sense of  how Workday has managed to become the default tool of HR users. 

Today's tool vs yesterday's

Custom Objects vs Flexfields

Here again, we have similar objects aiming at extending a system's capabilities beyond what was initially supplied by the vendor. But whereas Workday makes it easy to build, use and maintain such objects, Oracle's Flexfields have serious limitations. One of the most egregious being that on any screen it is linked to, a Flexfield appears systematically at the bottom. To give you an example, let's suppose that in a Hire screen in addition to the standard "Business Title" field, you want to add a related field called "Local Business Title". Since Oracle doesn't offer a second such field you'll have to create it via Flexields. So be it, except that being a Flexfield it appears all the way at the bottom of the screen, probably next to a data section on addresses or blood type which have nothing to do with it. Very confusing to the user. Worse, if the Flexfield is to be filled with a value depending on what you entered in the standard field, you'll have to scroll all the way up to remind yourself what you entered and, having duly taken note of it, scroll all the way back down to enter a value for the second, related, object. In terms of customer experience, it's simply awful, but on a par with Oracle's products.

DOCUMENTATION
The differences between the two vendors couldn't be starker: whereas Workday has a flourishing Community where you can find an easy answer to set-up documents, share best practice ideas with other customers, suggest enhancements to the tool (and track its status), Oracle is...well, Oracle. Its Help Center is anything but helpful. All you get is some marketing PowerPoint presentations, fluffy documents, links to attend Events and that's it. If men are from Mars and women from Venus, well Workday is clearly from Planet Customer and Oracle is still stuck in its Planet Larry Ellison - or Technology: the two are interchangeable.

So, why do some companies buy it?
I could go on for hours and inflict thousands of additional pixels on your retina, but I think you get my drift. Which prompts the following question: with Workday being manifestly so superior to Oracle in every way, why do some customers still buy Oracle for their HR needs? 

First, you have to realize that only current customers (those who are using Oracle database or middleware or Financials or legacy EBS system) have any interest in envisioning the possibility of purchasing Oracle's Fusion system. 

Second, a majority of Oracle customers (both PeopleSoft and EBS) moving their HR system to the cloud do it not with Oracle Fusion, but with...Workday, proof enough of what they really think of their current vendor.

Third, as for the minority who decides to stick with Oracle, you may still wonder that only masochists would spend good money on bad technology. And here you'd be more right than you may think. When I referred to these customers as buying Oracle Fusion HR, actually I wasn't being accurate because one of Oracle's (many) dirty little secrets is that these customers actually don't buy Oracle HR because ...they get it for free! Oracle just tells them that if they take Fusion Financials, they'll get HR for free. Most customers make the decision that sure it looks ugly but you don't look a gift horse in the mouth, do you? So, they decide to plod on and make the best out of a bad situation.

It's not dissimilar to those millions of consumers  who have a regular meal at McDonald's knowing it's not good for their health (or their palate) but that consideration is outweighed by price and convenience. 

So, my advice to Oracle customers as they head to Oracle CloudWorld is to remind them of that old phrase: you get what you pay for. And as you've seen it in this analysis, there's no denying it: Workday blows Oracle out of the water.

When Workday’s “Power of One” fails: An example from Payroll-Compensation integration

LONDON

At the turn of the millennium, PeopleSoft, the then-undisputed HR tech leader, asked me to join them as Product Strategy Manager to help them with their European payrolls. Until 2001, PeopleSoft only had payroll for North America. For other countries the spin was that what really mattered was to have all your employees’ key data in one global system (Core HR) which you would then interface to various downstream systems (Payroll, Finance, Time Tracking, Expenses etc.) depending on needs. The underlying message was that Payroll was just an engine, not a strategic tool and therefore there was little value in having it in the same system. Actually you didn’t even need to have it in-house, just outsource it to ADP and the likes.

That was until PeopleSoft realized there was a lot of money in the Payroll business and that there was a lot of value in a Payroll-Core HR/Compensation integration after all. That’s when they built a global team, of which your humble servant was part of covering France and Spain. In a payroll blitzkrieg unheard of in the industry until then and since, we brought to the market close to a dozen payrolls (France, Spain, UK, Germany, Switzerland, Netherlands, Japan, Australia and a sprinkling of other countries).

Suddenly, in a not-so-subtle move that I found highly entertaining, Payroll/Compensation integration was all the rage. At every meeting with customers, at HR tech conferences, in press and analyst encounters, our message was that an HR system without payroll wasn’t worth the pixels it showed on your PC monitor. You needed the Payroll module as a mandatory accessory to your global Core HR/Compensation.

Fast forward two decades and to today’s indisputable HR Tech leader, Workday. Just like its forerunner, Workday started with a limited number of payrolls (and no finance tool), so it was all about having a global core HR system, the rest was dismissed with a wave of the hand as optional, ancillary and unimportant. Then came finance and the slow drip feed of payroll and, lo and behold, out of the cloud emerges the fundamental, indispensable need to be able to integrate both within the same system with the same data model and UI (which now goes by the fancy term of UX). Workday coined the phrase of the Power of One which as they say in their marketing material does not “require any process or configuration changes on your end”.

Well, as we all know, there’s marketing and there’s the truth. Or, to paraphrase Mark Twain, there are three types of lies: lies, statistics and software marketing (truth be told, Workday is certainly not the most egregious perpetrator here; the Oscar probably goes to Oracle and their fanciful claims about basically every product they throw at their customers.)

But, back to Workday, since this post is about Workday. There are many examples where the Power of One is contradicted by the reality of many. The one that I want to focus on deals with one of my favorite Workday and HR topics: Compensation under its various guises: Core Compensation, Payroll and Compensation Review.

Compensation Review is the process whereby you increase employee salaries and award them bonuses and stocks, usually once a year, based on their performance (and the company’s.) To run this process Workday has a pretty strong module called Advanced Compensation, on which I got certified in 2019. I’m not going to inflict boring technical and business details on you, but suffice it to say that in order for a bonus to be calculated you need a reference compensation if your bonus is going to be a percentage rather than an amount. That reference compensation (which is called Compensation Basis in the Workday lingo) is usually the standard salary (Total Base Pay in Workday-ese ) or it can be created from scratch to include any compensation component such as allowances as long as these compensation components are…available in Workday. If they are not (such as overtime which is often part of another tool, Payroll) then you need to load those amounts back into Workday using some esoterically named Eligible Earnings Override.

 

The villain revealed

So far so good. Everybody understands that Workday cannot retrieve a data not held within Workday. And since a majority of Workday customers use third-part payrolls (especially outside North America), it is perfectly understandable that these amounts need to be extracted from your payroll system, appropriately formatted  and then loaded into Workday for Advanced Compensation’s consumption.

 

Except that, and here’s the rub, there are many customers who use Workday Payroll. In that case you’d assume from Workday Payroll to Workday Core/Advanced Compensation the data should flow as easily as the River Thames under London Bridge.

Wrong!

Rather than being able to point your bonus calculation to the relevant Payroll earnings (or sum thereof) you still have to go through the whole cumbersome task of extracting/preparing the data in payroll, then loading it into Workday, then going and referencing it for your bonus calculation.  Where is the Power of One? Looks more like the madness of many ─ as we all know how messy integrations are. When you’re using separate systems, no queda más remedio as my Spanish friends would say, you have to build that interface. But why would you have to do that when you’re running the SAME system? That’s what you were told and sold: buy one and no integration need, right?

I heard that Workday is planning on fixing this, which is long overdue. But why did you even have the issue in the first place?  Bad product design happens everywhere, even with the best. But then be a little modest when taunting your Power of One which has been found lacking.

And don’t get me started on absence management. With Workday you can track your employee absences in Core HR, in Time Tracking and via Payroll as well. In Core HR you have it more than once: the standard Absence features and the Leave of Absence functionality. Like estranged siblings, neither seems to be aware of the other’s existence. Another product strategy gone mad.

Workforce Planning? Integrated only in name. Another Power of One derailed.

Alright, I thing I’ll stop here. You get my drift. Time for Workday to spend a bit less time on Marketing and more on Product Strategy and Development.

 

(This is the latest in a series of posts on Workday. The most popular feature below. Many more can be found by searching chronologically the list of posts on the right-hand pane.

-Feb. 2021: "10 features Workday should deliver - yesterday!"

-April 2016: "SOW - A Comparison of 3 Global Cloud HR vendors: SAP, Oracle and Workday"

-Feb. 2015: "An open letter to Workday's Bhusri and Duffield: Time to fix Europe"

-May 2011: "PeopleSoft vs Workday - Old vs New" )

 

(The Global HR Technologist is enjoying a 4-day Jubilee Holiday in London, a place he has been visiting relentlessly on business and pleasure for over three decades now, going back to when he was a teenage student in Britain under the Iron Lady’s rule. “When a man is tired of London, he is tired of life; for there is in London everything that life can afford,” said Dr. Johnson a couple of centuries ago. So true now as then.)

Payroll vs Compensation: The sempiternal HRIS conundrum

RIO DE JANEIRO

Recently, a UN agency which is making the transition from an SAP-based HR system to Workday asked me what they should keep in their legacy system and what should be tracked in Workday. I was glad to share my knowledge and experience as this issue is something I witness in every HRIS implementation I work on. (Disclosure: In my distant past, I worked several years for the UN in New York and Madrid.) 

To understand the complexity of the analysis to be undertaken, you have to realize that the situation is radically different based on whether this is the first time you're embarking on an HRIS project versus whether you already had an on-premise HRIS system and are now moving to a cloud-based one.

If the latter, two situations may arise:

(1) Your scope includes Payroll: In that case it's to a large extent a shift-and-lift exercize. Of course, you may struggle with the limited availability of country payrolls in the cloud system you're moving to versus your legacy system (for instance, SAP has scores of country payrolls whereas Workday has only 4, with 2 more in the works.) This will limit your shift-and-lift capabilities as for the countries in your scope missing a cloud payroll you'll find yourself in a situation similar to the next one.

(2) Your scope doesn't include Payroll: either because (a) your cloud vendor doesn't cover your scope fully, or (b) because to minimize risk, you decided to keep Payroll out of scope for the time being. That's when you have to make a determination what to keep in your local Payroll system and what can be moved to your new cloud system's Compensation module. 

This exercize is similar to the one you'll have to run if you've never had a full-fledged HRIS in the first place. Or, which is the same, if your HRIS is basically your payroll system where HR Admin/Compensation and Payroll are subsumed in the same tool. You'll be surprised by how many companies, domestic or global, still fall in this category.

What is Payroll and what is Compensation?

There may be as many answers as there are unique circumstances. However, one can safely adopt the  following rules of thumb:

• Gross versus net: Compensation, and therefore your new HR system, should definitely hold your gross salary and similar items (such as allowances), whereas the net amount will be held by your local payroll. Don't get confused by the word "calculation" and think that all calculations are made in Payroll and simple amounts are held in Compensation. A Seniority allowance will have to be calculated first in Compensation and only when you have the amount due to the employee, will it then feed Payroll which, after performing a gross-to-net calculation, will then disburse the amount to the employee (via direct deposit or check.)
  
  
• Complex calculation: If a given compensation component needs to be calculated based on criteria and data which are not tracked in your new HRIS (let's say, time worked) then the decision is obvious: only track it in Payroll. 
  
  
• Compensation Package/Total Rewards visibility: One of the advantages of a modern HRIS is the ability to have all your employees' full compensation at your fingertips with a few clicks. If a compensation component is considered as meaningful and can be calculated in your HRIS then it should be part of Compensation. This criterion should definitely be taken into account when selecting a system as Workday, SuccessFactors and Oracle HCM Cloud (a.k.a. Fusion) are far from being interchangeable when it comes to their ability to take different data types into account when calculating a compensation item. 
  
  
  
  
  
  
• Document generation: If there is little doubt that producing a Payslip is a task best left with your local Payroll tool(s), you may decide that it makes sense from a business perspective that storing it in your new HRIS as part of Employee Documents (depending, of course, on your vendor's technological prowess.) On the other hand, if you use your HRIS to run your Annual Salary Review process, then generating your employees' Compensation Statements will be a task for Compensation, not Payroll.
  
  
• Many other criteria  and factors could also weigh in, depending on a company's unique circumstances, but remember the cardinal rule: Your new HRIS should NOT be a carbon copy of your Payroll, the two are linked but as explained in the few examples provided above they are quite different beasts and as such should be treated differently. 
  
  
  (The Blogger/Consultant, after having just implemented an Oracle-based HRIS is now taking a two-week vacation in the Wonder City before starting a new HRIS implementation project, this time based on Workday.)

Of cars and HR software: Metaphor-based HRIS tips

PARIS

Remember that great song "Why Can't a Woman Be More Like a Man?" from that wittiest of musicals, My Fair Lady? Well, for the past couple of decades that I have been in the HR technology industry, I have been asking myself a similar question: Why can't my HR software be like a car? Throughout my career I have peppered my articles, presentations and meetings with car metaphors to drive the various points I was trying to make. (Here's the scene from the 1964 movie with Rex Harrison singing, well more like uttering, the song.)

You'll find hereafter some of the most frequent ones. Note that most would apply to enterprise software, not HR only; however, since I am an HR technology person through and through, you'll hardly be surprised that's my focus.

System Evaluation
This is the oldest car-metaphor case I can recall, having used it for at least 20 years. In the latest 1990s when I started out as an HR system analyst-cum-consultant spending most of my time advising French companies on which HR system to select, I would use this metaphor quite often. Actually so much that I put it early on in my book, High-Tech Planet. Here's the relevant excerpt of the metaphor which I still use to warn my clients off including ever single product specification whim that might cross their mind just because "it can be useful."

Having four wheels on a car rooftop is certainly useful in case the car were to turn over; but since no car maker offers that, it would be a waste of time to include that feature in a list of requirements, especially when every business process is now available in a computer system developed, sold and serviced by countless companies. Delphi Tech was one of such companies. Actually, it was more than just one of them. It was the biggest, the largest, the best-known one: indeed, as Dick claimed, Delphi had to a large extent created the business of corporate software, or at least contributed to its development. It was, as Dick would say, the Rolls-Royce of computer systems.  (High-Tech Planet: Secrets of  an IT Road Warrior, 2010 edition, p. 3.)

I also warn against using SIs (system implementers) as selection advisors for obvious reasons: SIs tend to focus on one or two systems; many, especially the boutique ones, are actually one-trick ponies. If you only have experience driving one or two cars, you will only recommend those ones. Or using research firms like Gartner who have limited, if any, HRIS implementation experience. This is like recommending a car based on several great features, but forgetting to ask the prospective buyer whether they can drive.

And beware overkill: When famed French soccer club Paris-Saint-Germain bought Workday, considering their small headcount and limited resources, it was clearly like buying a huge bus just for you, your wife and your two kids. Or like buying a Lamborghini to avoid walking on your driveway to your mailbox and back.

Finally, I strongly advise against falling for what I call the "critical capabilities" trap. If you only focus on these, you are likely to overlook other useful aspects and not be able to really pick the system that is best for you. Such an approach is as smart as when buying  a car to look only at the number of wheels and car paint. Three cars can all have the same features (tires, automatic transmission, air conditioning), but when you use them you will know which one is better. 

Product Design
As someone who spent a big chunk of his career in product strategy and management roles (at PeopleSoft and Fidelity Investments' HR Access) I am still amazed at how HR system  vendors make a point to diverge on fundamental design choices. If SAP decides that one process will require different screens, you can be sure that Oracle would prefer to have just one screen (albeit a long one obliging the user to scroll down endlessly) while Workday would probably prefer to have several tabs on the same screen. This can be very confusing for users who, as part of their daily HR tasks, have to toggle back and forth between several HR applications. Wouldn't it be nice if they were all designed along similar lines? 

Just imagine that if Ford puts the brake pedal to the left of the accelerator, so Renault puts it to the right. If BMW  uses a steering wheel to enable the driver to move the front wheels, so everyone else must use levers and sticks and chains. There would be almost no learning-curve effects either from a manufacturing or a usability perspective. And yet, HR software vendors do exactly that, which is quite insane, especially when you know that the musical-chairs game so prevalent among software executives means it's basically the same folks who oversee products across companies. 


Change Management
What many end-user companies are still grappling with as part of their new HR system implementations, especially in the cloud, is the right mix between configuration and training which now goes by the fancy name of change management. As I often tell my client, redoing you car's body and changing the engine would be of little use if the driver is incompetent. If you never learned to drive, buy a BMW and then crash it into a wall , how is that the car maker's fault? 

And when a client insists on implementing the same inadequate process again and again, I warn them against reinventing the flat tire.


HR System Implementation
There are many companies that in their move to cloud HR adopted the approach whereby they start with the low-hanging fruit of talent modules before, like an afterthought, implementing Core HR. More often than not, the added complexity doesn't make up for the lower risk. Core HR is your HRIS engine, without it your global HRIS simply won’t work. It is like trying to drive without a steering wheel: you’re not going to go far.

Discussing the Implementation phase one is often reminded that the Design phase seems never to have been closed since users will always try until the very last moment (and even after!) to change the design. This is very dangerous and akin to changing the tyre while driving the car: recipe for disaster.

Another maddening aspect of requirements is that companies often come up with contradictory requirements. Imagine that you're driving a car and when you arrive at a crossroads you ask for instructions, "left or right?" "Both," is the answer you get. 

Cloud/SaaS HR for the dummies
Surprising as it may seem, there are still many corporate executives involved in on-premise-to-cloud transition projects who are still struggling with the cloud concept. This is where I probably make the most of the car metaphor. Starting at the evaluation stage, I warn my clients about  dinosaur vendors like Oracle who try to make us believe that they can tweak on-premise PeopleSoft into a cloud offering. It's like saying that if you affix wings to a car and add  a pointed nose along with powerful reactors, and find a way to hide the wheels, you can turn a car into a plane. It just won't fly - in more sense than one.  

Or putting a new body on a  30-year car. Would you fall for that?

If you still decide to take the risk to adopt half-baked products, then be prepared to fork out the funds needed to have onboard several consultants for a long period of time and whose function will be to fix the inevitable bugs and issues that are bound to arise. Remember that when the first automobiles came, owners needed to hire a mechanic full-time because those first cars had a bad habit of always breaking down.

For those who can't wrap their head around capex and opex (that's capital and operation expenditure to you) I explain that Saas is like leasing a car versus buying it. When they compare that with the millions they used to pay upfront just for the honor of being an SAP or Oracle customer, these executives' eyes brighten up immediately.

One car metaphor I used a lot when the cloud model arrived, and less so now as the cloud has gone mainstream, aimed at helping users to understand the key difference between traditional ERP (on-premise) and the cloud (SaaS based.) In order to convince the pro-ERP camp I explained to them they can't stop progress.  When automobiles arrived, they coexisted for a while with horse-drawn carriages before these got ditched because everybody saw that cars were faster and more practical. As an early advocate of the cloud model, against Oracle's (in)famous scorning of the cloud, I am glad to see that I eventually was vindicated by the market. (See my Jan. 2011 article, "Can software dinosaurs reinvent themselves as cloud-based vendors?")

One concept that, surprise, surprise, dinosaur vendors  try to push is the hybrid system of on-premise + SaaS system supposed to work in perfect harmony like hybrid cars. I debunk it by pointing that it's like saying, "Oh you don’t like the engine in your car, no problem, we can remove it for you and attach the car to two horses instead." Really!

Another fallacy about hybrid HR systems is that customers are led to believe that it's the best of two worlds. Come on! Will you really buy half of a Porsche and couple it with half of a Ferrari? 

SaaS, a relatively new concept,  is often confused with BPO (outsourcing the full process, be it payroll or recruiting.) When a client tells me they are not sure whether they should move to a SaaS  vendor or a BPO one, I tell them they are mixing things: First of all, you have to analyze and make a decision whether you want to run your full process inhouse or out. And only then can you decide, if inhouse, whether Saas or on-premise; and, if outsourced, then what vendor. In car terms, it is like saying, " I’m tired, I can’t walk to work, so I’ll invest in either a bike or a car." Well, they are two different tings, you should be either comparing bike/motorbike or motor bike/car but a bike vs. a car doesn't make sense. Like the proverbial apples and oranges.

Of second-hand cars
Of  course, no car metaphor would be complete without the time-honored used-car example. When Oracle provides its prospects with heavy discounts to adopt Fusion, I remind them that you get what you pay for: If the price of a second-hand car ("used car" to most Americans) is too good to be true, it's probably because it is neither good nor true. Also, you buy a second-hand car if  you’re a good mechanic (in HR technology words, you have enough in-house skilled resources), because then you can fix it. Otherwise, you’re on your own: Compare this with the first-automobile and mechanic metaphor a couple of paragraphs before.

Sales 
I could spend gazillions of pixels and tire your eyes out of their sockets decrying software sales tactics (the object of my aforementioned book.) One particular tactic which I recently saw  on a global HRIS project with payroll outsourcer ADP was when the vendor stated they were willing to bid with SAP SuccessFactors Core HR (Employee Central) but on the condition that my client bought two payrolls from ADP. I shot back at them, "How would feel if your car dealer offered to sell you a car only if you accepted to also buy two bikes?"

Vendor Management
Despite the Buyer Beware motto, customers  are entitled to escalate issues, especially when a promised feature is not working as touted in sales demos - or, worse, is not available. However, I find it misguided from some customers to focus on minor issues while not seeing the bigger picture. It is akin to buying a car that is  bigger, nicer and faster and yet spend an inordinate amount of time on small imperfections. As in life in general, you should choose your battles wisely: know which ones are worth fighting, and which ones should not be launched.

HAPPY NEW YEAR TO ALL!

This is the latest in an HRIS Selection & Implementation Tips series. Previous posts included:
- April 2018: Cloud HR Implementation Tips: Focus on Migration
- Jan. 2016:  Pricing and Contracting with Your Cloud Vendor: Tips and Tricks
- Jan.2013:  An HR leader's Top 10 New Year's Resolutions


(The fact that the blogger-analyst-consultant has been spending the better part of the last year and a half on implementing a new global HRIS for one of the world's largest car makers is obviously a cute coincidence, since I have been using these metaphors for two decades now.)