Service · Stage 2 · Industry

Your machines tell you when they will fail. So far nobody is listening.

Predictive maintenance for companies with 5 to 250 employees, laid over your existing assets, without a new platform: detect the signal, create a maintenance work order in the ERP, measure whether the downtime was avoided.

Discuss assets for a pilot How we go about it

Free of charge and without obligation.

Servers in Germany · AI advises, a human decides · Transparency under the EU AI Act

Fig. 01: From the signal to the completed task. We do not intervene in the controller.

Does this sound familiar?

Unplanned downtime costs you a five-figure sum per day, in production, refrigeration or conveyor systems. Maintenance still runs by the calendar, not by condition.
Your assets have sensors and a controller. The data ends up on a display at the machine or in a manufacturer’s cloud. None of it reaches your ERP.
You have seen offers for predictive maintenance platforms: a licence per sensor, a dashboard of their own, a data science team. For 20 assets, a project the size of one for 2,000.
A pilot showed that the algorithm detects anomalies. But nobody ever turned that into a maintenance work order. The pilot is over, the downtime is not.

Why

Why predictive maintenance projects fail and where our work lies

Not because of the algorithm. A BearingPoint study (2021) of 203 companies from Germany, Austria and Switzerland shows that only 4 per cent already fully exploit the potential of predictive maintenance. Companies now rate the technical hurdles as lower. The data is not accessible, nobody knows how much downtime there was before, the alarm does not reach the maintenance technician as a work order, and after the pilot nobody is responsible.

That is exactly where our work lies. We do not build another platform; there are enough of those. We build the last mile: from the anomaly to the prioritised maintenance work order in your ERP, to execution, to the record. That is the stretch where the benefit arises. Here too: logic first, then technology. → How we work

Approach

How a predictive maintenance pilot comes about: from the baseline to the measured result

Measure the baseline (2–4 weeks).
Which assets are critical? How often were they down in the last twelve months, for how long, and what did it cost? Without this number there is no measured result, and without a measured result there is no pilot with us.
Open up the data.
Controller (OPC UA, Modbus), manufacturer’s cloud, existing condition monitoring or retrofitting individual assets with sensors. We do not buy a sensor network if three measuring points are enough.
Define the logic.
Which signal triggers what? Who gets the work order, with what priority, in what time window? What happens if the maintenance technician disagrees? This is maintenance knowledge your people have. We write it down, you sign it off.
Close the cycle (pilot, 5–10 assets, 3–6 months).
From the anomaly to the maintenance work order in the ERP, to execution with a completion report and to recording whether the failure was avoided. The AI suggests and prioritises. Your maintenance technician makes the decision. We do not intervene in the controller.
Prove and expand.
After the pilot: downtime hours before and after, failures avoided, maintenance costs. If the number is right, we expand. If it is not, you know within a few months, with a number instead of a guess.

Result

What runs at your company in the end: baseline, models and the closed cycle

A baseline in numbers that has value even without us.
Connection of your existing assets and systems, no tie to one manufacturer, no platform obligation.
AI models for anomaly detection and, with a sufficient failure history, also for a remaining-life forecast, tuned to your assets.
The closed cycle in your ERP: work order, priority, execution, record.
A clear boundary: advice and suggestions, no intervention in the controller or safety functions. This is set out in the contract.
Ongoing operation and model maintenance, if you wish.

Example scenario

What a pilot looks like

Illustrative scenario, not a customer project, no customer data.

A manufacturing company with twenty assets, three of them critical: if one fails, the line stops. The controller supplies temperature and current, and a vibration sensor is retrofitted to one asset. Twelve months of downtime history are gathered from shift logs and the ERP. That is the baseline.

The logic: if the deviation exceeds the agreed threshold on two consecutive shifts, a maintenance work order with priority and deadline is created in the ERP. The maintenance technician accepts, postpones or rejects it, with one click, not with a form. After six months, two numbers sit side by side: downtime hours before, downtime hours after.

Tools

What we work with: systems, assets and interfaces

For assets: OPC UA, Modbus, MQTT, manufacturers’ clouds, edge devices, retrofit sensors. For work orders and maintenance: Odoo, Bitrix24, SAP Business One, HubSpot or custom development. We use whatever solves your task, tied to no vendor.

