Every Crossing Between Your Systems Should Have an Owner. Here Is the Benchmark We Would Set.
A retailer's systems are joined by timed files, scripts and people that nobody has listed. Here is the benchmark we would set for those crossings, and the path from a full list to the parts that must share, rebuilt and proven.
On Tuesday morning the website is showing yesterday’s prices. A promotion that should have started at midnight has not.
It takes until eleven to find out why. A small program copies prices from the accounts to the website every night. Last night it stopped, because someone renamed a column in a spreadsheet it reads on the way. It has run on a machine under a desk for seven years. The person who wrote it left in the third.
Nobody knew it existed until it failed.
The paradox: The systems are connected after all, by things the business does not know it owns and could not list.
What We Found
We looked for public evidence on how retail systems are joined when they are not fully integrated, and on what retailers say it costs.
Most brands that sell direct are not yet joined up. In a survey of more than 100 senior retail and brand leaders in the UK, “Among direct-to-consumer brands, 70% said their core systems were not yet fully integrated”. The survey was paid for by firms that sell to retailers.
Retailers say it affects the business. In the same survey, “Some 56% of retailers said fragmented systems were affecting profitability and customer experience”.
What an old system cannot show. A group the source calls a “retail and hospitality giant” said of the time before it replaced a ten-year-old in-house portal: “Before, we didn’t have access to real-time data visibility.” This is an older case, from 2023, about a large group.
Old technology is said to hold mid-size firms back. In a vendor-sponsored survey of 200 leaders at US and UK manufacturers, retailers and wholesalers with revenue between 25 million and 500 million US dollars, 72% agreed that outdated technology is holding them back.
A system that is “not yet fully integrated” is still joined by something. This article is about that something.
What our review does not show: We found no public evidence at all on scripts, timed files or spreadsheets as the joins between retail systems: no count, no case, no cost. Everything this article says about them is our reasoning, and the Tuesday morning is imagined. Both surveys were paid for by firms with something to sell. We found no named mid-size retailer with this problem, and nothing from India or the Middle East. The large group’s source gives no country.
What a Full List of Crossings Opens Up
A list of the places where data crosses between systems is usually seen as the technology team’s homework. Our reading is that it frees more than that team.
- Failures get an owner. A stopped file becomes someone’s job before it becomes the warehouse’s problem or a marketing error.
- Change becomes possible. A crossing that is written down can be altered when a system is updated. An unknown one can only be avoided, along with everything it touches.
- The hand-offs get counted. The copying that staff do between screens is real work. Once it is listed, it can be reduced stage by stage, and the people doing it move from copying to checking.
- Rules come into the light. A crossing rarely just copies: it rounds, skips, converts. Once written down, those rules can be kept, corrected or retired by the business.
The gap we see: most retailers know their systems are joined by something. Few can list every crossing, name its owner and say which ones are done by hand. The difference between that and a business that can change one system without breaking another is a written list, with an owner beside every line.
This is our reading. It is not a measured market figure.
Three Ways to Look After the Crossings, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Fix each crossing when it fails | There are few crossings, and the people who made them are still there | Each failure is found by its effects. Each repair adds one more rule nobody wrote down |
| Put a connection layer across the systems, bought from a supplier or built for you, and move the crossings onto it | The crossings are already known, and the systems at each end are sound | The crossings nobody listed are not moved, and keep running beside it. Someone must run and watch the layer |
| List every crossing, give each an owner, and rebuild the parts that must share, module by module | The systems are old and used every day, and some crossings carry rules the business depends on | It takes stages and costs money before anything is joined. Some crossings will be missed until they fail |
Our recommendation: list every crossing first, including those done by hand, timed files and scripts, and give each one an owner on your side. Then rebuild the parts of your own software that must share, module by module, while the old system keeps running, with each rebuilt part proven against the old one. If you also want a connection layer, that is your choice and another firm’s product, and the list is what it needs. We have no connection or integration product. We do not run or monitor a connection, and we cannot change a packaged product that belongs to another supplier.
Where You Are Now, and Where You Should Be
This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Crossings between systems, including those done by hand, timed files and scripts | Known in parts, to the people who do them | Every one listed, with what it carries, from where to where and how often | The map of the system as it stands |
| An owner for each crossing | Nobody, or whoever set it up | A named owner on your side for every crossing | The list beside the specification |
| Crossings done by hand | Not counted | Counted, and falling stage by stage | Reported at every review |
| The rules each crossing applies | Known only to the code or the person | Written in plain words, each marked keep, correct or retire by the business | The specification |
| The parts that must share | Waiting on a replacement | Rebuilt module by module, each proven against the old part | The traceability matrix |
The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.
A small part of the finished list might look like this.
| Crossing | Carried by | Owner | Status |
|---|---|---|---|
| Prices from the accounts to the website | A nightly script on a spare machine | Head of e-commerce | Its rules written down; the pricing part rebuilt and accepted in stage 1 |
| Store sales to the stock system | A timed file, once a night | Head of operations | Listed; in the stage 2 plan |
| Trade orders into the accounts | Two people re-typing from a printout | Finance controller | Counted; the order part rebuilt in stage 3, the two people now checking exceptions |
The rows above are an illustration, not taken from a real business.
How We Work With You, and What You Are Left With
- We listen: a free Reliability Review. A first conversation about your systems, the crossings you know about, and the last one that failed. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the software your firm built or had built, and the places where it meets your other systems. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the parts that must share, rebuilt first. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
This has a price. Finding the crossings takes patience, and some will be missed until they fail. Crossings done by hand appear in no code, so only your staff can point to them; they are the finding, never the fault. Writing down the rules will turn up some that nobody can explain and some that are wrong, and each needs a decision from the business. We have no connection or integration product. We do not run, host or monitor the crossings or the rebuilt parts; your own team does, and the owner on each line is someone on your side. We cannot change another supplier’s packaged product; where one sits at the end of a crossing, we can describe what goes in and out of it, and if it changes, the crossing must be changed too. None of this makes several systems into one. We have no published case of this work for a retailer.
At the end you hold the list of crossings with an owner beside each, the specification, the traceability matrix for every module we rebuilt, the code of those modules, and the filled-in benchmark.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The business no longer rests on scripts that one former employee wrote. |
| CTO or CIO | Each crossing is written down with an owner, and every rebuilt part is proven against the old one, so a change to one system no longer breaks another unseen. |
| CFO | Fewer month-end corrections traced to a file nobody knew about. |
| COO | Every crossing the warehouse depends on is on a list with an owner, so a stopped file is someone’s job before it is the warehouse’s problem. |
| Head of marketing | What shoppers are shown, in stock and in price, comes from crossings the business knows it has. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| In a UK survey, 70% of direct-to-consumer brands said their core systems were not yet fully integrated. | We have no connection product. We list the crossings a retailer’s systems already depend on, including those done by hand, and rebuild the retailer’s own parts that must share, module by module. |
| A large retail and hospitality group said that before replacing its in-house portal, “we didn’t have access to real-time data visibility”. | Our part is narrower than this case, and the group was not an IOanyT client. We do not sell or implement a replacement product. For a retailer’s own software, the list and the specification show where each figure comes from and how late it arrives. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next time a crossing stops, the business should already know it exists and who owns it.