Tuesday, 27 May 2014

Undoing a Workday Data Load EIB


I was browsing the Workday Community site, catching up on the Customer forum postings.  This one caught my eye:

I am a new in Workday and need your help regarding EIB.
I have uploaded an EIB for Contingent worker but now i need to rollback the changes.
Can you please help me in this regard.

Yikes!  Can you imagine? 

We are a large company and currently load data every single work day in our PeopleSoft environment, using Excel to CI (with the files being prepared and loaded by the IT team).  Workday's EIB functionality is awfully similar to the PSoft functionality, using (bulky and cumbersome) Excels to prepare and load data.  Both systems offer 'validated' data entry through these load processes, so a cleaner way to load data than say, a SQL load.  Both offer equally cryptic data load reports so that you know where you've loaded data or had issues.

So where are we today in Production?

 

Our US colleagues have made the decision to give EIB to the newly formed shared services center.  They have backed off of their original intent however, of anything more than 10 rows should be loaded and have completely given up on doing any new Hire loading, as it's been deemed as 'too complex'.

It's interesting to me as historically we don't have the data entry people loading data, but HR Transformation continues to turn the world upside-down.

My two cents, as I continue to delve into Workday functionality and imagine our future state world in Europe...

Advantages of Workday EIB functionality over PeopleSoft Excel to CI

 

1. WD gives you the templates out the box.  In PSoft we need our developers to do some building to create the option to load.  So we made a prioritized list and gradually worked our way through it.

2. If the WD functionality is broken, it's on them to fix it, not your developers.

3. Workday allows you to 'define' the template--so you're able to remove optional columns at the get go to save the user the hassle of seeing non-used extras.  In our PSoft world we do a manual workaround (we give the users a skinnier version of the Excel, and then paste it back into our normal, bigger one).

4. There is a roll-back option!  (Ha!  Lucky for that fellow who asked the question to the forum!)  You can use the 'Mass Rescind Business Processes'.  In our PSoft world, we'd either do another Excel to CI in correction mode to fix the 'wrong' data or we'd send in the users to manually delete rows.

Advantages of PeopleSoft Excel to CI over Workday EIB functionality 

 

1. You can build whatever Excels to CI whenever you want, for whatever you want.  In WD you are stuck waiting for them to build the functionality.  So you make a Brainstorm and then hope people vote it up and that it's easy for WD to build.  For example, a company put out a request to WD to create an EIB for healthcare rates as they have 4k lines to enter due to their retiree plans.

2. If the WD functionality is broken, you're stuck waiting for them to fix it vs. having in-house resources fixing something as top priority.

3. A minor observation, but a continuing dark lining in the HCM cloud is that these tools are not always as intuitive as they portray during the sales cycle.  For example, if you want to load a blank value into PeopleSoft, you put a space (i.e. blank) into the cell in your Excel to CI, which is common sense.  In Workday, you put this into the cell:  {empty}



Monday, 26 May 2014

Workday IDs and codes

In our current PeopleSoft world, we have processes and controls around codes, how we set up codes (we don't use smart coding, but instead next sequential), and interfaces tend to use the same logic to select certain populations, so it becomes a copy/paste exercise for new interfaces.

Workday provides a lot more on the coding front, so a few thoughts here.

Some foundational data operates with these options:

1. Workday ID

 

When you set up a new value, let's say you're setting up a new value of 'New York City' in the Location table, Workday generates an ID for that automatically in the background when you save the value.  It looks something like this, length 32:

z13a7c16a03333c4a44bb09afbdf72q73
 
The average user does not see this value, but may view it (if granted security) to 'View Integration IDs'.  Some other key points I've picked up on this one:
  • It's a globally unique code across all customers
  • It's also unique across instances (so your Location will have different Workday IDs in your production vs. sandbox tenants)

2. Reference ID

 

This one is a customizable value, or you can let WD set it for you.  In this case we'd have:
Location_ID = New_York_City_site if we allowed it to default.  But you could override it to a value that makes sense to your company.  In our case, we have a code structure for locations that is set up by the facilities group and used universally at our company.  So our Reference ID is overriden when setting up a location, to be our company generated location code.
  • You're not required to have reference IDs, but can have one or many per item if you wish
  • This one will be the same across your tenants
 

3. External IDs

 

I am rather digging this one, as we built a custom page in psoft that does basically the same thing.  :) Let's say that you have your NYC location with a Reference ID of 12345, but your payroll system requires a leading zero there, so you need to send 012345 to payroll.  In a psoft vanilla world, you'd hardcode that into your SQR or app engine, to append a 0 as a part of the interface.  WD allows you to set up this code on the location itself, so your user online is creating the location and then adding a row to set up 'Payroll System X' = 012345.  Then, the developer only needs to reference the 'Payroll System X' row when building the interface.  