Who it is for

Who a pilot pays off for

Companies with 5 to 250 employees: manufacturers, food businesses with refrigeration and conveyor systems, logistics businesses with conveyor installations. Typically 5 to 50 assets, some of which are critical: if one stops, it costs noticeable money. Ideal if sensors or a controller are already in place and nothing is being made of the data.

Typical industries

Manufacturing & mechanical engineering · Food & logistics

Our systems advise and prioritise. Our part intervenes neither in the controller nor in safety functions and therefore does not affect the CE conformity of your machine (manufacturer’s declaration). AI identifies itself as AI. → AI transparency

Where we know the cycle from, without customer names

We are currently building the cycle ‘signal, task in the ERP, execution, record’. Parts of it run today, with scales, printers and scanners as signal sources. Predictive maintenance is the same cycle with different sensors. → AI integration & process automation
Devices connected via their protocol, for example industrial scales whose reading is posted directly in the system: the same kind of connection an asset needs for predictive maintenance.
To be honest: we have not yet completed a predictive maintenance pilot in industry. We are looking for pilot partners for the first one. We discuss the terms in the first call.

→ Why we don’t name customers

Typical starting situations for predictive maintenance

Example scenarios, sorted by type of asset. The industry is only an example in each case.

Production or maintenance, for example mechanical engineering. The controller shows the machine’s states on the machine, the ERP knows the orders, and the foreman brings the two together on paper. We connect them and turn the anomaly into a work order. → Manufacturing & mechanical engineering

Cold chain or conveyor systems, for example a food business. Refrigeration units and conveyor belts whose failure destroys goods. A signal from the asset, a maintenance work order in the system, before the cooling fails. → Food & logistics

Logistics or conveyor installations, for example a warehouse operation. Conveyor installations with a controller, but without a connection to the order system. Three measuring points, one work order, one number before and after.

Your process is different? That is exactly where we start. → First call

Frequently asked questions about predictive maintenance

What do you measure before and after the pilot, and why is there no start without a baseline?

We measure downtime hours, the number of unplanned failures and the maintenance costs of the last twelve months. Without this number, there is no way to say after the pilot whether it had an effect.

Do we need new sensors, or are the controller and the manufacturer’s cloud enough?

What is already there is usually enough: controller, manufacturer’s cloud, existing monitoring. Where there is nothing, individual measuring points are retrofitted: vibration, temperature, current.

Do you intervene in the machine controller?

No. We read data and write work orders. The controller, emergency stop and safety circuits stay with the manufacturer. This is set out in the contract.

How long does a pilot on 5 to 10 assets take?

Three to six months after the baseline, because assets need time to show failures. Before that, 2–4 weeks go into establishing the baseline.

Is it worthwhile with 20 assets, or only with 200?

A pilot is already worthwhile with 20 assets if three of them are critical and a day of downtime costs a five-figure sum. We do the calculation in the first call, with your numbers.

Have you already completed a pilot like this?

Not in industry yet. We are currently building the cycle behind it; parts of it already run with other signal sources. We are looking for pilot partners for the first industrial pilot.

What the price of a pilot depends on: → Pricing & pilot models

Become a pilot partner (we discuss the terms in the first call): → Future Lab

→ All questions

Next step

Name the three assets whose failure costs you the most

In the first call, we estimate whether a pilot is worthwhile and what it means compared with a day of downtime.

First call about your assets Become a pilot partner Or call us directly: +49 3301 8673990

We discuss the terms in the first call.

30 minutes, one process from your daily work, no presentation.

Whether we connect your existing monitoring or retrofit sensors, whether we integrate into your ERP or build a lean application: your assets and your numbers decide, not a platform contract.

If no system manages your orders yet: → CRM & ERP with AI

If the logic is later to sit above machines and robots as well: → AI for machines & robotics

This page is one of five entry points: → All services: AI consulting for SMEs

Your machines tell you when they will fail. So far nobody is listening.

Does this sound familiar?

Why predictive maintenance projects fail and where our work lies

How a predictive maintenance pilot comes about: from the baseline to the measured result

Measure the baseline (2–4 weeks).

Open up the data.

Define the logic.

Close the cycle (pilot, 5–10 assets, 3–6 months).

Prove and expand.