Connecting your ERP and online store without rebuilding either

The proposal that shows up when the online store and the business system don't talk to each other is almost always the same: replace them both with a single platform. It's the most expensive answer, the slowest, and the one most likely to bring the company to a halt for a quarter.

In most cases the useful work sits in between: read the data where it lives, translate it, write it where it's needed. The two systems stay where they are, and there stops being a person acting as a bridge with copy and paste.

What gets synchronised, and in which direction

The first decision, and the only one that really matters: for each type of data, who's in charge. Data with two masters is data that will diverge sooner or later.

Customer records. Usually the business system is in charge, because that's where VAT number, payment terms and credit limits live. The online store receives and doesn't modify, except for the data born there — the account, the preferences.

Products and prices. The business system is in charge. The site shows what it receives, including the rules a standard theme doesn't cover: different prices per customer, tiered discounts, price lists with validity dates.

Stock. The warehouse is in charge, and the quantity shown online isn't the physical one: it's the available one, net of what's already committed to unshipped orders. Confusing the two is the classic way to sell what you don't have.

Orders. The site is in charge, in the opposite direction: the order is born online and becomes a document in the business system, with counterparty, lines, VAT rates and shipping already in place.

Start with the flow that hurts most

You don't need to connect everything at once. Look at where the time actually goes: in most stores it's order entry, in others it's wrong stock levels generating cancellations and refunds. Build that piece, put it into use, and watch what happens for two weeks before adding the rest.

There's a practical advantage: the first piece, in real use, already tells you whether the two machines understand each other. If there are surprises — and there are — they arrive on one front only.

Where it breaks

Integrations don't fail on the hard part, they fail on the details:

• product codes that differ between the two systems, sometimes by one extra space;
• variants that are size and colour online and three separate items in the business system;
• partial orders, returns and credit notes, which the «order → document» flow never anticipated;
• the order that arrives twice because the first attempt succeeded but the response got lost.

The last one deserves a rule of its own: every write has to be repeatable without duplicating anything. Without that property, sooner or later the link creates a duplicate document, and you find out from accounting.

When it isn't worth it

If you get ten orders a week and enter them in twenty minutes on a Friday, an integration doesn't pay for itself: it costs more than the hours it saves, and it adds one more thing that can break. The point where it becomes worth it is when the retyping is daily, or when the mistakes — not the time — have started to cost money.