Betfair rejects SAP, Oracle and Workday in favour of Fairsail for HR

Article here.

This one has been floating around the UK tech press the last few days, as Betfair is London based.  I must admit, I'm not much of a betting person so was not previously aware of Betfair, but I'm fascinated that a 1700 employee company in 15 countries would have been running SAP, just based on my limited knowledge of other big companies who use the SAP product.

Highlights include this part:

"In total 11 vendors were evaluated, these included a cloud HR solution from Workday, as well as Oracle, but MacDonald felt that these were also "too big for what Betfair needed".
This became more apparent when the company looked at offerings from smaller organisations, such as Fairsail, TribeHR, SumTotal Systems and Aragon-eRH."

Of course I had to go have a nose around Fairsail's website.  Key pieces:

• It's a San Francisco based company.  I found that one interesting, as we're an 8 hour difference from SF here.  I'm curious as to their support model as US west coast can be a challenge for Londoners.
• They use the term 'Glocal' to discuss their global vs. local functionality.  I like it!
• Their user interface has a very clean look.  It has the PeopleSoft functionality of menus up the left side, but reminds me of Workday on the main pages.  It's funny how all HRMS are starting to look the same to me these days.  I guess they're all using usability experts and designing better interfaces from what we've seen 10-20 years ago.
  

Tracking exempt status in Workday

A reader recently sent me a note, asking about how to track Exempt/non-exempt status.  I thought this info might help others, so here it is.

Workday allows you to track exempt status on a job profile, as do most HRMS these days.  A nice thing about Workday, however, is that you can attach different exempt statuses to one job profile based on location:

In previous HR systems that I've seen, you'd be stuck creating new jobcodes, profiles, positions, etc., each time that an exemption status changed, in order to track that status.  Prior to version 11 WD was in a similar situation, so nice to have seen them build out this functionality.

A few things to keep in mind though:

• You need to have your processes locked down tight, as to how you will use this tab.  Will you assume that any state values are exceptions to the country value?  
• Who is pulling any government reports, and where do they come from?  The use case presented on this one is that employees in California may be in the same job as someone in Texas, but due to California legislation, they are non-exempt rather than exempt.  There are a variety of ways to accomplish this reporting....

1. Put the exceptions into WD.  Document that a country is the norm and only exceptions are documented.

2. Don't put the exceptions into WD.  Establish your procedures outside of the system to assume all California jobs of a certain profile (grade level x etc) are non-exempt--in which case put employee work location into your report.

3. You could always put ALL the data into WD...so 49 exempt states and 1 non-exempt.  I'm not endorsing it, but I'm saying it's an option.

There are lots of options here and WD offers a lot of flexibility on this front.  To be successful, you need to ensure that your data entry procedures are watertight and that the reporting folks are working off of them consistently.

Workday Custom Objects in Action

Workday Custom Objects (CO going forward here) are easy to set up and configure, but how about from a user or data entry perspective?  Here we go:

1. You can access from multiple points on the person's record (see red boxes, for Additional Data menu).  It's nice that you have multiple paths to the same place:

 2. Once you've chosen the menu, you are then given a choice of which Custom Object you'd like to use.  In some ways, this isn't intuitive for the user at this point.  It's basically a collection of all the active Custom Objects.  So the data elements themselves are not related to each other (Apparel, Commute, etc.).  It's just a collection of 'Workday doesn't have these fields so we've created them' and stuck them in one place.

In my perfect world, I'd want to put 'Commute' with the Address data, for example.  Why?  We use the 'Commute' CO to track distance from home to work.  In Europe it's often woven into taxable benefits, such as when someone receives a company car or fuel benefit.  The greater the distance, the bigger the taxable benefit.  So if the data entry person is entering a new address on an employee, they need to remember to come over here and update the Commute value as well.

The Data Entry Pages

3. Since we spoke about Apparel in the setup example, let's stick with this one.  So here is the CO on Apparel, from a user's perspective.  It's pretty easy to choose an apparel type and size:

 

Keep in mind, this is Workday delivered sample data.  It's helpful for seeing how Workday envisions the pages to work if you're in a demo environment.

I'd like to point out a weakness about CO functionality however, using this example.  While we all say how we support standardization and global processes, I'd be much happier with this page if we could limit or apply the values to only certain regions or countries.