It's also nice that you can have multiple External IDs for various systems, so if you have 10 different downstream systems that want 10 different codes for our NYC office, we can set that up on the location.

4. Then other tables have different 'code' options.  

 
Let's look at Ethnicity.  WD delivers some sample values, but you're free to configure your own:


Interesting to me here is that you can set up the 'map to' option.

Overall thoughts on IDs

We're still in the early days of being live with WD in the US.  Most of our integration consultants seem to be learning WD as they develop our interfaces.  
 
In general, I suspect we're not setting things up in the most efficient manner.  Like often in WD, its flexibility appears to be our undoing, but we've only figured out after the fact in some cases how we actually *should* have set things up.
 
However, there are definitely more options here than in PSoft, so I like it from that angle.

It will be a bit of a learning curve as currently we're in the midst of HR transformation, so folks who never maintained (or knew about) the codes needed by payroll will now need to be aware of them in order to maintain them.

Sunday, 18 May 2014

Can HR Systems ever do Big Data? Workday?

'Big Data' is one of those IT buzzwords these days, with everyone jumping on the bandwagon.

Last week I was researching Custom Objects for our implementation, to see if there's anything new in the Workday world on this topic.  Custom Objects are Workday's 'customer-defined' fields, I previously looked into the Workday functionality last year.

On the 'Worker' data object, we're already up to 12 fields used out of 20, prior to starting our Europe roll-out.  Workday 'Big Data Analytics' customers, however, get 100 Custom Objects on the Worker!  This alone would be a reason to license the product, and I think that's why WD keeps the rest of us in check at 20.

What is 'Workday Big Data Analytics' (BDA)?

 BDA is a newer, separately licensed product that enables a customer to analyse Workday and non-Workday data together in one place.  You put non-Workday data into the 'Big Data Store' and use 'Big Data Explorer' as your interface to upkeep (i.e. load) your data and perform analysis.  (In some ways it reminds me of the promise of ERP in the late 1980's...your Financials and HR data, all in one system!)

Advantages?

As I'm curious, I've been looking at the WD presentations on this topic and reading through the forum posts by other customers. 
  • It sounds like it offers pre-defined templates and reports to help you to analyse large volumes of data more easily.
  • You can incorporate this data into your manager dashboards in WD, so a 'one stop shop' for a manager.


Can an HR System really deliver on 'Big Data' benefits?

When it comes to data in the HRIS world, I find a few main hurdles:
  1. Getting data
  2. Maintaining data
  3. Working with data so that it becomes a source of better decision making

I'm not sure how much Workday (or any other HRIS or HCM system) is really able to capitalize on Big Data, for a few reasons.
  1. Getting data and linking it across systems can often be a challenge.  Not all systems have a unique key structure that matches other systems.
  2. Other systems roll up data and define data in a different manner--it becomes an 'apples to oranges' exercise to compare it.
  3. Even when you are able to match data, it's often a one time exercise.
  4. HR data is not always maintained.  Someone may have a great idea to keep company property or driver licenses for company vehicle drivers in the HR system, but on-going maintenance can be an effort if systems and processes are not robust or meeting local needs.
  5. Even if you have the best data in the world, it can be a struggle to define a common set of reports or to figure out how to configure manager dashboards automatically at a highly detailed level so that you are providing targeted information at a manager's fingertips, on demand, rather than a 'general manager dashboard' which is the same for all managers.

When I think Big Data, this is how I think of it

Here in the UK, we have a large supermarket chain, Tesco.  They do some 24 hour supermarkets, some mega-stores that carry clothes and electronics, as well as having little stores tucked into train and bus stations and in neighborhoods.  Tesco appeals to a variety of customers as they offer foods from value through to upscale.

Most people (including myself) have a Tesco clubcard.  You can scan it when you pay and get discounts, rewards, and every other month, they send targetted coupons based on your spending habits.  Yes, it's very big brother, but no one is forcing you to take or use a card.

Tesco knows that I bought bananas at 6 AM on a Sunday, wine on Friday, and that I buy cat food from them.  Tesco has a super big database somewhere, and I suspect their analytics team is gigantic.

Big Data can change behaviour

A few rounds back, they sent me a cracking good coupon for 1.10 off cat food, so I used it.  In the last round of coupons, they sent me 75 p off of cat food.  I didn't use the coupon but bought my cat food elsewhere.  In this round of coupons, they've now raised the ante, and are offering me 95 p off.  Will it change my behaviour in cat food buying?  It might, as they're now making it more valuable to me. 

Big Data knows what I need before I know that I need it.

The bottom coupon absolutely tickled me!  I am a US person living in the UK.  Those very smart data crunching computers (or the smart IT wonks programming the logic) have analyzed the data and are thinking that they can woo me into their USA product range.  I can only assume that they put together the data facts, that I don't buy tea and milk, but instead coffee and a variety of other tidbits that lead them to this conclusion.

So why can't HCM, HRIS, HR Systems, etc. be this smart too?

I see a lot of hype from the HR data solutions that they're harnessing the power of Big Data, but I'm not sure that they're there yet. 
  1. I don't think that they have the data volumes necessary to fuel Big Data, even if you can combine data from other systems such as T&E or Sales.
  2. You'll never be in the 'daily, operational, transactional' level of data needed to get the deep data insights.  For example:
    1. An average HRIS may give you a report of terminations in the last fiscal year and an exit reason cited by the employee (where existing)
    2. Big data HR Systems may bring in data from other systems--what was the sales volume of the emps leaving?  Did you lose a top performer or underachiever?
    3. A Business Intelligence or Management Information team may use either of the above two sources to spot data trends...and then provide a further level of insight.
      1. An increase in terms at location X coincides with the HR policy changes to not match 401k and to reduce company contributions to benefits.
      2. Recommendation:  adjust the policy to influence the future term numbers.
      3. Check after six months, any impact?  Rinse/repeat.
However, we'll never get to that Big Data level of detail...without having the full data set, for example, knowing the compensation and benefits received at the new company, we're just making a one-sided, best guess, based on the data that we have.

Tesco doesn't know what I'm buying at the competing supermarkets...but it has an idea based on what I am buying and not buying at Tesco.  It knows that I have a cat based on all the cat related things that I buy, but I don't buy cat litter there (Her Excellecy prefers another brand that I buy elsewhere).  Those data gurus at Tesco periodically shoot me a fabulous deal on cat litter, knowing that it's a *missing* item on my list. 

We'll never get to that level of data in the HR systems world, regardless of how good the product may be at providing templates, reports and analysis tools and that is why we'll never do Big Data properly in an HRIS setting.

Of course, very happy to be proven incorrect on this point, be it on Workday on another HCM.  :)

