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.

Is Workday more complex that it appears? Or is the software not strong enough?

I've had a quiet week as my US HR colleagues are currently on an emergency trip to the HR Shared Service Center to try and sort out some Workday operational issues.  As you may recall, we had a soft launch in the US in December.  Now that everyone is back from their holidays and the first monthly payroll of January has run, it appears that post-implementation issues are larger than expected.  So a swat team of HR project members are planted in the SSC office to try and train them again and work through some issues.  A few key points:

1. It appears that some end-to-end processes really are not end to end.  So the processes work in the system, you can hire someone, transfer them, but at the end of the day, all of the dots are not connected on the process side, so they have orphaned tasks or recognizing that the WD process is a certain system data entry piece piece of a bigger functional process, such as a hire which requires non-system activity such as background checking.

2. Robustness of manager processes or lack of manager training?  My boss has been trying promote an employee using the manager self-service and it's required multiple HR people to help him to do this task.  Noticing online, there's not a lot of opportunity to provide dynamic help text, especially along the way.  You can enter help text into a transaction, but it's not smart enough to recognize what is wrong necessarily, which is the issue.  As well, the system is a little bit loosey goosey.  It's not as locked down as it should be for less knowledgeable or astute managers.

3. Change management/staffing.  In the sales cycle, it is insinuated that you can run the software with only trained monkeys, it's that easy.  Our SSC (who are bright data entry people, btw) are new to Workday as well as to the company.  The software is not so intrinsically easy that they can just pick it up and use it.  Further, similar to the above loosey goosey comment, it lets them do things online that they should not.  Not that WD is not an easy software, just that it's not so easy like looking at a web page, it's a software application like any other, so it requires training.  Further, with WD's updates, the pages change up to three times a year which does not help the people who are just learning it.

So I remain undecided whether the issue is:

• Workday isn't as easy as it is suggested to be.
• HR's training efforts were not good enough.
• The software is too flexible and open, so you actually need highly talented people to utilize it.
• Our implementation of the software is the issue, not the software itself.