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...

Integrations: Workday Core Connector

There are various options for building and interfacing data to and from Workday:  EIB, Workday Studio, Cloud Connect.  Keep in mind that I'm usually defining interface specs based on business requirements rather than getting my hands into coding, so the more technically astute may want to go and take a coffee break and come back tomorrow...

I was recently discussing integration options with my WD coding friends and they were explaining the Core Connector functionality, which comes under the Cloud Connect heading.  The delivered, pre-built interfaces come under Cloud Connect, but you can also build here, using Core Connector.

It sounded quite interesting, so I did a bit more research on this one.  Core Connector is perfect for 'changes only' files.  Wow.  In our PeopleSoft world, I tend to push full files as I know they're easier to build.  In our current world, to get a changes file, our developers use a 2 table method, with various temp tables being created and dropped when a job is run, after comparing the two tables. 

Core Connector seems to have been created just for this purpose.  It enables you to output a changes file, based on the transactions that you select to be one the file.  So on the front end you're defining the type of changes (hires, promotions, terms, etc.)  Then, when these things happen, WD writes them to a transaction table, after comparing the before and after.

Of course you still need to do all the other things you'd do in an interface (defining selection of employees, define fields to include/order, output format, destination etc.).  As well, it enables you to use your calculated fields, so your outgoing file can include whatever codes and such that you need.

Realizing this is simplifying the topic considerably.  I wait for my colleagues to actually build one of these change files via Connector, to get to a true opinion, but will keep my ears open to hear more on this topic...

A project delay

Sorry for the lack of posts, and thanks for your emails checking in.  We recently announced a delay to our Workday implementation, so I've been distracted.  The delay is due to many reasons, but some ideas to keep in mind if you are implementing:

1. Integrations take more time than you would think.  Many of our integrations, interfaces and reports are being developed offshore.  This is a model we currently use for PeopleSoft development as well.  However, I think timelines were quite tight and specs were late anyway.  I think the project would have been better served if things like calculated fields were centralized and designed up front, rather than having each developer to manually code these items, on each interface.  Many of these variables (active status, for example, or recreating ALPS as we're carrying forward that PS legacy of coding), should have just been available in a library to grab.
2. HR Transformation takes time.  I know HR Transformation is all the rage right now, and it's the basis for our implementation.  If we were only putting in Workday, that probably would have been possible, however, we're changing many of our HR processes and procedures in conjunction with the Workday implementation, taking advantage of Workday functionality.  As well, roles are being redefined in the post-Workday world, as part of a bigger organisational design activity.
3. We've all had to learn on the go.  While we've gone to WD training and have a skilled consultanting partner guiding us, I think the project was aggressively scoped, even taking out the HR organizational aspects.  If we were upgrading PSoft, the timeline would have been appropriate.  Trying to learn WD and making design/configuration decisions and then learning the impact of them and re-doing things took time.  I'm thinking future waves can follow a faster cadence, however, as we now are relatively up to speed on the software.

I know SaaS is supposed to have a quicker implementation timeline, but when making business process changes, you can't necessarily hurry along at a fast clip.  It's more than just implementing the software, especially when you go to a product like WD that has all this great functionality which turns your whole world upsidedown, compared with your current ways of doing business.

Business Processes in Workday HCM

I was able to attend the Workday Business Process Fundamentals course a few months back.  It's an online only course, 4 hours/day for 2 days.  A few thoughts...

Business Process (BP) Functionality

Business Processes have been described as 'the heart of Workday'.  If you don't have the BPs built properly, you cannot function.  A BP in WD is the set of tasks that need to occur as a part of an HR process.  It is here that you establish and associate all the nitty gritty details such as approval chains, notifications, escalations, , validation, help text on the step, security of who is seeing what step, etc.

Examples of business processes include:  Hire, Propose Compensation, Create Position and Termination.  Workday delivers all the basic ones, and you just need to make the business decisions of how your process should work, defining the approvers, etc.

From a user perspective, they are easy screens to use--point and click, similar to using Excel.  Anyone can set up a BP...however, it requires some skill and businss understanding to set up the BPs in the most efficient manner. 

Considerations when setting up a BP

• Think about the future state process.  It seems that many companies are implementing WD in the US first, and then other countries later.  When setting up processes, you need to give it some thought as to:  Will you have 1 big global Hire process or duplicate the Hire process per organization/country/region, etc?  Otherwise, if you are not sure of your design, you will potentially need to change your BPs in a Production system when other countries come on board.  Of course, if you duplicate processes and apply country specific rules, this will cause one result with troubleshooting and maintenance.  If you build everything into one big one, it's a different result as far as troubleshooting/maintenance efforts.  Both solutions will require work--it just depends on how big your company is, how different or standard the processes are, etc.

• Standardise where possible.  This one goes without saying, as WD is built on the premise that your HR processes are standarized.  However, when we started to do some analysis of local processes, we found quite a bit of variation, as well as local needs.  For example, we had a lot of 'post-hire' activities, such as generating a parking permit in one facility vs. confirming that a safety training occurred in a plant with previous issues.  We made a decision that any 'localized' activities that did not involve system tracking would not be embedded into the business process.

• How many approvals do you need?  We debated this one quite a bit, as we had defined some processes with a 'Manager +1 approval' level, but then one part of the business wanted to add 'Manager +2'.  It would have impacted our process design and cause some if/then work in our processes.

Tips for designing your Workday Business Processes

• Build the process flow on paper first, rather than in the system.  Sometimes, it's helpful to see the process in action, in the system.  However, if your HR colleagues cannot agree in the first instance to a proposed process flow, then it's of little use trying to automate that uncertainty.
• Gather the requirements before you start to build them.  For example, knowing the user groups who can initiate the transaction, where help text is needed, etc.  I would suggest to use something basic such as Word, and to fill in the details before beginning any build activities.

Overall thoughts

It's helpful functionality, and will allow for a lot more automation than we are able to generate out of our PeopleSoft system today.  In addition, depending on how detailed you go with them--they will make for a nice user experience, especially for our managers, who will suddenly get a lot more visibility to data.  Not sure how much the managers will appreciate suddenly being initiators of HR processes though!

As well, for those of us who are worried about automating outselves out of a job(!) WD's BP's actually create more work, as someone needs to maintain or design new ones, as well to monitor the queue, for processes that have failed or are somehow stuck.  :)