Tuesday, 13 May 2014

Why I wouldn't want a career in Workday HCM

Probably not the best title, but regardless...before I start let's be clear:  I like what I see of the Workday application, and have the utmost respect for Workday as a company (despite my occasional jabs, critical reviews of functionality and whining about how they could improve their software and become more global).  :)

I previously was employed by PeopleSoft many moons ago (prior and during the Craig Conway years--boo!), and if the Workday company environment is anything close to the early years of PeopleSoft, feel free Workday internal recruiter to send me an email, I'll be on the first train into central London to interview!  ;-)

I'd do anything to be able to work with Workday, I'd even work for free! 

 

Every week someone stumbles onto this blog and sends me an email about how they'd love more than anything in the world to get a hands-on position (be it HR, IT or somewhere in between) with Workday.  I can only assume there are a few key drivers for this interest:
  1. There is a lot of work for contractors, supporting Workday implementations.
  2. There are a lot of new internal positions being created to support newly implemented WD systems.
  3. Both of the above pay above market rates due to the scarcity of talent in the market.
  4. Based on WD's recent growth, it seems like there will be jobs in this area for years to come.
  5. It's something new and exciting, and who doesn't like a shiny, new software and being the first to have it?
However, some musings and my two cents on the topic based on what I've seen internally post go-live at our company and through talking with others, internal and external.  I may be a little controversial (short-sighted?) in making this statement, but if we were not implementing WD, I wouldn't be looking to jump ship or hitch my star to the Workday wagon, and here's why.

Reasons I wouldn't want a Workday job

 

* As a SaaS, it's a locked down system.

I am fully aware of the business value of such systems and the business benefits such as driving standardisation and its subsequent benefits such as lowered operating costs that such systems bring.  However, as an IT professional who designs usable solutions and implements HR Systems to support the business operations, Workday is not my bread and butter, and I'm struggling to find any crumbs even.
It is what it is, but my 'creating design and usability side' is floundering here.  My focus is more on forcing data into fields and convincing HR people to drop business requirements or to accept that a field called 'end date' can be used in your country for 'expected end date' while in another country it truly is 'end date'.  In PeopleSoft, we'd customize and add another field.  Now, I'm creating a messy data landscape, and even worse, I know that I'm making a mess but I have no other options.

