When people become the integration between systems

When staff copy information from one system to another, the organization has an integration; it is just made of people. Orders keyed from the CRM into the finance system. New starters typed into the HR platform, then into the identity directory, then into the service desk. A weekly export, a spreadsheet to reconcile it, and an email to the team that owns the other system. Every organization with more than a handful of systems has some of this. The question for an operations or IT leader is which of these human integrations are costing more than they appear to, and what the right fix is for each.

The cost is rarely visible in one place. The time spent keying is spread across many people in small amounts. The errors show up later and elsewhere, as a wrong invoice, a customer contacted twice, an employee without access on their first day or an account that stays active after someone leaves. The delay is built into the process, because the second system only knows what happened in the first when someone gets around to telling it. And the knowledge of how the transfer works tends to live with one or two people, so it stops when they are away.

There is also a control problem. Manual transfers rarely leave a trail. When a figure in one system disagrees with another, nobody can say with confidence which one is right, when it changed or who changed it.

Before choosing a fix, find out which system should own each piece of information. For every item that moves between systems, such as a customer record, an order, an employee or a contract, decide which system is the source of truth, which systems only need a copy, and how quickly the copy needs to be current. Many integration problems are really arguments about ownership that were never settled, and an integration built before that argument is settled will faithfully copy the confusion.

Once ownership is clear, the options can be compared. There are five ways to close the gap, and the cheapest one is often to stop needing the data in two places. The options run from lightest to heaviest.

The first is a process change. Sometimes a second system holds a copy of data only because of a report, a habit or a team preference. If the report can be run from the source system, or the team can work from it directly, the transfer disappears and nothing needs to be built.

The second is a native connector. Many business platforms already offer supported connections to common systems. They are quick to switch on and are maintained by the vendor. Their limits are that they move data in the way the vendor designed, which may not match the process, and that they can be hard to monitor. Check what they actually do with exceptions before relying on them.

The third is an integration built on the systems' interfaces: application programming interfaces, webhooks, scheduled file transfers or an integration platform in between. This is the right answer when data needs to move reliably in a specific way, with rules the connectors do not support, or across more than two systems. It needs design, testing and someone responsible for it afterwards.

The fourth is a purpose-built application. Sometimes the reason people are re-keying is that no system does the job in the middle, such as a step that combines data from several sources, applies a rule and produces a decision. A small application or portal that sits between the systems can be the cleanest answer, but only when a product that does the job well does not already exist.

The fifth is replacing one of the systems. This is occasionally justified when a system is at the end of its life or cannot expose its data at all. It is the most disruptive option and should be the conclusion of the analysis, not the starting point.

The build-versus-buy decision sits inside the fourth and fifth options, and it deserves a direct answer. Build when the process is distinctive to the organization, nothing on the market fits without costly workarounds, and the organization is prepared to own the software over its life. Buy when a product already does the job well, even if it means adjusting the process to fit. Paying for several tools to do one job, or bending a product through heavy customization, is usually a sign the decision was made the wrong way round.

Whichever option is chosen, design for failure. A silent failure costs more than the manual step ever did, because nobody is watching for it any more. The people who used to catch problems have stopped looking. Every integration needs to handle errors deliberately: retry what can be retried, hold what cannot, and raise an alert to a named person when something needs attention. It needs a log that a non-specialist can read to answer the question "did this record get across, and if not, why not?" And it needs an owner after go-live, because the systems at both ends will change, and the integration has to change with them.

Measure the change the same way you would any process improvement. Before the work, count the items transferred by hand, the time spent on them and the errors that result. After it, count the exceptions the integration raises, how quickly they are cleared and whether the two systems now agree.

In CnergyPro's delivery model, integration work starts in Assess, by tracing where information moves by hand and why. Architect settles ownership of the data and chooses among the five options. Implement builds, tests and stabilizes the connection. Optimize keeps it healthy as the systems around it change, with integration monitoring and continuous improvement where the engagement requires it.

When an integration is working, nobody has to think about it. Information is where it needs to be when it needs to be there, the people who used to move it are doing work that needs their judgment, and when something does go wrong, the right person knows about it before a customer does.

CnergyPro helps organizations improve critical business processes, then configures, integrates, builds and optimizes the technology that makes the better process operational. If your people have become the integration between your systems, tell us what's not working.