Lloyd Turley has over 15 years experience in a variety of technology and leadership positions, where he has strived to make things work for both internal and external customers. At ADP, he has used his knowledge and expertise with IT systems to reduce complexity and expand capabilities and agility, while breaking the rules for cloud-based integration. This is not an easy job, considering that ADP’s comprehensive cloud-based Human Capital Management (HCM) solutions require that HR, payroll, talent, time, tax and benefits administration be integrated to deliver analytics and compliance services for 80 percent of FORTUNE 500® companies. In the following discussion, Lloyd talks about how he and his team view and use data integration to drive service and value for ADP and their clients.
Q: How important is data integration for your business, and how do you see its importance for the organization in the future?
A: Benefits administration is a key component of ADP’s Human Capital Management (HCM) solution and is an area in which I focus. We integrate enrollment data and payroll deduction data with a variety of sources and that data must be accurate and loaded quickly. Since we depend on other systems within the cloud, we need flexibility to transfer that data and create a great service experience. This is our business and part of the value we provide, and something that our clients shouldn’t ever have to worry about. We handle integration in the cloud on behalf of the client as part of our services. In essence, our business runs on having good, clean data, processed and delivered quickly. Without the right integration, we risk poor service experience. And the complexity is only going to increase as we add more and more data and sources.
Lloyd Turley • Director, CHSA Operations
Consumer Health & Spending Accounts
Q: Do you see a difference in the way you view integrating and onboarding data into your company now vs. in the past?
A: In the early 2000’s, batch-oriented systems, processes, files and point-to-point interfaces were prevalent in the data integration landscape. Over the last 16 years, we have adopted an enterprise service bus that’s helped integrate data for ADP. In addition, we have evolved from requiring strict rules around the data where we basically said, “You have to format your data in this way and meet these rule sets or else we’re going to reject your data.” This led to numerous challenges with our data trading partners, including clients and other vendors, slowing down data integration, increasing costs and ultimately leading to a dissatisfying experience for our clients. Now, we’ve expanded the target to make the data integration much simpler and much easier, all while reducing data onboarding time and overall costs. Having this solution in place makes it much easier for our trading partners to meet our data requirements and for us to access more data to increase our customers’ experiences. In one area, we were able to reduce the implementation time of a complex and regulated interface from over 90 days to 30 days or less in most cases.
Over his fifteen year career, Lloyd Turley has worked to reduce systems complexity, while expanding capabilities for his internal and external customers. In this pursuit, he has been known to break the rules of cloud-based integration.
Q: Were there downsides to opening up your data requirements?
A: There is some amount of risk of swinging the pendulum too far to the other side and putting consistency at risk. You have to find a balance between very tight data constraints and trying to take any data format, any time and in any way. We have struck a balance with the right tools and systems somewhere in the middle. We maintain some standards, but also have a wide enough target that we can support, and our trading partners can hit. This opens up new questions about defining what that service is, what the expectations are and finding a way to meet as many clients’ expectations as possible.
Q: During integrations, were there actions or processes you had to stop, start or do differently to get it right and meet your needs and deadlines?
A: We have a lot of people who like to send data via email and it’s not a secure method. So, we’ve had to go back and address that and make sure everybody understands what proper data security methods are and how to get the data to us so that we can get it processed. When we stopped doing email collection, we also started allowing data in different forms and receiving data via different channels. This has caused us to start new trainings and to make sure we have proper reporting and transparency controls in place to get the integration right.
Q: What are some of the best practices that everybody should know when they go through these very complicated, very intricate data onboarding processes?
A: There are two keys here. One is to be a true data trading partner, which involves working with the people with whom you’re trying to trade data and really trying to find that middle ground. I’ve seen situations in which two trading partners really withheld collaboration and they both retreated into their organization, blaming the other for not meeting “my requirements.” You have to break down those obstacles and barriers and really reach out and collaborate to find common ground because typically there’s a customer in between that just wants things to work. The second key item here is having some flexibility and the appropriate agility to collaborate. To achieve this, we have a data layer that we use to process both inbound and outbound data over which we have operational control. It is not dependent on core product releases in order to influence the data, so we can control that operationally. This allows us to flex and meet the various needs in order to process data.
Q: What are the biggest learnings your colleagues should know about integration/ data onboarding?
A: There are two things we see. One, people got accustomed to addressing and allowing an error because the error had always occurred. As we started new integrations, we discovered that the error acceptance had become a permanent process in and of itself. Now, we as an organization are committing resources in order to address these errors. By fixing this behavior and the process, we were able to redirect resources as well as automate and eliminate those data errors, which ultimately cut costs and reduced data onboarding time. The second is having a data layer that you can control without needing a lot of outside resources. For example, I’ve seen tightly integrated systems that worked for a time. But then, as soon as the data requirements and/or legislation changed, the systems are so tightly integrated that anything new now requires a product roadmap change. We have a data layer to seamlessly influence the system without needing an architectural enhancement in order to work. For example, when the Centers for Medicare & Medicaid Services (CMS) adopted HIPAA 834 version 5010, we had an appropriate data transformation layer in place, so during that upgrade, we just simply had to swap out our file format, which was very easy. We upgraded to the new file format without issue, whereas others in the market were really challenged and ultimately had to re-architect their data management systems.
Q: What are the questions people should ask before tackling integration and onboarding?
A: People should ask, “What does success look like?” Data integration can only work well if we really help establish the same goals across customers, partners and internal teams. Then, we can all say, “Alright, this is our end goal. Now let’s focus on the best way to meet client needs.” That way we have set the ultimate objective and can use integration, systems and processes to get the data flowing in an accurate and timely manner while, at the same time, overcoming any challenges that would prevent us from providing the best services to our customers.
Q: Were there any pleasant surprises you encountered during your integration projects?
A: The degree to which we could decrease the headcount to interface ratio. We were deliberate in our goal to decrease that ratio and were surprised when the needle moved from 1 headcount for every 10 interfaces to 1 headcount for every 2000 interfaces annually. This has equated to millions in cost avoidance since then and has allowed us to scale. We have grown the business about 20 times since then and been able to hold the line on our costs.