Integration. It’s the lifeblood of your financial and operational systems. How many times do you find yourself pulling data from system A and re-entering it into system B? (Sometimes, “system B” is Excel…) Those systems are all critical to your business success, and they often all say, “Yes! We are integrated!” When we hear “integrated,” we want to hear “seamless, plug and play, it just works.” But “integrated” is a word that is open to a lot of interpretation. Here we’ve listed 4 key things to be aware of when digging deeper into what someone means by the word “integrated.”
Sometimes, a vendor means “we can create a .csv file for you to export, and then import into another system” when they say “integrated.” This can be fine for systems where you don’t need data daily. But it can be difficult and time-consuming to manage if you need that information every day.
Native integration sounds perfect, right? But it’s important to know what the vendor actually means by that – what, specifically, is integrated? What transactions? When does the integration happen? Here’s a quick punch list of questions to make sure you ask when reviewing a product that says it has a native or built-in integration to another system:
- Which pieces of data integrate? Be specific.
- When does the integration happen?
- Is it one way or two way between the two systems?
- What happens when an integrated piece of data (for example, a customer) changes in one system?
- What happens when an integrated piece of data is deleted?
- If there are processes being integrated, where are the hand-offs between the two systems, and what happens if you need to change the process midstream?
- How does error correction in one system get handled by the integration?
- For financial data – how does the integration deal with closed accounting periods?
- How is security handled between the two systems?
Sometimes, you need to build your own integration. All of the above questions (for the native integration) should be considered in your planning. You’ll also want to know the timeline for the custom-built integration, and how far along your systems need to be configured before anyone can start building or testing the integration.
Sandboxes and Testing
For most integrations, you’ll want to make sure you have a safe place to test the integration prior to moving it into a production environment. This sounds very basic, but often people don’t want to invest in the expense of a sandbox environment. However, it’s well worth doing!