- Chemical
- Opcenter Execution Process
- Multi-site rollout
- ISA-95 L2–L4
Multi-line MES rollout shared across two countries
Twelve production lines across two plants in two countries, built on one common Opcenter core instead of twelve separate implementations — and delivered with a 10-person team against a plan that called for far more.
- Industry
- Chemical manufacturing Specialty chemicals
- Client type
- Multinational producer ~80 countries
- Platform
- Siemens Opcenter Execution Process
- ISA-95 scope
- L2 – L4 DCS to ERP
- Installed base
- 2 plants · 2 countries 12 production lines
- Delivery team
- 10 people vs. 7–8 per plant estimated
Results
01 The situation
Where the project started.
The client runs two chemical production plants in two different countries, together operating twelve production lines. The plants make comparable products through broadly similar processes, but each line carries its own equipment, layout and process quirks, shaped by years of local operation.
Based on previous single-plant MES implementations at the same company — some of them executed by our team — the client realised that maintaining one code base per plant would result in large, steady labour costs and complexity even after the go-lives, since each plant would have to be supported and improved separately.
Treating each line, or even each plant, as its own project would have meant building the same MES logic from scratch multiple times over, increasing the timeline and therefore the budget. Based on experience, that would require a team of 7–8 people per plant during a development phase estimated at 24 months, plus one or two MES engineers to support each plant after go-live.
The technical challenge
- Twelve lines across two plants and two countries: similar processes on paper, different equipment and quirks in practice.
- Tight deadlines with zero margin for error. The plants had either a Simatic IT legacy MES or no MES at all — and both situations were incompatible with the incoming SAP S/4HANA update.
- Building each line's logic independently would have required a developer headcount the project's budget and timeline couldn't support.
- Keeping twelve lines of custom code consistent over time, across two countries and two support teams, would have made long-term maintenance unmanageable.
02 The approach
The architecture decisions.
Architecture diagram: the route not taken, compared with the approach that was built, its configuration layer, and where it was deployed.
One code base per plant
- 7–8 people per plant during development
- ~24 months estimated
- 1–2 MES engineers supporting each plant after go-live
One shared Opcenter core
Shared DLLs and FBs · sequencing logic · standard equipment models · alarm handling
Configuration keys + tailor-made entities
Different behaviours of the same business logic, set even at runtime
Plant #1
Own QA system · release version controlled per plant
Plant #2
Own QA system · release version controlled per plant
What stays line-specific, for example: the DCS integration Opcenter libraries, so the site automation team doesn't have to alter the current OPC UA address space or the DeltaV DCS logic.
Every code change validated in both QA systems, even when it only impacts one plant
Production deployment — human approval required
We built one common Opcenter core with reusable functional blocks and shared assemblies, so that anything common across lines — sequencing logic, standard equipment models, alarm handling — gets written once and reused, not reimplemented twelve times. Not many technical details can be revealed in order to protect intellectual property, but the common base consists of shared DLLs and function blocks, including state-of-the-art methods to query cross-domain data without diminishing performance. Many of the libraries are configurable via configuration-key entities and other tailor-made entities, which allows different behaviours of the same business logic to be set even at runtime.
Harmonised line design meant we didn't force every line into an identical mould. Some things were kept specific to each plant, based not only on differences in business requirements but also on practical criteria such as code troubleshooting difficulty, or integration effort and complexity. For example, the DCS integration Opcenter libraries are line-specific, so the site automation team doesn't have to alter the current OPC UA address space or the DeltaV DCS logic.
We used AI-assisted testing, code review and CI/CD throughout the project. A collection of agents executed repetitive but necessary tasks in order to save valuable senior developer hours. We trained the agents ourselves: Opcenter is not a standard or especially flexible product, and although it uses the C# framework, the platform carries many restrictions and conditions — so an out-of-the-box or popular agent could not be relied on to behave correctly. Among the tasks: generating release notes for end users, automated execution of unit and integration test suites, automated release and promotion pipelines for the Opcenter solution, and code review with suggestions on every developer pull request before the human architect does the manual review.
03 How it was implemented
Phase by phase, with the real durations.
-
Requirements & design
2 monthsBusiness and functional requirements gathering, and solution design.
-
Development
9 monthsBuild of the shared solution.
-
Validation
1 monthSAT, UAT and technical go-live for Plant #1.
-
Plant #1 go-live
2 weeksProduction cutover and hypercare support with the full team.
-
Pilot stabilization
6 monthsTime to catch and fix real-world issues before scaling, while Plant #2's specific logic is developed and validated in parallel.
-
Plant #2 go-live
2 weeksProduction cutover and hypercare support with the full team.
-
Long-term support
IndefinitelyContinuous improvement with a small team.
04 Results
What it delivered.
- The shared architecture let the project run with a 10-person delivery team instead of the larger team the traditional line-by-line approach would have required — a 33% saving on labour cost against plan.
- After go-live, the plants need a support team 50% smaller: one or two people rather than two to four.
- Common features can on average be validated and deployed for both plants 25% faster than if they were done individually, not counting the additional gains from AI and automation tools in CI/CD.
The takeaway
Multi-line, multi-plant MES rollouts don't have to scale headcount linearly with line count. The lines that actually differ from each other are usually a smaller fraction of the total logic than they first appear — and the rest is worth building once.
05 FAQ
Practical questions about this project.
A very detailed study and gathering of business requirements was done to find alignments across processes and features. The functional requirements stage then focuses on deciding how to maximise the common code base without making the libraries too complex or hard to maintain. Additional criteria such as integration effort or user experience were also applied.
No. The processes between lines were similar, but there are remarkable differences – even different products or raw materials being used. The same codebase is configured to fulfil specific plant requirements with the help of configuration keys, single and multi-value, and other custom-made entities.
The same codebase does not mean every plant gets the same Opcenter solution version. Through a solid release pipeline we control which version is deployed in each plant, and when. Every code change is also tested and validated in both QA systems – one per plant – even if the change only impacts one of them.
Only steps related to non-production systems are fully automated: CI pipelines, and QA-system deployment and validation, for example. Deployment to production still requires human approval and intervention, although the Opcenter package bundle is prepared and deployed by script to prevent human error.
Talk to us
Same challenge on your floor?
Planning an MES rollout across more than one plant or line? Let's talk about how much of it could really be one shared build instead of several separate ones.
