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.

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

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.

 Usability

• 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.

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

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.

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.

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.