As you can see, it's one field with one big dropdown list.  (CO security is driven when setting up the object, so I'm not worried on that front, that a data entry operator would not have unauthorized access).  However, looking at this Apparel example, sizes vary around the world.  For example, if i were to buy a pair of shoes, I'd have to know my size:

US:  7.5     UK:  5.5    Europe:  38

Sizing is not a universal concept.

Workday does not let me limit this pick list in any way, shape or form.  So data entry folks around the world are left with this big list.  The only thing you can do is to make sure you think ahead and apply smart coding when setting up the values.

So the shoe pick list would either need to start the values with a region or country code:

US 7.5

US 8

UK 5.5

UK 6

EU 37

EU 38

OR we'd need to make the mapping and plunk everything into one line, so that our pick list looked like this:

US 7.5 / UK 5.5 / EU 38

US 8 / UK 6 / EU 38

etc.

It's not the end of the world, but I seek to minimize data entry mistakes by getting clutter out of the way.

Error messages

Workday does come with built in functionality, it's smart enough to know when I'm trying to enter a duplicate.  Would be happier if it was a little friendlier out of the box, however.  With that dollar sign in the error box, it looks a little clunky.

User specified validation rules

Workday does allow you to put on validations, so if the data entry person enters a wrong value, you can trigger an error message to inform the person to enter more appropriate data.  This is the closest I can get to ensuring that correct data entry is done (since I cannot limit the list overall on the front end).

So let's say that a data entry person accidentally chooses an incorrect value from the pick list, here is the error message:

 

Here is how it gets triggered.  The functionality of setting condition rules is consistent throughout the application, so if you know how to do one of these from the business process page or reporting pages, you know how to apply it here too.  Same functionality.  On one hand, I like the consistency for the back office folks setting these up:

As well, you get to specify your exact message in such a scenario:

From a front end user perspective though, I'd rather that the data entry operator not see the value in the first place, rather than have to go through a big dropdown and accidentally choose the wrong one, and then have to re-enter the data.  Fully understanding that this is sitting on the overall WD platform, however, so it needs to use their existing tools.  I'm just saying I'm not overly happy with the lack of limitation possibilities and having to build in validation rules after the fact.  But I get that this is how the application works.

Overall:

• It's a 'configuration' rather than 'customization' option, so good from that perspective.

• The user experience isn't as slick as the rest of Workday.  Trying to incorporate COs into the app seems patchwork and haphazard.

 

• You have the option to use Effective Dated COs, at least for Worker.  While it would be great to have additional ones, Worker is the most critical.

• Big Disadvantage:  Currently you only get 20 of these per business object (such as Worker), unless you're a Big Data customer, then you get 100.  As someone pointed out on the WD Community site, this obviously isn't a technical application limit since it is granted to some customers.  There has been a brainstorm out since 2012 to increase those counts for us non-Big Data peons, and according to the site it's targeted for WD 23 (Aug 2014 in Production).  Fingers crossed that this will open up more possibilities for us.

 

• Another disadvantage:  Lack of integration into the Business Processes from a data entry perspective.  My HR colleagues who are more on the front end of process design try to avoid these Custom Objects whenever possible.  They like a process to flow along in a logical manner and give much thought into how and where the data gets entered.  They like to set reminders and make things as foolproof as possible.  The location of this data under the 'Additional Data' menu leaves it as a bit of an orphan, a collection of 'extra' data items.  They prefer to instead cannibalize existing unused fields on the pages where data entry is occurring (shudder!) so that the data entry can be in one place.  

 

Any other options?

The eloquent Naomi Bloom suggested on Twitter that I think some more on this topic and WD's options.  Custom Objects are really WD's main mechanism in the way of user-defined fields.  As you can see, it can be a powerful option, in particular if you are used to a non-configurable environment.

There is one more option that we've been pulling out of our sleeve, using 'Custom ID' functionality.  If COs are the powerhouse of user-defined fields, Custom IDs are next best option if we want to cannibalize and re-purpose something.  I'll put together a separate post on that one.  To be honest I'm not really proud of how we're using that one, as we're stuffing data into fields in a way that was never its intended purpose, but in the interest of full disclosure, I'll show you what we're misusing.  In particular, we were afraid of using up our CO allotment of 20, so we've had to go the Custom ID route to store additional data, but from a systems standpoint, it's less than exemplary.