How to create a solution in Workday

Workday comes with some really nice out of the box functionality that allows you to move things such as reports, integration system configurations, business process configurations, calculated fields, etc. from one Workday instance to another.  From a back office/support perspective, I think this is one of the best features of Workday HCM, but it doesn't seem to get much visibility or understanding, so thought I'd share some thoughts on it.

What is a Solution in Workday?

A Solution is a 'collection of artifacts' (Workday's term), or configurations.  So if you've built some complex reports in a sandbox environment or if another customer shares a report on the Workday Community, you can import these reports into your Production environment, by compiling them into a Solution.

How do you create a solution?

It's quite simple, in Workday you go to the Create Solution page and enter the details:

The really nice thing about this feature is that you have the ability to attach screenshots or documents to the item.  So for example if you would like to attach additional manual configuration steps that should occur, these can be attached here.  As well, I like the Description fields.  Then, it's only a matter from a process and procedure standpoint, to ensure that people always complete them.  :)

You then have a choice to either 'Save and Publish' or to 'Save and Migrate'.  You then are walked through some more wizard-like screens that guide you in making decisions of what tenant you are sending the item to, etc.  Importing a solution published by another customer is as equally simple, just follow the on-screen guidance.

My thoughts on this one:

• I am impressed with the ease of use.  Not sure about you SAP folks, but in a PeopleSoft world, custom items are packaged into a project which is then migrated to another database.  It's not quite as 'point and click' as we see here. 
• As well, not sure about other companies, but trying to move small items such as calculated fields or a handful of reports does not work in our current ERP, due to the efforts of getting a developer to package it and to send it through the testing lifecycle.  While you still need to ensure that testing occurs here, having the 'ready-made' access to these items should make our lives easier.

The disadvantages of Solution functionality in Workday

• As we've discovered firsthand, if you don't know what you're doing with this functionality, it's very easy to make a big mess.  For example, we had someone moving reports that contained calculated fields.  If you move something like this, it brings along everything underneath it that it needs.  The person didn't realize fully what was in the reports, so we suddenly had 200 calculated fields appear.  Fortunately, none of this was Production, but we still have an extra 200 calc fields to clean up.

Other thoughts

For those of us in IT, this can be seen as quite a shift of responsibilities, potentially.  For example, in our current ERP world, HR Systems Analysts make business requests and design functionality which the developer then makes happen.  After testing, we have a 2nd set of IT folks (server admins) who perform our moves to Production, both for SOX separation of duties and as well since things are sometimes run on the database level, such as SQL statements.

In this new WD world, potentially, that server admin is not really needed in this process.  Further, I'm doubting that a server admin would have any detailed knowledge of the item being moved, such as a calculated field.  If anything, you'd want to keep that move closer to the source, so either an HR or IT Analyst makes a report or calculated field, then a 2nd one (who understands the functionality, but due to separation of duties), would then move the item.

So a changing of the guards in this area perhaps?  Should make for interesting times for IT folks...

Tracking Ethnicity in Workday

Many countries around the world need to track ethnicity data, especially for government reporting:  the US, Canada, the UK, South Africa, etc.  Most HRIS systems give you some options, Workday included.  As it's a SaaS, there's a little less maintenance than in a traditional ERP setting, so thought I'd give you an overview of this today.

Tracking ethnicity at the employee level

Workday allows you to track Ethnicity for an employee under the Personal Information section:

Two nice things about this page:

1. The user doesn't need to know or worry about codes.
2. As the codes are hyperlinked, the user can directly click on them to find out more details about this value. 

Both of these points are an improvement over our current ERP.

Ethnicity setup

Workday delivers the values needed for many countries, and is continuing to increase the list with each release.  I dumped the list for our user, there were around 300 values, maybe 15 or so countries.

For those countries where WD delivers nothing, or where prefer to not use the WD values, you can use the Maintain Ethnicities page to add values or modify current ones.  As well, you can inactivate values so that they are not available:

Again, this is a SaaS advantage, as we'll be able to go into a country with a list in hand, rather than chasing people to try and get the correct government values.

How does the Workday functionality work?

• Ethnicities can be set up at the country or country region level.
• If you have countries where Ethnicity should not be tracked for employees, e.g. Germany, then you simply keep the setup list empty for Germany.  Then a user cannot choose anything as there is nothing there to choose.

IMPORTANT TO NOTE:  The Ethnicity values are tied to an employee's *work location*.  So if you have a US employee whose work location is in Mexico or Canada, that person will get the ethnicity options for Mexico or Canada.  If you change someone's location to another country, the current values for that person are blanked out.

I'm not sure I 100% agree with that logic, in particular as I think about cross-border workers in Europe.  For example, I think of our head office situation (Country A), where we have workers in a satellite location (Country B).  Reporting would still roll up via the head office, they are paid via the head office so would be reported to the government in Country A.

However, I understand how it is coded that way.

Overall, the functionality looks nice.  Now if we could just get Workday to deliver more of the statutory government reports (such as these involving ethnicity) in countries outside of North America, I'll be very happy.  :-)

Tenant Management in Workday

As many of us come from an ERP or non-SaaS HRIS environment, I'd like to highlight 'tenant management' as probably one of the biggest differences in going to Workday. 

What is a Workday tenant?

First--some terminology:  a 'tenant' is Workday's term for what many of us would call 'a database instance', such as your QA environment, Production, etc.  Workday has a pricing model as they host the customer tenants in their data centers.

Our HR Landscape

As an organization in the implementation phase, we've struggled a bit to get our arms around this concept.  As background information, we're a large (150k+ employee population) organisation.  Due to SOX in the US, as well as needing to manage systems, we have procedures of how implementation of changes happen in our current ERP.  It's a tightly structured process with defined roles and responsibilities; customers put in requests, they are assigned to developers, developers only have access to develop in a development environment, IT has an internal review before anything goes to QA, etc.  I'm sure it's similar to what many other companies are doing.

In the past when we've implemented, we had control over how many databases we needed and how we structured those.  So in an ERP upgrade we'd have various test copies for developers and configuration needs, we'd have a pristine test copy for payroll parallel testing, a separate database for training sometimes, etc.  Then, we'd have a gold copy where we'd copy or enter configurations and we'd migrate data and programs there.  If we want a database copy, we'd need to put in a request to our internal database team to make it (recognizing cost/space limitations).

 

How Workday updates databases

Here in the WD world, this seems to be a different procedure.  Not sure if it's WD or our WD consulting partner, but this is the first time I've seen migrations of code, configuration, etc. going in multiple directions, rather than in a linear fashion.  So we have a demo database.  We have 3+ copies of test databases, with our company test setup and employee data loaded into them.  We then have 1 for integration, so for the developers building our interface files.  We have another for solution testing.  We have one for the report team.  Then, configuration and programs are being moved to and fro, using EIB, iload, and solution migration.

I went to the Workday Community, so see what the WD delivered guidance on this task would be.  A few things I learned:

1. Customers in Deployment would have the following setup:
1. GMS tenant (demo data), Prototype tenant, Full dataload tenant, Testing tenant, Gold tenant.
2. So customers are typically provisioned 4 tenants during deployment.
2. Customers in Production would have the following setup:
1. Production, Sandbox, Update/Conversion
2. The Sandbox is to be used by both the customer+WD support.  It's not meant to be a training or implementation tenant though.  It's for testing out changes.

Workday provided the following visual, it's helpful as it demostrates the complexity of this topic:

 

 

 

So once we are in Production, then how do things work?  How are Workday Sandboxes updated? 

Workday updates the sandbox environments so that you can test out their new updates before production is updated.  It works like this:

1. Production is cloned.
2. Update to next version of WD.
3. Create WD Update sandbox for test environment.
4. Production gets updated to new version.
5. Sandbox gets deleted.

As a reminder, these updates happen 3 times per year.

Workday has a set procedure for managing these tenants, both during implementation and in production.  So you're managing online various tenant tasks, such as Convert tenant, Delete tenant, Exclude tenant (this one means that it is excluded from any upgrades).  There are set policies, such as requests must be entered by 2 PM Pacific time, etc.  All of those process details are clearly outlined by WD.

I recently noticed a position in London for a company who had implemented WD, and they had a newly created position called 'Tenant Manager'.  The person had responsibility of managing the above, as well as coordinating the testing processing during those 3x/year upgrades.  So while WD may be a source of cost savings as you don't need so many developers, there is hope for us IT folks that it will create jobs in other areas.  :-)

Timezones, effective dating and Workday

I recently received an email about timezones in Workday, wondering how all the pieces come together regarding the timing of transactions, as it's a SaaS solution, hosted in the US.  In particular, when and how do things such as a hire become effective, particularly when it's a timezone around Asia or India, where today is already tomorrow?  A few points:

Workday gives you a few options, when it comes to timezones.  You can set timezone in 3 areas, or you can keep the delivered defaults:

• the tenant (default = US Pacific)
• locations (default = tenant timezone)
• on the user (default = location timezone)  Only an admin can set a user's timezone, a user cannot self-select.

Workday has this piece of guidance on Community:
Effective dates are in Pacific Time. When something becomes effective, it is effective all over the world, because all users are logged into the Workday servers in the Pacific Time zone.

I guess this makes sense, as California is the 'end' of the date around the world.  So by the time it becomes effective there, everyone else has already reached this date.  However, on a practical sense, this means that if you make a business process change active as of August 1st, for Austrailia and countries in this part of the world will be closer to the 2nd before the change becomes active.

We discussed this topic a bit in the HRMS Fundamentals class, as we were hiring employees and kicking off workflow approvals.  We noticed that if the initiator was in Singapore and the approver was in New York, the transaction was date/time stamped with the local user settings.  As a result, it looked like the transaction had been approved before it was entered.

So--the idea would be that you date things according to your location.  So if your new hire starts on August 1, then make the effective date August 1, so that your history on the person will be correctly displayed.

A tip:  If you are doing EIBs or other admin tasks--best to adopt the timezone of the impacted population, so that your event dates ring true.  Otherwise, you may end up with incorrect timing for mass transactions.

Converting data into Workday - why it isn't easy some days

I wrote previously on the topic of converting from PeopleSoft to Workday.  Since then, we've gone through another conversion cycle, so I thought it would be an interesting example of why converting into Workday can take longer than you expect some days....

Like many companies, we track Emergency Contact data.  In our case, it's in a PeopleSoft system.  Nothing fancy, just whatever the new employee wrote onto the paper form, which then got entered into the system.

During fit gap, we looked at WD and yep, it has Emergency Contact data pages too, so we should be good to go.  During data mapping, we looked at both systems and defined rules of what needed to point to the various WD fields....here is where it gets interesting, when we attempted to convert the data...

 

What we learned during the conversion exercise

1. WD has built-in formatting on the address and phone numbers, PSoft does not.  In particular, PSoft does not offer standardization on phone numbers, and it wasn't a high priority item for the HR users to keep formatted.  So we have phone numbers that have the required number of digits, but not in a consistent format:  (555) 555-5555, 555.555.5555, and 555/555-5555, etc.  Around 80% of them follow one format though, so we can try and squeeze the data for those into one format to convert.

2. WD requires one piece of contact information for an Emergency Contact, in order to save it--either email or phone number.  We do not always have contact details, and in particular, we do not store email for emergency contacts.  Perhaps not the best from an HR perspective, as it defeats the purpose of an emergency contact, but we do have a name, and it saved just fine into PSoft.  WD demands a little more in this regard.  So above, we lost 20% of the population due to the various odd number formats, and now we lost another 10% due to lack of any contact details.

3. WD breaks apart the name fields for Emergency Contact, PSoft has in it one text field.  This is a big one for us from a conversion perspective, because similar to the inconsistent phone number formatting, we also have inconsistent name formats.  In some cases it was 'First Last' in others it's 'Last, First'.  Then, we have the additional complexity of Mexican names, where a 2nd last name is involved, which is an additional broken out field in WD.  Divining the mapping on this one was painful and I am not confident of the correctness of the data once mapped.

4. As PSoft has that one text box for names, our HR users also used it for other pieces of data, in particular where they did not have a dropdown value for Emergency Contact type.  So in PSoft rather than putting 'Joe Smith' and choosing the type of 'father' and 'Mary Smith' and 'mother', our HR users put 'Joe and Mary Smith (parents)' in the name box.  Trying to break this out in any automated fashion is impossible.

5. PSoft has a 'same address as employee' functionality on emergency contacts.  WD has something similar, a checkbox that allows you to take the emp's data.  Our consulting partner, however, cannot convert this checkbox using their proprietary conversion/load program.  They can however, load the address, etc. data.  They gave me a big explanation, due to technical web services that are called on the fly, bla bla.  The end result, however, is that we do not have this checkbox enabled in WD for our loaded data.  Manually entered data will be just fine.  As a result, we've had to write into the process documentation, that if an entry person is changing an address for an employee, they need to check the emergency contact page and click on the same address box (if address is the same), to trigger the 'linkage' and so that we do not need to upkeep two separate instances of the same address/phone numbers. 

Based on all of the above, my recommendation was to open up this area to self-service and push it out to the emps as a 'to do'.  As this data is collected upon hire and many of our emps have 10+ years of service, I am not sure of the viability of the data in any event, nevermind the above conversion issues that will result in incomplete data and additional entry steps.  Our business owner, however, is insistent that we convert whatever we can convert, as she has little confidence that the employees will enter the system and update their emergency contact details.

In Summary

Workday offers Emergency Contact pages, and the functionality is suitable for the purpose.  Like all other pieces of data in your new WD system, you need to be aware of the future WD edits as well as the condition of your data, otherwise it can end up taking a lot more time than you originally expected.

Historical data and Workday HCM

Many of us who have spent years in HR systems—be it SAP, PeopleSoft, Lawson, Oracle, or some other HR ERP or HRIS—have gone through conversions and upgrades.  Many of us have gone through major releases or one ERP to another.  However—Workday is a different HRIS entirely. 

Should we convert historical data?  If so, how much should we convert from our legacy system to Workday?

Workday history functionality

Workday provides some pre-delivered functionality that allows you to track job and compensation history from a previous system.  It looks like this if you're viewing it online:

As you can see, it's not so detailed. 

Advantages of using WD Previous System pages:

• It is pre-delivered functionality from WD, so you only need to put the data into the system to use it.  You can enter the data manually online or via EIB.
• It's also available for reporting too.
• It saves you the hassle of keeping an archive HRIS or secondary system for reporting purposes.

 

Disadvantages of using WD Previous System pages:

• You are limited to the fields WD provides. You cannot choose to bring in other history fields.
• If you're trying to run a report of BOTH current and history data, it can be a little ugly as the structures are slightly different. 

 

What about 'recreating' our history in WD?

Some companies choose to replicate their historical data (or a subset of the data, or perhaps for certain employees) in Workday.  Then, they recreate all the transactions.

• It's cleaner from an end user perspective, when viewing the data. 
• ALL of your data elements can be used, so reporting is less manual as you can directly drive the reporting from WD
• It requires effort to set up all the supporting data though (supervisory orgs, locations, job profiles, security, reporting relationships, etc.)

Other perspectives

Fortunately, many companies have already gone through such analysis efforts, so it’s good to research online what others have done, to learn the pitfalls and advantages in advance.  Interesting reading:

• University of Southern California’s decisions on history in WD
• Cornell’s analysis of moving history from PeopleSoft to Workday 
• Some guidance from Towers Watson – check out the pdf

 

Our decision

We have 20+ years of history in our PeopleSoft system.  We're implementing WD as part of an HR Transformation though, so much of the data structures will be changing.  With that in mind, we'd prefer not to bring over any of our legacy data.  We'll be converting people with two rows:

• A hire row, with defaulted data
• A current row, with current data

We will not utilize the WD Prior history functionality detailed above.

 

Workday HCM - is it really that easy? Is everything really configurable?

I recently received a nice email via this blog (thanks for the emails and questions, keep them coming, it keeps me thinking), and it included the following question:

I have watched few demos and have gone through many articles and I am speechless when I see some of the them . However I dont know what is really happening in the backend and if everything is really simple and easy as they show in the demo?

Today I was thinking about this part:  is everything is really simple and easy as they show in the demo?

During our sales cycle, we had lots of questions while we watched the demos, and the answer to everything was basically, 'Yes!  You can do that via configuration!  It's flexible!'  As were finding out though, it's not completely 100% the case.  For example...

Configuring Org Chart functionality in Workday

Workday HCM offers some interesting 'organization chart' capabilities.  If you want more details of org chart functionality, here is a free job aid on that topic that I found while searching online.  Job aids posted by other companies can be quite useful, as mentioned.  :)  Here are a few screenshots from that document to illustrate...

