This is the third in our series of pieces about the hassles of making data work. You'd think it would be simple. "I want to know the relationship of x and y." But, depending on the system and your subcontractors, it's not easy.

This is the third in our series of pieces about the hassles of making data work. You’d think it would be simple. “I want to know the relationship of x and y.” But, depending on the system and your subcontractors, it’s not easy.

So, you’re the proud owner of a brand new integrated single-sign-on system from company X. After a ton of negotiating and almost getting fired during implementation, you are ready to go to work. You might think you’re done with the surprises and heartache.

Sadly, it’s just beginning.

This is the third in our series of pieces about the hassles of making data work. You’d think it would be simple. “I want to know the relationship of x and y.” But, depending on the system and your subcontractors, it’s not easy.

Unless a piece of software is written in a single code stack (or developed with precise descriptions of all of the data elements…which doesn’t happen), the process of getting data out for cross functional questions involves mapping and cleaning the data. Every single time.

The thing you need to understand is that a system can operate perfectly well and still be a mess in the data layer. Since non-expected scenarios are not called out in any RFP ever, the buyer doesn’t have to come to grips with the question until after the system is installed.

Here’s an example:

Let’s say you want to track something like “Time to Productivity” in new employees. You’d need data from payroll, recruiting, on boarding and performance management. In a system where all of those functions have been developed from scratch with one architecture, it’s a relatively easy question to ask.

In a Single Sign On system (SSO), you’re probably in trouble. SSO is all about not having to remember passwords. SSO tools are generally ‘lightly’ integrated. That means that the various components of an SSO tool are unlikely to share basic data structures. While that can be solved with mapping, there is usually more at stake.

SSO is really a gimmick. Designed to make unassuming purchasers feel good, an SSO system generally skips through the critical phase in software integration. In exchange for a slight reduction in administrative burden, you get endless headaches from users who think there should be more.

Between SSO and an Single Code Stack (SCS) are a variety of ways to produce integrated solutions. Integration doesn’t solve the real problem. Instead, integrations anticipate various ranges of potential use cases. You can think of Integrated Systems as Single Sign On Plus.

The real trouble comes when the C-suite wants answers to questions that are out of the box. You should be expecting to answer questions like

  • How does the orientation program affect attrition?
  • Do employees who were sourced through LinkedIn get to productivity faster than those who were sourced through Monster?
  • Does putting an employee in the hi-po group decrease attrition?
  • What is the pay differential between new developers and 1o year vets? Is there a performance impact?

In integrated systems, you will always have to clean and validate the data before you present it. Executives will be frustrated by the turnaround time.

The series:



 
Read previous post:
From Transactional Data to Strategic Insights

By understanding the business you are in and the challenges the business face, HR can truly have influence and impact...

Close