How to set up a Workday Custom Object

Around a year ago, I had written about my initial impressions on custom objects (Workday's 'customer defined' field options).  Still worth a read if you're looking for an overview of 'user defined' field concept in Workday.

Now that we're live in North America and into our European implementation, time to revisit the topic.

Today I'd like to focus on the logistics of setting one up, as I think this is one of Workday's strong points, the ability to easily create company required data fields.  Then later this week I'd like to look further at the nitty gritty of actually using them.

Rather than starting from scratch, let's look one up as it's the same page layout to enter or view (smart from a Usability perspective, the consistency).  You have a few options when searching, to filter.  Often we'd look by business object (similar to a 'table' in a traditional database setting, it's a grouping of related fields):

Most of our Custom Objects are tied to the 'Worker' Object in Workday.  The Worker Object is where we track something at the 'individual Employee' level.

Let's pull up the WD sample data, for the object 'Apparel'.  This is actually a useful one for us, as we are required to supply work shirts, trousers, etc. at some of our manufacturing sites, and there are repercussions if we do not provide replacements on the appropriate schedule.  If we were setting up a new custom field, WD walks us through the same pages:

Some useful things on this page, is that you can define the object name, validations, the field order, as well as specifying the security domain.  It's probably a smart idea to name these carefully, in particular, the 'web alias', as that is something that is not editable once a custom object is in active use.

Another feature I like overall about WD is the orange box you see here.  When you are on a Workday page, you can use it as a launch pad to other actions that you can perform on this 'thing' (be it a custom object, a foundation value, an employee, etc.)  Then you get a list of 'available actions' that pertain to the item that you are reviewing.  So in the case of this Custom Object 'Apparel', I can look up its integration ID, I can go report on it, etc.  Not exclusive to custom objects, but deserving of a call-out in any event.

Also on the page is the nice little summary, again on the page, I like being able to instantly see the security domains where this item is assigned.  Other colleagues doing some other tasks prefer some of the other fields summarized here.

In addition, there is a 'Usage' tab which is especially helpful if you're into reporting.  If you're planning to edit a custom object, seeing that it is currently included in a calculated field, for example, is quite helpful for impact analysis:

Last but not least, lest I always sound like a curmudgeon on Workday's lack of globalness in some areas, I must admit, I appreciate this global feature, to translate the Custom Objects into local language.  Two thumbs up!

So a few thoughts on the setup of custom objects in Workday:

• Very easy to do online!  It's 'customization by functional people'.
• I like the linkages and the displayed details.
• Overall, I think this is great functionality from the setup perspective, and recognizing that there is nothing existing in the PeopleSoft front in this area, except for proper customization.

Still to come:  Actually using the fields . . . is it still so easy?  Stay tuned . . .

A European solutioning example in Workday

As a global company, we have offices and employees in almost every country in the world.

Much of our North American Workday implementation was based upon US requirements, with a handful of Mexico and Canada business needs sprinkled in.  This design, configuration and use became 'the global footprint'.

Now that we're looking at European countries as part of our next wave of implementation, in general the current use is getting challenged.  In addition, the design is getting extended for business requirements that did not exist in the US, e.g. contract data.

What is European contract data?

 

First, I'm not talking about contractors.  :) In Europe, most countries have the concept of employment contracts, so prior to accepting an employment offer, the contract provides a contract offer to the candidate (i.e. future employee), and the candidate may choose to sign 'as is' or negotiate some of the contract clauses.  Then both the candidate and a company representative sign the contract to make it official.  Each country will usually have different things that they put into their contracts, depending on local business practice.  There is no 'Euopean contract'. 

For comparison, I've worked in three countries for the same company.  In the US I received an offer letter of 2 pages, it listed things like salary and work location.  In Germany, I received a 25 page contract with all of the employment terms and details spelled out.  In the UK, my contract was a little shorter, only 12 pages.

If you get a big promotion such as from non-manager to manager or to a high position, you may get a new contract.  Otherwise, for smaller promotions, your contract would just get an addendum with any new details.

What kind of data is in a European contract?

 

Often, you'll have some general and overarching principles that apply to all employees, such as an ethics policy or general details about working conditions.