The current generation of HR Systems professionals will have an entirely different skill set than ones who cut their teeth on ERPs or even some of their green screen predecessors.

* High salaries will not stay forever, and will ultimately be replace by lower salaries than you're on in the first place. 

Around a year ago in London, the Workday market was absolutely on fire.  All the big consulting houses were offering top money and the ability to train and certify you in WD.  The niche players were out there as well, seeking everything from consultants through to business development and integration specialists.  The work is still out there for consultants, HRIS Analysts, HR Systems Managers, Workday Tenant Managers, etc.

However, I'm also seeing an ugly underside.  I see positions trying to recruit HR Systems Analysts at 18k in central London where as an equivalent title in the ERPs (PSoft, Oracle, SAP) will get you 23-25.  Granted, the skillset in the WD arena is lower, very operational:  maintaining configuration, supervisory orgs, job profiles, etc.  Ultimately, this is the benefit of a SaaS solution, isn't it?  You don't need highly skilled resources to operate and support the software on a day to day basis.  Granted, Psoft, Oracle and SAP may not be around long-term, but I'd prefer to ride it out with one of them rather than getting lowballed 2-3 years from now as the market fills up with skilled resources.

* I don't want to be an operational drone!

I stole this phrase from one of my HRIS colleagues.  This person is currently the first tier of operational support for the HR colleagues.  She partners with them on new functionality requests to help document their requirements for me to solution, as well she provides user support for the application (data entry, query, etc.)

She's been noticing what the US side of the house is doing with her counterparts and is not impressed.  As part of the move to WD, we implemented a mega HR Shared Service Center (in a low-cost country).  This hub is now responsible for that first level user support.  The previous HRIS staff are no longer tasked with speaking with the HR customers but instead are focused on data entry for configuration (which was not a distributed task to the Shared Service Ops folks).  So she'll lose that 'people' connection with her job and is not happy to be a 'glorified HR data entry person'.

On the IT side, the IT Analysts got tasks with being the Security Admins.  Workday has been a step backwards for us from a Security Administration standpoint.  (It's one part application clunkiness + 1 part our WD certified implementation partner's inappropriate setup for our requirements = inefficient, admin-heavy administration -- but that's a topic for another posting.)  I recently heard one of my IT colleagues comment on a call--I don't really have time to look at this HR user security request, this isn't my real job.  Well then.  Same outcome though, isn't it?  Implementing Workday may give you more of a mindless, yet operational necessary role in an organisation.

I certainly don't want to be negative here at the Workday application, I think these points are part and parcel of operating a SaaS, and a bit of a shock to people who previously had a different job prior to WD.  My point is that the grass is not always greener on the other side for those of you searching for work in this area.  However, let's face it, the industry is going cloud and SaaS, but relevant to keep your eyes open, as this is a completely different world than traditional HRMS.

Monday, 12 May 2014

Workday Training Schedules...still 'unglobal'

Way back in November 2012, I was whining about Worday's US-centric training schedule.  Here we are 18 months later, and I'm about to do it again...

I am very lucky that my company will pay for me to attend training.  While I've done most of the basic training early on in the project, our US colleagues are struggling post go-live with reporting topics.  I took the basic reporting class last year, but wanted to get my hands into the 'Calculated Fields' class, a 1.5 credit (15 hour option).

On the plus side, it's a virtual class offered over 3 days at 5 hours a day.

On the minus side, the timing is pretty poor.  For a company that claims to support global companies, I find it lacking.
  • There are 8 instances of this course scheduled between now and the end of July.
  • None are in the Eastern US timezone (which is somewhat palatable to London), but 7 are in Pacific or Central US.
  • One is in the 'London timezone' (from 11 AM - 4 PM) according to their website.  I cannot quite figure out why the Pacific and Central classes start at 9 AM, but Workday thinks that in London our workday begins at 11 AM??  For anyone on the continent, that's a noon-5 PM run.
  • That being said, the class does fall inside the European workday, a novelty from my friends in Pleasanton.
  • Most of the US classes are Wed-Fri, so even if you did want to bite the bullet and take the US-centric offering, you're stuck online until 11 PM Friday night if you choose the Pacific option.  As well, starting a course at 6 PM on a Friday after a long work week will not be effective for me.
I wish I could have a better report out in this area.  I can only assume that Workday's customer base/focus remains heavily in the US market?