When you're in WD, you can click on the blue 'org chart' button from a Worker:

Then, it brings you to the Org Chart page in WD.  From here you can navigate up/down and around the Org Chart:

It's nice looking functionality, especially if you don't have anything.  Of course like every other HRMS, it's not as great as the niche player software applications, such as OrgPlus.

How does it look from the backend/setup perspective?  It's quite simple to configure, actually.  There are multiple 'views' of the org chart, or various org chart options.  So you can have an 'Employee' org chart (as above).  Or you can have a 'location' org chart or a 'supervisory' or chart or a 'pay group' org chart.  Then, you can provide different data elements on these various views.

Each is quite simple to set up, just point and click to select the org chart fields to display, as well as whether or not to display the emp photo:

Looks great, easy to use.  However...

 

Configuration Limits on the Org Chart

 

1. You have a limited number of fields.  As above, you can see Lines 1-3.  Then you can add in the photo and the organization (such as in the Supervisory Org shown in the online functionality).  But otherwise--you cannot add more fields.  You cannot add a line 4 or 5, for example.  Our organization wanted to show more data, so then we started to consider workarounds, to make a calculated field to be able to squash more data into line 1, for example (which WD allows you to do).  However...

 

2. The org chart only allows you to choose/display 'public' fields or calculated fields based on those public fields.  Well sure, on one hand that makes sense.  If everyone is viewing the org chart, then it needs to be public fields.  However...in our case, we wanted to show BOTH job title and business title.  Business title is NOT a public field.  Therefore we cannot reference it in our org chart.  Sidenote:  someone on Community put in a Brainstorm for the exact same requirement, to allow them to show biz title in the org chart.  So far, it's not been picked up by WD for a future release.

 

