February 11, 2015

3 Reasons You’ll Regret Developing an In-House Data Integration Program

3 Reasons You’ll Regret Developing an In-House Data Integration Program

By Kit Dickinson on February 11, 2015

IDI_Office_Fire

Many companies have found that they can develop their own data integration solution in-house without much hassle. You obtain the vendor specs, program some mappings, no big deal. If you’re exploring integration options, internal development is certainly one that’s worth considering.

But there’s more to it than meets the eye. There’s no such thing as “get it and forget it” with integration solutions. If you’re not fully aware of what you’re committing to, you could regret developing your integration system within months of launching it. Suddenly you could find yourself putting out major fires you didn't know were smoldering.

Before you implement an in-house integration solution, make sure you think through these three scenarios.

Hidden Consequences of In-House Integration Systems

1) You can't get technical support for your internally-developed solution when you need it

Eventually, the IT person who wrote the data transfer solution will move on to another project or leave your company. They won’t be around to troubleshoot problems, such as why critical payroll information isn’t transferring from time-and-attendance into payroll. This leaves you to hand-key payroll or, worse yet, miss payday for your employees.

If you build your own integration system, be sure you have a plan in place that will let you quickly and easily resolve critical system errors like this. You will discover bugs in the system, no matter how thoroughly you develop and test it before rollout. It’s tempting to save money by internally developing your own solution, but a broken system isn’t a bargain by any calculation.

2) Pay policies have changed and you can't get IT support to update your internally-developed solution

Even if you don’t have a software failure, it’s possible you’ll still be entering data manually. What happens when you ratify a new union contract with different incentive rules, or add a division that has a commission policy and there’s no one to make the necessary software changes?

Before you start development, implement a procedure for handling any number of changes that need to be programmed into the data transfer solution to payroll. If you don’t have designated personnel to help you due to other competing project priorities, you could end up spending hours doing manual calculations instead of using a perfectly functioning integration application.

3) An upgrade to your time, payroll or HR system breaks the data connections

At some point you’ll need to make a systems upgrade, and you’ll need to make sure data integration continues to work properly. Will you have the resources to update your internally developed interface?

It may have been easy to develop the initial program, but continued support will take dedicated time and effort. Every time any of your connected systems receive any kind of update, you’ll need to thoroughly test the integration and create your own patches to address the changes. Major upgrades will require heavy investment of time and resources.

Besides this, you’ll always be playing catch-up, trying to fix problems that surface rather than proactively preventing errors.

Considering the Cost of Internal Development

Are you willing to wait for your development team to update your internally developed integration application? Payroll won’t wait until their fixes are in place. Make sure you have a fool-proof plan to address upgrades and minor updates—if you’re unprepared, even tiny system updates can throw a big wrench into the works.

Next Steps

Quick Time Entry Video