ERP eCommerce Integration: What to Sync and What to Leave Alone

Why does ERP eCommerce integration fail on scope rather than technology?

The connectors work. NetSuite, Microsoft Dynamics and QuickBooks all have mature APIs, and any competent integration team can move a record from one system to another.
What fails is the decision about which records should move at all.

Gartner names scope deviation and misalignment with business needs among the recurring causes of enterprise resource planning failure, and the same pattern shows up in smaller integration projects. Failure rates are widely reported in the 55% to 75% range. Very few of those projects failed because an API call did not work.

 The scope trap

Someone asks which systems should be connected. The answer sounds obvious: all of them, in both directions, kept current.

That answer creates three problems at once.

• Every synced field is a field that can go stale. A value copied from one system to another is only as fresh as the last run. You have not eliminated a delay. You have added one.
• Bidirectional sync creates ownership fights. If your ERP can write a price to the store and the store can write one back, the last system to run wins. Not the correct system. The last one.
• Volume hides failure. A sync moving 400 fields will fail on a handful and keep running. Nobody notices until a customer does.

To be fair to the “connect everything” instinct, it comes from a real place. Resellers have spent years retyping the same order into three systems, and the instinct is to stop that permanently. The goal is right. The scope is not. That is also why the business case for integrating at all, which is well established for resellers, gets mistaken for a mandate to connect every field in sight.

What four questions decide every field you sync?

Take one field. Customer credit limit, say, or order status, or unit cost. Answer four questions before you write a line of integration code.

• Which system creates this value? That system owns it. Everything else reads a copy. Credit limits are created in finance, so the ERP owns them. Cart contents are created on the storefront, so the store owns them. Ownership is not a preference. It follows the point of creation.
• Which direction does it move? One-way, from owner to reader, unless you can name a specific business reason for the return trip. Most bidirectional sync is one-way sync that nobody was willing to argue about.
• How fresh does it need to be? Not “real time” as a default. Ask what breaks at each delay. A customer address that is four hours old breaks nothing. Availability that is four hours old sells stock you do not have.
• What happens when it fails? This is the question teams skip, and it decides whether a failed sync is an inconvenience or a lost order. Should the store block the transaction, show the last known value, or fall back to a live lookup? Decide it now, in writing, per field.

Run those four questions across your field list and the list shortens on its own. Most fields fail question two.

What the docking stations cost

Forty units at roughly $280 each is about $11,200 of hardware, and at the 5% to 15% band typical of hardware resale, that deal carries somewhere near $900 of margin. Twelve shipped Wednesday. The rest went on backorder for nine days. The customer canceled the balance and bought the remainder elsewhere.

Nobody made a mistake. The sync ran exactly as designed. The design routed live distributor data through a system that updates once a night.

Note which question would have caught it. Not the first one, because everybody agrees the distributor owns availability. It was question three. Somebody assumed nightly was fresh enough because it always had been in accounting, where nightly is fine.

What should you sync, and what should you leave alone?

Two lists. The second one matters more, because nobody writes it.