Key takeaways
In four stages, and the first is not technical. Stage one, agree the group taxonomy: one asset naming convention, one hierarchy shape, one criticality method, one set of downtime reason codes. This is the only thing that is genuinely hard to change later, so it is the only thing that must be right before anything is installed. Stage two, run a pilot on one site and one line, chosen for representativeness rather than enthusiasm. Stage three, roll the pilot site out fully and write down what you had to change. Stage four, run the remaining sites in waves, two or three at a time, reusing the configuration.
Run the country-level approvals in parallel from week one, because they are the long pole and they are not yours to accelerate. In Germany, Austria, the Netherlands and France, systems that can produce data about individual employees typically require works council involvement. The data protection assessment and, for entities in scope, the NIS2 supplier record run alongside. Fabrico supports this shape with multi-plant views and cross-plant benchmarking, role based access control with SSO and SAML available, an interface in English, Bulgarian, German, French and Polish, hosting in an AWS EU region, and 3 days of Fabrico-side setup for the CMMS layer per site.
This decision determines what the programme can ever deliver, so make it deliberately rather than by default.
One instance means every site shares a taxonomy and a permission model, and group reporting is a filter rather than an integration project. Cross-plant benchmarking, which is usually the reason a group funds the programme at all, works on day one. The cost is political: every site gives up some autonomy, and a change that helps one plant has to be acceptable to all of them.
Separate instances per site or per country give each plant freedom and remove the negotiation. The cost arrives later and is permanent: comparing two plants means reconciling two taxonomies, which is a recurring analytics job rather than a one-off decision. Groups that choose this route usually end up building a warehouse to undo it.
There is one legitimate reason to split that is not political: a genuine legal or contractual requirement to keep a jurisdiction's data separate. That is rarer than it is claimed to be within the EU, where a single EU region satisfies most requirements. Establish whether the constraint is real before it decides your architecture, using the questions in our GDPR and data protection buyer guide.
The default recommendation is one instance, with permissions doing the work that separate instances would otherwise do.
This is where most European rollouts go wrong, and the error is almost always over-standardisation rather than under.
Standardise, centrally and without exception: the asset naming convention and hierarchy shape; the criticality method, so a critical asset means the same thing in Poland and in Spain; the downtime reason code list, because it is the vocabulary of every comparison you will ever make; and the definitions behind the headline metrics, especially what counts as planned downtime.
Leave to the site: preventive schedules and intervals, which depend on duty cycle, environment and local regulation; shift patterns and calendars; the language of the interface; local suppliers and part sources; and the sequencing of their own internal training.
The test for which list something belongs on is simple: does it need to mean the same thing in two countries for a group-level number to be valid? A downtime reason code does. A preventive interval on a compressor does not. Applying that test consistently prevents both the centralisation that makes sites resentful and the localisation that makes group reporting fiction.
The downtime reason code list deserves special care because it is deceptively easy to get wrong. Keep it short, make every code mutually exclusive, and translate the labels rather than letting each site invent its own. A list of fifteen codes that everyone uses is worth more than a list of ninety that each site interprets differently.
Employee representation. In Germany the works council has co-determination rights over technical systems capable of monitoring employee performance, and equivalents exist in Austria, the Netherlands and France. This is not a formality and it is not something a group agreement resolves in advance. It is also entirely survivable when handled early and honestly, and it is covered in detail in our works council approval guide for OEE monitoring. The pattern that works is to bring the council in before selection rather than after, and to be specific about what is measured at machine level versus at person level.
Data protection. One data processing agreement can cover the group, but the assessment of the processing is done where the controller sits, and local data protection officers will ask about hosting region, sub-processors and retention. Answer those once, centrally, in a document each site can reuse.
NIS2 supply chain record. Whether an entity is in scope depends on its sector and its size, so within one group some sites will be caught and others will not. The obligation under Article 21 to manage supply chain security makes your software vendor an entry in a documented risk assessment at each in-scope entity. Details in our guide to CMMS and OEE software under NIS2. Collect the vendor evidence once at group level and distribute it, rather than having five sites ask the same questions separately.
The efficiency available here is real: do the vendor security work once, centrally, and reuse it. The vendor security questionnaire is the same in every country even when the approver is not.
Do not pick the best-run site. It will succeed on the strength of its own team, prove nothing that transfers, and generate a configuration that assumes a maturity the other sites do not have.
Do not pick the worst site either. A rollout that begins as a rescue confuses two problems, and if it fails you will not know whether the tool or the site was the cause.
Pick a representative site with a willing manager. Representative in size, equipment age and team composition; willing because the pilot will need decisions made quickly and someone to absorb the disruption. If the willing manager runs a site that is unrepresentative, take the willingness anyway and be explicit that a second, more typical site will validate the configuration before the wave rollout.
Within the pilot site, start with one line rather than the whole plant. One line reaches genuine daily use in weeks, which is the only evidence that matters, and the mistakes are cheap.
The multi-site capabilities are multi-plant views, cross-plant benchmarking, role based access control so a site sees its own data while group sees all of it, SSO and SAML available for custom configurations, an audit log, and customisable dashboards. The interface is available in English, Bulgarian, German, French and Polish, with further languages straightforward to add, which covers most of the shop-floor language problem in a European group without a per-site workaround.
On measurement, availability, performance and quality are calculated from PLC data, with IoT sensors and AI cameras for machines with no usable signal, which matters in a group where plant ages differ by decades and one site's equipment will not expose the same signals as another's. Integration runs through a REST API, webhooks, Excel import and export, and a bidirectional SAP PM sync including S/4HANA for groups running a central ERP.
On compliance the answers are the same everywhere, which is the point: ISO 27001, ISO 9001 and ISO/IEC 20000-1, a GDPR data processing agreement, hosting in an AWS EU region, encryption at rest and in transit, daily backups and a 4 hour recovery time and recovery point objective. Support response is contractually under 2 hours.
On timelines, be precise with your steering committee. The CMMS layer is quoted at 3 days of Fabrico-side setup per site, covering configuration, users, roles and bulk import. Machine connection for OEE is not a software timeline: PLC addressing, tag mapping and any retrofit sensors or cameras are physical work paced by your equipment and by line access. Presenting those as one number is the single most common way a rollout plan loses credibility in month three.
A group with six plants across Germany, Poland, Romania and Spain wants one view of availability and a common maintenance process.
Months 1 to 2. Taxonomy workshop with all six sites, ending with one naming convention, one hierarchy shape, one criticality method and fifteen downtime reason codes. In parallel, the German works council process opens, the group data protection assessment starts, and the vendor security pack is collected once. No software is installed.
Months 3 to 4. Pilot on one line in Poland, chosen as representative with a willing plant manager. Reactive work orders and the asset register first, preventive plans for critical assets second, OEE on that line connected during a planned shutdown.
Months 5 to 6. Full rollout of the Polish site, and a written list of every change the pilot forced. This list is the actual deliverable of the pilot, more than the working line is.
Months 7 to 12. Waves of two sites. Germany goes when the works council agreement is signed, which may be later than the plan wants, and the plan should already assume that rather than treat it as a slip.
The two things that decide whether this works are both non-technical. The taxonomy has to be agreed by the sites rather than issued to them, or it will be quietly ignored. And the German timeline has to be independent of the others, because a co-determination process that is rushed produces a worse agreement and a slower one. Groups that treat both as project management problems rather than as negotiation problems are the ones still running two taxonomies three years later.
No. Duty cycle, ambient conditions, water quality, local regulation and equipment age all differ, and forcing an identical interval on a compressor in Spain and one in Romania produces either over-maintenance in one place or a failure in the other. Standardise the method and the vocabulary, not the intervals. Where two sites run genuinely identical equipment under identical conditions, sharing a schedule is sensible, but that is a site-level decision to converge rather than a group instruction.
By comparing the components rather than the headline. A single OEE figure across a job-shop and a high-volume line is not a comparison, it is a coincidence. Availability against its own history, stoppage reasons ranked, and preventive completion are all comparable across very different plants because they measure the process rather than the product. Save cross-plant OEE comparison for genuinely similar lines and use trend against self everywhere else.
No. Interface language is a per-user setting, so a Polish technician and a German planner can work in the same instance in their own languages. What has to be shared is the data vocabulary, meaning the asset names and the reason codes. The usual approach is to keep asset tags language-neutral, since they are codes rather than words, and to translate the reason code labels while keeping the underlying code identical.
It varies too much for a useful average, and treating it as a fixed duration is the mistake. What reliably shortens it is opening it before vendor selection, being precise about what is measured at machine level versus at individual level, and offering to write the limits into the agreement itself. What reliably lengthens it is presenting a signed contract and asking for approval. Plan the German site as an independent track with its own dates.
Usually not in the same wave. They have different constraints: the CMMS layer is configuration and change management, while OEE is physical connection work paced by line access. Running them together means the whole programme moves at the speed of the slowest shutdown window. The pattern that works is CMMS first across the group, OEE connected line by line as maintenance windows allow, with the pilot site doing both so you learn the interaction early.
To scope a group rollout, including the security pack you can distribute to every site at once, book a demo. If you are commissioning a new site as part of the programme, see the greenfield plant startup guide, and for the metric definitions the group will standardise on, the OEE for manufacturing guide.
Last updated: 7 August 2026.
Login
Blog