3. The overall configuration is a little lacking.  For example, we often want some flexibility to not display people on long term disability leave.  Or in the specific case of Europe, where people have a termination reason of 'garden leave' (so they are released prior to their 'true' term date, often 3-12 months), while they are active Workers, they are no longer actively working for the company and therefore we shouldn't confuse people by showing this data.  There is no way to easily filter out 'active' workers in scenarios such as these from displaying in the org chart.

 

In Summary

 

Yes, Workday is configurable and flexible, however, I say this with a pinch of salt.  It may not be configurable to *exactly how your company wants it*.  And that, my friends, is the negative of a SaaS solution.  You must also be flexible in your business requirements to be able to use this functionality, and sometimes you must bend your requirements to meet how the software has been designed.

 

A tip

 

You just need to be aware of your business requirements.  It's like everything else when dealing with a SaaS solution (regardless of the vendor).  In this example, if you are evaluating WD, you need to be aware and document your requirements in advance.  If your requirement is just 'to have org charts' because you have little or no functionality currently, then no problem. 

 

If your requirement is to 'have org charts with 7 lines of data, and to be able to suppress certain data on certain levels of the org, along with hiding photos in Europe and on and on', then WD will not be able to meet your needs.  So it's important to know your requirements early on, such as in the sales cycle, rather than getting to the configuration stage and suddenly being disappointed that, 'I can't configure it the way I want'.

 

