Platform & SaaS · 2026
Equipment lifecycle management — one asset record, three operating lines
Equipment registry plus the three lines that hang off it — inspection, repair and fault — with four families of statistics that cut across device, department, area and time, and drill down to a single asset.
The situation
Equipment-dense sites — manufacturing floors, commercial kitchens, facilities with a few hundred assets — tend to run equipment management in four disconnected places. The asset list is a spreadsheet. Inspections are a paper form on a clipboard. Repair requests arrive by phone and live in a chat thread. Fault history lives in the heads of the two technicians who have been there longest.
The systems sold into this space usually start from the workflow: a repair ticket is a table row, an inspection is another table row, and each module keeps its own idea of what a device is. Six months later the site has three device lists that do not agree, and the only question management actually asks — which machine, in which department, in which period, is costing us — cannot be answered.
The call we made
The asset is the primary key of the whole system. Inspection tasks, repair work orders and fault records all hang off the device record rather than pointing at a device name. That is a data-modelling decision with a visible consequence: from any chart you can drill from category to department to a single machine and read its full history. It is also the slower way to build three modules, and the only way the statistics are worth looking at.
Statistics are designed as a question, not a listing. Four families, each cutting across dimensions:
- Fault statistics across device, department and time together — bar chart by device, pie by department, line by trend.
- Device count across classification, department, area and status, in both quantity and value.
- Inspection statistics in four states (new task, completed on time, overdue, completed overdue) with an attainment rate.
- Repair statistics across time, device, department, classification and request status.
The reason for one screen with three charts under one filter set is not visual. It is that answering “which department” and then “which device” by switching pages is how people stop using a reporting module and go back to Excel. Time granularity switches between day, week, month and quarter; every chart exports, because the weekly report is the real delivery target.
Inspection needs four states, not a completion rate. A single attainment number hides the difference between work completed on time and work completed after the deadline. A site manager can act on overdue counts by route and by team; a percentage tells them nothing they can schedule. So overdue is measured as a separate state, and an inspection exception can trigger an approval flow of its own.
Every state change is a record with a responsibility. Equipment moves through purchase, commissioning, transfer, maintenance, deactivation and scrap; repair moves through request, dispatch, repair and acceptance; fault moves through registration, classification, cause analysis and closure. Each step keeps a person and a timestamp. That is what makes the ledger auditable rather than decorative.
What we built
Eight modules around the asset record:
- Equipment ledger — base data, classification, location, responsible person, status, QR identity per device.
- Lifecycle — purchase, commissioning, transfer, maintenance, deactivation, scrap as one traceable history per asset.
- Inspection — plans, routes, task issue and execution results, including exception reporting.
- Repair — request, dispatch, process record, spare-parts consumption and acceptance.
- Fault — registration, classification statistics, cause analysis and closed-loop tracking.
- Workflow — configurable approvals for inspection exceptions, repair requests and scrap requests.
- Statistics and export — the four families above, multi-dimensional and exportable.
- Roles, organisation and audit — data-scope permissions, org structure, operation log.
The deployment is on-premise for sites that cannot send operational data outside their own network, and the interface set is deliberately ordinary: a maintenance supervisor should be able to use it after one handover session, not a training week.
Result
The site ends up with one equipment list that every module reads, inspection that produces a state rather than a form, repair that leaves a cost trail, and fault history that survives staff turnover. The question “which machine, which department, which period” is answerable inside the system, to the asset.
The honest limit: this is an operational system of record, not a predictive maintenance product. Nothing here forecasts a failure. What it does is make the failure history complete and comparable, which is the precondition for any later reliability work — and, in our experience, the part most sites are missing.
Technology
| Stack | Vue 3 · Element Plus · Spring Boot · MySQL · Redis · ECharts · Docker |
|---|---|
| Delivery model | On-premise B/S back office |
| Client | Manufacturing and commercial kitchen equipment fleets |
| Status | Delivered |
What we cannot show
No interface from this system is publishable yet: the four statistics screens referenced in the capability material are not available as assets, and the only candidate file in the asset library shows a radar installation, not this platform. The page therefore describes the modules by function only.
Similar problem?
If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.