Order dressing
Translate commercial orders into producible production orders — grade mapping, dimension tolerances, over/under delivery rules, route selection.
Modular. Multi-tenant. Deployed per customer as a versioned unit. Covering steel, aluminium, copper and special alloys from charge to despatch — on a PostgreSQL stack with no database licence attached.
DigiPlantMES owns the execution layer: what is being made right now, from what, to which specification, and what happened to it. It does not pretend to be your ERP, and it does not try to replace your L2 process models.
That boundary is deliberate. The programmes that go badly are usually the ones where an MES quietly absorbed order management or setup calculation because it was easier than integrating properly. We integrate properly.
Every piece of material carries its full ancestry — charge lots, heat, chemistry, cast, reheat, rolling, coating, cut — and every quality record hangs off the node it belongs to.
When a customer calls in fourteen months' time about a coil that failed a bend test, you need to know which heat it came from, which other coils shared that heat, where they went, and whether the same caster sequence produced anything else at risk. In DigiPlantMES that is one query, not a week of spreadsheets.
From a raw material lot to every finished piece and customer it reached.
From a complaint back to charge composition, process actuals and operator.
Cuts, re-coils, re-melts and blends modelled properly — not as a comment field.
Mill test certificates generated from the same data, not re-keyed from it.
Modular is not a marketing word here — modules are separately licensable and separately deployable. Start with tracking and genealogy on one line if that is all the appetite you have.
Translate commercial orders into producible production orders — grade mapping, dimension tolerances, over/under delivery rules, route selection.
Real-time position and state of every heat, slab, billet, coil, plate and bundle across the route, driven by L2 events and manual confirmations.
The full ancestry model — splits, merges, re-melts and re-work, with every quality record attached to the right node.
Internal specs, customer specs, test plans, sampling, dispositioning and non-conformance handling with proper approval trails.
Thirteen rule models covering practice selection, routing, disposition and alerting — configured by your engineers, not by a change request.
Stockyard layout, stacking rules, coil pyramids, crane moves and pick strategy — rendered in 3D so the constraint is visible, not implied.
Kafka and Celery under the hood, with configurable XML/JSON field mapping, replay and a readable dead-letter queue.
OPC-UA, EtherNet/IP and Modbus tag definitions managed centrally, so a new gauge is a configuration change, not a project.
Shift patterns, crew assignment, handover notes and shift reporting that ties production back to the people who made it.
Aggregated transposed views give planners fast, wide reporting over deep production data without hand-written SQL.
A retrieval assistant over your own production data — 370 pre-built queries across nine sections, so a planner can ask instead of filtering.
Melt shop, caster, hot mill, cold mill, finishing and forging schedulers. See the suite
Every one of these was made against a ten-year plant lifecycle, not a demo.
A service-based architecture deployed as one versioned unit per customer. A mid-size mill should not need a platform team to run their MES — and a broken service mesh at 03:00 is not a fair trade for architectural fashion.
215+ tables across 19 apps, with no Oracle licence in the total cost. For a mid-market producer this is often the single line item that moves a project from "impossible" to "approvable".
Our MES-GRID renders 50,000 rows in under two seconds and is embedded inside React rather than replaced by it. Planners live in grids; the grid has to be quick or the system is not used.
Liquibase layered over Django migrations, so a customer three releases behind can still be upgraded predictably instead of manually.
Multi-tenant in the data model, but deployable per customer on your own infrastructure or in your own cloud tenancy. Plant data does not have to leave your boundary.
Semantic versioning, a release-train branching model and per-customer release management — so upgrades are routine rather than an annual crisis.
We would rather tell you this now than in month nine of an implementation.
We are selecting a small number of design partners to build DigiPlantMES against real operations rather than assumptions. You get the product on terms that will not exist again; we get a reference and a reality check.
For the first three customers, scaled to the reference commitment you make.
Every release on the train, at no additional licence cost.
Continuity protection, so a mid-size supplier is never a single point of failure.