CRM-Marktanalyse Bund-Verlag — Gesamtanalyse & Management Summary
Stand: 24.07.2026 · Projekt: BV-CRM-2026 · Autor: IT-Services (Recherche-Lauf Runde 2, AP1–AP5) Datenbasis: 184 gesichtete Systeme · 30 Steckbriefe · 8 Deep-Dives · 4 Labortests mit echten Installationen · adversariale Verifikation (15 Prüf-Agenten) · kommerzielle Messlatte (14 Systeme) Interaktives Begleit-Artefakt: vergleichsmatrix.html — Gewichte live verschiebbar
Teil I — Management Summary
Auftrag
Der Bund-Verlag sucht ein neues CRM: zuerst für das KI-Produkt KARO, mittelfristig als Baustein zur Ablösung des Bestands-ERP NTX (das vorerst führend für Abo/Faktura/Debitoren bleibt). Harter, terminierter Use-Case: #BR26, 16.–17.09.2026 in Berlin — QR-Code am Stand → Landingpage → Lead per API ins CRM. Systementscheidung bis ~19.08.2026. Leitplanke der Geschäftsführung (Festlegung #1): Anpassbarkeit schlägt Lizenzkosten — Open Source und Self-Hosting werden priorisiert, Geld ist kein Showstopper.
Vorgehen in einem Absatz
Statt Anforderungslisten gegen Herstellerprospekte zu halten, wurde prototypen-getrieben gearbeitet: Vier Kandidaten (Twenty, EspoCRM, Odoo, Frappe CRM) wurden real installiert und gegen ein einheitliches Testprotokoll (T1–T11) mit echten API-Schreibtests geprüft. Parallel lief ein Multi-Agent-Marktsweep über neun Suchmodi (184 Systeme gesichtet), dessen kritische Behauptungen anschließend adversarial verifiziert wurden — jede kritische Aussage von mehreren unabhängigen Prüfern gegen Primärquellen (Repo, LICENSE, Pricing-Seiten) gehalten. Die Methode hat sich doppelt bezahlt gemacht: Ein vermeintlicher Lizenz-K.-o. bei Twenty erwies sich als Fehlalarm, zwei vermeintliche K.-o. bei Odoo waren schon im Labor widerlegt worden. Messwert schlägt Web-Recherche.
Das Ergebnis: Top 3 für das Prototyping — drei Profile für drei Prioritäten
| System | Score* | Profil — wann dieses System gewinnt | |
|---|---|---|---|
| 🥇 | Odoo 19 CE | 81 | Funktions-Allrounder: breiteste native Abdeckung, einziger Kandidat, der #BR26 komplett nativ baut, rundestes M365-Profil (gratis Entra-SSO + Graph-Kalender-Sync, im Labor verifiziert), volles Deutsch. Offene Flanke: die strategische Zweit-ERP-Frage neben NTX. |
| 🥈 | Twenty | 80 | Zukunfts- und Hackability-Kandidat: moderner TypeScript-Stack, nativer MCP-Server mit 215 Tools (im Labor verifiziert), Auto-REST/GraphQL — die direkte Antwort auf Festlegung #1. Preis: #BR26 braucht Vorbau (kein Web-to-Lead), SSO ist Enterprise, ~1,9 GB RAM. |
| 🥈 | EspoCRM | 80 | Die sichere Bank: einziger Kandidat, dessen #BR26-Kernflow im Labor komplett durchlief (Lead-API, Dublettenschutz, DOI end-to-end), bestes Datenmodell ohne Code, schlankster Betrieb (~207 MB), gratis SSO. Kein MCP, kein Graph-Sync. |
* Gewichteter Score 0–100 mit den Startgewichten; die Gewichtung entscheidet, nicht der 1-Punkt-Abstand. Die Sensitivitätsanalyse zeigt: höheres Gewicht auf Hackability (K1) → Twenty auf Platz 1; auf Funktionsbreite (K4) → Odoo baut aus; auf Datenmodell (K3) → EspoCRM vorn. Genau deshalb ist die interaktive Matrix Teil dieser Lieferung — das Ranking ist live nachrechenbar.
Es gibt keinen eindeutigen Sieger über alle Gewichtungen. Die Empfehlung lautet daher bewusst Top 3, nicht Top 1: Alle drei gehen mit dem #BR26-Szenario und dem neuen T4b-Bauteil in den Phase-2-Prototyp; die Entscheidung fällt an gebauten Prototypen, nicht an Papierwerten.
Die vier Funde, die man kennen muss
- Twenty-Lizenzalarm war ein Fehlalarm. Der Marktsweep meldete „nicht Open Source"; die Verifikation am LICENSE-Volltext widerlegte das: Der Kern ist AGPL-3.0, REST-API- und API-Key-Modul tragen keinen Enterprise-Marker — der #BR26-Use-Case ist lizenzfrei baubar. Bestehen bleibt: SSO ist Enterprise, der Self-Host-Preis ist nicht öffentlich (→ Entscheidungspunkt 2).
- Der NTX-Hersteller ist identifiziert (GRÜN Software Medien GmbH; per Logo-Bildvergleich auf der
Referenzseite bestätigt) — aber es gibt keine öffentlich dokumentierte NTX-API. Die geplante
Koexistenz-Architektur (Abo-Spiegel im CRM über
ntx_debitorennr) steht damit auf einer unbestätigten Annahme (→ Entscheidungspunkt 1). Zusätzlich verschärfend: Die NTX-AGB (02/2024) enthalten harten Lock-in — Datenherausgabe nur auf Anforderung, kostenpflichtig, ohne zugesagtes Format, Löschung 14 Tage nach Vertragsende, kein Migrationskapitel. - Neue fachliche Anforderung T4b: Für einen Betriebsrätverlag, dessen Kundenstruktur sich alle vier Jahre durch BR-Wahlen neu sortiert, müssen Gremienrollen zeitbefristet und historisiert abbildbar sein („Wer war am 01.10.2026 Vorsitzende?"). Kein Standard-CRM löst das über die native Beziehung — überall braucht es ein Zwischenobjekt mit Gültigkeitszeitraum; nur CiviCRM kann es nativ. Im Labor wurde das bei keinem Kandidaten praktisch gebaut (→ Entscheidungspunkt 3).
- MCP ist 2026 Marktstandard geworden. HubSpot, Attio, Pipedrive, Dynamics, Zoho, folk und Close haben herstellergepflegte MCP-Server ausgeliefert — kein einziger deutscher Mittelstandsanbieter hat einen. Das relativiert Twentys Alleinstellung, ist aber zugleich das stärkste strukturelle Argument für den OSS-Weg: Souveränität + KI-Modernität gibt es 2026 nur selbstgehostet zusammen.
⚠ Die offenen Entscheidungspunkte
Stand 25.07.2026: Von ursprünglich drei Punkten sind zwei offen — der dritte (T4b) wurde inzwischen praktisch nachgewiesen.
| # | Punkt | Warum es drängt | Nächster Schritt |
|---|---|---|---|
| 1 | NTX-Herstelleranfrage (PROGRESS O7/O8) | Terminkritisch. Ohne bestätigte Schnittstelle steht die NTX-Koexistenz-Architektur auf einer Annahme; die NTX-AGB machen den Lock-in zusätzlich hart. | Anfrage an GRÜN Software Medien mit 3 Fragen (API? DB-Zugriff? Connector-Preis?) — CSV-Export-Fallback fest einplanen, nicht optional. |
| 2 | Twenty-SSO-Preis (O4-Rest) | Entra-SSO ist bei Twenty Enterprise; der Self-Host-Preis ist nicht öffentlich. SSO ist erst zum Rollout Q4 Pflicht (Festlegung #3), aber der Preis gehört vor die Systementscheidung. | Anfrage an Twenty.com: Self-Host-Enterprise-Subscription für Entra-SSO. |
| ~~3~~ | ✅ T4b erledigt (O9 geschlossen) | Die fachlich zentrale Gremien-Historie war bei keinem Laborsystem nachgewiesen. | Am 25.07. in allen drei Top-Systemen gebaut und geprüft: Zwischenobjekt „Gremiumsmitgliedschaft" mit Gültigkeitszeitraum, Stichtagsabfrage liefert überall die zum Datum amtierende Person, Historie bleibt erhalten. Bericht: lab/T4B-NACHTEST.md. |
Was der T4b-Nachtest zusätzlich ergab: Alle drei erfüllen die Anforderung fachlich, aber nicht gleich elegant. EspoCRM und Twenty liefern nach dem Anlegen sofort ein nutzbares Objekt; bei Odoo fehlen danach noch Zugriffsrechte und Oberflächen-Ansichten. Das bestätigt den K3-Abstand (EspoCRM 5 · Twenty 4 · Odoo 3) empirisch.
Was der kommerzielle Weg kosten würde (Preisanker)
HubSpot Sales Professional für ein 10-Personen-Pilotteam: ~12.000 USD/Jahr + 3.500 USD Onboarding, mit der Kontaktzahl steigend — bei einem großen Abonnentenstamm potenziell prohibitiv. Der OSS-Weg tauscht diese wachsenden Lizenzkosten gegen einmaligen Aufbau-Aufwand plus laufenden Betrieb bei voller Datenhoheit. Unter Festlegung #1 ist das kein Kosten-, sondern ein Kompetenz- und Kontroll-Argument: Man kauft Souveränität und Hackability, nicht Ersparnis.
Empfohlene nächste Schritte
- Gewichte bestätigen (30 Min mit der interaktiven Matrix) — das Ranking ist bis dahin vorläufig.
- Beide Anfragen versenden (NTX-Hersteller, Twenty-SSO-Preis) — Laufzeit einkalkulieren.
- Phase-2-Prototyp der Top 3 — das T4b-Bauteil steht bereits in allen drei Systemen, offen ist noch die vollständige #BR26-Strecke je System (Details: roadmap.md).
- Entscheidung bis ~19.08.2026, damit die #BR26-Strecke rechtzeitig produktiv steht.
Teil II — Gesamtanalyse
1. Methodik: Warum diesen Zahlen zu trauen ist
Drei Erhebungsebenen, absteigend belastbar:
- Labor (4 Systeme): Twenty, EspoCRM, Odoo 19 CE und Frappe CRM wurden real installiert
(Docker) und gegen das einheitliche Testprotokoll T1–T11 geprüft — mit echten
API-Schreib-/Speichertests, nicht mit UI-Sichtprüfungen. Ergebnisberichte:
lab/*/ERGEBNIS.md. - Deep-Dive (4 weitere): SuiteCRM, CiviCRM, NocoBase, berliCRM wurden gegen Primärquellen (Repo, LICENSE, Release-Historie, Doku) analysiert.
- Steckbrief (30) / Sichtung (184): Der Multi-Agent-Sweep über 9 Suchmodi lieferte die Marktbreite; 30 Systeme erhielten Steckbriefe, der Rest wurde mit Begründung aussortiert (Entscheidungslog, §6).
Die methodische Kernlehre des Projekts (im Labor entstanden, mehrfach bestätigt):
Ein sichtbares Konfig-Formular ist kein Beweis für Verfügbarkeit. Twentys Community Edition zeigt die SSO-Maske — der Server blockt beim Speichern. Übertragen: Herstellerseiten sind Behauptungen, keine Belege. Jede kritische Aussage wurde deshalb gegen Repo/LICENSE/Pricing geprüft; sechs Behauptungen durchliefen zusätzlich eine adversariale Verifikation mit 15 unabhängigen Prüf-Agenten (
research/verifikation.md). Bilanz: 1 widerlegt · 2 bestätigt · 3 teilweise — und in vier Fällen war der eigentliche Risikofaktor ein anderer als der behauptete.
Das prominenteste Beispiel: Bei Twentys MCP-Server kamen beide Web-Prüfer zu „ungeklärt, Doku ist 404" — der eigene Labortest hatte die Frage längst empirisch beantwortet (nativer MCP end-to-end, 215 Tools, auch für Custom Objects). Messwert schlägt Doku-404. Das ist das Argument für prototypen-getriebenes Vorgehen in einem Satz.
2. Das Feld: 184 → 30 → 8 → 3
| Stufe | Umfang | Artefakt |
|---|---|---|
| Sweep (9 Suchmodi, 246 Nennungen) | 184 eindeutige Systeme | research/longlist.md |
| Longlist Track A (self-hostbare CRM-Kandidaten) | 30 Systeme, je ein Steckbrief | research/steckbriefe/ |
| Deep-Dive | 8 Systeme | research/deep-dives/ |
| Empfehlung Prototyping | 3 Systeme | diese Analyse + vergleichsmatrix.html |
Die Longlist ist in fünf Tracks geschnitten: A CRM-Kandidaten (30) · B kommerzieller Benchmark (14) · C Verlags-/Verbands-/Abo-Referenzsysteme · D Companion-Tools (Marketing, Formulare, Support) · E gesichtet und mit Begründung verworfen. Diese Struktur hält die Frage „habt ihr X geprüft?" dauerhaft beantwortbar.
3. Bewertungsmatrix K1–K9: Ergebnis und Sensitivität
Kriterien und Startgewichte aus RECHERCHEPLAN §2 (K1 Hackability 20 · K2 API 15 · K3 Datenmodell 15 ·
K4 Funktionsabdeckung 15 · K5 Community/Lizenz 10 · K6 Betrieb 10 · K7 DSGVO 5 · K8 M365 5 ·
K9 TCO/Exit 5). Vollständige Scores: research/matrix/bewertungsmatrix.md.
Ranking mit Startgewichten: Odoo 81 · Twenty 80 · EspoCRM 80 · Frappe 70 · NocoBase 70 · SuiteCRM 68 · CiviCRM 56 · berliCRM 55.
Die drei Laborsysteme liegen an der Spitze und clustern eng — kein Zufall: Es sind die einzigen mit belegten Messwerten, und ihre Reife zeigt sich. Entscheidend ist die Sensitivität:
| Wird höher gewichtet … | … steigt | … weil |
|---|---|---|
| K1 Hackability (Festlegung #1!) | Twenty klar auf 1 | einziges K1=5 |
| K4 Funktionsabdeckung | Odoo, SuiteCRM | beide K4=5 |
| K3 Datenmodell/T4b | EspoCRM, NocoBase | beide K3=5 |
| K8 M365 | Odoo baut aus | einziges K8=5 |
| K6 Betrieb/Ressourcen | EspoCRM | K6=5, Faktor ~9 leichter als Twenty |
4. Die acht Deep-Dive-Systeme im Urteil
Die Top 3 (Empfehlung, siehe Management Summary): Odoo · Twenty · EspoCRM.
Bewusst nicht in der Top 3, aber als dokumentierte Optionen erhalten:
| System | Score | Rolle | Kernbefund |
|---|---|---|---|
| Frappe CRM | 70 | Purist-Alternative | Kein Open-Core, exzellentes DocType-Modell — aber schwächster Dublettenschutz, ~42 % deutsche UI, kein Graph-Sync. Lohnt nur mit akzeptiertem Eigenbau. |
| NocoBase | 70 | „Bauen statt kaufen" | Kein CRM, sondern beste No-Code-Plattform: Auto-API mit Upsert + gratis Public Forms lösen #BR26/NTX-Spiegel/T4b ohne Fremdcode — aber Pipeline/Kampagnen/Support komplett Eigenbau, Entra-SSO einmalig 8.000 $. Gehört in die Roadmap-Diskussion. |
| SuiteCRM 8 | 68 | Funktions-Sicherheitsnetz | Einziger OSS mit voller nativer Funktionsabdeckung (inkl. Vertragsobjekt AOS_Contracts) — aber SugarCRM-Kern von 2013 und Zwei-Personen-Bus-Faktor. |
| CiviCRM | 56 | Gremien-Spezialist | Einziges System mit nativem T4b (end-datierte Relationships). Aber kein natives Pipeline-Objekt — Kandidat für eine separate Gremien-/Mitgliederdatenbank, nicht als Vertriebs-CRM. |
| berliCRM | 55 | Deutscher Außenseiter | Einziger durchgehend deutschsprachiger OSS-Kern mit deutschem Träger — aber vtiger-6.5.0-Kern von 2015, und zum Stichtag existiert kein PHP-8-Release. |
5. Die kommerzielle Messlatte: was 2026 „normal" ist
Details: research/benchmark/messlatte.md. Die drei Kernaussagen:
- State of the Art 2026 = flexible Objektmodellierung + nativer KI-/MCP-Anschluss + Marketing aus einem Guss (Referenzen: Attio, HubSpot). Von den OSS-Kandidaten kommt Twenty dem am nächsten.
- Die deutschen Mittelstandsanbieter (weclapp, CAS genesisWorld, cobra, CentralStation, TecArt, SuperOffice) sind technisch konservativ und ohne MCP — wer souverän und modern will, findet im kommerziellen Feld keine Antwort. Das ist das stärkste strukturelle Argument für den OSS-Weg.
- Die schmerzhafteste OSS-Lücke ist Marketing-Automation. Die belegte Antwort ist der Companion-Ansatz (Mautic, AGNITAS OpenEMM oder Keila neben dem CRM — Track D), nicht ein anderes CRM.
TCO-Anker (10 Nutzer/Jahr, Größenordnungen): HubSpot Professional ~12.000 USD + Onboarding · Dynamics 365 Enterprise ~12.600 USD · Zoho Enterprise ~4.800 USD · OSS self-hosted 0 € Lizenz + Betrieb/Personal (+ ggf. Einmalkäufe: EspoCRM Advanced Pack ~395 $, Twenty-Enterprise für SSO — Preis offen).
6. Konsolidiertes Entscheidungslog
6.1 Die 13 Prozessentscheidungen des Recherche-Laufs (E1–E13, Kurzfassung)
| # | Entscheidung |
|---|---|
| E1 | Die vier Laborsysteme werden nicht neu recherchiert — Messwerte schlagen Web-Behauptungen. |
| E2 | Sweep über 9 Suchmodi statt der 4 geplanten (KI-native, Companion- und Benchmark-Modus ergänzt). |
| E3 | Benchmark-Track (AP4) im Sweep mit erhoben statt separat. |
| E4 | Longlist in 5 Tracks geschnitten statt flach auf 40 gekürzt — erhält die Nachvollziehbarkeit. |
| E5 | Verlags-/Abo-Systeme (knk, Klopotek, GRÜN VEWA, plenigo …) nicht in Track A — sie besetzen die NTX-Rolle, kein CRM-Ersatz. |
| E6 | Django-CRM und Day.ai per K.-o. „keine brauchbare API" ausgeschlossen. |
| E7 | Twenty trotz Lizenzzweifel in Track A belassen — erst verifizieren, dann entscheiden. ✅ Bewährt: Der Befund war falsch. |
| E8 | MCP-Kriterium von „hat MCP ja/nein" auf Drei-Stufen-Raster umgestellt (Träger · Sicherheitszyklus · Schreibrechte). |
| E9 | metasfresh und hitobito nach Track C verschoben statt verworfen (Abo-Datenmodell bzw. T4b-Blaupause). |
| E10 | NextCRM bleibt als Referenz in Track A, ist aber ausdrücklich kein #BR26-Kandidat (Security). |
| E11 | T4b als neue Anforderung aufgenommen (zeitbefristete Gremienrollen mit Historie). |
| E12 | Deep-Dive auf 8 Systeme: die 3× JA + Frappe + je ein Vertreter der stärksten Archetypen. |
| E13 | No-Code-Plattformen nicht einzeln deep-getaucht — NocoBase als Vertreter des Archetyps genügt. |
6.2 Verworfene bzw. umsortierte Systeme mit Ein-Satz-Begründung
Aus Track A umsortiert oder markiert:
| System | Begründung |
|---|---|
| metasfresh | Kein Vertriebs-CRM (Opportunities = Tickets mit Prozentwert, kein Lead-Endpunkt) — bleibt als Abo-/Vertragsdatenmodell-Referenz in Track C. |
| hitobito | Mitgliederverwaltung ohne Pipeline und ohne Webhooks — bleibt als T4b-Blaupause (BR-Amtsperioden) in Track C. |
| NextCRM | 2 Critical-Security-Advisories (22.07.2026) und kein Mandantenmodell — nur noch MCP-/Architektur-Referenz. |
K.-o. „totes Projekt" (>12 Monate ohne nennenswerte Aktivität):
| System | Begründung |
|---|---|
| X2CRM | Letzter Push 26.12.2022 — 3,5 Jahre tot, wird in Listicles trotzdem als „Top Open Source CRM" geführt. |
| Flectra | Letzter Commit 24.10.2024, letztes Release 2021 — der Odoo-Fork löst seine Versprechen nicht mehr ein. |
| YetiForce | Haupt-Repo im August 2025 archiviert, Nachfolge ohne sichtbaren offenen Code. |
| Zurmo CRM | Mutmaßlich seit Jahren eingestellt (nicht abschließend verifiziert). |
| ConcourseSuite | Status unklar, einzige Quelle eine ungeprüfte Vergleichsliste. |
| openCRX | Keine Primärquelle zu Releases auffindbar; DSGVO-Behauptung stammt aus einem SEO-Listicle. |
| SplendidCRM CE | Lizenz, Aktivität, API, Lokalisierung — nichts verifizierbar. |
K.-o. „keine brauchbare API":
| System | Begründung |
|---|---|
| Django-CRM (DjangoCRM.github.io) | Läuft primär über Django Admin, keine dedizierte externe API — #BR26-Flow müsste selbst gebaut werden. |
| Day.ai | MCP ja, aber keine belegte REST-API/Webhooks — MCP allein trägt keinen Inbound-Lead. |
Falsche Kategorie / falscher Zuschnitt:
| System | Begründung |
|---|---|
| Monica | Explizit Personal CRM für Freunde/Familie; 24.900 Stars täuschen B2B-Relevanz vor. |
| Tryton | Sauberes Python-ERP, aber kein natives CRM-/Marketingmodul. |
| Huly | All-in-One-Kollaborationsplattform, kein dediziertes Vertriebs-CRM. |
| IDURAR ERP/CRM | Schlanke Invoicing-App mit rudimentärem CRM. |
| ITFlow | PSA für IT-Dienstleister — falsche Branchenlogik. |
| Horilla CRM | HR-gekoppelt, für reinen CRM-Bedarf falsch geschnitten. |
| Macro | AI-natives Arbeits-Frontend; CRM als Beiwerk zum Kommunikations-Client. |
| DenchClaw | Early-Stage-Agent, Repo verweist auf Migration zum kommerziellen Produkt. |
| wacrm | WhatsApp-zentriert — Kanal-Fokus passt nicht, DSGVO-Problem durch Meta. |
| Openbravo | Retail-/Hospitality-Schwerpunkt, OSS-Linie fraglich. |
| ONLYOFFICE CommunityServer | Produktstrategie sichtbar zu Docs/DocSpace gewandert; CRM-REST-API nicht mehr gelistet. |
Zu jung / zu klein für ein Produktivsystem:
| System | Begründung |
|---|---|
| crmkit | Pre-1.0 mit angekündigten Breaking Changes, ~32 Stars. |
| Hubleto | 39 Stars, 49 offene Issues — Beobachtungs-, kein Evaluationskandidat. |
| Warpdrive | Nichts verifiziert; einzige Quelle ist eine Liste desselben Autors. |
| Aureus ERP | 2025/2026 entstanden; Reifegrad und CRM-Tiefe unbelegt. |
| Open Mercato | Eigenbau-Fundament, kein fertiges CRM. |
| IOTA SDK | CRM-Modul laut eigener Roadmap „Work In Progress". |
| Fat Free CRM | Noch gepflegt, aber API und Lokalisierung unbelegt. |
| DaybydayCRM | Keine belegte API, Vue-2-Altlast (EOL). |
| Django-CRM (MicroPyramid) | API-first, aber deutsche Lokalisierung und Funktionstiefe unbelegt. |
Sprach-/Rechtsraum unpassend:
| System | Begründung |
|---|---|
| CordysCRM | UI ausschließlich chinesisch, Lizenz mit Zusatzbeschränkungen. |
| WukongCRM | Chinesisches Microservices-CRM, Lizenz unbekannt. |
| Rebuild | Chinesisches Low-Code-Portal, sprachlich nicht praktikabel. |
| Vtiger (Open Source) | Community-Edition stiefmütterlich gepflegt, kein offizielles Docker-Image. |
| Axelor Open Suite | Schwache UX, überdimensioniert (Marmelab-Schlusslicht). |
| 1CRM | „99 % Open Source" ist keine Open-Source-Lizenz — de facto source-available. |
| Bitrix24 On-Premise | Kauf-Lizenz, source-available, russischstämmiger Anbieter. |
(Vollständige Track-E-Liste mit Belegen: research/longlist.md.)
7. Offene Punkte und Vorbehalte (über die drei Entscheidungspunkte hinaus)
| # | Punkt | Auswirkung |
|---|---|---|
| O1 | Gewichte K1–K9 sind ein Startvorschlag, nicht bestätigt. | Ranking vorläufig; Matrix ist live verschiebbar. |
| O2 | Anforderungskatalog aus dem parallelen Management-Projekt liegt nicht vor. | Bewertung kann sich verschieben; nicht überdehnen. |
| O3 | Konkrete NTX-Schmerzpunkte nicht erhoben. | Koexistenz-Bewertung an dieser Stelle generisch. |
| O5 | 26 der 30 Track-A-Bewertungen stammen aus Web-Recherche. | Labor-Lehre gilt doppelt; kritische Aussagen wurden gegen Repo/LICENSE geprüft. |
| O6 | weclapp (DE-Cloud-ERP+CRM, Vertragsmodul 55 €/Mon.) könnte die NTX-Frage auch als Ablösepfad denken. | Strategische Option für die Roadmap-Diskussion, bisher nicht projektiert. |
8. Glossar (Auswahl der entscheidungsrelevanten Begriffe)
Basis: research/glossar.md (~60 Begriffe, lebendes Dokument). Hier die für diese Analyse zentralen:
AGPL (GNU Affero General Public License) — Strenge Open-Source-Lizenz: Wer die Software verändert und über ein Netzwerk anbietet, muss den geänderten Quellcode offenlegen. Gilt nach §13 auch gegenüber eigenen Mitarbeitenden (kein Zwang zur öffentlichen Veröffentlichung).
API / API-first — Programmierschnittstelle für den Datenaustausch zwischen Systemen; API-first heißt: jede Funktion ist über die API erreichbar, die Oberfläche ist nur ein Client. Pflicht für #BR26-Flow und NTX-Koexistenz.
AVV (Auftragsverarbeitungsvertrag) — Nach Art. 28 DSGVO zwingender Vertrag mit jedem Dienstleister, der personenbezogene Daten im Auftrag verarbeitet.
BetrVG § 87 Abs. 1 Nr. 6 — Erzwingbares Mitbestimmungsrecht des Betriebsrats bei technischen Einrichtungen, die zur Verhaltens-/Leistungskontrolle geeignet sind. Ein CRM fällt regelmäßig darunter — ohne Betriebsvereinbarung kein Go-live.
BV / Regelungsabrede — Betriebsvereinbarung: verbindliche Regelung zwischen Arbeitgeber und Betriebsrat (z. B. Auswertungsverbote, Logdaten). Eine Regelungsabrede ist die formlosere Variante, geeignet zur Absicherung eines Pilotbetriebs.
CDP (Customer Data Platform) — Führt Kundendaten aus vielen Quellen zu Marketing-Profilen zusammen; kein Ersatz für ein CRM und für dieses Projekt kein Bedarf.
CRM (Customer Relationship Management) — System für Kontakte, Vertriebspipeline, Aktivitäten, Kampagnen. Das gesuchte System.
Debitorennummer — Kundennummer aus dem ERP; dient als stabiler Fremdschlüssel (ntx_debitorennr) zwischen CRM und NTX.
DOI (Double-Opt-in) — Zweistufige Einwilligung per Bestätigungsmail; in Deutschland de facto Pflicht als gerichtsfester Nachweis für E-Mail-Werbung.
DSFA (Datenschutz-Folgenabschätzung) — Risikoanalyse nach Art. 35 DSGVO; bei klassischem B2B-CRM meist nicht zwingend, bei KI-Scoring neu zu bewerten.
Entitlement — Berechtigung eines Kunden auf eine Leistung (Abo, Lizenz). Bleibt führend in NTX.
ERP — System für Innenprozesse (Buchhaltung, Billing, Abo-Verwaltung). Bei uns NTX; bleibt neben dem CRM bestehen.
MCP (Model Context Protocol) — Offener Standard, über den KI-Assistenten direkt auf Systeme wie CRMs zugreifen. 2026 im kommerziellen Markt Standard geworden; bei deutschen Anbietern Fehlanzeige.
Open Core — Geschäftsmodell: Kern Open Source, wichtige Funktionen (z. B. SSO, Reporting) kostenpflichtig. Beispiele im Feld: Twenty (SSO Enterprise), EspoCRM (Advanced/Sales Pack), Odoo (Enterprise-Apps).
PQL (Product-Qualified Lead) — Lead, der sich durch tatsächliche Produktnutzung (z. B. Testzugang) qualifiziert — relevant für ein KI-Produkt wie KARO.
Self-Hosting — Betrieb auf eigener Infrastruktur; volle Datenkontrolle (DSGVO-/Mitbestimmungs-Vorteil), aber eigene Verantwortung für Betrieb, Updates, Sicherheit (TOM).
SSO (Single Sign-On) — Anmeldung mit dem zentralen Firmenkonto (Entra ID/M365) via SAML/OIDC. Pflicht erst zum Rollout Q4 (Festlegung #3).
T4b — Projektspezifische Anforderung: zeitbefristete, historisierte Zuordnung von Personen zu Gremien mit Funktion („Wer war am Stichtag Vorsitzende?"). Lösung überall: Zwischenobjekt mit Gültigkeitszeitraum; nativ nur in CiviCRM.
TCO (Total Cost of Ownership) — Gesamtkosten über die Nutzungsdauer: Lizenzen + Hosting + Personal + Betrieb, nicht nur der Lizenzpreis.
Upsert — API-Operation „Update oder Insert": verhindert Dubletten beim Lead-Eingang.
UTM-Parameter — URL-Anhängsel zur Kampagnen-Zuordnung; Pflicht im QR-Ziel-Link, damit Leads messbar der Quelle #BR26 zugeordnet werden.
Web-to-Lead — CRM-Funktion, über die Website-Besucher ohne Login direkt als Leads im CRM landen (Referenz: EspoCRM Lead Capture).
Webhook — Das System ruft bei einem Ereignis aktiv eine externe URL auf — Basis für Echtzeit-Automatisierung ohne Polling.
Bund-Verlag · CRM-Marktanalyse · Interne Entscheidungsunterlage — Veranstaltungsbezeichnung ausschließlich „#BR26".