Report security

This blog will probably be a mishmash of Workday, PeopleSoft and SuccessFactors for the foreseeable future as I continue to consult on Workday topics while using SuccessFactors and PeopleSoft in my day to day job.

SuccessFactors

Today, I was supporting an HR user who needed access to certain data in order to do some analysis for the HR VP over here in Europe. I know that I have access to a really good report but my user did not. My user has access to similar data so I asked my SF guru colleague in the US what I needed to do to enable the report for the user.

"Hold on, I'll add her to the report."

Me: Wait, what? We need to grant access to reports individually?

My colleague: "Well, in some cases, yes. It depends how the report security was originally set up."

It's an interesting concept that you can roll out reports and lock them down individually, at a user level but there is always a maintenance and upkeep tradeoff, isn't there?

Workday

I previously posted about Workday domain security and the same concept still holds true. If you can access the domain you can see the data on the pages or in a report.

I guess this SF concept is a little like the 'report sharing' feature in WD. You can share a report with another user which is like giving them the framework and structure to easily run a report but the output is still dependent upon their domain security so you cannot give them more access than what is in the domain security.

PeopleSoft

Old faithful is predictable on the topic of report security. If you have access to all the tables, you can access the report. Even PS had a 'sharing' option but it was more than you were copying your report definition over to another user id and then you each had your own copy rather than a 'shared' version.

So I guess in this case we are more alike than different from a user perspective.  :-)

8 years later: how global is Workday?

Back in 2012 when I was just starting to learn Workday I wrote a post at the time How global is Workday? and I was especially curious about how they handled a European requirement which wasn't a US requirement. My use case was 'company cars'. 

What did Workday do for company cars in 2012?

 In 2012 Workday had no company car functionality which was a bit of a disappointment as:

1. PeopleSoft had company car functionality.  (Actually, I should use present tense here as PeopleSoft has company car data functionality, if you're an Oracle customer.)

2. The data structure is not complex or intensive.

3. There are government requirements around tracking who gets a company car since an employee is taxed on it. 

There was a brainstorm kicking around the Workday Community which many US multinationals and European customers voted up.

The suggestion from WD consultants at the time was to cannibalize the Business Assets functionality. It was an awkward suggestion to enter data in a consistent manner in fields that were not designed for this purpose. The other suggestion was to build a Custom Object, also not a great idea since there are multiple car data fields needed.

So we're just starting 2021 and nine years later, what's changed?

If you're a UK Payroll customer who only needs to track company cars for UK employees, you're in luck! If you're not a UK Payroll customer or you have cars outside the UK, to use a UK term, 'sod you!'

If you're in the former camp and you're a Workday UK Payroll customer, Workday has delivered the functionality to set up cars, assign them to employees and to run the report to deliver the data to the government for tax purposes.

Well...it's a start and it's better than nothing!

There are some kinks to still be worked out as others have pointed out. It would be nice to have an EIB to load the car data. Also WD has held back on exposing the tables so customers are not able to design custom reports around who has what car and even which employees have cars. I find both of those point to be big limits to gaining value from the data.

 And If you're not a UK Payroll customer you can...

(create your own list of ineffective workarounds here).

In all seriousness, you choose the best ineffective workaround that meets your needs. I've seen companies say:

- Store it in the local payroll systems - Great, that covers the taxation aspect but most companies in Europe operate at least one payroll system per country. Trying to get a report of all employees who have a car for compensation purposes is a lengthy hassle that involves contacting local resources and compiling reports.

- Create a dirty little custom solution, such as a .NET app - Great, but how many .NET apps do I need to create and does HR need to use instead of just using the core HCM?

- Go back to the Excel / local payroll combos we all know and love so well - Back in the early days of HRIS this happened quite a lot. Central HR needed to track X while local HR took care of Y in local payroll. It's not a great solution as it entails double data entry but it's certainly possible and was all the rage in 1983.

I plan to do an update nine years from now and sincerely hope that we're in better place at that time. In the meantime, happy motoring. 

As always, differing opinions fully welcomed in the comments or by email, always open to new ideas and perspectives. :-)

 

