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.

The frequency of Workday's upgrades

Our move to Workday is an overall strategic direction to move applications to the cloud.  One of the major points that was highlighted in the presentations of many of our business leaders was the frequency of updates of Workday; I recall the graphic used to represent the current ERP providers was a herd of dinosaurs.  ;-)

When we started this project, WD was on version 17 and they're now on 21 with 22 just around the corner.  Thankfully WD is doing twice per year updates rather than three times a year, as the testing and re-writing of training documentation, etc. can be quite an effort.  I had written about the overall Tenant Management Process a while back.

I was reading some of the discussion on Workday Community (Workday's portal for customers, it is a helpful source of information and to connect with other customers).  The current upgrade version timing is listed, along with some tentative dates.  A lot of discussion centers around the Winter/Summer timing, as opposed to being Spring/Autumn.  So Winter is Jan/Feb Summer is Jul/Aug, if the tentative timing is any guide.  I realize that no date is perfect for everyone, but a few key points here:

• A lot of companies are still closing out the calendar year in January, doing performance reviews, etc.  Resourcing can be a challenge.

• For those of us in Europe, Jul/Aug are key holiday months for most of the continent.  While it can be quiet as most employees take vacation or facilities are completely closed, it can also be scarce in HR departments too.

• WD 22 is scheduled for Easter weekend.  Back when I worked in the US, I recall system launches during holidays, to take advantage of employees not needing or using the systems.  Since I moved to Europe however, I've discovered the joy of the four day Easter holiday weekend.  Most countries over here are completely off and trying to get people to work on those days would be a struggle.  This point takes me back to a regular point:  WD still does not bring a global mindset to the table.  (But they're getting there.  I noticed some new non-US functionality--such as French government reports-- is included in WD 21 and WD 22, so pleased as punch to see that.)

• On the other side of the coin, if you want to use functionality in your comp process let's say, you cannot want for the summer upgrade, it really needs to get there early in the year.

• I'm continuing to see WD Tenant Manager jobs advertised, it seems that companies are recognizing the efforts that are needed in this space.

Workday modules (licensing woes!)

During the past two years, I've had a chance to do fit gap analysis and scope out how we'll meet our business requirements by data entry and processes within Workday.  As you might expect, a lot of the core HRMS fields are in Workday just like they would be in any other HRMS.  A few gotcha's however:

1. Company credit cards 

• Background  
• we use equivalent functionality in PeopleSoft, mainly with a minimum field set.  We use it to flag that someone has a card, expiration date and card status (closed, etc), but none of the actual card details.  
• We built an interface from the credit card (CC) vendor into PSoft to load the data automatically.  Then the team responsible for credit card administration runs existing reports to see what terminated employees have a non-closed card so that they can close the card and take steps toward chasing up any open balances.  The team in Europe has 90 days to get the balances paid off by the employee, otherwise they are written off.

• Workday functionality 
• Workday has credit card pages, and they look very similar to what we need and currently have in PeopleSoft, yay!
• WD classifies the credit card pages under their 'Expenses' rather than 'HCM' module...so we cannot use them...booo!  :(

• Our WD workaround?
• Use the 'Business Asset' functionality.
• The good:  it allows us by hook or by crook to shoehorn the data in there.
• The bad: we cannibalized the pages to make the data fit.  Also, Business Assets are tied into the Finance Management side of WD, so there's a lot more background functionality that you need to work around.  Don't get me wrong, officially, you can use it under HCM, but you need to take care to not wander into the FM fields/processes, as those are not allowed.

  2. Non-employee/Contingent Worker Suppliers

• Background - we store contractors, consultants, auditors, etc. in PeopleSoft currently, including their provider (Randstad, Hays, etc.)

• Workday functionality
• Workday allows you to store non-emps, yay!
• Supplier (provider) is not an HCM field.  Instead, you're wandering back into the Finance side of things, and having to make big changes to business processes (BPs) to create a supplier setup process to be able to set up a supplier and associate it with a non-emp.

• Our WD workaround?
• Our WD certified consultants would prefer not to do all this extra work to get in one data element.  So now we're going back to the business to inquire further if they really truly need the supplier data on the 70%+ non-employees where they have entered it, or can we drop it when we go to WD.
• If they do not agree either we'll need to start setting up the processes or we'll need to use one of our custom fields instead.

I'm sure we'll find more of these and no software is perfect.  However, I'm noting them here as I wasn't expecting to get tangled up with either of these.  Hope this helps someone out there!

Workday in a global phased approach

Part of our company has gone live on Workday, the rest is still to come.  I've been involved with multiple HRMS implementations in the past, both big bang and a waved approach.  A few thoughts in this moment on Workday in a phased approach.

• The setup of org structures really challenges a waved approach.  Back in the good old days, with a software such as PeopleSoft, you would simply put the minimum in for a group, and leave other fields blank, such as department supervisor.  Workday wraps a lot more into the orgs, and more data is required.  So either you are dumping people into large bucket orgs just to get the people in (to be corrected later), or you're having to define the org structure completely.

• If you have a large cross-country management population, Workday in a phased approach will be challenging.  For example, many of our US folks have non-US managers.  We've had to *hire* these non-US people into Workday, as it was the only way to show the 'real' manager of the emp.  (The other options considered were to give them all one bucket supervisor and hire that person, or to give them US managers or to hire the non-US managers as non-employees).  It was deemed insufficient by the business to give them 'fake' information, especially as the data flows downstream to places like expense management.  Therefore, our Workday certified consultants recommended that our best option was to *hire* the non-US people.  As you can imagine, this will be quite a jigsaw puzzle to put together once we get to those countries, to make sure we don't load that non-US manager twice.  (sigh)

• We had considered to roll in the countries as we have a country done, via Workday's delivered EIB functionality.  Then, a group could submit the completed Excel and the current operational support team would load the files.  Our consultants have instructed us, however, that this is not an option, as Workday requires you to take down the system to implement new groups.  I'm not sure on this one, but we regularly acquire new companies and large groups, and like many other large companies, we have people around the globe in the system at all times.  We have other SaaS HR applications, and the do require you to take the system down for major configuration changes.  However, I'm struggling to understand why a new employee load requires system downtime.

• We are cross-challenged by other variables outside of the US, such as the timing for payroll implementations.  Country X can only go live in January and country Y prefers to go with their tax year that start in April.  Therefore this org thing and the lack of flexibility there puts us between a rock and a hard place but payroll tends to trump.

• I've been chatting with other WD customers in London, most of them are small firms and everyone has gone big bang.

Watch this space, it's bound to get interesting.