Why it's important to have an integration project framework
Recently I was asked to speak at the IPPA conference in Las Vegas as the topic of integration has become more of a pain point in the payroll/hr/hcm space. Admittedly I was proud to be invited to speak, but also anxious over what to present. After much thought, how we at detamoov approach an integration project came to mind and I thought would be an interesting topic for folks in the industry to hear.
To understand why I felt this was a good topic, it's important to understand why integration is so key in the payroll industry?
When I first entered the payroll industry 20 years ago, the offering was payroll. Yep just payroll. Pretty cut and dry - payroll companies calculated pay checks and made sure employees received a physical check they could deposit into the bank or cash.
Over the years the offering expanded to include time and attendance, scheduling, electronic onboarding, benefit management, recruiting, employee engagement and more. As the offering expanded, the need for integration did as well especially in the world of benefits. Couple this with more and more businesses embracing the internet and technology which enabled system integration, we had a perfect storm.
But payroll companies weren't equipped to handle this world so what they did was rely on practices they were comfortable with and "got the job done". Doesn't mean these practices are ideal, but they felt comfortable to many in the payroll industry. And if I say so myself, these are not ideal practices.
Bad Practice #1 - manual data entry into third-party websites
This should be an easy one to picture. Employee signs into a third-party website and manually keys in data. Sounds simple right? Well not when you're manually keying data for 20, 30 or dare I say 50+ employees.
Hand keying data is messy, tedious and error prone. Typing an extra 0 accidentally into an employee's retirement plan contribution can make a huge difference. You could've just added $900 to the employee's retirement plan with an extra 0. Or worse yet, $9,000 dollars extra.
Plus we're not even talking about the data security around password management. You know the classic sticky note that many would write passwords on and stick to their computer monitor. If you do this, you know it's not right but it's just so convenient. I won't even get into why it's a bad idea because you know.
So all in all, hand-keying data is not a great option. A few got smart and moved to bad practice #2.
Bad Practice #2 - creating custom extracts/reports
So you're convinced that manually keying data isn't the right fit. You easily see the pitfalls and know you need a better solution. What's next is you decide to look at "semi-automating" your integration by either having a member of your team or hiring a consultant to create a custom report/extract matching the requirements of the third-party.
Simple enough right?
Sure, but there's a hard cost with the time and expertise it takes to create these custom reports. Plus what happens when maintenance is required? Will you have that resource on staff to help or will you be paying someone else even more money to maintain this custom work?
Even if you have a great reporting tool, do you really want to maintain 50, 100 or 200 different custom formats? Do you or your team have the skills to do this? My guess is you don't.
It's starting to get complicated right? No matter which bad practice you pick, you risk over/under reporting information and being out of compliance. It's likely not a situation you'd like to be in.
What is there to do?
I hope you're starting to realize that having an integration project framework is important. Even if you're not a technology company, it should be something you consider creating. And I'm not asking you to create it yourself. I'm going to share with you the integration project framework we use at detamoov soon!