Updates and a techonology move

It's been a while since I've updated this blog. If you're still here, drop me a comment to say hello or click an ad so that I know someone is still reading me?

So what's new?

I'm still here and ended up doing something new, for the past four months I've been at a company who is running PeopleSoft alongside a (relatively recent) SuccessFactors instance. Let's call them NewCo (NC) for now.

I know a lot of you out there are SF fans whose careers in the SAP space parallel mine in the PeopleSoft space. It wasn't that I was specifically seeking out a move to SF ('old dog' and 'new tricks' springs to mind) but I'm not a diehard software loyalist and the time, space and place was right for me.

The technology landscape of how this company is running both PeopleSoft and SuccessFactors is a story for a different day and another post...

It's still early days on my SF experience but a few thoughts as I start to get my sticky fingers on the system.

I joined a conference call early on and it was with the consulting partner who implemented the instance of SF and the top management of NewCo. Man, I know I'm in a rut with all things PS and Workday but I slotted very easy in my brand new SF rut!

It was the exact same conversations that I've been having in the past few years at companies who have recently implemented Workday, but 'find and replace' the term 'Workday' with 'SuccessFactors' and you get the idea.

NewCo Management: 'So what should be next on our horizon, what should we be worrying about?'

SF Consulting Partner: 'Well, you'll want to standardize your operational processes so that you can maximize your software investment by implementing new functionality. We recommend that you set up a global governance team comprised of representatives of the various HR functions...you'll need resources available to test the twice annual upgrades...you should join our customer community for tips and interaction with other customers...'

Basically it was the EXACT SAME conversation that I'd hear post-implementation in a company running Workday. Yeah I know all of you out there who are more hardcore IT and technology agnostic are rolling your eyes right now but for some reason I didn't realize that underneath the covers that these cloud solutions would be so similar. One would not have expected this if you listen to the sales pitch of the various vendors.  ;-)

I'm reminded of the 'Coke vs. Pepsi' debates of the 1990s in the US. I know there's a diehard population who swear by one or the other and can tell the difference in a blind taste test but for the remaining 95% of the population, they're indifferent. Give them a can of caffeinated brown fizzy water and you've met their need. 

Is it the same as an HR systems user? As long as I can hire, promote, pay and terminate an employee does it really matter to me if I do it in Workday or SuccessFactors? Stay tuned as I figure that one out.

 

 

 

 

 

 

Auditing Workday business processes

I've previously talked about Business Process functionality in Workday.  Today a topic near and dear to my heart is auditing those business processes (BPs).

Most companies have auditing or corporate governance in place to minimize risk; in the HCM world areas that often require auditing are processes and procedures that relate to hiring, pay changes and terminations.  These are areas where fraud can occur, such as the hire/term of a 'ghost' employee, or pay increases that are not authorized.

How do you audit business processes in Workday?

 

Similar to how there are many routes into a city, there are a variety of ways to get this job done.  In our case, our Compliance department decided that these 4 Workday BPs should be audited quarterly:

-Hire
-Change Job
-Request Compensation Change
-Termination

Our Compliance department does not state 'how' you need to do a job, but instead they have requirements of what is necessary to prove at the end.  Their requirement from us is to 'show that no unauthorized changes occur on the business processes.'

How do we do this? 

We have a set of Work documents for each process; they include a variety of details about the process, such as the process description, the participants, requirements, regulatory reports required from the process (if any) and importantly for us here, the business process flow broken down by steps (both internal and external to the system).

Our locked down Word documents are the 'golden copy' and our Workday business processes should always mirror the same tasks, performed by the same roles, with the same conditional logic, etc.

So for each audit, it's a matter of using the Excel button in Workday to download each BP and then bringing our Word documentation steps into this Excel and manually going line by line to make sure that they match on 'who,' 'what' and 'how'.

Isn't there an easier way?

 

