System integration: building a data flow between disconnected software

The moment an order lands on the e-commerce site, three people retype the same information in three different places: one into the accounting program for the invoice, one into the warehouse spreadsheet to reduce stock, one into the shipping system for the address. Every entry is a new chance for an error, and every spreadsheet holds a slightly different “truth”. When the numbers do not match at month end, finding out who updated which data, and where, becomes a job in itself.

System integration is the work of enabling software that runs independently of each other to share data without re-entry, under defined rules and in a traceable way. The aim is not to replace the systems, but to make every data field come from a single, reliable source and reach everywhere it is needed on its own. In this article we explain how to build a data flow between disconnected systems and what to watch out for.

Where does the disconnect begin?

Each piece of software may be fine on its own; the problem is the gap between them. These signs show that the data flow is disconnected:

• The same customer, product or employee information is entered by hand in more than one system.
• Reports are prepared by manually merging files taken from different systems.
• Until a change in one system reaches the other, nobody knows the current information.
• When an error occurs, it is unclear in which system and at which step the problem arose.

A controlled data flow in four steps

Integration is not connecting two systems with a cable; it is a decision about which data moves, in which direction and under which rule. In its Integration work, YazSis follows these four steps:

1. Choose the source. Pick a single, reliable source for every data field. Will the master record of a customer’s address be kept in the CRM or in accounting? If this is not decided, the two systems overwrite each other’s data.
2. Design the flow. The direction, frequency and transformation of the data are defined: will it move in real time, hourly or daily? How will fields be mapped? What happens when the other system is down? Error scenarios should be written down at this stage.
3. Set up control. Logging, permissions, retries and data validation are applied. Which service accesses which data, is a failed transfer retried, where does a faulty record wait? All of this should be on record.
4. Make it visible. The health and business result of the integration are monitored: how many records moved today, which ones failed, who will take care of them? An integration you cannot see breaks silently, and by the time it is noticed the data is already contaminated.

Let’s make this concrete with a small example. The source of an approved order is the e-commerce system; the order number, product and amount come from there. The flow is one-way: the order moves first to the ERP and then to accounting, and the trigger rule for each transfer is written down in advance. At the control layer, if the same order number arrives a second time, no new record is created; if a transfer fails, the order is not lost, it waits and a warning goes to the person responsible. For visibility, the screen lists how many orders have moved, how many are waiting and how many failed. The four steps work even in a small flow.

Which systems get connected?

The scope varies from one business to another. These are the main areas of connection; each of them is handled separately within the project scope, depending on your existing system:

• ERP and accounting: keeping operational and financial data consistently in sync.
• Payroll and PDKS (time and attendance): connecting personnel and time data to the related workflows.
• CRM and e-commerce: centralising customer, order, product and status data.
• Bank: integrating financial data flows through controlled services.
• Production and warehouse: carrying movement in the field into the ERP and reporting layer.
• SMS and e-mail: managing notifications from a central, traceable communication layer.

Four common mistakes

• Connecting everything at once. Starting with a single flow and expanding once you see it working reduces both risk and the load on the team.
• Leaving error scenarios to the end. An integration usually works when everything is fine; the real test begins when a system does not respond.
• Not choosing the right source in a two-way flow. If both systems can change the same field, it must be decided in advance who wins.
• Building it and not monitoring it. When a data flow breaks, the first to notice is usually a manager who has seen a wrong number.

An integration is not a connection you set up once and forget; it is a production line that runs every day and whose health is monitored.

You do not need to replace every system

The first reflex of companies with disconnected data is often “let’s replace the software”. A proper integration layer, however, protects existing investments while bringing operations together. The first question should not be which software to throw away, but which data is not reaching which system on time. The answer usually points to a single data flow; when that flow is fixed, the team saves time and starts to trust the numbers again. Moving on to the next flow after that keeps the project manageable and measurable.

To look at the data disconnect between your systems together, take a look at the Integration page.