When two business systems don’t share information properly, it’s usually treated as a minor annoyance. Someone exports a spreadsheet, fixes a few rows, emails it to a colleague, and they upload it somewhere else. It works, until that person goes on vacation, or order volume doubles, or one of the systems gets an update and the file looks different.
What started as a quick workaround has quietly become something the business depends on.
The retyping is only the visible cost
The obvious cost is the time spent copying information from one place to another. The bigger cost is the delay. An order is taken, but stock levels don’t reflect it until tomorrow. A payment comes in, but the accounts still show it as owing. The crew finished the job this morning, but the office still thinks it’s open.
People work around these gaps. They phone each other to check. They keep their own spreadsheets. They add extra approval steps just in case. Over time, the business builds a second, unofficial system on top of the official ones, and it usually lives in the heads of a few experienced staff.
Decide which system is in charge of what
Before connecting anything, I ask a simple question that turns out to matter a lot: for each piece of information, which system has the final say?
If a customer’s address can be changed in three different places, which one wins? If an invoice is cancelled after it has already gone to accounting, how does accounting find out? If a scanner accidentally sends the same reading twice, should that create two transactions?
These sound like technical questions, but they’re really business decisions. Agreeing on them up front saves a lot of confusion later. A connection can move data perfectly and still move the wrong data.
Plan for things going wrong
Connections between systems fail in ordinary ways. The internet drops out. A password expires. A supplier changes their software. Information arrives in the wrong order. A good connection expects this. It notices the problem, holds on to the information, tries again sensibly, and makes it easy for someone to see what’s stuck and sort it out.
Trying again needs care. Checking a stock level twice does no harm. Sending the same payment or the same shipment twice does. Well-built connections recognize a repeated message and ignore it, instead of processing it a second time.
Make problems easy to see
A good connection should be able to answer a few plain questions at any moment. How many orders came through today? Are any waiting? How long has the oldest one been waiting? Did anything fail, and does someone need to look at it?
The most useful alerts are about the business, not the computers. “An order hasn’t reached the warehouse in two hours” is far more helpful than “the server is busy.”
It’s also worth regularly comparing totals between systems: order counts, invoice totals, stock on hand. Even good systems slowly drift apart. Nobody can promise nothing will ever go wrong. What you can do is catch problems early, before they become expensive surprises.
Fix the connection that hurts most first
Not every connection needs to be instant. A sales report that updates overnight is often perfectly fine. Anything that controls what stock is available to sell, or moves money, needs to be much more dependable and more closely watched.
A good place to start is to sketch how information moves around the business, count how often people handle it by hand, and note which problems eat up the most time. Then fix the most painful connection first. One small, well-watched link can remove more risk than a big platform project that never quite gets finished.
If you remember one thing
Good integration isn’t about how many systems you’ve connected. It’s about the right information reaching the right place at the right time, and being able to see quickly when it doesn’t.