Pleasantly surprised

A while back, I mentioned looking at address data.  While we mapped from PeopleSoft to Workday and made decisions to combine fields where we had to, we had a country where WD made the field required, while we would call it optional.  I spoke with our data entry expert in country to confirm it is not used and to confirm that it's not existing in local payroll.  I checked online as well and everything that I found aligned with this data being optional.

I put in a Brainstorm making this request to convert it to optional.  Three weeks later it had hardly any votes, but someone from WD responded to it and asked for the legal source, as their sources said that it was required.  I missed getting a notification at this point that someone had responded, so I did not respond.  However, the same WD employee then responded a few days after, that indeed it should be an optional data element based on new research, and that it was targeted for WD 21 to be updated.

On one hand, I have no idea how they can get to WD21 with no one else noticing this, except that we are not a pharmaceutical company, so maybe our global footprint differs from other big customers.

We had already programmed our conversion logic to stick 'unknown' in the field (no field validation), which was going to look ugly from a self-service standpoint.  Happy to be able to lose that logic and instead leave the field blank.

As a PSoft customer, our management made a strategic decision not to apply patches.  We don't run payroll out of PSoft in Europe, so we can do that.  Occasionally, when something is noticed by the users and it is deemed critical, we will extract that bit of code out of a project, and our developers will manually apply just that bit.  As you can imagine, whenever we would log a case with PSoft customer support, it would be instantly closed as you are not on the latest code line.

I realize this is a quick little fix by WD for something that should not have been wrong in the first place, but quite pleased at how this one has turned out.

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.