A mid-sized fragrance manufacturer let us walk its shop floor before deciding what to build next. It wasn’t a lack of data, and it certainly wasn’t short of tools - a dozen of them, a wall of Power BI reports, and a stalled attempt to weld them all behind one single screen. It looked like a front-end project. It was a data-integration problem that no clever interface could hide.
In Brief
- A mid-sized fragrance manufacturer had a dozen tools and a wall of Power BI reports - plus a stalled attempt to weld them behind one screen.
- One simple question - “how many units are ready to ship right now?” - returned four different answers from ERP, MES, the line system and Power BI.
- A screen on top only reads the systems; it cannot invent a shared definition, so it inherits every disagreement beneath it.
- The fix was not a thirteenth tool above the twelve, but one governed layer beneath them: connect once; link, don’t copy; harmonise meaning.
The ambition
A landscape stacked one tool at a time
The company makes fragrance compounds and fills them across its own lines and a network of external packers. Over the years a tool had been added for almost every need - an ERP for orders and materials, an MES for the day-to-day, a line-performance system, quality and traceability systems, ticketing, and a wall of Power BI reports stacked on top. None of it was wrong. Each system was correct within its own job.
The stall appeared the moment they tried to deliver the “single view” the way it is usually attempted - from the top down, by building one more screen that would finally pull everything together.
Failure point #1
Solving fragmentation by adding one more thing on top
When you are running a dozen tools, the obvious move is a thirteenth that sits above them, reads everything, and shows it in one place. The role it is really being asked to play is not display - it is to invent, on the fly, the shared definition the systems beneath it never agreed on. And that is exactly the one thing a screen cannot do.
The point is easiest to see in a single, ordinary question:
One simple question, four honest answers
| System | What it reports |
|---|---|
| ERP (planning) | 4,500 planned , 0 confirmed |
| MES (released) | 4,120 released to the floor |
| Line-performance system | 3,880 actually off the line |
| Power BI “stock, v14” | 3,950 - retrieved 6 days ago |
“How many units of one product are ready to ship - right now?” A screen on top would faithfully show all four numbers. What it could not show is the one thing anyone asked for: a single figure they could trust. Four honest systems, four honest numbers - and no shared meaning underneath them.
A screen shows you data. It cannot agree with itself on your behalf.
Failure point #2
Shadow BI: the integration layer nobody chose
While the single interface stalled, the real integration layer had quietly become Power BI and the spreadsheets feeding it. Every new business question - output by packer, availability by line - meant another manual export, another hand-built join, another report nobody could fully trace. The company had never decided to make BI its integration layer. It had simply run out of other places to do the joining, so the work drifted into the one tool flexible enough to absorb it - and least able to be trusted with it.
Failure point #3
The blind spot a screen can’t paint in: the returnable asset
The most valuable object in the whole landscape had no system of its own: the returnable containers moving compound between the plant and its external packers. They carried real financial value and real risk, and they were tracked nowhere - reconstructed after the fact from delivery notes and memory. A screen can only show what a system already holds. It cannot model an object that no system was ever given. So the returnable asset stayed invisible, precisely because it needed a definition, not a dashboard.
The problem in one image
Ask a dozen people the time and photograph all twelve watches on one wall. You now have a beautiful single view - of twelve clocks that disagree. The wall did not make them agree. Only setting them to one shared source would.
The way out
Not a thirteenth tool. One layer beneath the twelve.
The answer is not another screen on top; it is one governed layer beneath the tools that already exist - the place where the shared definition finally lives:
- Connect once per system - not to each other. Every tool joins one shared layer instead of wiring point-to-point, so a new tool stops multiplying brittle interfaces.
- Agree the object; let each tool keep its own words. Define “one unit of product X” once; each system keeps its own wording, mapped to it.
- Link to the live source; never copy. Views reference data where it lives, so they cannot quietly drift the way a six-day-old export does.
- Model the things the tools can’t. The returnable asset becomes a first-class object with an owner, not a blind spot.
- Keep every tool; complement, don’t replace. ERP stays, MES stays, Power BI stays - now sitting on a foundation instead of on each other.
- Start with one question and one asset. Prove it on the number they already argue about; grow by need.
| The screen-first reflex | The foundation-first move | |
|---|---|---|
| Where the “single view” lives | On top, inside a new interface | Underneath, in a shared model |
| What it does with the sources | Aggregates copies, point-to-point | Connects each once, links to the live source |
| When a source changes | The view breaks | The link holds |
| A new business question | A new extraction or report | A new query on the same model |
| A reusable asset with no record | Stays invisible | Becomes a modelled object |
| BI / AI on top | Sits on sand | Sits on a foundation |
They didn’t need a thirteenth tool above the twelve. They needed one layer beneath them.
The lesson travels
Four signs your “single view” is being built in the wrong place
The pattern lives in any plant that grew its tools one at a time - chemicals, food and beverage, machinery, pharma. Four signs are worth looking for in your own landscape:
- Every new business question means a new extraction or report - never just another query.
- Your “single view” is a screen someone is building on top of everything - not a definition everyone shares underneath.
- You track what is easy to see, while the assets that carry real value go unmodelled.
- The thing you trust least is the “one more tool” that was supposed to solve everything.
Any one of these is a warning; all four together mean the single view is being built in the wrong place. Putting one governed layer beneath the tools - so a dozen honest systems finally share one honest meaning - is exactly what the boTec DataBridge is built to be.