Service 02 of 04
Integration and automation
We connect the systems your business already runs, set up EDI with your trading partners, and automate the steps people currently do by hand between systems. Each interface and each automation is specified in writing, tested against agreed cases, and handed over with a runbook your people can follow.
Who it is for
- A business whose customers now require EDI (for example ORDERS, ORDRSP, DESADV) and whose ERP was never set up for it.
- Operations teams re-keying the same data into two systems, with the errors and delays that come with it.
- A business that has bought or merged with another and needs two sets of systems to exchange orders, stock or invoices.
- IT teams with interfaces nobody fully understands any more, where the next change is the one that could break month-end.
What it covers
- Interfaces between systems: ERP, WMS, CRM, EPOS, finance and bespoke systems, by API where there is one and by file, database or scheduled export where there is not.
- EDI: message mapping, trading-partner onboarding and conformance testing, working with your EDI hub or VAN provider.
- Rule-based automation: scheduled jobs, validation and exception queues, barcode and scanning steps, document generation (dispatch notes, labels, confirmations), and audit trails that record who did what and when.
The boundary. If a step needs a model to read, decide or write (reading free-text emails, classifying documents, drafting replies), that part is AI, and Industrial™ does not provide it. AI UVD, the applied-AI practice I founded, provides it under its own terms: https://aiuvd.com/
What you get
- an interface specification for each interface: what moves, when, in which format, and what happens when it fails
- the built interfaces and automations, tested against agreed cases, including the failure cases
- alerting that tells a named person when something fails, rather than finding out when a customer chases
- a runbook for each: how to check it, rerun it and recover it
- a recorded handover to the people who will support it
What you don't get
- An automation of a broken step. If the step is wrong, it is fixed or dropped first, in writing. Automating it only makes the errors arrive faster.
- Licences resold at a mark-up. Third-party licences, EDI hub fees and hardware bought for you are shown separately at cost, agreed in writing in advance.
- Changes inside your ERP vendor's code where your contract with them says only they may make them. We design the change and coordinate them to build it.
- AI. See the boundary above.
How it runs
Scope. From a solution pack (/architecture-and-design-authority/), or a short scoping milestone at the start of the statement of work if the change is already well understood.
Specify. Each interface and automation written up and agreed before it is built.
Build and test. Against a test copy of your systems or your partners' conformance environments, never first against live.
Parallel run. Where the change replaces a manual step, the manual route stays available until an agreed number of clean runs.
Handover. Runbook, recorded walkthrough and a named owner on your side.
What we need from you
- A named owner for each system the interface touches, and your ERP or WMS support partner's contact if you have one.
- Test environments, or agreement on how testing will be done safely without them.
- Your trading partners' EDI specifications and test contacts.
- The people who do the manual step today, for an hour or two, so the exceptions are found before anything is built.
What can go wrong
| What can go wrong | What we do about it |
|---|---|
| The current interfaces are undocumented | What we do about itFound in discovery and priced as a gap, not guessed |
| Your system has no API | What we do about itWe use what it has: a scheduled export, a file drop or a database view. The trade-off (for example, hourly rather than immediate) is written into the specification. |
| A trading partner changes its message format mid-project | What we do about itTheir change is logged with an owner and a date on the plan, and priced if it adds work |
| Your ERP vendor will not give access or make a change | What we do about itNamed as a risk in the decision note, with an alternative option |
| The manual process has exceptions nobody mentioned | What we do about itWalked through with the people who do the work before anything is built |
| A failure goes unnoticed | What we do about itEvery interface has alerting to a named person and a documented rerun |
Tools
We choose the tools from what your systems already run, not from what we prefer.
Price
| Form | Pricing basis | Price |
|---|---|---|
| Delivery of the whole | Pricing basisFixed price or priced milestones, set after the solution pack or scoping milestone. Third-party costs shown separately at cost. | PriceQuoted after the solution pack |
| Hosted service (for interfaces that need someone accountable for running them) | Pricing basisSetup fee plus subscription | PriceSetup from £4,000; subscription from £800 a month |
Prices exclude VAT. Terms: /engagements/.
Why the price is what it is: it is a price for the outcome, tested interfaces running by an agreed date, not for the hours it takes. AI agents I direct draft the mappings, the test cases and the runbooks under my review, so fewer engineering hours go into each deliverable and you reach go-live sooner. They never touch your live systems or credentials. How it works: /how-we-work/.
If it isn't in the statement of work, it's a change request, and it's priced before it's built.
Every engagement is architected by me, and I'm the person you deal with.
We take on a small number of clients at a time.