Tuesday, 1 April 2014

A customer perspective on Workday Rising Europe 2014 - day 1

General Throughts

Workday's first customer conference in Europe, Workday Rising, started today in London.  Officially it started last night with the welcome reception, but the kick-off and first sessions were today.  Supposedly 600 people were there, and it felt like it.

Kudos to WD for allowing anyone to watch the keynote online live, and recorded (only through Friday morning).  I will leave you to make your own thoughts on that one.

Everyone had a colour-coded lanyard, that helped in case you were looking to talk to someone.  Blue = existing customer (me), orange = potential customer/considering workday, green = consultant/vendor, grey = workday emp.  After the keynote there was a coffee break, so helpful to get to meet other customers and to catch up with people I've met through the years.

HCM/Finance combined session

Next was an overall combined HCM/Finance session, to show customers who used WD for both sides.  Sidenote:  As we're in the coffee break and the overall session was about to start, orange t-shirted people (WD emps?  KPMG?  outsourced logistics?) came through and instructed us to move to the next room.  It was more of an order than an offer.  Once in the next room, they used hazard tape to block off the last rows of seats, forcing people into queues to pack in the first rows.  At this point, my European colleague says, 'what is this, kindergarten?'  I managed to ease us around one of the matrons by saying that I might need to leave to take a phone call and managed to get us at the back of the room, thereby avoiding the sardined front section.  It worked out better for us as well as we were conveniently in front of a screen so could see the WD pages that they were demo'ing.

It was a joint session with HCM and Finance, done by WD emps and supplemented by customer stories.  the HCM leader was an American living in Paris and she insisted on kissing each speaker twice as she gave them control.  Odd.  I can only assume she was trying to be more European, but in London we don't go around kissing colleagues in the office.  When I've been in conferences or business meetings in the past in France, the kissing was mainly a greeting thing, not done while in presentation mode, but however...

There was another WD woman, something with HCM strategy and she spoke terribly fast, so a bit difficult for non-native speakers to follow.  It was nice to see her demo some of the newer recruitment functionality upcoming.

They went with the 'theme' of 'be a hero to your business,' complete with cartoons and continued references.  I can only assume that was a marketing take over from the US conference as that one wasn't really understood, appreciated or geared toward European work styles.

One of the male WD speakers made a reference to some functionality, and it would make him a hero 'equivalent to half of a Churchill'.  I think he expected laughs there, but the American humour really fell short.

One of the female WD speakers had a slide with Twinkies on it and at least asked if the crowd knew what they were.  As there was a large American contigent there, I'd guess maybe 25% of attendees raised their hands.  (They're not a European product, although especially in the UK we get a lot of US TV shows, so UK people know more American cultural references than on the continent.)  She explained that she was asking as she did this presentation in Copenhagen and not one soul knew what a Twinkie was.  The whole purpose though, was to explain how WD helped Little Debbie with the acquisition of Twinkie.

Thompson Reuters had an engaging speaker, explaining why they chose WD and what they were doing with it and what they were planning to do next.  Another company, icm, gave a presentation, another great speaker, but completely not relevant for us as they have an employee population of 500 and were able to standardize onto one set of systems for Financials.  As we are 320 times their size, we have a diverse Finance and Expense system landscape and have no plans to implement Workday for either.

Lunch was one of those typical conference affairs of help yourself and then stand around at bar tables or balance your plate on your lap where you could find a seat on some of the benches.

Afternoon sessions

The afternoon was smaller sessions, you chose your sessions when you registered for the conference.  Then, the door monitor would scan your badge to see if you were allowed in.  I was a bit disappointed to miss out on the 'support' session, but went dutifully to my 2nd choice 'global' session with J&J.  (I registered over a month ago, so no idea when you would have had to register to get first choices.  They had maybe 60 people in a session.)  It was sort of disruptive, they would allow people to wait outside, then at 5 minutes past the start time, they would start to let them in, one at a time, then do a seat count, let in another, etc. until full.  People would then have to climb over 5 people to get to a spare seat, so distracting to everyone.

It was interesting to see how J&J was implementing (a waved approach) and as well the audience questions were quite telling, as people who were live were asking how they had handled x, y, and z.

I next went to 'automated testing', another 2nd choice.  It was informative to hear from the WD QA lead, about the testing that WD does, and how they do it.  Diageo was the customer who presented their perspective of how they test and what they're planning going forward--it seemed a very honest overview from their speaker.  Around 30 minutes was also devoted to Kainos, who explained their Smart testing product.  We don't own it and maybe we should, but I felt too much like a captive audience there.

Later sessions were of a similar ilk.  There is a 'customer appreciation party' planned for later tonight.

In the meantime, I leave you with a few photos from directly outside the venue, where Oracle and SAP are making their presence felt.  If I was WD, I'd be pleased as punch, as these large players are obviously taking them very seriously, and these cobbled together adverts seemed lacking in substance.  Who would pay 900+ GBP for conference entry and then turn around their IT strategy based on a placard on a bicycle? 

Looking forward to tomorrow's sessions...

 

Monday, 31 March 2014

Workday Rising in Europe

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

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

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

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

Monday, 24 March 2014

Workday and German Works Councils

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

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

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

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

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

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

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

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

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

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

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

Monday, 17 March 2014

Custom Labels in Workday

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

What is the functionality?

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

 

What are the areas?

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

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

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

 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.

Sunday, 16 March 2014

Address Data in Workday - SaaS vs non-SaaS

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

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

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

Workday (SaaS) advantages:

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

PeopleSoft (ERP) advantages:

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

 

My wish list...

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

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

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

Thursday, 13 March 2014

Workday overlapping responsibilities

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

Implementing Workday, however, has caused some interesting discussions.

Who owns calculated fields?

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

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

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

Who moves projects in Workday?

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

Saturday, 8 March 2014

Required vs non-Required fields in Workday

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

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

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

Where this is going to be a challenge for us:

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

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

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

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

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

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

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