A contract will often hold basic data, such as the employee's name, home address, and job data such as title/position, the title/position that the role reports into, weekly hours, pay frequency, pay rate, hire date, seniority date (if differing for benefits calculations), notice period, probation date, etc.

As well, you'll find some 'eligibility' items 

• if a company provides a contribution to a pension on the employee's behalf, what is the percent
• if a company car is provided, what is the level/budget or allowance in lieu of car
• holiday entitlement
• private medical scheme, if offered
• what sort of sick pay you are entitled to
• etc.

 

What is the Workday functionality?

Workday gives us a page for contract data, it looks like this:

• Workday has the usual 'per country' configuration, so that you can set up your Contract Types per country, which is helpful.
• The attachments and comments feature is also there, so that is useful if we want to attach a copy of the contract.

Some of the job-related data found in the contract will be on the 'regular' Workday job pages.  Other data such as pension or health, we can try to store on the benefits screens.  However...

Where we're challenged in Europe, trying to use Workday

There's a lot of great fields on this page, which we would definitely use.  But we're struggling to figure out where to put the rest of the contract data.  It's like we were invited to dinner and only served the appetizer.  My current thought is that this page was designed without European input.  Mexico does have more of a concept of contracts, so maybe that was the driver, who knows.

Here are some areas that are providing heartburn at the moment.  And specifically, our payroll systems in the countries do have the concept of contract data, and would like to receive it on an interface from Workday.  Our HR people as well would like to be able to store and view this data.  So where are the disconnects?

1. Notice period

 

This particularly pains me, as it's such a basic concept that any European based HR system would contain.  A notice period is included in your employment contract.  The higher your position, the longer it is likely to be.  None of this '2 weeks notice' in Europe!  My notice period in the UK and Germany has been 3 months.  High level executives may have 6 months or a year even. 

This applies to both the employer and the employee, and may differ, although if we could just get the employee one, that would be great.

Notice periods are often a 'date in words', for example:  3 months, 6 weeks, etc.  There is an added complexity to some, such as 1 month to the end of the quarter.  I've heard some other companies try to simplify and specify a number of day or weeks.

In addition, local labor law may specify a minimum statutory period, but as a company you may wish to put a longer notice period into place.

Workday has no functionality in this area!

There is a Workday Brainstorm (Workday's mechanism to make change requests to the application) from other companies to at least get a 'notice date' added.

2. Dual contracts

 

This comes up in various EU countries, in particular where we have better benefits than our NA counterparts.  :)  Often, an employee has a regular contract, and as a part of that may receive maternity benefits from either/both the company and/or government, depending on the country.

The employee on maternity may receive their regular benefits, but may want to work part time during maternity leave.  Usually in this case, the company will need to make a new contract with the relevant employment information.

Workday only allows for one active contract at a time!

Again, there's a Brainstorm to get this changed, or at least configurable to allow for two simultaneous contracts.

A workaround is to use Workday's 'multiple jobs' functionality.  If you put the employee into two distinct positions, the employee may have two active contracts at the same time.  However, that's a lot of work to enable, both from a functional and technical side, just to get some minimal contract data into place on a 2nd contract.

3. Contract renewal

In Europe, for better or for worse, it's more difficult to terminate an employee.  Often, we hire people on in temporary contracts.  Depending on the country, you are allowed to extend the contract a certain number of times, but after extension number x, it automatically converts the emp into a 'regular' contract (with all corresponding rights).

Workday missed to include this functionality!

Workday workaround:  Use the freeform 'Contract ID' field and get the data input folks to consistently put in '0001' for 1st contract, '0002' for 2nd contract, etc.  I don't like using freeform fields in this manner, as you end up doing extra auditing as people forget the 0's or make it length 5.

There's a Brainstrorm for this one too.

I could continue on here with my online gap analysis, but I think you get the idea.

Why is this especially irritating?

 

PeopleSoft has a lot more functionality!  Granted, we probably only using 10% of the fields on the pages, but they met our needs.  In my 'notice period' example above, we set up a contract clause for each notice period, such as the 'non competing' clause listed below.  As each employee has a contract, you then choose the relevant notice period clause for that employee.

In Summary

We're continuing to review the data against what our payroll systems need to receive.  As the contract data pages are not very robust in Workday, we'll be left having to 'MacGyver' it in, or not store it at all.

