Why Integration Is the Starting Point for HR Digitization

Dec 15, 2017


If you are wondering when and how you will catch up to the rest of the digitized HR world, you are not alone — but you may be wrong about your self-assessment.

In what may be an indicator of the state of digitized HR, in 2016, Gartner estimated that 55% of its clients were in the “getting started” phase of their integration development. If you are just getting started, you are in good company. It’s not important where you are, but whether you are on the right path.

In the new digitized HR, no single vendor can meet all our technology needs. Organizational structures are fluid, and everything is becoming data-driven. Managing integrations becomes essential as the foundation for coordinating how people interact with machines and machines with each other.

Integration means many things to many people, depending on the context, but we can define  integration in two equally important ways:

  • The data exchange required for two or more processes, applications, systems, platforms, or businesses to work together (interoperability).
  • The data flow required to aggregate information for reporting and analysis.

Microsoft became the world’s leading purveyor of office software because it focused on interoperability. Each application in Microsoft Office works with the other applications in the suite, at least to some degree, and with many different business applications.

Integrations are invisible to business users, and when you mention integration to a project team or a room full of people, they look like they want to lose their eyes and stick their fingers in their ears, or look at IT to make it go away.

We can get an idea of why integrations are so involved if we think how much easier human communication would be everyone used the same medium and the same language, and every word had only one meaning.

The logistics industry has been using Electronic Data Interchange (EDI) for decades. What makes it work is the definition of electronic documents. The structure of the data has been defined by the agreement, and large retailers drove adoption by requiring their trading partners use to EDI. Information flow is much easier to manage because no translation is needed. As people in the industry say, an invoice is an invoice.

In human resources, and in many other business functions, there is no such agreement. While we may have our standard set of best practices, we have no formal agreement on what constitutes an employee profile, succession plan, or any other talent management data structure.

Every software developer, vendor, implementation partner, and the customer has a unique perspective on what the data structure should be, but that is only one component of data transfers. To integrate these disparate entities, the parties to the data exchange must agree to three primary considerations:

  • Transport — How data will be sent from one computer to another. There are dozens of transport protocols, the most popular of which are FTP, HTTP, SFTP and Webhooks.
  • Format – How the data will be formatted. If two entities are not in agreement on the structure of the data, some mediation is required, and that adds another level of complexity.
  • Meaning — what each datum in the dataset means. We can also think of this as semantics.

The technology industry has worked through many ways of coping with this. In the ERP of the 80s and 90s, businesses attempted to force all data into one database structure. The problem was that technology is continually changing, and we are always adding new capabilities, applications, and platforms. Since ERP vendors found it difficult to keep up with the pace of change, we often ended up with an unwieldy system of satellite applications integrated (or not) with the ERP.

With the growth of big data analytics, the next trend toward centralization was to dump all the data into a single data warehouse. That proved to be difficult and outrageously expensive.

The current trend is toward a hub-and-spoke kind of architecture, where, instead of a single repository for all data, we have hubs that handle integrations with related applications and platforms and with each other.

We see a lot of potential in this approach. The problem with the master data approach is that many organizations thought master data meant all data. The reality is that some data are master data, but most are not. For example, payroll does not need all the information in an employee profile, nor does it require the entire chart of accounts from finance.

Strategy First

We urge you to resist the impulse to buy a “complete” integration solution immediately. As we discussed in “How to Get Control of Your Disconnected Data,” it is best to chart your course before you decide what will carry you on your journey. And integration platform may eventually be the answer, but ask the right questions first. Too many organizations bought technology solutions expecting them to solve their business problems when technology was not the problem.

Begin by asking these questions:

  • What is the best source? What data is most reliable and should be the data source for other functions and applications? Everything in finance stems from the chart of accounts. Everything in HR begins with the employee profile.
  • What information does each application need to operate? Payroll does not require the entire general ledger, nor does it need the whole employee profile.
  • In each integration, which system should rule? How should conflicts be resolved?
  • What information do you need for operational reporting and analytics? Instead of capturing all data and trying to make sense of it, you can add data to analytics as it is required.

When you are starting out, application-to-application integrations will most likely be most comfortable and least costly to manage, but as your infrastructure grows, you may need an integration platform.

As we do with every technology project, we recommend you start with a business problem. The most common issues we see are excess administrative overhead when people must enter the same data in two or more systems. The most straightforward solution to that is an application to application data feed, where, for example, your LMS retrieves new employee data from the employee profile in ADP.

Start small and simple and think big. Solve one problem at a time, but keep your eye on the whole picture.

Chasma Place, is an independent source for solutions that will help you keep pace with changes in the way your people work without ripping and replacing your existing systems.

Chasma Connect




News Letter Sign up

Get in touch with us
phone_footer.png  +1 903-306-2430,
              +1 855-978-6816