System integration

You can tell you need it when someone is copying things across. The order from the shop is keyed into the ERP, hours from the time system go into payroll, stock is checked against a spreadsheet on Fridays. Every step like that is a place where two versions can drift apart.

But not every step should be automated. If someone is there to approve, the approval should stay, and a step done a few times a month can be cheaper to do by hand. Where the line goes is covered under process automation.

What happens to the order when a system stops?

Take an order in an online shop. It has to reach the ERP with the right customer, price and VAT, stock has to get back to the shop and the shipping label out to the logistics partner. Four decisions determine whether the flow holds, and they are yours.

• Which system owns what. Customer, item, order and stock may be changed in one place, and the others read from there.
• How old a piece of data may be. A stock level that lags behind during a campaign sells goods you do not have. Payroll data does not need to be real time, but it should arrive well before the cut-off date.
• What happens when the receiver is down. Are orders queued and sent when the ERP is back, or are they lost?
• Who owns what did not arrive. A rejected order does not disappear by itself. Someone has to see it, fix it and send it in again. Queues and retries solve the technical part. They do not answer who is watching.

What we need to know about your systems

The names of the systems and what access you have to them today. The flow that costs the most manual handling, step by step, with the exceptions that usually stop it. What can be built depends on which API or file format each system accepts, and we look at that before we promise anything.

The first thing to agree on is not a technical solution. It is who owns each piece of data, how fresh it needs to be and who deals with the exceptions. Get in touch with the flow that hurts most, and we will start there.