“This the real world, homie, school finished. They done stole your dreams, you dunno who did it.”
Kayne West (no relation)
A New People Analytics Blog Series : Gloves Off Friday!
At the moment, in People Analytics I see a lot of the same keywords repeated over and over. Two examples: insights and storytelling…
I find myself thinking: It is great you are using the right words. These are what we want out of our analytics system, and great claims, but what do these words really have to do with your application today? Are these words real or are they hype?
The first hard truth is this: most of the time enterprise analytics system keywords are just marketing hype.
Sell the people what they want to be sold.
Keep in mind if an existing system has any real market traction it probably was designed well before we even started using the keywords we use today. If the product was designed 5-10 years ago, you might ask: so really, what has changed? Are these just old solutions packaged a new way? If these systems have existed all this time, why are they suddenly going to help HR in a different way now that they didn’t in the past?”
My suggestion is this - when you peer under the hood of a reporting system look at the following:
1.) make sure you are finding what would constitute viable insights or stories to substantiate the insights and storytelling claim.
2.) make sure you can find examples of insights you could only derive in this system (not something you could substitute almost any other system of the same family for to achieve the same result)
3.) make sure that the way these insights are achieved will work in the real world (that it based on clear and accurate assumptions and with a process that is scalable)
I’m might be going out on a limb by myself, and maybe I could get fired for saying this, but I will stand on this view: at the moment, insights and stories are mostly functions of human beings – not systems! Let me say it again: insights and stories have mostly to do with the observations of the operators of systems, analysts; little to do with the systems themselves. My position could change someday, but for now I’m not holding my breath.
Instead, when you review a potential solution you should ask better questions: How does this application enable my analysts to derive insights in a different & better way than any other application? What do analysts think about this application?
The second hard truth is that the problem addressed by the analytics systems of today is the efficiency of the analyst at producing the insight, not the insights.
Despite differences in features and presentation, there really is not a lot of meaningful difference between most broad use case enterprise reporting applications in the range of possible insights produced.
If you see that the essence of the problem these application are designed to solve is the efficiency of insight production, you will know how to better prioritize your decision.
By nature the principles that underlie the use of technology are: automation, repeatability & scalability. How does this application support automation, repeatability & scalability of the analytical process? Where does the data come from? How is the data loaded? How do we deal with the unique nuances of our organization and quirkiness of our data? What do I do when we change our underlying systems? How can this application adjust to changes? What level of expertise is required to do the work? Who will do the work?
Pay very careful attention to those features that promote a sustainable path to insights (with less manual work per insight produced) - producing ongoing long-term efficiencies in the analytics process. The devil is in the details. Ask the people who do the work what they think.
This statement is not intended to overemphasize the importance of efficiency over all else– I’m just saying let’s be clear about what real problem we are solving for when we implement a technology system – the alternative is a disaster waiting to happen. The system will eventually roll out and it will eventually be held to the standard of how it was promoted.
What I mean is this : if the assumption is that after this is implemented there will be no analysts required, does the system actually produce insights without an analyst? If the major difference in this application is how it can bypass the analyst to get the insight directly to the downstream user, you must observe, does the downstream user take on the work to go in to see those reports? Do the reports viewed by the downstream user translate directly into any useful action? Is the insight better than what could be achieved with the assistance of a specialized analyst. Be honest. If the answer to any of these questions is no, but you sold it as so, you will be tearing that solution out in a few years. Fool me once_________, Fool me twice _________?
The third hard truth is that THERE ARE REAL DIFFERENCES in how the enterprise analytics systems approach efficiency in the production of insights.
The first great simplifier - consider, where is the system maintained and delivered? Is it an “On Premise" or “Cloud” solution?
The keywords here are: Cloud, Software as a Service (SaaS)
This is the first major branch in your decision tree.
Cloud and SaaS are not very human words and at this point already feeling a little tired out, but are still very important to pay attention to. There are technical nuances to the definition of cloud but in layman's speak essentially we are getting at is: are all customers on the same instance over the internet (cloud) or does each customer maintain their own instance on their own servers or desktops (on premise)? Software as a Service usually goes together with cloud - this refers primarily to the method of payment. With a SaaS solution you are renting the software, rather than buy it.
My opinion. If you are not moving to the cloud “You are going the wrong way!…”
For fun, here is a great wrong way clip – https://youtu.be/_akwHYMdbsM - I just love John Candy and Steve Martin together in this movie.
For example - there is a reason Google just pulled out their homegrown Human Resource Information System (HRIS) –GoogleHR (GHR), which giant teams of Google engineers had worked on for over 10 years, replacing it with WorkDay, a cloud, Software as a Service (SaaS) HRIS.
The reasons are:
A.) Your business is XYZ, not whatever this is.
Unless Google planned on getting into the HRIS business, Google had to ask, what the hell are we doing fooling around with HRIS? A very good question.
B.) You will spend less on a cloud solution than an on premise solution.
The cost of cloud infrastructure is spread among all customers, as opposed to a single entity. Fundamental economics, 9 out of 10 times cloud will be a better value than on premise. Also, because you are billed for your use of this software over time, if somewhere down the road you don’t like it you can go with another solution. You just turn it off! This is a lot easier pill to swallow than a PeopleSoft or Oracle implementation used to be.
C.) Cloud companies are faster innovators.
Cloud companies have a single instance to invest continuous innovation in – consequently they push more frequent updates out to all customers on one platform - therefore they are faster innovators.
Google is a cloud company too, this fact is too close to home to miss.
Technology is evolving so rapidly - if you buy something that sits on premise (or build it), it will be out of date before it is fully implemented.
-------------------------------------------------------------------------------------------
By the way, I’m NOT for or against WorkDay specifically. WorkDay is just an example the overwhelming trend in HR going into the cloud. We were not sure if we wanted our HR data in the cloud at first – now the market is tipping to the cloud dramatically! There are a number of different cloud HRIS product options. Even the old on premise providers (Oracle and SAP) have options that are cloud now. WorkDay is just a working example of an HR application in the Cloud that the market has already wrapped its mind around.
--------------------------------------------------------------------------------------------
If you are looking at an enterprise analytics solution that is not in the cloud and not delivered as software a service – and you don’t have a really unique good reason for this - you are probably making a mistake.
The next consideration to pay attention to in HOW is : what functional use case or domain was this enterprise analytics system designed for? This is the next big divider – here is where we get into the nuances of important less obvious choices you will be making.
The second great simplifier - is this system designed for generalized purposes or specific?
This is another major branch in your decision tree.
Option A : a generalized analytical system that can theoretically be applied to any analytical problem (but that is not designed specifically for any).
Option B : a solution that is designed specifically for a particular domain, customer type, or use case.
To use the HRIS example again, back when we were actually debating questions like this you could a.) build your HRIS system (an HR database) on a generalizable database structure – say generic Oracle – or b.) go with a database designed specifically for HR - PeopleSoft, Oracle HR, SAP HR, Lawson HR, Ultimate Software, WorkDay, etc… It took us time to figure this out, but the market decided that buying a system designed for HR is much better. Do you really want your IT team to be learning, following and servicing obscure changes to payroll, compensation or arcane HR needs that ultimately drive database design? That argument was long ago concluded. Overwhelmingly, with no uncertainty, the big girls and boys do not build and service their own HR databases. It turns out that what you are using the database for impacts important design decisions! It also follows out that customizing a generalized solution for an HR purpose is overwhelmingly more expensive over time. (because of labor costs and other problems unforeseen at the outset).
Option A : Generalized Analytical System.
Option A - Generalized, may on the surface look less expensive because it is a single solution that can applied across many functions, however you have to factor in the labor costs to bend it to the reality of each business function and their needs and maintain that. You won’t want your critical IT and Software Eng. teams working on HR stuff, so don’t do it. HR problems are notoriously needy and difficult. Stay out of it.
The big costs in technology are not in software, they are in the design and set-up. For example, I can buy a single license of Tableau for $2000 (+ $100K+ on a Tableau server to distribute that report over the company intranet with security), but to apply Tableau to my HR reporting needs I might actually “spend” $300K on IT labor for build of my ETL (extract, transform, load) and Data Warehouse path, which must occur prior to delivery of the data into Tableau. After this I will probably spend another $100K in labor to get my Tableau dashboard designed to do what I want it to and to look good. Was this actually a $2000 solution? No. Not counting the server (presumably used by other business functions outside HR) the solution actually cost me $402K, and possible a lot more. I will go through those labor costs several times while iterating towards the right set of metrics and reports for HR on a generalized analytical platform. Who will support me when I need to change the ETL?
I have been involved in one way or another with these generalized solutions four times over my career: Cognos at Merck, MicroStrategy at PetSmart, MicroStrategy at Google and Tableau at Jawbone. Google simultaneously experimented with Tableau and ClickView and MicroStrategy. There were people at Google who called MicroStrategy, “MicroDisaster” or “MicroSadly”, or (insert your own hilarious Micro explicative). The general consensus was, it actually may be a great solution, we are not sure, but WAY to difficult to implement and WAY complex for the typical user. Keep in mind, this was GOOGLE! Do you know the kind of people they hire? I’m wondering if anyone can figure out MicroStrategy? Sad indeed.
In some regards, Tableau and ClickView is designed to be more accessible but get into the nuances of Tableau and ClickView you will see they are going down the same path. Arcane nuances. Sub menu within sub menu. Flip this little switch in submenu 24, under the heading of a new word we invented, and then the report will work right… Seriously, that is your solution? Tableau promotes this as a simple solution, FOR EVERYONE. I'm holding them to it. Do you know what Tableau Professional Support Services costs per hour? $250 per hour. I once spent $5000 in Tableau Professional Services to find out that if I changed the way the data looked to Tableau on the way in then everything would work right, if I didn’t there was no solution to my problem. Major question - who is going to design and support the right ETL to accommodate this thing I am buying, what does the solution really cost? Choose carefully.
I can go down the line but the premise is about the same – you might save costs on software by leveraging the same software across functions of your organization, but you give that back on labor costs bending those applications into your functional needs and use cases. It may not be a silver bullet. It may not be cheaper. It may not be easy.
The other non-obvious consideration here is that if you are lucky enough to have a Business Intelligence (BI) team - IT people who specialize in business reporting - HR may be able to get their attention briefly, but my experience has been that 4 out of 4 times they tire very quickly of this BI ignorant HR person and their silly needs. The BI people go away. They disappear. The result is a solution that never gets where you want it to go and ultimately doesn't work. If you are going to go in house, you need dedicated resources - dedicated resources cost money. You also have to find some really smart technology people who actually like and want to work on HR problems, rather than try to invent the next Facebook. Non coincidentally, this is extremely hard - even at Facebook. Especially at Facebook.
------------------------------------------------------------------------------------------
For the record, Tableau could be a great downstream data exploration and data visualization application, IF YOU HAVE a viable data warehouse and ETL solution in place for HR.
------------------------------------------------------------------------------------------
Option B : Specialized Analytical System For HR
Here is a sample of options for varied HR Analytics purposes (alphabetical order)
- CultureAmp
- CruncHR
- Glint
- HiQ Lab
- One Model
- OrcaEyes
- Sapience Analytics
- SAP SuccessFactors Workforce Analytics (used to be InfoHRM)
- Visier
- ZeroedIn
(Folks, feel free to add other HR Analytics applications to the comments of this post and I will edit this list to include those later)
Maybe someday I will do a detailed analysis of all these applications – for now, here are the main questions you should ask as you evaluate each option? (you and your team need to answer these in a no-spin zone)
- What is the focus of this application? (consider depth, breadth, etc.)
- What are the 1-3 main differentiators of this application relative to its peers?
- What non-transparent assumptions underlay those 1-3 main differentiators?
- What other data management effort and applications are required to produce the final insights and stories that I am looking for?
- What is the data management strategy to get the data from your varied HR systems to these environments? (consider at the go live and consider the ongoing refresh)
This was a Gloves Off Friday Post from Mike West
Disclosures:
%20(1).svg "One Model People Analytics for HR Logo")
%20(1).svg)
%20(1).svg)
%20(1).svg)
%20(1).svg)
%20(1).svg)