So 'is everything really configurable?'

Maybe--it depends on your requirements.  :) 



How to create a calculated field in Workday

I was having a discussion recently with someone, about the calculated field functionality in Workday.  I've previously posted about procedures and tips around using calc fields in an operational capacity, but I recently put together this quick example to explain the topic further, so thought I'd share it here too.

Once you're in Workday, the first thing to do is to define the type of calc field that you'd like to build:

There are many different options, more than I'm showing here, but the point is to know what you are seeking to do.  An average, untrained user would probably be stopped at this point.  Let's keep it simple and do a concantenation example.  It's also relevant to note--you need to know what business object should be invoked here.  We'll use the Worker object, since it's a main source for employee data.

On the next page, you're brought into a screen that functions in the same manner as the 'normal' reporting page.  So you can choose your fields, as well as add in the more intense logic if you're building something more complicated.  In my example, I just want to concatenate two fields together.  I'm using email+mobile just as a sample, so that I get a mix of letters and numbers:

Next after you save your new calculated field, you can use it in your reporting.  You need to choose the same Object (in our case Worker), to be able to find the field.  Then, your new calculated field will exist like any other field on Worker.

Then, you're ready to run your report.  Here's the example which I then ran into Excel:

 

 

A few points (and the reason I included a snippet of the output)...you'll see some workers have only a phone or some have only an email...so this is all you get.  So getting a good output on a calculated field will depend on what data you have to work with underneath it.  You can see where these can get tricky then as well, once you make more complex ones...is your bad output due to bad design of your calc field or bad data?

 

This was a quick and dirty two minute example.  WD offers a 3 day/15 hour training class on the topic, to get really in-depth with the logic of creating these special fields.  However, seeing how easy it is to create them, you start to get an idea of how dangerous they can become, if not regulated.  

 

Workday job aids - learning and using Workday

In the Workday sales cycle, one of the things they often emphasize is how easy it is for the users:  HR, managers, etc.  Once you're in the implementation phase, however, you realize that you need some type of help documentation--the system is not standalone and usable without some background/training.  Workday does not mention on their 'main' webpage, but there is plenty of discussion about this topic on the Workday community--they're called 'job aids'.

Job aids are 1-2 page instructional documentation, to help a user to perform a task.  They are meant to provide just in time information to a user or manager who needs to perform a task.  According to examples presented on the Workday Community site, companies are handling these in various ways:  Word docs, pdfs, instruction on internal company portals, etc.

Examples of job aids would be:

• Logging into Workday
• Changing your Workday password
• Create a position
• Create a requisition
• Separate an employee
• Delegate a task
• Hire an applicant

The interesting thing for me to see is how companies are approaching this topic.  Because WD changes three times a year, many people are trying to minimize the screenshots and just include the menu path.

For example, here is a piece of a sample from Community:

Notice this company is not using screenshots and minimizing the actual pictures/icons used.  Doing so makes upgrades easier, otherwise you'd be re-doing these docs three times per year potentially!

As a global organisation, our company is particularly interested in this topic of user training on Workday.  In particular, because we have very limited manager self-service capabilities in the current system.  We provide view only access currently.  In the post-Workday world, managers will be able to initiate transactions, such as pay increases, terminations, etc.

Where to find more info on this topic

IF you're a Workday customer, the Workday Community provides many job aids.  Search for 'job aid' in the search box and then select 'Shared solution' on the left under 'Filter by'.  There are at least 30 samples out there, probably 50+ if you search well.

IF you're not a Workday customer--there are still options and Google is your friend.  :)

Many customers post their materials and for whatever reason they are open to the world.  Type 'Workday job aids' into Google and you'll see what I mean.  Here are some examples of what I've found recently:

Cornell University transfer process
Activis goal setting
Tyco's hire documentation

Hope this has been helpful.  It seems that many companies are handling this training topic differently, so always great to hear what others are doing, so that we can all learn more and produce a better user experience.

Feel free to add any insight into the comments.  :)

Workday HCM security groups

I mentioned Workday security a while back.  Today, I'm thinking a lot about the concept of Workday 'security groups'.  In WD you assign users to groups.  The groups have various defined permissions.  If someone is in a group, they get those permissions.  A person can be a member of multiple groups.

 

A few key points:

1. Workday-delivered groups

Workday comes with some groups that get automatically assigned, based on WD's rules.  You cannot change/modify/delete etc. these groups.

Examples:  All workers, All contingent workers, All terminated people, All users, Employee as Self, Manager's Manager, etc.

2. Workday security groups get assigned a 'context'. 

This context is not changeable and it dictates what we'd consider to be 'row-level' security.  There are 3 types of context possible:

