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.

2 comments:

  1. What we have realized throughout our project life cycle has been the complexity on the back end business process. From a business process standpoint, you could probably setup something along the way that would do on the fly validation. However, that would require significant up front configuration and maintenance if anything major changes in future updates. It's a difficult decision, but I think those with resources (if anyone actually has available resources these days) would benefit greatly by examining extensive validation with the actually BPs themselves. More than likely this way of thinking, aside from the development work, is also probably why it is not a higher priority for Workday to address.

    ReplyDelete
    Replies
    1. Interesting points. We spent some time looking at making some fields required in the BPs, but then backed away from it. I am hoping that once we have some more populations in the system and it's more of a stable environment that we'll be able to enhance the functionality a bit rather than running behind it.

      Delete