By Ritvars Mētra, Founder of ReadinessCompassThe German go-live slipped by four months. Not for a technical reason — the build was finished — but because the works agreement covering the new system had not been concluded, and without it the system could not be switched on.
The programme plan had a line for it. It said “works council briefing”, it was scheduled six weeks before go-live, and it was owned by communications.
What the framework actually requires
Across the EU, Directive 2002/14/EC establishes a general framework for informing and consulting employees. It applies, at Member States’ choice, to undertakings with at least 50 employees or establishments with at least 20, and it covers information and consultation on the development of employment and — the phrase that matters for transformation programmes — on decisions likely to lead to substantial changes in work organisation.
An ERP implementation that changes who does what, in which sequence, with which approvals, is a substantial change in work organisation by any reasonable reading. Member States implement the framework very differently, and local arrangements vary widely, but the obligation to inform and consult is not optional and it is not satisfied by an announcement.
Note the word consultation. It implies an exchange that can influence the decision. A briefing delivered after the design is frozen is information, and treating it as consultation is precisely how programmes end up renegotiating from a weak position.
Germany raises the stakes considerably
If your rollout touches Germany, the relevant provision is stronger than consultation. Section 87(1) No. 6 of the Works Constitution Act gives the works council a genuine co-determination right over the introduction of technical equipment intended to monitor the conduct or performance of employees.
The decisive point, and the one most international programmes discover late, is how broadly this is interpreted. Under established Federal Labour Court case law it is sufficient that the equipment is suitable for monitoring — the mere possibility of monitoring performance or behaviour triggers the right, regardless of whether the employer intends to use it that way.
That standard captures almost everything. An ERP that timestamps transactions by user is suitable for monitoring. A CRM that records activity is. A ticketing system, a time-recording module, a collaboration platform, most analytics — all suitable. Co-determination is not a consultation you can conclude unilaterally; without agreement, the system does not go live.
None of this is legal advice, and local counsel should own the legal position. The point for a programme is planning: this is a dependency with a veto attached, and it belongs on the critical path rather than in the communications workstream.
Why programmes get caught
| What programmes do | What it produces |
|---|---|
| Schedule consultation near go-live | No time to negotiate, so the date carries all the risk |
| Present a finished design | Consultation becomes approval, which representatives are right to resist |
| Send communications, not answers | The questions asked are about data and consequences; the material is about benefits |
| Treat it as one conversation | Local works councils exist per establishment; a group-level agreement may not cover them |
| Assume silence is agreement | Under co-determination, absence of agreement is a blocker rather than a neutral state |
The fourth row causes the most schedule damage on multi-site rollouts, because the structure of representation is genuinely complicated and a group agreement does not automatically resolve site-level rights.
The questions they will ask are good ones
Programmes often treat works council engagement as an obstacle. It is more useful to notice that the questions asked are almost exactly the questions a well-run change programme should be able to answer anyway:
- What data does the system capture about individuals? Most programmes cannot answer this precisely, which is itself a finding.
- Who can see it, at what granularity? Can a manager see one person’s throughput, or only a team’s?
- What will it be used for — and what will it not be used for? Specifically, will it inform individual performance assessment?
- How long is it retained?
- What changes about workload, and who decided that?
These map closely onto the commitments that make readiness data trustworthy in the first place. An organisation that has already decided what it will and will not do with employee-level data arrives at the works council with answers rather than reassurance.
How to run it without losing months
- Start at design, not at deployment. The cheapest time to accommodate a concern is while the configuration is still open. The most expensive is after user acceptance testing.
- Put the agreement on the critical path with a named owner, a legal counterpart and a target date, exactly as you would treat a licence or a contract.
- Bring the data questions first. Lead with what is captured and how it will be used, not with the benefits case. It answers their actual concern and shortens the process.
- Map the representation structure early. Which bodies exist, at which sites, with which rights, and whether a group-level agreement is possible.
- Offer commitments you can keep. A narrow, checkable undertaking — system data will not be used in individual performance reviews for the first twelve months — is worth more than a broad assurance, and it is the same discipline that makes any commitment about employment credible.
Programmes that do this well rarely describe consultation as a delay. They describe it as the conversation that forced them to decide, early, what the system would actually be used for — which is a decision every organisation should make deliberately and most make by default.
More on readiness across countries and functions in the Change Readiness Hub, or read where global change plans break locally.