In discussions with our Workday certified consulting partner, the only thing they can tell us to do is: either don't store the data in Workday, or make custom objects, custom IDs etc. to accommodate it, recognizing that you don't have enough custom objects free to meet the needs.  As well, it would just be generally ugly from a data entry and reporting perspective, as well as not in harmony in one place, with some fields on the contract data pages and others independently as custom objects etc.

I think the irritation here is that we currently have a workable solution in PeopleSoft, and in going to Workday it's seen by the users a going backwards as Workday does not come to the table with a real solution here.

Pleasantly suprised: Workday's social media response

I occasionally take a break and log into Twitter, to see what is happening in other HR System topics around the world.

Last week, Workday had tweeted about an upcoming online event:

Announcing our 1st tweet chat! Join us on 6/19 from 10-11am PT using #WDAYchat. @LeighLevensaler will discuss Big Data for Better Recruiting

It sounded really interesting, but once again, I wasn't impressed with the lack of global thinking, from Workday.  So I tweeted a polite response to the timing of it.  6 PM on the European mainland, 1 AM Hong Kong next day, it's not great if you are seeking to reach a global audience.  Although fair enough if your focus is the US market.

I wasn't expecting much of a response to be honest (in particular as I'm not tweeting under some big company name, but as an anonymous blogger), but was please to see that Workday's Social Media Director quickly responded to me, in under an hour.

Thx for feedback. We plan to make this a recurring series, so future chats could be at other global times.

We'll also record & post this tweet chat via @Storify for on-demand viewing & to keep the conversation going!

Even though I'm still not impressed that Workday seems so US focused (especially when they could slightly back it up to 8 AM and get into the European workday), I was pleased to get a response.  From a customer perspective, while I'm not happy with the timing I am happy with how they handled my comment.

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}

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.

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

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.

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?

Apologies for the radio silence

It's been a busy few weeks here in the UK, and I'm currently working and traveling a lot for our project.

In addition, I haven't been overly pleased with the solutions I've been designing in Workday for our business requirements, so I have not felt compelled to list them out here.  As a little bit of background on that point...

We're heavily in the throes of gathering business requirements for our European countries.  My more HR-oriented colleagues do a great job of gathering the HR folks in the countries and they outline our new global Workday processes and inquire about the local processes that HR do in comparison to our scoped out list of global Workday processes, as well as gathering their field level requirements for those processes.  Then, for anything that does not fit into the global model or is not readily available through existing configuration, e.g. new event reasons, it gets forwarded over to me to provide some solution options and a recommendation.  I look at things holistically, so keeping things in mind like:

