Einführungs-Roadmap — CRM Bund-Verlag
Stand: 24.07.2026 · Projekt: BV-CRM-2026 · Basis: Gesamtanalyse (gesamtanalyse.md), Bewertungsmatrix (vergleichsmatrix.html), Labortests (
lab/*/ERGEBNIS.md) Prämissen: Empfehlung Top 3 = Twenty · Odoo · EspoCRM · Self-Hosting/OSS priorisiert (Festlegung #1) · SSO erst zum Rollout Q4 Pflicht (Festlegung #3) · BR-Einbindung für den Pilot informell geklärt (Festlegung #4)
0. Die Roadmap auf einen Blick
| Phase | Zeitraum | Inhalt | Meilenstein |
|---|---|---|---|
| 2 — Prototypen-Rennen | jetzt – Mitte 08/2026 | Top 3 parallel: #BR26-Szenario end-to-end + T4b-Bauteil | Systementscheidung ~19.08.2026 |
| 3 — #BR26-Produktivstrecke | Mitte 08 – 15.09.2026 | Gewähltes System produktiv härten, Landingpage-Anbindung, DOI, Betriebsbasis | Go-live vor #BR26 (16.–17.09.) |
| 4 — Pilot KARO-Team | 09 – 11/2026 | Pilotbetrieb mit dem KARO-Vertriebsteam (~10 Nutzer), Lead-Nachbearbeitung #BR26 | Pilot-Review |
| 5 — Konsolidierung & Rollout | Q4/2026 – Q1/2027 | Entra-SSO, BV/Mitbestimmung formalisieren, NTX-Spiegel produktiv, Companion-Marketing | Rollout-Entscheidung |
Architekturprinzip aus Runde 1 (bleibt gültig): Die #BR26-Landingpage ist vom CRM entkoppelt (QR → Landingpage → API/Webhook → CRM). Damit ist die #BR26-Strecke auch dann sicher, wenn sich die Systementscheidung verzögern sollte — der schlimmste Fall ist ein Puffer (n8n o. ä.) vor dem CRM, nicht ein Ausfall am Stand.
1. Phase 2: das Prototypen-Rennen (jetzt → ~19.08.)
Alle drei Top-Systeme laufen bereits als Docker-Installation im Lab. Der Prototyp prüft die zwei Dinge, die die Auswahlentscheidung tragen und noch nicht beide gebaut sind:
AP Phase-2.1 — #BR26-Szenario end-to-end (je System)
QR-Ziel-Link mit UTM-Parametern → Landingpage → Lead per API ins CRM → Dublettenschutz/Upsert → DOI-Strecke → Follow-up-Aufgabe. Bei EspoCRM ist der Flow aus dem Labor bereits belegt; bei Odoo ist er nativ zu konfigurieren; bei Twenty ist der Vorbau (Adapter + DOI + UTM-Felder) explizit Teil des Tests — sein Aufwand ist ein Entscheidungskriterium, kein Hindernis.
AP Phase-2.2 — Das T4b-Bauteil ✅ erledigt am 25.07.2026
Anforderung: Eine Person wird zeitbefristet einem Gremium mit Funktion zugeordnet; nach einer BR-Wahl bleibt die Historie erhalten und ist datumsabfragbar („Wer war am 01.10.2026 Vorsitzende?").
In allen drei Top-Systemen gebaut und geprüft (Bericht: lab/T4B-NACHTEST.md). Prüfszenario: ein
Gremium, zwei Amtsperioden derselben Funktion — Erika Musterfrau hat den Vorsitz 2022–2026, Maxine
Mustermann ab 2026. Die Stichtagsabfrage liefert überall korrekt Erika für den 01.10.2024 und Maxine
für den 01.10.2026, beide Datensätze bleiben erhalten.
| System | Umsetzungsweg | Ergebnis |
|---|---|---|
| EspoCRM | Zwischen-Entity + Links + Rebuild, ohne Code | ✅ danach sofort nutzbar |
| Twenty | Objekt + Relationen über die Metadata-API | ✅ sofort nutzbar, ausdrucksstärkster Filter |
| Odoo | Modell + Felder über ir.model, ohne Studio und ohne Addon |
✅ funktioniert, aber Zugriffsrechte und Oberflächen-Ansichten fehlen danach noch |
Erkenntnis für die Auswahl: Alle drei erfüllen die Anforderung fachlich. Der Unterschied liegt im Aufwand danach — bei Odoo ist ein frisch angelegtes Modell ohne expliziten Rechte-Eintrag für niemanden lesbar, und es erscheint ohne eigens gebaute Ansicht nicht in der Oberfläche. Für ein Team, das Gremienstrukturen selbst pflegen soll, ist das der praktisch spürbare Unterschied (K3: EspoCRM 5 · Twenty 4 · Odoo 3).
Offen bleibt der Ausbau: Wahlperioden-Workflows und Stichtagsberichte (Phase 5, §7.6). (Referenz-Blaupause: hitobito-Rollenmodell, Track C; CiviCRM bleibt als Spezialoption dokumentiert, falls die Gremienverwaltung später als eigenes System neben dem CRM gedacht wird.)
Parallel in Phase 2 (nicht blockierend, aber terminrelevant)
- ⚠ Entscheidungspunkt 1 — NTX-Herstelleranfrage sofort raus (Details §4).
- ⚠ Entscheidungspunkt 2 — Twenty-SSO-Preisanfrage sofort raus (Self-Host-Enterprise für Entra-SSO; Antwort muss vor der Systementscheidung vorliegen, sonst bewertet die Matrix Twenty mit einer Unbekannten).
- Gewichte K1–K9 bestätigen (30 Min mit der interaktiven Matrix — O1).
2. Pilot KARO-Team (Phase 4)
- Zuschnitt: ~10 Nutzer (KARO-Vertrieb), Start mit den #BR26-Leads als echtem Arbeitsvorrat — der Pilot beginnt mit Daten, nicht leer. SLA-Vorschlag: Follow-up auf jeden Event-Lead < 24 h.
- Champion benennen: eine angesehene Person im KARO-Team als CRM-Champion (wichtigster Adoption-Hebel laut Grundlagen-Dossier). Schulung schlank halten: 1 h Kickoff + Kurzreferenz.
- Pilot-Umfang bewusst klein: Leads, Kontakte, Firmen/Gremien, Pipeline, Aufgaben. Kein Abo-Billing (bleibt NTX), Marketing-Automation erst ab Phase 5 (Companion).
- Absicherung: Pilot läuft unter Regelungsabrede (§6); Auswertungen im Pilot nur aggregiert.
- Pilot-Review (11/2026): Adoption (aktive Nutzer/Woche), Datenqualität (Dublettenquote), Lead-Durchlaufzeit, Zufriedenheit im Team → Input für die Rollout-Entscheidung.
3. Betriebskonzept Self-Hosting (ab Phase 3, dauerhaft)
Die Labortests liefern die Betriebsdaten; hieraus die Eckpfeiler:
| Baustein | Festlegung | Beleg/Anker |
|---|---|---|
| Plattform | Docker Compose auf einer internen VM; Ressourcen je nach Systemwahl (EspoCRM ~207 MB / Odoo ~370 MB / Twenty ~1,9 GB idle) | Labor-Messwerte T1/T9 |
| Backup | Täglicher DB-Dump + Volume-Snapshots; bei EspoCRM zwingend das custom/-Volume mitsichern |
Restore im Labor belegt: EspoCRM 4 s, Twenty ~2 s (T9) |
| Restore-Übung | Quartalsweise Probe-Restore mit Beziehungscheck — Backup ohne Restore-Test gilt als nicht vorhanden | Labor-Verfahren T9 wiederverwenden |
| Updates | Monatsfenster für Minor-Updates; Major-Upgrades (insb. Odoo) als geplantes Projekt mit Staging-Kopie | Odoo-Major-Upgrade-Risiko aus Deep-Dive |
| Monitoring | HTTP-Healthcheck + Container-Status + Disk; Alarm an IT-Services | — |
| Sicherheit/TOM | TLS, Zugriffskonzept nach Rollen, API-Keys mit minimaler Rolle (Labor-Lehre: API-User braucht zwingend eine Rolle), Secrets nie im Repo | Art. 32 DSGVO |
| Exit-Fähigkeit | Dokumentierter Export (DB-Dump = vollständige Daten, offene Formate) — der Gegenentwurf zum NTX-Lock-in (O8) | K9-Kriterium |
Personalseite ehrlich benennen: Der eigentliche TCO-Block ist Personal/Know-how (Aufbau, Updates, Eigenbau der Lücken), nicht Hosting. Das ist der Preis der Souveränität — bewusst akzeptiert per Festlegung #1. Einmalkäufe je nach Systemwahl: EspoCRM Advanced Pack ~395 $ (BPM/Reports), Twenty-Enterprise für SSO (Preis: Entscheidungspunkt 2).
4. NTX-Koexistenz (Phase 3–5) — mit den Vorbehalten O7/O8
Zielbild: NTX bleibt System of Record für Abo/Faktura/Debitoren. Das CRM führt Vertrieb/Leads/
Gremien. Im CRM entsteht ein read-only Abo-/Vertragsspiegel je Kunde, verknüpft über die
ntx_debitorennr als stabilen Fremdschlüssel. Vor dem ersten Integrationsbau steht eine
Data-Ownership-Matrix (welches System ist Master je Feld).
⚠ O7 — die Architektur steht auf einer Annahme (Entscheidungspunkt 1, terminkritisch): Es gibt keine öffentlich dokumentierte NTX-API; der „NTX-Connector" ist eine Agentur-Projektlösung. Die Herstelleranfrage an GRÜN Software Medien (drei Fragen: dokumentierte API? DB-Zugriff/Read-Replica? Preis/Konditionen eines Connectors?) muss sofort raus — Antwortzeit ist nicht in unserer Hand.
Fallback ist eingeplant, nicht optional: Bis eine API bestätigt ist, wird der Spiegel über
periodischen CSV-Export aus NTX befüllt (täglich/wöchentlich, Import-Job mit Upsert über
ntx_debitorennr). Das ist funktional ausreichend für den Pilot — nur nicht echtzeitfähig.
⚠ O8 — der NTX-Lock-in ist vertraglich hart (AGB 02/2024: Datenherausgabe nur auf Anforderung, kostenpflichtig, Medium/Format nach Wahl des Herstellers, Löschung 14 Tage nach Vertragsende, kein Migrationskapitel). Konsequenzen für die Roadmap:
- Kundendaten nicht weiter in NTX vertiefen — Neues entsteht im CRM (eigene Datenhoheit).
- Früh und regelmäßig vollständige Datenabzüge aus NTX sichern (solange der Vertrag läuft).
- Jede spätere NTX-Ablöse-Diskussion beginnt mit der Export-Frage, nicht mit der Funktionsfrage.
Strategische Notiz (O6, nicht Teil dieser Roadmap): weclapp (deutsches Cloud-ERP+CRM mit Vertragsmodul) ist der einzige Benchmark-Kandidat, der die NTX-Frage auch als Ablösepfad denken lässt — als Option für die Mittelfrist-Diskussion dokumentiert, bewusst nicht projektiert.
5. DSGVO & AVV (ab Phase 3, vor Go-live #BR26)
| Punkt | Was zu tun ist | Wann |
|---|---|---|
| AVV | Bei Self-Hosting auf eigener Infrastruktur entfällt der CRM-AVV; AVV nötig mit Hoster/RZ (falls extern) und ggf. Mail-Versanddienst der DOI-Strecke | vor Phase 3 |
| VVT | Eigener Eintrag für das CRM (Zwecke: Lead-Management, Vertrieb; Löschfristen definieren — z. B. Leads ohne DOI nach X Monaten) | vor Go-live |
| DOI | Double-Opt-in für jede E-Mail-Werbeeinwilligung (BGH-Standard); Nachweis-Speicherung im CRM — im Labor bei EspoCRM end-to-end belegt | Phase 3 |
| Landingpage | TDDDG beachten (Cookies/Tracking minimal), UTM ohne Personenbezug, Honeypot statt CAPTCHA-Drittdienst, keine personenbezogenen Daten in URLs | Phase 3 |
| Art. 9-Vorsicht | Keine Felder, die Gewerkschaftszugehörigkeit von Einzelpersonen abbilden — Gremienbezug ist Organisationsdatum, personenbezogene Zuspitzung vermeiden; DSB einbinden | Datenmodell-Design |
| DSFA | Für klassisches B2B-CRM voraussichtlich nicht zwingend; neu bewerten, sobald KI-Lead-Scoring (KARO) aktiviert wird | vor KI-Features |
| TOM | Siehe Betriebskonzept §3 (Verschlüsselung, Rollen, Backups, Audit-Log konfigurierbar) | laufend |
| DSB | Datenschutzbeauftragte:n früh einbinden — spätestens mit dem VVT-Entwurf | Phase 3 |
6. Mitbestimmung (parallel zu Phase 3–5)
Ein CRM ist regelmäßig eine technische Einrichtung i. S. v. § 87 Abs. 1 Nr. 6 BetrVG (objektiv zur Verhaltens-/Leistungskontrolle geeignet) — ohne Mitbestimmung kein regulärer Betrieb.
- Pilot: per Festlegung #4 informell geklärt (Benjamin) — sauber abgesichert über eine Regelungsabrede für den Pilotzeitraum (Zweck, Nutzerkreis, keine individuellen Leistungsauswertungen, Löschung bei Abbruch).
- Vor echtem Go-live/Rollout: Betriebsvereinbarung verhandeln. Kerninhalte: Zweckbindung, Auswertungsverbote (keine individuelle Leistungskontrolle), Umgang mit Logdaten/Audit-Log (aggregierte Auswertung), Rollen-/Rechtekonzept, Change-Prozess für neue Module/Felder, Beteiligung bei KI-Funktionen (Lead-Scoring!).
- Zuständigkeit klären: bei unternehmenseinheitlicher Einführung GBR statt örtlicher BR.
- Transparenz als Haltung: Der Verlag ist Betriebsräte-Fachverlag — die eigene CRM-Einführung sollte das Lehrbuchbeispiel einer sauberen Mitbestimmung sein. Das ist auch ein Vorzeigbarkeits-Argument.
7. Rollout-Stufen (Phase 5, Q4/2026 → Q1/2027)
- Entra-SSO aktivieren (jetzt Pflicht per Festlegung #3): Odoo/EspoCRM gratis (OIDC, im Labor belegt); bei Twenty Enterprise-Subscription — Preis liegt dann aus Entscheidungspunkt 2 vor.
- BV abschließen (§6) — Voraussetzung für die Ausweitung über den Pilotkreis hinaus.
- NTX-Spiegel produktiv (API oder CSV-Kadenz, je nach Antwort aus Entscheidungspunkt 1) + Data-Ownership-Matrix verbindlich.
- Companion-Marketing andocken (die belegte Antwort auf die größte OSS-Lücke): Mautic, AGNITAS OpenEMM oder Keila self-hosted neben dem CRM; Anbindung via Webhooks/n8n. Auswahl-Spike 1–2 Tage, erst nach stabilem Pilotbetrieb.
- Nutzerkreis erweitern (weitere Vertriebs-/Marketingbereiche), dann erst über Support/Ticketing (Prio ④, Track D: Zammad/OTOBO) entscheiden.
- T4b-Gremienmodell ausbauen (Wahlperioden-Workflows, Stichtagsreports) — auf dem in Phase 2 gebauten Fundament.
8. Risiken & Gegenmaßnahmen
| Risiko | Eintritt | Gegenmaßnahme |
|---|---|---|
| NTX-Anfrage bleibt unbeantwortet / API existiert nicht | mittel–hoch | CSV-Fallback ist eingeplant (§4); Koexistenz funktioniert auch ohne Echtzeit |
| Twenty-SSO-Preis unverhältnismäßig | mittel | Festlegung #3 gibt Zeit bis Q4; Odoo/EspoCRM haben gratis SSO — fließt in die Systementscheidung ein |
| Prototypen nicht rechtzeitig fertig (~19.08.) | niedrig | Entkopplung Landingpage↔CRM: #BR26-Strecke kann notfalls gegen einen n8n-Puffer live gehen, CRM-Anbindung folgt |
| Adoption im Pilot schwach | mittel | Champion, Start mit echten #BR26-Leads, SLA sichtbar machen, Pilot-Review mit klaren Metriken |
| Betriebs-Know-how konzentriert sich auf eine Person (Bus-Faktor) | mittel | Runbooks aus dem Lab übernehmen, Restore-Übungen im Quartal, zweite Person einarbeiten |
| KI-Features triggern DSFA/Mitbestimmung ungeplant | mittel | KI-Scoring erst nach DSFA-Neubewertung + BV-Passus (§5/§6) |
Bund-Verlag · CRM-Marktanalyse · Interne Entscheidungsunterlage — Veranstaltungsbezeichnung ausschließlich „#BR26".