You'd think there should be, as WD always highlights the audit aspects of their system.  So I set out to find a way to do this task in a more efficient manner than I just described.  In addition, back in the early days of my career, as an auditor myself, it was always easier to pass a process which was locked down systematically and performed automatically, as opposed to one that someone had to remember to do and where eyes can sometimes miss a line or a step.

Here are some items that I looked into:

 

1. Use the 'Audit trail' feature 

One of the nice things about Workday is that it has a built-in audit trail automatically turned on.  So while you're on a page, such as the Hire BP, you can click through to "View Audit Trail" and see an audit trail for the object:

Does this solve my problem?

Unfortunately, no.  While it will cover the 'big things' like if a step or notification is added/deleted it does not show the changes if a step is edited, for example.

2. Use the 'View User or Task or Object Audit Trail' report  

This one looked promising, like it would allow you to audit all BPs for changes at once, rather than individually per process.  (We'd like to be able to edit more than the four I previously specified, but using the manual method did not justify the risk.)

Here's what this one looks like:

When you run it in a Sandbox environment it looks quite interesting showing new value, old value, the operator who made the change, date/time stamp, etc.

  
Does this solve my problem?

Unfortunately, no.  When I ran this one in Production for a one month time frame, I got the message:  "The number of transactions found in the specified time range exceeds the report limit of 50,000. Please narrow the time range and try again."  Looking on Workday's Customer Connection, it seems that others have the same experience.  It seems that something is not indexed correctly or there is some other issue that you're filtering through all transactional audited data rather than only the BP audit data.  Those could perhaps be workable if you're a smaller company or have less transactional data or are only auditing on a very narrow time frame, such as a week.

So now what?

I turned to the trusted Workday Community, with the hope that some brighter mind than me has come up with an awesome solution.  It seems that the question has been asked many times in the customer forums over the past few years so I sifted through the responses with high hopes.

There are some newer features and customers have presented some ideas.  I will not bore you with these in the meantime, but the above was meant to illustrate the types of steps that you need to do as a Workday customer to meet a basic business requirement when it's not delivered out of the box.

But I just want a basic report!

We are currently trundling through our rest of world (non US, Canada, Mexico) Workday implementation. We are in the second round of test loading data.

As a part of our data validation our Workday implementation partner is issuing reports to us from the test system. I am combining these reports with PeopleSoft reports in Access. Then our HR community is reviewing the data to ensure that it matches.

One of the items that we need to validate is 'HR Partner.' In PeopleSoft we have an HR partner assigned at the department level. We're bringing that over to Workday and assigning an HR partner to a supervisory org (along with other roles such as Absence partner).

I have a report from PeopleSoft, it includes two fields: Department ID and HR manager ID.

Trying to get the equivalent from Workday is like trying to get blood from a stone.

First our Workday implementation partner ran me a report that looked something like this:


Our Workday implementation partner seems to be staffed with consultants who have never worked in-house. Fair enough, a lot of consulting houses are like this, as they've never done operational support they have no concept of how things actually work once the software is turned on.

I know everyone likes to say how great Workday is, that you no longer need to know codes you can work off of description but try matching on names from two different systems. People get married, etc. it's just inefficient.

Also, how am I supposed to parse all of the gobbletygook in the box?

I clarified the request and asked specifically for 'Supervisory Org code' and 'HR Partner employee ID'. In return I received this response:

Due to the Worker, Sup Org, and security business objects in Workday, we’re limited from splitting out a single org’s assignments into multiple rows when an org has multiple assignments. We’re trying one last effort during India time tomorrow to see if we can get it to work, but it’s not looking promising.

I mentioned a while back when I took the reporting class, how Workday reporting is not intuitive, but these folks are experts, Workday certified consultants.

I'm not quite sure if the problem is consultant knowledge or the Workday system itself. If I ever get to the bottom of it I'll let you know. In the meantime we'll just go on a wing and a prayer than our HR Partner data is being converted successfully.

Exhausted

We have restarted our European PeopleSoft to Workday implementation which was stopped back in 2013. My goodness I am tired.

One of the selling features of SaaS like Workday is, 'they're so easy to implement!' We did a first prototype with a limited population back in late December. Starting the first week of January I've worked every single weekend except for two. When I say I 'worked the weekend,' that means that I worked 10 hours per day instead of the usual 12-14 hour days that I do during the week.

I love implementation! I don't mind extra hours as I like the mental challenge of figuring out conversion topic. I worked for PeopleSoft as an implementation consultant. I've been implementing HR systems for 20+ years. This is honestly the worst implementation that I've ever known.

A few 'data things' that suck when you're implementing Workday:

1. The need to produce lots of load files.

Our Workday consulting partner has given us a list of files to produce from PeopleSoft. We're pretty basic, implementing the absolute minimum, but we still have 40 employee data files to produce. Setup is handled separately. I'm not sure about you other bright and shiny SaaS providers but 40 files is a lot to produce.

2. The need to populate data...or failure

I get that one of the advantages of SaaS is the built-in data checks and functionality. Over here in Europe and Asia we have a minimum set of data. We don't provide benefits to dependents so the dependent birthday is not required. 'State' is often not a required data element in Europe or Asia but it is required in WD and in the US.

I have physically cringed when I had to send data reports out to our shared service centers that they need to figure out 'required States' and 'require postal codes' for employee addresses when none currently exist in PSoft today (and it obviously isn't a concern for downstream systems, integrations, etc.).

The employees in our shared service centers work hard to add and update data and I just gave them 20k rows of data where they need to contact the employee or somehow get on google maps to figure out an employee's post code.

3. The amount of setup data stuff has just floored me

I mentioned marital status earlier. But it seems that I am setting up everything....name prefixes like Mr./Mrs., citizenship status like France native. I expected to have to set up things like our Contract types but I'm setting up lots more. 

Guest Writer 1 sends us another post!

I sometimes receive emails from people who are trying to transition from other technologies (SAP/SuccessFactors, Oracle/PeopleSoft, etc.) to Workday. Here are some thoughts from Guest Writer 1 on the topic. If you'd like the honour of being 'Guest Writer 2,' email me a post: helloworkday@gmail.com. In the meantime, enjoy the thoughts of Guest Writer 1:

I’ve been reading Vinnie Mirchandani's  excellent book SAP Nation recently. It points out that the economy (what software folks rather oddly like to call an ecosystem) around SAP is about the equivalent in size to the Republic of Ireland.  Quite a few SAP customers have contributed to the book, directly or otherwise.

I don’t know how Workday compares and I have neither the time, the resources nor the inclination to find out.  What is certain is that whatever the size of the Workday economy, they (Workday) have a very significant slice of it.

Very little detail of the detail of the contents of Workday applications leaks out - it’s quite remarkable in comparison to other software and services vendors.

At one level this is entirely understandable.

It’s a fierce world out there in enterprise sales - competitors will seize any chance they can to point out a lack of functionality or a customer who would prefer something added or something to work in a different way. Less scrupulous competition will even bend the truth and try to sow fear and uncertainty.

On the other hand, almost every other vendor has an active community beyond the bounds of its own websites and social media where people swap frank opinions about various aspects of software and services.

There are a few independent voices, Matthew Heminger, Ahmed Liman are two, but they are part of a rare but slowly growing breed of professionals operating in connection with Workday but remaining outside the tightly controlled world of Workday and their partners.

Time will tell whether the “grey market” in Workday Talent will become significant. What is certain is that ambitious and industrious folk in various parts of India are gaining Workday expertise through some official and some very unofficial means. For those of us who have been around long enough to remember PeopleSoft, this is a familiar picture.

Workday continues to restrict implementation access to those who have officially certified training - and outside of Workday this means partner employees only. Since becoming a partner is way beyond the reach of an individual or even a small company, this effectively rules out self-employed contract workers from working on implementations.

Again this is understandable from a Workday perspective - much has been made of the “Wild West” that exists in talent available for projects involving other vendors and Workday avoids this by the tight controls.

What is clear is that it's not just the approach to software that Workday does very differently.

Whether customers benefit from the official "partner only" lockdown depends upon who you talk to of course.