MES Configuration vs Customisation vs Extension: What to Change, How, and What It Costs Later
On this page
Every MES must be adapted to the plant: products, routings, equipment, checks, screens and interfaces. The question is how. Changes made through the product’s own configuration survive upgrades; changes made by modifying the product’s code often do not. Many MES installations that became “impossible to upgrade” got there one reasonable-looking customisation at a time.
Three ways to adapt an MES
| Approach | What it means | Examples | Upgrade impact |
|---|---|---|---|
| Configuration | Using the product’s built-in settings and modelling tools | Equipment model, routings, recipes, check plans, user roles, screen layouts, reason codes | Low: carried forward by the vendor’s upgrade tools |
| Extension | Adding functions through supported interfaces: APIs, scripting, low-code apps, plug-ins | A custom label format, an extra operator app, an interface to a local system | Medium: must be retested; usually survives if APIs are stable |
| Customisation (core modification) | Changing the product’s source code or database structure | Changed standard transactions, altered data model | High: may have to be redone at every upgrade; can void support |
Deciding for each requirement
- Is the requirement really necessary? Challenge “we have always done it this way”. A standard process that is slightly different may be fine.
- Can configuration meet it? Check with the vendor and experienced partners.
- Can a supported extension meet it? Prefer APIs and low-code over code changes.
- If customisation is unavoidable, document why, isolate it, and budget for its upgrade cost.
- Record the decision in a requirements traceability matrix.
A useful rule: aim for configuration for the core processes and extensions at the edges, with customisation close to zero.
Typical configuration work
| Area | Configuration items |
|---|---|
| Plant model | Sites, areas, lines, work centres, equipment (ISA-95 equipment hierarchy) |
| Product definitions | Materials, bills of materials, routings, operations, recipes, specifications |
| Execution | Work instructions, data collection points, electronic signatures |
| Quality | Inspection plans, sampling, SPC charts, deviation workflows |
| Performance | Machine states, downtime and scrap reason trees, OEE rules |
| Integration | ERP message mapping, equipment tags, label printers, scanners |
| Security | Roles, permissions, signature rules |
Much of this is master data: its quality decides whether the MES works. See MES Cost and Implementation Complexity.
Governance
- A design authority (process owners plus MES architect) approves deviations from the standard template and any extension or customisation.
- Global template for multi-site programmes, with defined local configuration options.
- Change control for configuration in production, with testing and, in regulated plants, validation.
- Version control of configuration exports and extension code.
Documentation and validation
- Keep a configuration specification describing what was configured and why.
- Document extensions like software: design, code, tests, versions.
- In GMP environments, configuration and extensions are validated according to risk (GAMP 5 categories distinguish configured products from custom applications). See Computerised System Validation.
Upgrades
Plan upgrades from the start:
- Track every extension and customisation in a register with its owner and test cases.
- Test extensions against each new version in a test environment.
- Budget for regular upgrades rather than letting the system fall several versions behind.
Warning signs of over-customisation
| Sign | What it indicates |
|---|---|
| Upgrades postponed for years | Customisation makes upgrades too expensive |
| Only one person understands the system | Custom code without documentation |
| Vendor support refuses issues | Core modifications outside support |
| Every site behaves differently | No template governance |
| Many screens mirror old paper forms exactly | Processes were copied, not improved |
Frequently asked questions
What is the difference between MES configuration and customisation?
Configuration uses the product’s built-in settings and modelling tools and is carried through upgrades. Customisation changes the product’s code or data structures and usually has to be redone or retested at each upgrade.
Is low-code the same as customisation?
Not necessarily. Low-code apps and scripts built through supported interfaces are extensions: they need testing at upgrades but do not change the core product. Poorly governed low-code can still create a maintenance burden.
How much customisation is acceptable?
As little as possible in the core. Most requirements should be met by configuration, with supported extensions for genuinely specific needs, each documented and justified.
Key takeaways
- Configuration first, supported extensions second, core customisation last.
- Challenge requirements before adapting the system to them.
- Govern changes with a design authority, template and change control.
- Keep a register of extensions and plan regular upgrades.
Related tutorials
Before you apply this in a plant: this article is for education. Always check the current edition of the relevant standards, the manufacturer's documentation for your exact product and version, and your site's procedures. Safety-related work needs qualified personnel. See our editorial policy.