• Unconstrained - in such a group, the users have access to ALL data that the group allows. 
• Constrained - imagine a more limited group, a subset that is contrained--such as by organization.
• Mixed - a combination of the above two context.  A mixed group can be an 'intersection' or a subset of the two where they overlap, or an 'aggregation', so the two parts together, regardless of overlap.

It's a somewhat difficult concept to grasp by itself, but I found it starts to make a lot more sense once you look at the actual group definitions and configurations.

3. Security administration and on-going maintenance.

Excluding the system delivered ones, Workday groups can be manually assigned or auto-assigned.  More about this in a future post.  As well, user creation and termination of accounts can be automated.

Calculated fields in Workday

An interesting feature in Workday is the 'calculated fields' functionality.

 

To quote WD, 'Calculated fields allow users to perform simple arithmetic, date calculations, text manipulation, logical expressions, retrieval of related data, and transformations of their existing data. You can use calculated fields in reporting, business processes, integrations, scheduling recurring processes, and other areas within Workday.'

 

It's a nifty little feature, as

• it gives complex power to the users in reporting, via an online interface where you build them.  (As opposed to having to write complex expressions with if/then statements, for those of us from a PeopleSoft world).
• it allows for 'cleaner' development, as a developer is also using the online point and click functionality to build these items, rather than writing code from scratch.
• they are convenient, since you only need to build them once and then can reference them in reports, integration, etc.

So as a practical example, if you are interfacing to various systems, let's say 'gender' and one system needs 'M' or 'F', another system needs 'Male' or 'Female', another system needs '1' or '2' and another system needs 'M' or 'W' (male/female in German would be 'männlich' or 'weiblich').  So in each instance, you'd create a calculated field to allow for the M or F or 1 or 2, etc.  Then, if these systems ever changed their coding, it would be a simple online update to change the interface.  It's much nicer than other systems I've seen where hardcoded SQL needs to get updated.

 

As well, you can do traditional if/then or 'evaluate' expressions.  So if an employee's hire date is more than 10 years ago, put >10 or that sort of thing. 

 

From a reporting perspective, it allows you to build user friendly reports in an easier manner than I've previously seen in other systems.

 

Where are they not so convenient?

 

Like much of WD, the functionality is very flexible.  If you don't have your business processes in order to support this flexibility, you're in for some issues...

 

In our implementation (being lead by a mainstream consulting partner, but supported by multiple offshore consulting firms), the main parter says that best practice is to implement WD by 'an iterative approach'.  Basically, we keep putting data in, seeing how it looks, then tweaking here and there what we're doing.

 