• Ease of use for the person doing data entry.  Will they enter it all on one page or have to go to multiple pages?  Are the labels good, or are we heavily mis-using a page (doing it Saas style, as I'm now calling it), so they'll need to ignore the labels and fill in the data entry boxes. 

• Can we interface any of the data in?

• Is this data going somewhere, such as a payroll system?

• How do all the pieces fit together in the process?  Can we get all of the data in a certain step or is this going to be a back and forth to collect data?

• Ease of reporting on the data

• Making is easy for the integration guys, for current as well as future interfaces

• Etc.

As I've been based in Europe for 10+ years, I often know the business needs/use better than my US-based HR colleagues, so some of the things they just throw over the fence to me to define requirements and solutions.  For other stuff, they're doing a great job of gathering data definition, especially where the business does not use PeopleSoft now to meet a need and the central team thinks that we should start to accumulate this data in Workday.

I was talking to a colleague of mine, he's a general all-arounder, understanding technology plus the business use of systems, although his area of expertise is recruiting systems.  He's been assigned a task to investigate a certain area of data that overlaps between the recruitment system and Workday core HR data, and to get a team together to figure out what data should be captured in the business processes.

I gave him a debrief today of the Workday functionality.  It's a common European set of data, but WD is very light on the ground in this area, as it's not data that is used in the US.  I was giving him an overview of:

1. Here are the business requirements that I have heard from the core HR calls in Europe.
2. Here is the data we currently store in our European PeopleSoft instance for this topic.
3. Here is the Workday functionality in this area.

So now we're counting on him and his team to define the business requirements, and I'll then solution them.

He was asking me questions to confirm that he understood the WD functionality and was a little surprised that the functionality was so light in this area.  In particular, it's basically a page with some dates and free form fields.

For anyone who has worked in an HRIS operational capacity, free form fields are the devil's handiwork:

1. They're a hassle for the data entry people who can't just do a few characters of predictive text/choose a dropdown value.
2. They're a hassle for the team responsible for auditing data, as they're always chasing up and having to get corrections to misspellings, etc.
3. They're a hassle for downstream systems, due to a lack of consistency.

Implementing Workday: size does matter!

Last week at the Workday Rising conference, one of the most interesting things for me was to hear from other customers:  what functionality they are using, what is their support model, and what is their roll out schedule.  It seems that WD marketing and sales has done a good job of spreading the idea that the software can be rolled out perfectly on a very fast timeline.  Our own CIO was on a call explaining the new 'we're going cloud for all applications' strategy and made the statement:  those business processes, the ones that are taking you 6 months now to design, those will take 6 hours in the new world!  Actually, I'm discovering over time, that's not really the case.

There was an interesting presentation by a small WD customer, 500 employees, industry = wealth management.  They had rolled out HCM plus Financials in 12 weeks, then brought in expense management quickly, and are further augmenting their HCM use.  I compare it to a session on the same day by a large pharmaceutical company of 130k employees who explained their global roll out strategy.  They started with Asia and were going West to Europe and Latin America and finally finishing up with the US.  It was an interesting concept to me, as the bulk of the companies and people that I know start with the US and head East to Europe.

This pharma explained that they were on SAP and their US office was happy with it, so they were going to get the rest of the world on board first, although they did have to do some workarounds, such as putting in some shell records for US managers of employees in the non-US regions, in order to be able to approve goals etc.

They started WD implementation in 2012 have launched Asia countries (including payroll interfaces for some) and are working their way around the globe.

They also made the statement that they were two weeks from launching SAP in the UK and pulled the plug on the project, which sounds quite similar to us, except we were 1 year into a PSoft upgrade.

I mentioned last year, on our US implementation, that the project launch encountered a delay, so that the US launch was in December instead of October.  We're now going through re-sizing efforts on the Wave 2 Europe launch.  Rather than launching Europe for Jan 2015, we're now splitting the group up, with some countries to keep January but others to delay.

This certainly isn't to blame WD as a software application (which is being done internally in my organization as people seemed to think this was a 'magic' software that would fix all of our HR process issues) and they're now seeing the same issues on a new software platform.

It's currently my thinking that especially where you have a large and decentralized environment and you are injecting any sort of standardization or HR Transformation as a part of the mix, implementing WD is the same as implementing a traditional ERP...it's a multi-year effort due to all of the change management and factors outside of the software.  When you're a small company with Excel-based processes or on one Finance, one Expense system, you're able to make that 12 week implementation schedule as you can more readily fit the mold of standardize, change, launch.

Pleasantly surprised

A while back, I mentioned looking at address data.  While we mapped from PeopleSoft to Workday and made decisions to combine fields where we had to, we had a country where WD made the field required, while we would call it optional.  I spoke with our data entry expert in country to confirm it is not used and to confirm that it's not existing in local payroll.  I checked online as well and everything that I found aligned with this data being optional.

I put in a Brainstorm making this request to convert it to optional.  Three weeks later it had hardly any votes, but someone from WD responded to it and asked for the legal source, as their sources said that it was required.  I missed getting a notification at this point that someone had responded, so I did not respond.  However, the same WD employee then responded a few days after, that indeed it should be an optional data element based on new research, and that it was targeted for WD 21 to be updated.

On one hand, I have no idea how they can get to WD21 with no one else noticing this, except that we are not a pharmaceutical company, so maybe our global footprint differs from other big customers.

We had already programmed our conversion logic to stick 'unknown' in the field (no field validation), which was going to look ugly from a self-service standpoint.  Happy to be able to lose that logic and instead leave the field blank.

As a PSoft customer, our management made a strategic decision not to apply patches.  We don't run payroll out of PSoft in Europe, so we can do that.  Occasionally, when something is noticed by the users and it is deemed critical, we will extract that bit of code out of a project, and our developers will manually apply just that bit.  As you can imagine, whenever we would log a case with PSoft customer support, it would be instantly closed as you are not on the latest code line.

I realize this is a quick little fix by WD for something that should not have been wrong in the first place, but quite pleased at how this one has turned out.

A customer perspective on Workday Rising Europe 2014 - day 2

My company graciously paid for me to attend the Workday Rising Conference in London this week.  I mentioned day 1 yesterday, here are my thoughts on day 2.

Best Practices in Configurable Security and Global Data Privacy

It was an early start for me as I'm in the suburbs on the opposite side of London.  Pleased to say I was on the 7.20 train to arrive at 8.40, in time to grab a coffee, mini bagel with salmon and fruit from the breakfast set up in the vendor hall.  It was supposed to be a 9 AM start with 120 people in a full session.  As mentioned by the presenters and others, the customer appreciation party went long into the night, so they finally started at 9.08 with around 80 people.

Two WD pieces/presenters:  Data Privacy & the Security Toolset

1. Data Privacy - it was a good overview by Barbara, and I'd previously seen most of the material online.  Data Privacy can be a passionate subject, but WD's stance is clear--they are the processor and *you* the customer are responsible to ensure that you're not storing data on employees that you shouldn't/aren't allowed by your Data Privacy legislation, Works Councils, etc.  (Although WD does have some functionality in place here, to control some of these things systematically.)

No qualms there, it's standard in the SaaS world.  While it was a good overview on Data Privacy and Works Councils and where WD is with their various certifications, etc. most of the participants in the room were Europe-based and well versed in the area, so would have appreciated a little more depth here.  This presentation would be very good as an introduction to an American or Asian audience, however.

2. The Security Toolset - Kathy H from Workday did an outstanding job of presenting the topic.  It was an overview but as well she went in-depth and highlighted upcoming functionality.  As pieces of it are being worked on by *her* personally, it was straight from the horse's mouth.  Most interesting, this was so different from a sales presentation--when people asked her if WD could do X, she was quite honest in acknowledging where WD could not meet business requirements and where things were in the pipeline.  As a customer, I need exactly that sort of input to be able to plan workarounds, rather than unclear or unconfirmed answers.

Kudos to both American presenters for having more of a European presentation style--organized and serious, rather than the WD presenters' comedy routine of yesterday's joint HCM/Finance session.  Noticed that the audience was fully engaged in this session 9 AM session.

Maximising Your Investment in Absence Management

This was also a great presentation to attend.  There were maybe 20-25 people in attendance, and Brian K from WD is an expert in Absence Management functionality, to a similar depth as Kathy was to security.  He gave some advance previews of upcoming functionality.  As well, there was clear honesty in answering customer questions, and solid knowledge.  As well, he had a nice slide of the main brainstorms outstanding for Absence Mgt, which really laid bare the flaws/opportunities for WD.  As many of the customers were actually using the product already, it required detailed knowledge to field their questions.

The 2nd part of this presentation was done by a customer, Medtronic, who is using the functionality in multiple countries.  It was really great to get this customer perspective, and as well they provided tips and lessons learned from their implementation.  Most interesting, they had presented a case study of how they tackled some difficult requirements from France (via WD Studio).

Final Thoughts

There was then a break and then a 'Closing and Goodbye' session.  I must admit, I popped into the vendor hall to pick up some goodies and then cleared out before that session.  Overall, I could not imagine learning anything new, and also, it would run until 12.45 and after my early start, I didn't want to wait that long for lunch.  (Sorry WD!)

I'm glad I had a chance to go, it's nice to see WD building up a base over here in Europe, such as putting a training centre in Amsterdam.  As always, it's great to be able to connect with other customers, in particular ones of a similar size, to trade ideas.

A customer perspective on Workday Rising Europe 2014 - day 1

General Throughts

Workday's first customer conference in Europe, Workday Rising, started today in London.  Officially it started last night with the welcome reception, but the kick-off and first sessions were today.  Supposedly 600 people were there, and it felt like it.

Kudos to WD for allowing anyone to watch the keynote online live, and recorded (only through Friday morning).  I will leave you to make your own thoughts on that one.

Everyone had a colour-coded lanyard, that helped in case you were looking to talk to someone.  Blue = existing customer (me), orange = potential customer/considering workday, green = consultant/vendor, grey = workday emp.  After the keynote there was a coffee break, so helpful to get to meet other customers and to catch up with people I've met through the years.

HCM/Finance combined session

Next was an overall combined HCM/Finance session, to show customers who used WD for both sides.  Sidenote:  As we're in the coffee break and the overall session was about to start, orange t-shirted people (WD emps?  KPMG?  outsourced logistics?) came through and instructed us to move to the next room.  It was more of an order than an offer.  Once in the next room, they used hazard tape to block off the last rows of seats, forcing people into queues to pack in the first rows.  At this point, my European colleague says, 'what is this, kindergarten?'  I managed to ease us around one of the matrons by saying that I might need to leave to take a phone call and managed to get us at the back of the room, thereby avoiding the sardined front section.  It worked out better for us as well as we were conveniently in front of a screen so could see the WD pages that they were demo'ing.

It was a joint session with HCM and Finance, done by WD emps and supplemented by customer stories.  the HCM leader was an American living in Paris and she insisted on kissing each speaker twice as she gave them control.  Odd.  I can only assume she was trying to be more European, but in London we don't go around kissing colleagues in the office.  When I've been in conferences or business meetings in the past in France, the kissing was mainly a greeting thing, not done while in presentation mode, but however...

There was another WD woman, something with HCM strategy and she spoke terribly fast, so a bit difficult for non-native speakers to follow.  It was nice to see her demo some of the newer recruitment functionality upcoming.

They went with the 'theme' of 'be a hero to your business,' complete with cartoons and continued references.  I can only assume that was a marketing take over from the US conference as that one wasn't really understood, appreciated or geared toward European work styles.

One of the male WD speakers made a reference to some functionality, and it would make him a hero 'equivalent to half of a Churchill'.  I think he expected laughs there, but the American humour really fell short.

One of the female WD speakers had a slide with Twinkies on it and at least asked if the crowd knew what they were.  As there was a large American contigent there, I'd guess maybe 25% of attendees raised their hands.  (They're not a European product, although especially in the UK we get a lot of US TV shows, so UK people know more American cultural references than on the continent.)  She explained that she was asking as she did this presentation in Copenhagen and not one soul knew what a Twinkie was.  The whole purpose though, was to explain how WD helped Little Debbie with the acquisition of Twinkie.

