Over the last ten years we’ve seen a trend where businesses pick “best of breed” (BoB) software to meet process needs rather than trying to do everything in their ERP software. This is a great path to follow, as a BoB package will often provide the best software solution for a specific process. However, it only becomes truly optimal if an automated integration is in place between the BoB and other systems, such as the primary ERP. The other side of this trend has been that larger businesses have the in-house skills to ensure they have integration in place, small to mid-size businesses using BoB often avoid automated integration between their software packages as an unnecessary expense. Instead, they’ve relied on manual integration, or “swivel chair integration”, where their staff rekey the data between the different systems, often as each transaction occurs. This obviously breeds long-term inefficiency and increasing cost as businesses and transactions grow, which then leads many of these businesses back down the automated integration path.
This is where the challenge for the business begins. How do you pick the right integration and does your software vendor have what you need? Particularly when they tell you they can “Integrate to anything”? Is the integration really as simple as they’re telling you it’s going to be?
So many software solutions now claim to have “simple” or “easy” integration options. This often encourages customers to believe that the vendor is disclosing everything they need to know and that it will be easy for them to put an integration in place. Unfortunately, this can be a bit of a misdirect, as the customer can easily assume that this means what they want it to – that integrations between their nominated software and third party software can just be “switched on”.
There are definitely many simple out of the box integrations that are well supported and work. Accounting software like Xero, MYOB and Quickbooks connect to hundreds of packages via a simple api key and work well for master data sharing and transaction posting. However, if you step away from the simpler packages and popular transactions, the landscape is not as simple to navigate.
It’s the complicated details that often aren’t disclosed, such as:
- “Our integration options are dependent on you integrating to a system we have built an OOTB integration for AND you fit within the standard transactions/processes we included”, OR
- “Our integration options are dependent on your business having middleware such as Dell Boomi or IBM Websphere in place to do the data translation”, OR
- “Our integration options are dependent on whether your third party software will and can continually poll our system, checking for changes.”
The reality of system to system integrations is that unless they have been purpose built for specific software packages with nominated data transfer events (eg invoice creation, payment receipts), then your business will very likely need some method of managing the data mapping and translation as the data goes from one system to the other.
An additional complication is that BoB systems often like to position themselves to be the “source of truth” for your data. They publish APIs that enable their own data to be read or updated, as well as for new data to be given to them, in their required format. For this reason, the BoB package may not be as interested in getting data to the “other” system, which may be your business’s actual data “source of truth”. A common solution the BoB provides is to allow you to configure something called a “web hook call”. This is a mechanism which lets another software package retrieve information from them, where the other software does the bulk of the work. By allowing for this, the BoB can legitimately tell you that they have APIs and provide “easy integration”. However, the ease is all on their side – your business then becomes responsible for checking and retrieving changes, as well as for the setup and maintenance of the public web server with the web service endpoint that you need so that you can accept the contents of the web hook call. You then have to get the data to your other software package.
So how do you navigate the highly technical and often misleading world of software integration?
The first tactic to get past a software vendor’s “we integrate to anything” line is not to accept what they say on face value. Ask questions! Such as, does your integration only work between certain software packages? Is it pre-configured or configurable? Do I need a translation piece? And most critically – does your OOTB integration only work with predetermined processes on predetermined software? Following on from this, if the vendor doesn’t haven’t a pre-built integration available, then there will ALWAYS be an element of translation between their software and your chosen software. You might need to translate what different codes mean in the two packages, or determine how data is interpreted, or even build your business rules. Sidebar – vendors tend not to tell you any of this because it’s better business for them to make an integration project that has the capacity to be very complicated/expensive seem like it’s going to be simple/cheap.
Which leads to the second tactic: before you start, make sure you understand the data and transaction flows that will bring efficiency gains to your business, including your business process rules. You need to understand this at a high level (key functions) as well as at a detailed level (what does that transaction need to work for you?). This will help you to identify the high level in the vendor API-speak, as well as then ask them about the specific details that you will need. For example, we’ve seen customers ask vendors if they have an integration that will accept their “jobs”, or “projects”. The vendor response was “Yes, we can!”. However, the customer specifically saw the project as a standalone master record that was used to drive the process, while the vendor saw it as an additional code to add to a general ledger accounting record.
It’s also important to understand the data structures in both systems and the key codes used to transact with. It is very common for a record to have a UUID (Universally Unique Identifier) code that is hidden from users but critical for updating data between systems. For an API call to be successful the UUID must be stored in the system initiating the API call. This relies on that data being obtained when the record is created and a field being available for storage.
Once you know the level of integration you need, and if both vendors can deal with your data flow requirements on your terms, it then comes down to the “how”. Another little trick that vendors often don’t make apparent is that they’re free and easy with the APIs when it comes to updating or inserting data into their system, but if you want to send it somewhere else? It will be possible, but generally it’s ONLY IF THE OTHER SOFTWARE ASKS FOR IT. It’s not uncommon for both sides to say they integrate, so long as the other system spontaneously sends them the data. When neither package wants to ask for the data, or spontaneously send it, it can lead to a bit of a stalemate. You can read more about how we’ve solved this one previously in our case study here.
The translation and interpretation between different software integration styles, processes and needs can be complicated and a head-scratcher for even an IT guru. It can be very expensive when you get it wrong, but it also has the capacity to be very expensive even when you assume you have it right. Anyone who tells you that an integration is “standard” is more often than not making an assumption that you will fit into the way they want to process. Or they’re assuming that they can hook you in with that line and then overwhelm you with the detail later.
So how do you move past all of this and get the integration you need? If you have someone in your IT team who understands your business processes, your software systems and integration methodologies, you’re already part of the way there. This resource is going to be your champion to determine if the vendor-speak on integration works for your business and if it doesn’t, they can work out what your path forward will be. If, however, you don’t have that internal resource, then you’re going to find someone like us, who can act as your trusted partner and “vendor-translator”. We look at the best method for your business, which may not be the most cutting edge method. The solution needs to be right-sized in terms of cost and ongoing management. Yes, there’s a cost to bringing someone else into the equation, but it’s going to be a lot less than the potential time, effort and money spent on a vendor integration that will never deliver what you need.
Done right, you can integrate to anything, so long as you cut through the vendor tech-speak and achieve what you need. And removing manual integration between your software systems is worth the effort due to the elimination of manual input errors and the time, cost and efficiency gains returned to your business.
If you’d like to learn more about this project or talk to us, click here to contact us.
You must be logged in to post a comment.