When the topic of calculated fields came up, our traditional approach was to try to standardise and lock down the functionality.  (We have 150k + employees and a large part of our business is manufacturing, so we live by documented processes, otherwise it's a free for all mess.)  Our consulting partner directed us that 'best practice' is to not standardize, as that would cause a bottleneck, and instead, each developer should be creating any/all fields needed.  Not quite sure that was the best way, in retrospect.

 

We have 200+ integrations that are being built (many offshore) as well as local development of reports that are also generating calculated fields.  As there is no clearinghouse or rules, people just make a new calc field rather than hunting for an existing one.  The Data Governance and Controls team is now quickly working to implement standards and structures as the count of calc fields has soared to above 1000.

 

An example

 

To put it into a practical perspective, I've been working on some reports recently, to support our HR colleagues who are looking at the data.  I was seeking 'Business Unit Descr' so I searched for 'Business Unit'.  The top field is the WD delivered one (is it descr?  code?  who knows).  The ones after are all our calc fields.  This is not all of them, as others created them as 'bus unit' and all sorts of shorter versions such as 'BU':



 

You can see where the standards of the Data Governance team are starting to come into effect, such as using 'CF' as a prefix for calc fields or 'INT' when an integration is involved.  If you have only a handful of folks using this functionality or creating reports, it might not be such a big deal.  However, we will ultimately have hundreds of HR folks in the system using (if not creating) reports, so this willy nilly lack of standards will be confusing for them, even if they are only running reports and seeing disparate field names.

Looking online at the Workday Community site, other companies are grappling with these very same issues.  (Sidenote:  I'm a little surprised that WD itself does not issue more guidance).  There is a 'solutions' section in the community where other WD customers can post their top tips and documents, to share with other companies.  The group at Brown University put together some really great documentation, but just to give you an idea of how extensive this calc field naming can get, here is a snippet of their rules:

 

 

 

In addition, another customer (who has been live for a while) has developed a series of reports for more what I'd call the 'structural' aspects of the system--so basically audits to keep things tidy and more efficient.  He also includes calc field review in his list of 30 reports, such as keeping up with the following:

My tip of the day

As you can probably gather from the above, calculated fields can get very messy, quite fast.  Not necessarily WD's fault as it's a side effect of the flexibility of the technology, but you need to have strong business processes in place to control the creation of these things.  So I'd suggest:

• Define who will create calc fields in the future.  Read up on Community, various customers have defined different ways for this to happen (HR Business users, HRIS, IT, etc.)
• Develop your guidelines and structure of how these items will be named and categorized.  WD does provide things like 'tags' to help you in classifying them.  Again, the Brown University guidance is a good start.
• Be prepared to do auditing on calc fields in the future, to be sure that your environment is doing well against your rules.

Training on calculated fields

It's probably worth a mention, calc fields is a 3 day/15 hour online course from WD, to give you an idea of the level of complexity that you can get into with them.  The pre-req is the Report Writer class (2 days/10 hours)

Data loading in Workday HCM - a functional view

Having spent 14 years and counting in an HR Systems (or HRIS or HRIT, pick your favorite term) capacity, as we all know, data loading is a necessary evil, in particular for big processes, such as year end merits or performance review uploads. 

Background:

Working in a large company 150k+ emps, we load data every single day.  Mainly it's of a daily operational nature rather than the yearly processes.  When we acquire a new population, even if it's only 100 people, we try to save the data entry people the effort of loading.  As well, we have regular changes of coding, such as cost centers, we have increases in the data we're storing--so maybe a group needs to start storing a certain element.  Finally, we have data changes--so our job codes change, or grading structure changes, etc. 

Currently, my team performs this data loading in PeopleSoft, using Excel to CI functionality.  Previously, we loaded flat files using SQR or by having a developer write SQL.  In the new world, we'll use Workday's EIB functionality to load data and make data updates.

System Functionality:

You log into WD to generate spreadsheet templates.  You populate the templates.  Then, you upload the templates.  If you've using PSoft's Excel to CI, the user interface is extremely similar.  I've spent some time trying out this functionality in our test tenant; as well, I asked one of my analysts (who is a bulldog about the details of doing it right in our current environment) to try it out as well.  In addition, we had a demo yesterday by our consulting partner, who walked us through a new hire load.

 

My take:

As mentioned, we load data every day.  We're used to looking at data and codes and running reports to pre-populate Excel sheets for our HR data entry partners to fill out further before sending back to us to load.  The steps and overview of the process itself in WD is simple.  You can generate a template in minutes.  However--you need to know the data structures or else it will never work properly for you.

For example, when you choose the New Hire delivered option, it creates a spreadsheet with 20+ tabs.  There is an overview tab where you go through each line item and state whether it is 'required' or 'optional'.  So if you are not tracking visa or work permit data for a new hire, you'd mark that item 'optional' and not populate it with data.  In addition, once you start to look at each tab of data, you need to know what you want to load.  For example, if you look at the 'Names' tab, it gives you all the country variations, preferred names, legal names, etc.

Your only saving grace from my perspective is to go into the template creation step and manually shut off these tabs and fields before generating the spreadsheet.  Otherwise, it will be overwhelming to the end user.  This 'generate template model' is also nice, because it allows you to assign comment text which will then be on the Excel as help for the user.

It's a little tricky though, as you need to know what data will override other data.  For example, our consultant doing the demo had mentioned, 'you don't need to populate job title as that will come from the job profile, otherwise bla bla.'  Ou HR person asked how we should know that from this sheet?  'Uuuuuh,' was the answer.

It's no magic wand, but data loading never is in an HRIS.  On the plus side, when you try to load the data, it runs through the data entry checks as if you were doing the entry online, so less cr*p data is making it into the system.  On the minus side, these Excels are a freeform adventure--you need to know your data structures and codes.  For example, if your employee ID starts with a leading 0 but you miss to include this, the sheet doesn't notice that you're a digit short.  It's only when you go to load that the file will bomb out and you can review the error log.

HR's take

This demo was the first time our HR colleagues were seeing this functionality, and there was some disappointment.  During the sales cycle, this functionality was very highly recommended as 'easy' and 'user-friendly'.  As a result, as a part of our HR transformation, this 'data loading' function was going to move to the data entry professionals.  It was seen that instead of them spending two hours doing manual entry, that in 10 minutes they'd be able to load data perfectly.  HR is now adjusting processes and personnel to take into account in the new world that this is not an end-user tool.  Those data entry folks would still be responsible to fill out the Excels, but it was recognized that it wouldn't be *these* Excels as generated from Workday.

 

How do other companies use this functionality?

We asked our consultant this question...mainly it sits with an HRIS, HRIT or whatever you call your IT-minded staff who support HR.  In a few exception cases they'd seen data entry folks getting this access.  In some cases they'd seen the opposite end of the spectrum, that companies built custom spreadsheets that HRIS or whomever would then massage into these templates.

Note:  Current WD 19 does not allow you to pre-populate the sheets when generating them.  So you would need to generate your sheet, generate a separate query and do some cut/paste work to get them pre-populated.

 

What should we ask about in the sales cycle related to this topic?

I would suggest, ask for a 'new hire' demo, with the consultant generating the sheet from scratch, so you can get an idea of how it looks, and ask to see the 'Names' tab.  (Granted, it is dependent upon how much demo time you have.  We had a week, so an hour was ample in our deep dive schedule). 

Alternately, ask for copies of a generated Excel workbook (with the 20+ sheets 'as is'), as well as a sample error log. 

In addition--ask to see the documentation that supports your team in performing this function.  I suggest this as:  1) the WD community documentation is not so great.  It gives a high level overview, but it's not in-depth enough.  My analyst spent days on a 'try this and see if it works' method of working.  Also 2) EIB training comes under the technical side of the house, as part of the overall integration framework.  So if you're expecting your business users to generate and execute the load, you won't be able to get them training, as this piece is embedded into the bigger integration training.

Configuring Workday HCM application security

We've been spending some time recently on our implementation, on defining Workday security.  I mentioned attending security class a few months back, here is an introduction to the key concepts.

If you are used to a PeopleSoft security model, just forget everything you know, this is a totally different world.  :) 

Functional Areas - Workday security comes pre-delivered with defined functional areas such as 'Benefits', 'Staffing', 'Jobs & Positions' or 'Compensation'.  Each of these areas is further divided into 'domains' and 'business processes'.

Business Processes - Each HR process in WD is set up as a 'business process'.  So the steps and the roles that can perform each step, as well as any approvals or notifications are defined.  Examples of a business process can be large like 'Hire' or smaller like 'Passport and Visa change'.  There's more to say about buisness processes, but we'll save that for another day. 

For today, imagine a swim lane flow chart in Visio with roles assigned to certain tasks.

Domain - This one can be difficult to grasp as it's quite foreign from anything I've seen in other HR Systems.  Basically, a domain is a collection of related securable items, such as tasks and reports.  WD delivers similar items together within domains, and you cannot change which items are assigned to which domains.  There are also sub-domains in some cases, but that's for a later day too.

To give you some ideas, a Domain would be 'Set Up: Jobs & Positions' and examples of sub-Domains under that would then be:

• Set Up Job
• Set Up Position

Other examples of Domains would be 'Job Profile: View' or 'Job Information'.

Domain Security Policy - This is where we can do some configuration.  While we cannot change what comes delivered in a Domain, with the domain security policy we control access to it.  So we control who can 'View and Modify' or 'View Only' or 'Get and Put'.

Within this security policy we address 'Securable Actions' and 'Securable Reporting Items'.  So for the Task 'Create Job Profile' or 'Delete Job Family', we say that it is a 'Modify' task rather than 'View' task. 

For individual fields that fall under this area, we can then define if those are viewable or not too.

So let's work with an example so far:

