Executive summary
The subject should not be treated as an isolated technical point. It must be read as an industrial transformation challenge: decision quality, operational robustness, operational support capacity and measurable value creation.
The difference between a standard approach and a rigorous approach is the depth of the diagnosis. It is not enough to identify what is malfunctioning. It is necessary to understand why the organization has allowed this dysfunction to settle, what decisions have not been taken, which indicators have masked the problem and what governance will prevent its reappearance.
Industrial digital performance does not come from the stacking of tools. It comes from the alignment between processes, data, responsibilities, systems and management routines.
The status quo: many committees, few decisions
Most ERP/MES programs already have formal governance: project committee, steering committee, planning, action register, reports. However, critical topics often remain open for weeks: ERP/MES border, standard or specific, data responsibilities, resumption of history, testing criteria, bypass rules, start-up support level.
The problem is not the lack of governance. The problem is the confusion between information governance and decision-making governance. An information governance presents the status of the project. Decision governance transforms grey areas into documented, assumed and executable decisions.
In an industrial program, every decision not made ends up being made by the schedule. When the go-live date approaches, the default solution often becomes: deliver with debt, bypass with Excel, postpone operations or ask the site to adapt. This mechanics destroys trust and shifts the cost to users.
Define decision rights: who decides what, at what level and with what criteria?
Robust governance begins with a mapping of decisions. Not all of them should go up to the same level. A screen wording choice may remain operational; a deviation from MES template or a change in the quality release process must be assessed with a risk, cost, adoption and compliance reading.
The decision matrix must be explicit. It avoids two frequent drifts: over-escalation, which slows everything down, and under-escalation, which allows structuring decisions to be made locally without transverse vision.
| Type of decision | Recommended level | Decision criteria |
|---|---|---|
| Local desk at the template | Design authority / Cross-functional business committee | Business value, regulatory constraint, run effort, reusability |
| Border ERP/MES | Architecture + profession + program | Data ownership, real time, criticality, supportability |
| Specific SAP or MES | Decision Committee solution | Standard alternative, technical debt, maintenance cost, impact adoption |
| Go-live readiness | Steering Committee | residual risks, business continuity, hypercare, users, data |
| Prioritisation backlog | Product owner trade / PMO | Business impact, regulatory emergency, project dependency, effort |
A useful RAID log: move beyond administrative tracking
A completed RACI to satisfy a project methodology is of little value. A useful RACI clarifies the responsibilities at the moment when there is tension: incorrect data, interface incident, process decision, testing delay, specific request, site deviation, post-go-live support.
In an ERP/MES project, the grey areas are numerous. The supply chain sometimes thinks that the methods are the owner of the bills of materials; the methods believe that the production validates the routings; the CIO considers that the business decides on the flows; the integrator expects a formal validation; the site expects an operational solution. Without clarification, critical topics circulate without an owner.
Choose between standard and custom solutions using economic criteria
The standard/specific debate is often poorly established. The standard is not always virtuous and the specific is not always bad. The real question is: which option best protects the industrial value on the entire life cycle?
A specific can be justified when it responds to a regulatory constraint, a real competitive advantage or an indispensable operational security. Conversely, a specific one that is asked to preserve a non-differentiating local habit creates a sustainable debt. It complicates tests, support, upgrades, training and rollouts.
| Criterion | Question to Ask | Warning sign |
|---|---|---|
| Value | What measurable gain or avoided risk justifies the gap? | Argument based solely on user comfort |
| SAP/MES Standard | Is there an acceptable standard alternative? | Specific requested before real exploration of the standard |
| Run | Who will support the solution in 18 months? | Absence of owner support or low documentation |
| Scalability | Is the solution reusable on other sites? | Solution designed for a non-represented local case |
| Risk | What is the industrial risk if you do not make the difference? | Unquantified risk, emotional decision |
Anonymised case study: the schedule was green, but the decision was red
In a multi-site ERP/MES program, the consolidated schedule indicated a satisfactory progress: workshops realized, documented design, developments launched. However, several structuring decisions were not decided: component consumption rules, synchronization of order statuses between ERP and MES, management of blocked batches quality, responsibility on post-reporting corrections.
The risk did not appear in the milestones. It appeared in the conversations: each team had a different hypothesis. The integrator built according to a technical interpretation, the pilot site projected its local practices, the quality wanted to preserve a manual validation, the supply chain was waiting for strict synchronization.
The overhaul consisted of creating a decision register, with each decision associated with business impact, go-live risk, owner, deadline and test scenario. This simple change of governance shifted the debate: we no longer discussed preferences, but impacts and options. This is exactly the role of effective governance: to quantify what is too often political.
Control risks by industrial impact, not by PowerPoint colour
Project risk matrices are often too generic. In a manufacturing program, the risk must be qualified by operational consequence: line stoppage, shipping blocking, traceability error, overconsumption, component break, inability to release quality, loss of inventory, regulatory non-compliance, overload support.
A risk must contain five minimum information: scenario, industrial impact, probability, mitigation time, owner. Without an owner and no associated decision, the risk is only an observation.
| Risk | Industrial Impact | Expected mitigation |
|---|---|---|
| MES interface → SAP not tested in recovery | Blocked or inconsistent statements after technical incident | Degraded scenarios, queue, monitoring, replayability procedure |
| Material master data not ready | MRP unstable, non-executable orders, consumption errors | Critical family data, quality control, business ownership |
| Key users not available | surface testing, low adoption, insufficient support | Operational backfill, engagement management site, validation planning |
| Unresolved template deviation | Late customisation, design delay, operating debt | Weekly decision committee, standard-versus-custom criteria |
The target governance model: fewer meetings, more decisions
Effective governance does not increase meetings. It clearly separates the places of analysis, decision and escalation. The Operational Committee deals with short-term actions and risks. Design authority arbitrates the structuring rules. The steering committee decides the cost, delay, scope, risk and value impacts. Site rituals capture adoption by shop floor teams.
The key point is the quality of the entries. A steering committee should not receive a gross problem. It must receive a decision note: context, options, impacts, recommendation, decision requested. It is this discipline that transforms a committee into a leadership body.
Decision checklist
- Create a separate decision register from the action registry.
- Define decision rights by subject type: data, process, template, specific, go-live.
- Qualifying every risk by concrete industrial impact.
- Formalize standard-versus-custom criteria before first sensitive decisions.
- Impose a decision note for any structuring decision.
- Connect project rituals to shop-floor pain points and testing signals.
Operational conclusion
ERP/MES governance is not an administrative layer. It is the mechanism that protects industrial value when business interests, IT, integrator, group and sites diverge. Low governance produces reporting. Strong governance produces decisions.
Fenlynks positions governance as a lever for security: clarify responsibilities, objectively decisions, speed up decisions and prevent planning from masking risks.
Fenlynks provides scoping, rapid audits, business project support (AMOA), project governance, testing assurance, SAP/MES roadmaps, change management and post-go-live stabilisation.