HR Analytics is still in its infancy in most organizations. One way to gauge that is to ask about and investigate the degree to which activity in this area is evident in HR practices in organizations. If you have either read some of my previous articles:
or read the book I published:
you may remember that there are at least 3 broad categories that have the capacity generate HR-related information/data that can benefit from the use of HR Analytics:
- Traditional HR Metrics – information generated because of ‘onboarding, participation in, and offboarding’ of employees as they interact with organizations
- HR Operations themselves -when HR starts capturing information about every ‘HR request for service’ that comes into them, tracking its status from inception to completion to assist in HR process improvement.
- Embedding HR Analytics (Machine Learning and Artificial Intelligence) directly into HR methodologies themselves to improve the reliability and validity of the HR decisions we make on behalf of the organization
I’ve mentioned in my book and in previous LinkedIn articles the rarity of this evidence – particularly of the last two. And in most organizations even the first one stagnates typically at the first level of analytics- ‘descriptive’ (reports and dashboards), rarely venturing into the even higher payoff areas of diagnostic, predictive, and prescriptive.
I think that one way for HR to get out of its infancy, in this area of HR, is to continue as much as possible to immerse itself hands-on into their data wherever possible and experiment with HR analytics on their data (with appropriate rightful access assumed of course.)
It’s in that spirit, that I continue to have the passion to write in this field.
The intent is to show examples of how HR analytics and some of the technologies out there can be brought to bear to make this field ‘more real’ to organizations and show that real gains can be made in the productivity in the organization as a result.
In this blog article, I wanted to explore further a previous example that I had given- Job Classification in R- and share a little bit further one example of what that ‘embedding’ might look like in a practical example, and how some of Microsoft’s technologies might help and be of use in that regard.
The Previous Job Classification Example
If you want the details, please refer to the original article in this link
A Reader’s Digest version
The previous example used statistical ‘classification’ algorithms to do ‘job’ classification in HR. A series of 66 ‘narrative’ job class specifications were reviewed – from a hypothetical organization for commonalities.
After reviewing the narrative descriptions, it became evident that a common set of ‘factors’ were used in the traditional classification process to determine the pay grade. These were:
- Education level
- Organizational Impact
- Problem Solving
- Contact Level
- Financial Budgetary Responsibility
Each narrative description was quantified as to the level of each of these mentioned in each job classification description. For each description, a record of data was created in a spreadsheet with identifying information, and the current Pay Grade assigned.
The goal in HR Analytics in this example was to see whether this quantification of information from narrative sources and application of machine learning algorithms could provide a reasonable prediction of the paygrade – as compared to the actual paygrade.
In looking at the previous article, the accuracy of predicted versus actual was pretty good- so in the R script an example was given to test a ‘new’ job classification not in that existing population or records to determine where it would line up paygrade wise- given the ‘known’ population.
The example above showed the process used to validate which algorithm performed best on the data- with the accuracy of prediction against actual being the criteria. With the best algorithm chosen, new data was then applied to the model.
In a very loose, rudimentary, technical and ‘non-user-friendly’ way – that WAS ‘embedding’ – choosing to use the results of machine learning as part of the ‘decision making’ in a Job Classification process that already existed.
Generally, the more you find yourself able to trust the results (from your experience) of machine learning, the more willing you are to significantly alter your current practices.
But what if we wanted this ‘embedding’ to be more ‘ user-friendly’?
What if we wanted to encourage end users to use the power of machine learning and artificial intelligence in something they can interact with? One of the ways of doing that is to develop an end-user application that puts the complexities of ‘doing’ and the ‘how its done’ behind the scenes.
Enter Microsoft R Server, Microsoft SQL Server 2017, and Visual Studio 2017
While R is freely downloadable from CRAN, you can also download it from MRAN which Microsoft’s version of R is- based on CRAN R with some nice additions.
I will leave it up to you the reader to track down the details of the differences. But one significant difference is that Microsoft has a server version. This version is significant because it allows the running or execution of R within SQL Server itself.
Why is this important?
There are at least a couple of reasons:
· When it runs inside SQL Server itself, data doesn’t have to be imported and exported out of SQL Server. For this simple example of 66 records- this isn’t terribly important. But when you have hundreds of thousands of records, or millions or billions or records- import/export is a big issue. Your data starts in SQL Server and stays there.
· When it runs inside of SQL Server, other software can be used in conjunction with SQL server to develop end-user applications. R scripts exist inside stored procedures. And stored procedures can be called from applications developed in Visual Studio (in this case version 2017).
· This means that once a predictive model has been created and validated for use, an end user doesn’t need to know R to use the predictive model built in R. It is ‘behind the scenes’. The user interacts with an end user application instead of R.
Click here to continue reading Lyndon Sundmark’s article.