• In the Functional area of 'Jobs & Positions' we have a Domain called 'Set Up: Jobs & Positions'.
• We have Business Processes such as 'Edit Position' or 'Create Position'.
• We apply a Domain Security Policy to 'Set Up: Jobs & Positions' so that various tasks are given either view or modify rights.

We then attach the above to a 'Security Group' via configuration tasks, and this is how a user is able to view tasks, perform function, etc.

I realize the above is quite a complex topic--you can see why this can be a full training course from Workday!  Let's talk some more about the User piece on a different day...

Challenges of converting from PeopleSoft to Workday: data conversion topics

As we are three months away from go live, there are currently a lot of issues being worked.  Many of them are related to data conversion.  A few thoughts on this topic...

In any system conversion, you can expect to have data differences, and to accommodate for these differences via decisions on the data, mapping, and logic.  In some cases you may decide to drop data, or in others you set default values.  Doing a conversion from PeopleSoft to Workday HCM is no different.  A few things we learned:

1. Be prepared to build your organization structure from scratch.  The Workday org structure is very different from the PeopleSoft department tree.  Org elements are independent fields, rather than a top down data structure.  As a result, our company is having to build the organisational structure in Excel for each round of conversion (using the PeopleSoft dept structure as a basis) and building it up to represent future state.  It's quite a manual effort.

2. Be prepared for more data edits.  While PSoft does some editing of address data, for example expecting an employee's zip code to be a length five number, it doesn't go beyond that.  Workday has built in a checking feature that recognizes if you put in a postal code that does not match the state.  As we have thousands of locations, some of our incorrect post codes were then caught upon loading to Workday.

3. Be prepared for differences in fields (in all areas).  We were originally expecting that Workday's global address formats would be similar to the PeopleSoft delivered ones (keeping in mind that PSoft ones are configurable, the fields you turn on/off, but have defaults).  This was not quite the case, and we ended up doing a lot of mapping for international locations (Mexico, Europe, Asia, etc.) such as 'PS has 4 lines for Mexico address, WD only has 3'.  So we had to map data and then adjust interface specs to reflect the fields of the new system.  It wasn't the end of the world, but a bit of a surprise. 

4. Get used to not seeing codes.  PSoft is a traditional ERP, so when you set up a location, for example, you give it a code.  Workday keeps any coding in the background, so that the user does not need to worry about it.  Granted, you can still search for a location by the code if you know it, but you're not seeing it on the screen.  In some cases we've had to accommodate our codes as 'integration IDs' or 'custom IDs', so additional data elements that you can attach to core objects.  Not a big deal, but a different way of thinking for us, an additional bit of complexity in configuration and conversion, and a little bit more of an effort to check converted data.

Any conversion tips from your side?

How to learn Workday

It seems from the stats that a few people come here wanting to find out:  How can I learn Workday?  A few thoughts...

1. Join a consulting company - Here in the London area, Workday is a very hot skill.  Even if you do not have actual Workday experience, as long as you have some other ERP or SaaS experience, companies are willing to hire you on (especially consulting companies), on the premise that it's easy to train you on this new software, as long as you have some HRIS experience.

2. Take an entry level position in HRIS - As well, companies that have already implemented the software are looking for people to maintain it, in HRIS analyst roles.  If I was an entry level or junior person, I'd take one of those positions to build up some experience.

3. Take the training/get a look at the training manuals/get access to a test tenant/get access to the Workday Community - It can be difficult to get started in this area as you cannot get access to a test tenant or to the WD Community unless you are an implementation partner or a customer.  However, once you are, the Workday training provides a good foundation to get started.  As well if you are a self-starter, there is a lot of learn from the documentation, if you can get access to it.

4. Join LinkedIn groups - There are a variety of LinkedIn groups that discuss Workday functionality.  Join them all.  :)

5. Apply for positions at Workday itself - Having worked for PeopleSoft, I understand the Workday work environment is similarly quite good--sharp and dedicated people, a fun place to be.  I've heard what they might lack in compensation they make up for in intellectual stimulation and a pleasant work life balance.  Try here to apply.

6. Read blogs - There's not a lot out there (yet), but some good info is starting to emerge, if you search for it on Google, etc.

Other ideas?

How good is Workday HCM?

Someone found this blog through typing 'How good is Workday HCM' into google.  I began to ponder that question, with 10 months of implementation experience behind me...

As a SaaS, it's as good as any other SaaS HRIS.  If you want the pre-built processes, fields etc along with heavy configuration/low customization, it's great.  If you have a highly customized environment or your business cannot fit the pre-defined mold of a delivered system, it's probably not the best option at the end of the day (nor would any other SaaS be a fit for your needs though).

If you're coming from *no system*, it's probably an easy way to jump quickly into an HR system, with little or no fuss.  Everything is pre-built and out there, you only need to start using it..

As far as functionality goes, the system offers the fields and processes one would generally need.  My major area of concern remains the 'global' pieces.  I noticed last week on the Workday community that one of the HR Consulting houses had published a set of reports into the Workday Solution area of the Workday Community.  This is the area where customers can publish their solutions, as a means to help others.  While it's great that this consulting firm created this set of country regulatory reports, I am a little surprised that WD does not pre-deliver this solution as a part of the base product. 

For the end user, the system does have a high degree of usability, and a well-designed user interface.  If you're used to a 'traditional' HRIS, you're used to a set of menus and training manuals that take you to various places.  WD instead drives everything off of the 'search box' functionality.  So if you're looking for an employee or setup data or a process--you simply type the keywork into the search box to be given a set of options that contain the keyword.  From a training perspective, it means that you don't need to focus the user of following a strict set of guidelines to follow a path to get to data.

Also, the interface has a 'webpage' look and feel.  When a manager is looking for data about an employee, or an employee is looking for data about him/herself, it's all available in dashboards and easy to find via following 'about me' links and such.  It's intuitive from that perspective, and much more like a 'web page' than a 'system'.

One topic that I have not yet discussed on this blog is the frequency of updates.  While it's great that WD is constantly evolving, it does equate to updates occurring three times a year.  On one hand it's great to have new functionality, on the other hand it requires you to then have a team that is responsible for testing new functionality, new configurations, testing and communication to the end users.  As well, if a  user is trained in doing things a certain way and they suddenly change, that may be confusing or even annoying at the end of the day.

Other thoughts anyone?