One line. One expensive question. One proven cause.
We get the data out of your machines and tell you why that line stops, with the engineering behind it rather than a statistical association. Fixed scope, fixed duration, and everything we build stays with you.
You already know which line we mean
The line that stops
It goes down for no clear reason, and usually at the worst possible moment.
The reject rate
It climbs after a product changeover, and nobody can say precisely why.
The seasonal machine
It behaves differently in summer than in winter. Everyone knows. It has never been quantified.
The theory nobody tested
Everyone has a suspicion. Nobody has ever demonstrated it, so nothing changes.
There is almost nobody in the middle
Inside your organisation
- Your people have no time. The line has to run.
- The data is there, but nobody ever gets a clear run at it.
- Every investigation ends with "let us keep an eye on it".
Out in the market
- IT firms want to build a data platform first, and talk in years.
- Sensor vendors sell a box that answers only its own questions.
- Your systems integrator knows the machine but does not do analysis.
We deliver a cause, not a correlation.What makes the difference between a finding and a fix
A model that says "when A rises, B often breaks" is a guess with numbers attached. We keep going until there is a technical explanation your own engineers can repeat back, because that is the point at which it becomes something you can act on rather than something you can only watch.
Why does line 2 stop?
24 unplanned stops a year
More than 58 hours of downtime, spread across the year with no obvious pattern anyone had been able to name.
Everyone said gearbox
A worn gearbox was the shared theory, and it was a reasonable one. It was also wrong, and replacing it would have cost a great deal and changed nothing.
A shared cooling circuit
Oil temperature climbed hours in advance, and mostly on days when line 3 was running. Line 3 shares the cooling circuit, and when it runs the cooling water arrives 5.4 degrees warmer. The gearbox could no longer shed its heat and tripped on thermal protection. Five of six stops fell on such days.
The fix was not a sensor and not an algorithm
It was moving the line 3 campaign two hours. That is what a cause buys you that a correlation does not: something specific enough to change.
Simulated data, used to illustrate the method. The approach is real, the company is not. We would rather show you the shape of the work honestly than dress up a case we are not free to describe.
Six steps, one bounded question
A fixed duration, running from the moment the data becomes available. One line, one clearly defined question.
- 1. Kick-off
- Half a day on site with production, maintenance and quality together. This is where the question gets sharpened, and it matters more than any other step.
- 2. Unlock the data
- A connection to your control system, historian or MES. The export is validated for completeness and for units, which is where a surprising number of investigations quietly go wrong.
- 3. Clean
- Gaps, outliers, downtime periods and product changeovers identified and linked. Roughly a third of the work, and it is inside the agreed scope.
- 4. Analyse
- Find the pattern, find the cause, build the model and test it on a period the model has never seen. Not on randomly split data, which leaks badly with time series.
- 5. Physical interpretation
- Does the relationship hold up technically? Without a mechanism there is no conclusion, and we would report that rather than dress a correlation up as an answer.
- 6. Handover
- Dashboard, report and a session with your own people, not only with the management team.
All of it yours, whichever way the answer goes
A working data connection
From your control system, historian or MES to usable data. Repeatable, documented, and yours.
The answer to one expensive question
Supported by the data and by the technical explanation behind it.
A dashboard
One screen showing the findings and the measurements that genuinely matter, rather than everything that can be plotted.
A recommendation and a roadmap
What should happen now, and what the next few applications would be worth.
Everything we deliver is yours: the connection, the dashboard, the report and the underlying scripts. We retain only the right to reapply our own generic methods elsewhere.
One technical contact is the critical condition
- Data access
- Or someone who can make the export for us. Six months to a year of history is ideal.
- Fault and maintenance records
- Over the same period, even if they are incomplete. Incomplete is normal and we work with it.
- Order, recipe or shift data
- So that product changeovers can be separated out rather than showing up as unexplained noise.
- One technical contact
- Roughly four hours a week, and access to the line for the first visit. Without that person we deliver statistics instead of an explanation, which is why we treat it as a condition rather than a preference.
The questions that always come up
Our data is a mess.
That is the normal situation. We have never seen a dataset that was ready. Missing values, wrong timestamps, wrong units and unmarked downtime periods are daily work for us, and roughly a third of the engagement goes on cleaning, inside the agreed scope.
What is genuinely a problem is data stored too coarsely. Many historians only record on change, with a dead band of a couple of percent, so a fast phenomenon such as a two-hundred-millisecond current spike is gone before we start. That is why we ask for four weeks of raw data up front, and if it is too coarse we say so before quoting.
We have no historian, only a PLC.
Then we read the control system directly, over OPC-UA or a read-only connection, and there is often more in there than people expect. A simple export from your MES or your maintenance system also gets us a long way.
If there really is no usable history, an analysis of existing data cannot succeed and we would rather not sell you one. In that case the starting point is measurement: we place our own temporary sensors, which most data firms cannot do, but that is a different project with its own steps and its own decision.
How does this work with our IT and our security rules?
We only read. We write nothing to your control system and change nothing in your process. Read-only network access is our preference; otherwise a periodic export on a disk is entirely workable.
We sign a non-disclosure agreement and a data processing agreement, and your IT department receives a single page up front stating exactly which access we are asking for and why. In practice IT is the first gatekeeper, and we would rather make that conversation easy than difficult.
How do we know your conclusion is correct?
Every model is tested on a period it has never seen, not on randomly split data, which leaks badly with time series. We check that the relationship we find is physically explainable, because without a mechanism it is not a conclusion. A second person here tries to break the finding before you ever see it. And we are explicit about uncertainty, because an honest range is more useful than false precision.
A result that looks too good is usually wrong. We go looking for that ourselves rather than waiting for you to find it.
We already have a MES or SCADA supplier.
Good. We replace nobody and we sell no competing system. They make sure the data is recorded; we use it to answer one expensive question. We work with them happily, because they usually know exactly where the data lives. And if their system can already answer your question, we will tell you, and you will not need to hire us.
What if nothing comes out of it?
It can happen. Then you hear from us why it did not work and what would be needed to find the answer. A well-founded conclusion that the assumed cause is demonstrably not the cause is also an answer, and it saves you from a wrong investment.
If the data genuinely cannot carry the question, we use the remaining time to establish what would have to be measured instead. What we will not do is hand over "we still do not know" and call it a result.
Why would we not do this ourselves?
If you have the people and the time, do it yourselves. We mean that seriously.
In practice the bottleneck is not knowledge but attention: your people get pulled back to the line every day. We bring undivided attention for a fixed period and a method we have applied many times, and we leave the connection and the dashboard behind so that next time you can do it yourselves.
What about scaling to more lines?
The second line is cheaper than the first, because the connection and the knowledge are already in place. We scope per line so you can decide step by step rather than sign for everything up front. For ongoing monitoring and model maintenance there is a separate arrangement, but that is a conversation for after the first engagement has produced something.
Which line costs you the most money right now?
Send us four weeks of raw data from it, plus your fault records over a longer period. Within a week you get an honest verdict: is the answer in there, and if so, which question would we investigate? That costs you an hour of work and nothing else.
