Section §1
Executive summary
What the system does, who depends on it, what would break if it stopped.
1.1 The system
MES-Plus v6.4 is the integrated manufacturing and accounting platform on which a 180-person discrete-manufacturing business runs its daily operations. It has been in continuous service since 2008. The current version dates from a partial upgrade in 2017; no major version change has been delivered since.
The system covers, end-to-end:
- Quote → customer order → production planning → shop-floor execution → quality control → goods issue → invoicing → cash receipt
- Demand → MRP → purchase order → goods receipt → invoice match → supplier payment
- Master data: items (~14 000), bills of material (~3 200), routings (~1 800), customers (~600), suppliers (~280)
- Period-end financial close, cost rollup, GL posting, basic statutory reporting
It is the operational backbone. Sixteen of the company’s named business processes (out of nineteen documented) execute through it. The three that do not are payroll (separate vendor system), regulatory tax filing (handled in the accountant’s office), and CRM activities (managed in a spreadsheet workbook by the sales director).
1.2 What depends on it
The following operational facts hold today:
- 30 shop-floor terminals are MES-Plus clients. If MES-Plus is unavailable, production reporting cannot be captured. Operators continue to work — the alternative is paper backstop sheets, in use during quarterly maintenance windows — but the WIP picture goes blind for the duration.
- 8 office workstations in planning, procurement, accounting, and quality run MES-Plus continuously. Most users have it open as the first window of the day until the last window of the day.
- One nightly batch window (currently 22:30–02:00) executes inventory revaluation, MRP recalculation, cost rollup, and three integration-export jobs. If any of these fail silently, downstream dependencies (banking import the next morning, BI dashboard refresh, tax-aggregation report) inherit incorrect data.
- The single SQL database, ~340 GB, holds 17 years of operational history. Selective archival has been discussed annually since 2019 but never implemented because no team member is confident which historical rows are still referenced by which active process.
- The custom integration broker — a 2014-era .NET service running on the application server — moves data between MES-Plus and the company’s bank, customs portal, EDI partners (3 large customers), and BI export target. It is undocumented and has one person who understands its internals; that person retires in 2027.
1.3 What would break
If MES-Plus stopped — for any reason that prevented recovery within 4 hours — the following operational consequences would unfold during a typical Tuesday workday:
- ~120 production orders could not be released to the floor that day
- ~30 shop-floor workers would lose access to their work-instruction terminals; they would either work from yesterday’s printed travelers (where available) or stand idle
- The two morning shipping windows would miss their cut-off; ~€80–120k of customer orders scheduled to ship would slip by 24–48 hours
- Goods receipt for the day’s inbound deliveries would queue at the warehouse dock; reception would either refuse delivery (carrier penalties accrue) or accept paper-only and reconcile later (with known data-integrity risk)
- Period-end close, if the outage spanned month-end, would slip; statutory deadlines (VAT submission, intrastat) might miss legal cut-offs
Recovery from a 4-hour outage to fully reconciled state, based on the company’s 2024 outage-recovery exercise, took 11 working hours.
The system has not had a full disaster-recovery test since 2019. The documented RTO is 4 hours; the last successful tape-restore-to-running-state took 9 hours, in a controlled exercise.
1.4 Audit conclusions in two sentences
The system works, today, well enough to run the business. It is not failing. The risks identified in this audit are not “MES-Plus is broken” — they are “MES-Plus is increasingly fragile, in specific named ways, and the people who keep it running are either ageing out or were never replaced after the 2017 upgrade team disbanded.”
The audit’s purpose is not to recommend replacement. A full replacement would cost €450k–1.2M and take 18–36 months; it is the most expensive, slowest, and highest-risk of the available options, and not always the right one. The audit’s purpose is to make the current state, the trajectory, and the near-term decisions visible — so the leadership team can choose deliberately rather than react to an incident.
1.5 What this document contains
This document is a structured audit of MES-Plus v6.4, organised into 14 sections:
- §3–§10 describe what the system is — architecture, roles, journeys, data, processes, integrations, reporting, non-functional behaviour. This is the descriptive core: it makes the system visible as a single readable artifact rather than scattered tribal knowledge.
- §11 is the risk register — a concrete, prioritised list of operational, financial, and continuity risks observed in the audit. This is the highest-value section for a CFO.
- §12 is modernisation considerations — the audit’s findings mapped to four scopes of intervention (Patch, Mend, Retrofit, Restructure), so the leadership team can see the decision space without commitment.
- §2, §13, §14 cover scope, glossary, and methodology so the audit is reproducible and defensible.
A reader with three minutes should read this section and §11. A reader with thirty minutes should read this section, §3, §11, and §12. A reader who will commission the next phase of work should read all of it.
1.6 Sample-audit caveat
This document is a sample — a generic, composite portrait of a small-to-mid-market manufacturing ERP system in the CEE region as such systems exist in 2026. It is not an audit of any specific real system. Customer names, system internals, and exact figures are illustrative.
A real audit of a real system follows this same structure but is grounded in evidence collected from the actual environment: interviews with named users, inspection of the actual database schema and code, observation of the actual integrations in flight, and review of the actual operational history. The structure is the deliverable shape; the content of the real audit is, by construction, customer-specific.
This sample exists to demonstrate the shape and the rigour. If you read it and recognise your own system in the portrait — that is the intended response, and the conversation that follows from it is the one this document is designed to start.