Thompson Reuters had an engaging speaker, explaining why they chose WD and what they were doing with it and what they were planning to do next.  Another company, icm, gave a presentation, another great speaker, but completely not relevant for us as they have an employee population of 500 and were able to standardize onto one set of systems for Financials.  As we are 320 times their size, we have a diverse Finance and Expense system landscape and have no plans to implement Workday for either.

Lunch was one of those typical conference affairs of help yourself and then stand around at bar tables or balance your plate on your lap where you could find a seat on some of the benches.

Afternoon sessions

The afternoon was smaller sessions, you chose your sessions when you registered for the conference.  Then, the door monitor would scan your badge to see if you were allowed in.  I was a bit disappointed to miss out on the 'support' session, but went dutifully to my 2nd choice 'global' session with J&J.  (I registered over a month ago, so no idea when you would have had to register to get first choices.  They had maybe 60 people in a session.)  It was sort of disruptive, they would allow people to wait outside, then at 5 minutes past the start time, they would start to let them in, one at a time, then do a seat count, let in another, etc. until full.  People would then have to climb over 5 people to get to a spare seat, so distracting to everyone.

It was interesting to see how J&J was implementing (a waved approach) and as well the audience questions were quite telling, as people who were live were asking how they had handled x, y, and z.

I next went to 'automated testing', another 2nd choice.  It was informative to hear from the WD QA lead, about the testing that WD does, and how they do it.  Diageo was the customer who presented their perspective of how they test and what they're planning going forward--it seemed a very honest overview from their speaker.  Around 30 minutes was also devoted to Kainos, who explained their Smart testing product.  We don't own it and maybe we should, but I felt too much like a captive audience there.

Later sessions were of a similar ilk.  There is a 'customer appreciation party' planned for later tonight.

In the meantime, I leave you with a few photos from directly outside the venue, where Oracle and SAP are making their presence felt.  If I was WD, I'd be pleased as punch, as these large players are obviously taking them very seriously, and these cobbled together adverts seemed lacking in substance.  Who would pay 900+ GBP for conference entry and then turn around their IT strategy based on a placard on a bicycle? 

Looking forward to tomorrow's sessions...