Organization elements in Workday

A while back, there was a question from Pete in the comments of this post:

Hello, Can you say more about the following? 
"The Workday org structure is very different from the PeopleSoft department tree. Org elements are independent fields, rather than a top down data structure."

You say in a separate post that WD's Org Chart supports hierarchical relationships between orgs of the same type.

The organization structure is probably one of the finer points of Workday when compared to PeopleSoft.  Having seen a few different dept trees at various companies, most of us end up putting lots of detail into the dept tree for various purposes, such as security. 

In looking at our company, in PSoft we have 4 business groups.  They have a regional split, Europe/US/Asia/etc.  So we have 4 groups x 4 regions = 16 department trees.  Then, we have business units as our next level down, then sub-region, then country, then location.  As you can imagine, that's a lot of maintenance of the dept tbl and trees.

In WD, we're going through a transformation, but even if we were not, we still wouldn't end up with such a mess of data like the above.

In WD, we have the Supervisory orgs, so you still get your hierarcical relationships.  Local IT helpdesk orgs report into a helpdesk mgt org which reports into an IT support org, etc.  However, this is the extent of the hierarchy.

In our old world, we'd end up setting up depts by location, and putting them under the region, etc.  HR in region is segregated, so they'd get certain branches of the tree.  It was very hierarchical.  In some cases, when we had HR people who shouldn't see other HR people, we ended up with two HR depts, who were really one dept, except we had to break it into two due to security requirements.

In our new world, we can have just one dept, and people in whatever location we want.  We put the location on the employee, it doesn't have to be rolled into the supervisory org.  This, is where I was going with the statement of a lack of hierarchy.  (However, you can keep your strict hierarcy if you want, and mirror the PSoft tree.  You would just set up your orgs in the same parent/child relationship as the dept tree.)

*****
Regarding the org chart--you have various options in the 'types' of org charts available.  You can have a Supervisory org one (so like the dept tbl structure in psoft), it's your WD orgs.  OR you can use the 'location' org chart--so you can search for a location and move about the org chart.  If you choose location X, you get the emps in location X, regardless of their supervisory org, manager, etc.  There are various types of org charts pre-built into WD--you decide whether or not to use them, and which fields to display, if so.  There's a payroll group org chart, for example--we're not configuring it, but perhaps useful for payroll folks, not sure.

These org charts all run off of the various data element, so provide a different view of the data, outside the traditional org chart hierarchy.

Hope that clarifies a bit where I was trying to go with the above statements.  :)

Moving from PeopleSoft to Workday - security topics

Someone was asking me about moving from a PS environment, and how easily the current set up of users and security translates into Workday.  In our case, it didn't really, it was like starting over from scratch to define the security pieces.  I guess it depends though...if you're replicating your PS structures into WD and your users have the same powers as they did in PS, it might be a better fit for you.  As we are doing an HR transformation, redefining and improving our HR structures and core data is making our future system quite different than our current one.  A few things to consider:

1. You have the ability to assign HR roles to the org structure.  We have nothing like this in PS.  So in WD, if you have an org (similar to a dept in PSoft), you're able to identify who is assigned from the HR side to whatever roles that you'd like.  So person A is the HR Business Partner, person B is the HR Admin, etc.  The workflow then uses this data.  As PS doesn't have such fields, we're having to define this for conversion through outside excel spreadsheets.  Note:  this is different/additional to 'normal' security where user X is assigned the role of HR BP.

2. WD comes with defined roles.  Whether or not you use them is up to you, however, as they are pre-built, it might save you some time.  However, these roles may or may not mirror the ones in your company, or your current system.

3. WD works on the concept of domains, PS does not.  WD bundles like items into domains and 'it is what it is'.  In PS you're either working on the dept tree (pre 8.9) or with the more configurable security options, such as defining your own security sets.  We heavily utilize this feature in our PS 9.0, in particular with the location and grade fields.  When comparing to WD, however, it's an entirely different kettle of fish.  We found it to be an exercise of A) What roles do we see in the future?  Shared Service Centre rep, HR BP, etc.  Then B) What shall those roles see.  In PS you have the flexibility to add/remove pages, that doesn't exist with WD.  You either find a different domain without the item you want, or you show that item.

We were not able to map over anything from PS, but instead are doing manual mapping on spreadsheets, of users to the new roles.

How is WD security similar to PS?

• Reporting security works the same; if you can see the online pages, then you can report on the data too.
• Overall, it's a similar concept--set up roles, then assign people to them (either manual or automatic).
• Users can be view only or can modify ('put' in WD terminology) data, just like in PS.
• You can have access to create reports or only to run them, just like in PS.
• Users can have multiple roles assigned.

Tips to prepare for a PS to WD implementation?  What to ask/bring during the sales cycle:

• Query your users to get an overall picture.  How many active users are in PSOPRDEFN?  How many roles?  How many permission lists as far as population visibility goes?  In particular, if you have strict requirements, e.g. this role sees all Personal Data except for personal data tab 2 due to xyz, you'll want to have those documented.  That is where WD will struggle to fit your needs. 
• WD is pretty good as isolating certain key data elements, such as birthdate or national ID, into their own domain.  But if your company keeps certain items hidden (for us, grade is highly sensitive, even though it's a core HR data element rather than being personal data), then you'll want to highlight those in the sales cycle to get a read out from WD.
• If you've locked down your query tree, you'll want to bring that to the table, as to why it's locked down and users can only access certain tables.
• If you use security other than the dept tree, you'll want to have that documented as well.  For example, we use PS security based on grade--so certain HR people have access to employees with high grades.  We set this up in PS based on 'if emp z is in grade q, then HR role 1 has access'.  This scenario seemed to be more difficult in WD, which seems so much more focused around the org.  So I'd suggest to know your non-dept tree security, to bring that to the table too.

Names in Workday

We're starting to get into the data analysis phase here in Europe.  Something new I learned about Workday today--names are not configurable per country.  To put it another way:  if WD defines that country xyz has name format (first last) and country abc has name format (first middle last), then that is what you get.

Understanding WD is defining a global solution based on name requirements around the world, as they understand them.

Also sitting here looking at the analysis done by one of my analysts to compare our current PeopleSoft names data to the Workday global matrix (a helpful resource that lists out per country the various fields available for items such as names).

We have a mismatch in a number of countries.  :-(

So now, we'll need to look closer, per country, to figure out what to do with our current data.  A few options, of course:

• Delete the middle names from PS.  Don't store going forward.
• Concatenate into the first name field in WD.  Then, get smart coding that parses out the middle name part depending on the country/interface.  Deal with the fallout if Middle Names (located in the first name field) are pulled into a report by an analyst and distributed further.
• Put middle names into another solution such as a Custom Object.  Then build rules that 'if country is xyz, then concatenate this field with First Name when sending the data to downstream system 123.  Force the report analysts to reference it as well.

In a perfect world, WD would make this a configurable item for me, so that I could use checkboxes to select which name types apply to a country.  Just sayin'.

Once we start making the conversion decisions, I'll give you an update about how it all turned out...