One systemfor thewhole plant
MRP, procurement, inventory, quality and shop-floor analytics — running on the sensor data your equipment already speaks.
We reply within one business day. No commitment to see it run.
01 — The actual cost
The plant is
already paying for
the system it
doesn't have
Every workaround has a price. Most plants just never add it up.
- 01
Spreadsheets
MRP math done by hand in a workbook one broken formula away from a stockout, held together by whoever built it.
- 02
Legacy ERP
Six-figure licenses, an eighteen-month rollout, and a module fee for features that should be table stakes.
- 03
Point tools
A forecasting app that doesn't talk to inventory, that doesn't talk to the quality log — three logins to answer one question.
- 04
Tribal knowledge
The one planner who knows why the BOM is wrong leaves, and the plant finds out the expensive way.
- 05
Hardware lock-in
A dedicated OEE/downtime box that only does OEE/downtime, priced like it's the whole plant.
02 — Five modules, two tiers
Three modules
to run the plant.
Two to run
ahead of it
Core covers the floor as it runs today: what the machines are doing, why they stopped, what the plan needs. Premium adds the models that run ahead of it. See what a shift looks like with all five running, or how they share one data model.
- Core
OEE
OEE and SPC control charts, rolled up to a plant summary.
- Core
Downtime
Downtime Pareto and MTTR, compared shift against shift.
- Core
MRP
Revisioned recipes, netted-vs-gross explosion, build calculator.
- Premium
Predictive Maintenance
Machine risk scoring drives the maintenance schedule.
- Premium
Demand Forecasting
Moving average and exponential smoothing feed the plan directly.
One database.
One audit trailEvery module reads and writes the same data model — BOM, MRP, POs, lots, OEE and quality in one system, not five integrations.
Schedule a Demo
03 — The second system
Inventory that
reads the world
outside it
Not every operation is a plant. Inventory Analytics is a standalone, multi-industry app on its own AI-first data model — the same discipline about forecasting and traceability, without the shop-floor surface.
Demand doesn't start in your warehouse
It reads the WHO's Disease Outbreak News feed and Google Trends, then matches what it finds against your own catalog. A reported outbreak surfaces the medicine you actually stock; a trend spike surfaces the line it applies to.
It never places the order. Every signal arrives as a recommendation for a person to accept or ignore — and so does every write the chat assistant proposes, from a stock adjustment to a purchase order.
- 01WHO outbreak feed · Google Trends
- 02Matched against your catalog
- 03Surfaced as a recommendation
- 04A person confirms — or doesn't
Forecasts per item, not per catalog
Croston's method with the SBA bias correction for intermittent demand, Holt for trend, Holt-Winters where there's a season. The model is chosen per item from that item's own consumption history — a part that moves twice a quarter isn't fitted the same way as one that moves daily.
Reorder points that account for lead time
Safety stock and reorder points derived from the forecast and the variance in how long suppliers actually take. It drafts a purchase order per supplier off the result — and drafts stay drafts until a human confirms them.
Lots, recalls and cold chain
Per-item shelf life, first-expiry-first-out consumption, storage-condition fields, and recall genealogy that traces a lot back through the supply chain. Built for the tenants where that is the whole job — food, pharma, hospitals.
Valuation on a ledger models can read
FIFO, LIFO and weighted-average costing, aging and turnover — computed over an inventory transaction ledger that was designed from the start to be consumed by models, not just rendered in a table.
Built for
- Clothing
- Food
- Manufacturing
- Pharma
- Hospitals
Running a warehouse rather than a plant? Ask for the inventory demo — same twenty minutes, your own stock data.
04 — Why now
Equipment that
already speaks
the language
Modern manufacturing operations run OPC-UA and MQTT-capable equipment out of the box — which means live sensor ingestion works on day one, not after a multi-month PLC integration project. That's what makes predictive maintenance (CBM/RUL machine risk scoring) deliverable immediately instead of blocked on a hardware-connectivity gap.
Priced to undercut sensor-hardware-only tools on OEE and downtime alone — before you even get to the rest of the plant.
Live ingestion
- OPC-UAPLC data
- MQTTSensor telemetry
- HistorianTime-series
Time to first reading
- Typical PLC integration~18 months
- EvoWerkDay one
05 — No logos yet. Here's the proof instead
Security isn't
a feature. It's
the foundation
Every claim below is enforced somewhere you can check — a database trigger, a CI gate, a Terraform module — not a paragraph in a security questionnaire. More on tenant isolation and deployment in the FAQ.
- 01
Multi-tenant by design
org_id scoping is baked into every table from day one, not bolted on after the first customer complaint.
- 02
Runs in your infrastructure
Customer-hosted by design — the deployment lives in your cloud account, so EvoWerk never holds your production data and never sits in your uptime path.
- 03
Audit log enforced by the database
A Postgres trigger blocks UPDATE and DELETE on audit rows — insert-only holds even if the app layer has a bug.
- 04
MFA that fails safe
TOTP secrets encrypted at rest; re-enrollment requires a password, and the old factor never drops until the new one verifies.
- 05
Gated on every push
SAST, dependency scanning, secret scanning and container scanning all run in CI before code ships — not on a quarterly schedule.
06 — Show, don't dashboard
The shape of the
shop floor, not a
slide about it
Real OEE, downtime and machine-risk data — read live off the plant, not typed into a report once a week.
07 — Worked example
What a shift
looks like
before and after
A three-line plant, modelled end to end on the numbers shown elsewhere on this page.
This is an illustration, not a customer. EvoWerk has no named deployments to publish yet — when that changes, a real one replaces this. Until then we'd rather show the arithmetic than borrow someone else's logo. The security posture below is the part you can verify today.
Before — the patchwork
- OEE
- 83.4%
- MTTR
- 17.3 min
- Downtime / shift
- 3h 12m
- Time to answer "why did line 3 stop?"
- Next morning
After — one system
- OEE
- 87.3%
- MTTR
- 14.2 min
- Downtime / shift
- 2h 34m
- Time to answer "why did line 3 stop?"
- Same shift
- 01
The starting point
Three lines, a legacy ERP for finance, a separate OEE box on two of the three, and a workbook doing the MRP maths. Nobody could answer a downtime question without exporting from two systems first.
- 02
What changed
OPC-UA and MQTT feeds from equipment already capable of both, ingested on day one. BOMs and the netted-vs-gross explosion moved into the same database as the machine data, so the plan and the floor stopped disagreeing.
- 03
Where the gain came from
Not from running the machines harder. Changeover was the largest Pareto category, and it was only visible once downtime reasons were logged against the same shift boundaries the plan used.
Want this run on your numbers instead of ours? Book the twenty minutes — or read how the modules share one data model first.
08 — Questions we actually get
The five things
everyone asks
first
If yours isn't here, ask it directly — we reply within one business day.
01Where does EvoWerk run — your cloud or ours?
Yours. The deployment lives in your own AWS or Azure account, so EvoWerk never holds your production data and is never in your uptime path. That is the default, not a paid enterprise upgrade.
02What does it take to connect our equipment?
If your equipment speaks OPC-UA or MQTT — most modern lines do out of the box — live ingestion works on day one rather than after a multi-month PLC integration project. A historian feed works too where the time-series already exists.
03What is the difference between Core and Premium?
Core covers the floor as it runs today: OEE, downtime and MRP. Premium adds the models that run ahead of it — predictive maintenance from machine risk scoring, and demand forecasting that feeds the plan without a manual handoff.
04How do you handle security and tenant isolation?
org_id scoping is in every table from day one, the audit log is append-only enforced by a Postgres trigger rather than by application code, and MFA re-enrollment never drops the old factor until the new one verifies. SAST, dependency, secret and container scanning all gate every push.
05Do we have to replace our ERP to start?
No. There is no forklift migration and no six-figure commitment before you have seen it run. Most plants start with one line, one BOM, or one week of downtime data and keep the existing finance system in place.
Still deciding? Read the security posture, the worked example, or book a demo.
09 — Ready to see it in action?
Stop
picturing an
eighteen-month
project
No forklift migration, no six-figure commitment before you've seen it run. Bring your own data — one line, one BOM, or one week of downtime — and we'll show you the plan explosion on your numbers.
We reply within one business day.
Or write to sales@evowerk.io— and if you're still weighing it up, the five questions everyone asks are answered above.