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.