Zum Inhalt

Handlungsempfehlung Datenlandschaft SCK

Erstellt: 2026-03-21 | Basiert auf: 62_datenlandschaft_analyse_sync.md Zielgruppe: Entscheidungsträger und IT-Verantwortliche

Zusammenfassung

Die Stiftung Creative Kirche betreibt vier Kernsysteme für Kontakt- und Datenverwaltung:

System Hauptzweck Kontakte
Dynamics 365 Customer Service Service-Center, Teilnehmerverwaltung, Ticketing ≥ 5.000
Brevo Newsletter, E-Mail-Marketing 111.508
FundraisingBox Spendenverwaltung, SEPA, Zuwendungsbescheinigungen 3.597
Business Central Buchhaltung, ERP 144.820

Kernproblem: Kontaktdaten werden in allen vier Systemen parallel gespeichert und gepflegt — ohne zentrales Master Data Management. Die Verknüpfung erfolgt informell über eine gemeinsame Kontaktnummer (z.B. 106369), die aber nicht überall gepflegt ist. Marketing-Listen werden doppelt geführt (D365 + Brevo), Opt-Outs sind nicht systemübergreifend synchronisiert (DSGVO-Risiko), und der Vivenu-Ticketimport erzeugt fehlerhafte Kontaktdaten bei Drittbuchungen.

Zentrale Empfehlung: Business Central als Stammdaten-Master definieren, Marketing komplett in Brevo konsolidieren, Opt-Outs zentral synchronisieren und Datenqualität in allen Systemen bereinigen.

1. Kein Master Data Management

Problem: Es gibt kein führendes System für Kontaktstammdaten (Name, Adresse, E-Mail, Telefon). Bei einer Adressänderung müssen mindestens drei Systeme manuell aktualisiert werden. Brevo speichert gar keine Adressen.

Empfehlung: Business Central als Master für Stammdaten definieren. Die Debitorennummer dient bereits systemübergreifend als Schlüssel — dieses Prinzip konsequent umsetzen.

2. Marketing-Listen doppelt gepflegt

Problem: 568 Listen in D365 CS und 165 Listen in Brevo existieren parallel, viele thematisch identisch (z.B. "Judith ZS Dortmund", "Chorleitende regional", "Ehrenamtliche"). D365-Listen haben keine Versandfunktion — der eigentliche Versand läuft über Brevo.

Empfehlung: Marketing-Listen nur noch in Brevo pflegen. D365-Listen archivieren.

3. Opt-Out nicht synchronisiert (DSGVO-Risiko)

Problem: Sperrlisten existieren in vier verschiedenen Formen: D365-Listen ("WillKeineBriefe"), Brevo-Blacklist, FRB-Flags (wants_no_email/post/call) und BC (keine Sperre). Eine Abmeldung in einem System erreicht die anderen nicht automatisch.

Empfehlung: Brevo als zentrale Opt-Out-Verwaltung. Synchronisation zu D365 und FRB über automatisierte Prozesse.

4. Vivenu-Import fehlerhaft

Problem: Bei Drittbuchungen (Tickets für andere Personen gebucht) legt der Vivenu-Import Kontakte unter dem Namen des Buchenden statt des Teilnehmers an. Diese werden dann fälschlich als Duplikate erkannt und irreversibel gemerged. Dokumentiert am Beispiel Veronika Grewe-Knorr / Barbara Grewe → fälschlich unter "Andreas Knorr" gemerged.

Empfehlung: Import-Logik anpassen oder Merge-Sperre bei unterschiedlichen Geburtsdaten einführen.

5. Datenqualität mangelhaft

Problem: Massive Duplikate in allen Systemen, inkonsistente Telefonnummernformate, drei Brevo-Attribute für dieselbe Information (Singstimme), doppelte Brevo-Listen. Gravierendster Befund: 144.820 BC-Kontakte, davon 99% (143.412) ohne jede ERP-Verknüpfung — ein historisch gewachsener Adress-Friedhof aus mindestens 3 erkennbaren Massen-Imports. Operativ relevant sind nur ~1.400 Kontakte mit Business Relation. Die 2.913 als "gelöscht" markierten Kontakte existieren weiterhin, 379 sind komplett leer.

Empfehlung: Systematische Bereinigung in allen vier Systemen, priorisiert BC (Details in Abschnitt 6, insbesondere 6.6).

6. Maßnahmenplan — Detailliert

6.1 BC als Stammdaten-Master etablieren

Ziel: Kontaktstammdaten (Name, Adresse, E-Mail, Telefon) haben genau eine autoritative Quelle — Business Central.

Sync-Architektur:

BC (Master) ──→ D365 CS (cnsc_kontaktnummer)
             ──→ Brevo (KONTAKTNUMMER_CRM)
             ──→ FRB (external_person_id)

Umsetzungsschritte:

  1. Verknüpfungslücken schließen: Alle D365-Kontakte mit cnsc_kontaktnummer prüfen — fehlt die BC-Verknüpfung (cnsc_bcckmid/bcsckid), nachpflegen. Ebenso FRB-Kontakte ohne external_person_id und Brevo-Kontakte ohne KONTAKTNUMMER_CRM.

  2. Stammdaten-Sync implementieren: Bei Änderung in BC automatisch D365, Brevo und FRB aktualisieren. Technisch umsetzbar über:

  3. BC → D365: Power Automate Flow oder BC-Webhook
  4. BC → Brevo: Brevo API (PUT /contacts/{email})

  5. BC → FRB: FRB API (PUT /persons/{id}.json)

  6. Änderungssperre in Satellitensystemen: Adressänderungen sollten nur noch in BC erfolgen. In D365 und FRB Adressfelder als "read-only" behandeln (organisatorisch, nicht technisch erzwungen).

  7. BC-Kontakte bereinigen (Voraussetzung!):

  8. Leere Kontakte (ohne Name und E-Mail) identifizieren und deaktivieren
  9. Automatisch aus E-Mail-Adressen generierte Einträge (800xxx-Nummernkreis) prüfen
  10. Geschätzt 50.000–100.000 Einträge betroffen

6.2 Marketing komplett in Brevo konsolidieren

Ziel: Brevo ist das einzige System für Marketing-Listen, Segmentierung und E-Mail-Versand.

Umsetzungsschritte:

  1. Listen-Abgleich D365 ↔ Brevo:
  2. Alle 568 D365-Listen exportieren (Namen, Mitglieder)
  3. Prüfen welche bereits als Brevo-Liste existieren

  4. Fehlende Listen in Brevo anlegen und Mitglieder importieren

  5. D365-Listen archivieren:

  6. Status aller D365-Marketing-Listen auf "Inaktiv" setzen

  7. Information an Service-Center: "Neue Listen nur noch in Brevo"

  8. Brevo bereinigen:

  9. Doppelte Listen zusammenführen (identifiziert: PNL WDS Dortmund ID 240 + 300, diverse TN-Listen)
  10. Drei Singstimme-Attribute konsolidieren: CHORSTIMME behalten, Werte aus SING_STIMME und SINGSTIMME migrieren, alte Attribute löschen

  11. Deaktivierten Sender mit Tippfehler (ID 2, "ev-pop-insitut.de") löschen

  12. Segmentierung statt statische Listen:

  13. Brevo-Attribute nutzen (BET_TOURABFRAGE, BUNDESLAENDER, CHORSTIMME) für dynamische Segmente
  14. Reduziert Anzahl manuell gepflegter Listen erheblich

6.3 Zentrales Opt-Out einrichten

Ziel: Eine Abmeldung in einem beliebigen Kanal wirkt in allen vier Systemen.

Umsetzungsschritte:

  1. Brevo als Opt-Out-Master:
  2. Brevo-Webhook konfigurieren: Bei Event "unsubscribed" oder "spam_report" → Script aufrufen

  3. Script aktualisiert parallel:

    • D365 CS: Kontakt in "Marketingmaterial NICHT senden"-Liste aufnehmen
    • FRB: wants_no_email = true setzen via API

  4. D365 → Brevo Rückkanal:

  5. Wenn Service-Center eine DSGVO-Löschung oder Abmeldung bearbeitet (Case-Typ "DSGVO"):

    • Power Automate Flow → Brevo-Blacklist + FRB-Sperre

  6. FRB → Brevo Rückkanal:

  7. Täglicher Batch-Abgleich: FRB-Kontakte mit wants_no_email=true gegen Brevo-Blacklist prüfen

6.4 Vivenu-Import absichern

Ziel: Keine fehlerhaften Kontakte mehr durch Drittbuchungen.

Umsetzungsschritte (Optionen, nach Machbarkeit priorisiert):

  1. D365 Duplikatserkennungsregel anpassen:
  2. Geburtsdatum als Pflichtkriterium für Merge aufnehmen
  3. Wenn Geburtsdaten unterschiedlich → Merge blockieren

  4. Umsetzung: D365 Admin Center → Duplikaterkennungsregeln

  5. Vivenu-Webhook / Post-Import-Script:

  6. Nach jedem Vivenu-Import: Neue Kontakte prüfen
  7. Wenn Kontaktname = vorhandener Kontakt, aber Geburtsdatum anders → Warnung statt Auto-Merge

  8. Flag setzen: "Vivenu-Import — manuell prüfen"

  9. Langfristig: Vivenu-Konfiguration ändern:

  10. Vivenu-Support kontaktieren: Ist es möglich, bei Drittbuchungen den Teilnehmernamen statt des Buchenden zu übernehmen?
  11. Alternative: Separate Vivenu-Kunden-ID pro Teilnehmer (nicht pro Buchung)

6.5 Telefonnummern normalisieren

Ziel: Einheitliches E.164-Format in allen Systemen (+491736167044).

Umsetzungsschritte:

  1. Normalisierungs-Script schreiben:
  2. Input: Diverse Formate (0173..., +49 173..., 49173..., +49(0)173...)
  3. Output: E.164 (+491736167044)

  4. Regeln: Deutsche Nummern (0→+49), bereits internationalisierte beibehalten

  5. Batch-Korrektur pro System:

  6. D365 CS: CRM API PATCH auf telephone1/mobilephone
  7. Brevo: PUT /contacts/{email} mit korrigiertem SMS-Attribut
  8. FRB: PUT /persons/{id}.json mit korrigierten Telefonnummern

  9. BC: BC API PATCH auf phoneNumber

  10. Laufende Normalisierung:

  11. Bei jedem Sync-Vorgang (6.1) Nummern normalisieren

6.6 BC-Kontaktdatenbank bereinigen (144.820 → ~9.000)

Ziel: Die 144.820 BC-Kontakte auf operativ relevante Datensätze reduzieren.

Analyse-Ergebnis (21.03.2026): - 99% der Kontakte (143.412) haben keine Business Relation — sie sind weder Debitor noch Kreditor - Nur 613 Customer + 379 Vendor + 68 Multiple + 348 None = ~1.408 Kontakte sind mit dem ERP verknüpft - 2.913 Kontakte tragen "gelöscht" im Namen, existieren aber weiterhin - 379 Kontakte sind komplett leer (nur Leerzeichen als Name) - Die Masse stammt aus 3 erkennbaren Massen-Imports (200000er: 93.399, 100000er: 31.751, 700000er: 18.690)

Umsetzungsschritte:

Phase 1: Analyse und Sicherung (Claude Code)

  1. Vollständigen Report erstellen:
  2. Alle 143.412 Kontakte ohne Business Relation exportieren (Nummer, Name, E-Mail, Stadt, Erstelldatum)
  3. Gruppieren nach Nummernkreis und Erstelldatum → Import-Batches identifizieren

  4. Abgleich mit D365 CS (cnsc_kontaktnummer), Brevo (KONTAKTNUMMER_CRM) und FRB (external_person_id): Welche BC-Kontakte werden noch von anderen Systemen referenziert?

  5. "gelöscht"-Kontakte auflisten:

  6. 2.913 Kontakte mit "gelöscht" im Namen → Report für Andrea

  7. Prüfen ob sie Posten (Ledger Entries) haben → falls nein: sicher löschbar

  8. Leere Kontakte identifizieren:

  9. 379 Kontakte ohne Namen → Report für Andrea
  10. Diese haben keine Buchungen und können gefahrlos entfernt werden

Phase 2: Bereinigung (Buchhaltung — Andrea Paschen)

  1. Sofort löschbar (kein Risiko):
  2. 379 leere Kontakte (kein Name, keine Daten, keine Posten)

  3. Geschätzt: 5 Minuten Aufwand in BC

  4. Nach Prüfung löschbar:

  5. 2.913 "gelöscht"-Kontakte — falls keine offenen Posten
  6. Kontakte ohne E-Mail UND ohne Adresse UND ohne Business Relation

  7. Geschätzt: ~30.000 Kontakte

  8. Archivierung statt Löschung (für den Rest):

  9. BC erlaubt keine Massenlöschung von Kontakten mit Interaktionsprotokoll
  10. Alternative: Kontakte mit Status "Inaktiv" markieren (falls BC das unterstützt)
  11. Oder: Dedizierte Kontaktkategorie "Archiv-Import" anlegen und zuweisen
  12. Langfristig: Mit BC-Berater klären ob Massen-Archivierung/-Löschung über RapidStart oder Configuration Package möglich ist

Phase 3: Prävention

  1. Import-Prozess dokumentieren:
  2. Klären: Wer hat die Massen-Imports durchgeführt? (Navision-Migration? CRM-Sync? Newsletter-Import?)
  3. Sicherstellen, dass künftige Imports nur Kontakte MIT Business Relation anlegen

  4. Kontaktnummernkreise sauber trennen (z.B. 100000er = Debitoren, 200000er = nur bei Bedarf)

  5. Negative Artikelbestände korrigieren:

  6. Betroffene Artikel identifizieren (z.B. "7WK CHP" mit -90)
  7. Mit Andrea klären: Fehlende Wareneingänge nachbuchen oder Bestand korrigieren

Aufwandsschätzung:

Phase Wer Aufwand
Phase 1 (Analyse) Claude Code 2–3 Stunden
Phase 2a (Leere löschen) Andrea Paschen 30 Minuten
Phase 2b ("gelöscht" prüfen+löschen) Andrea Paschen 2–4 Stunden
Phase 2c (Archivierung Rest) Andrea + ggf. BC-Berater 1–2 Tage
Phase 3 (Prävention) IT + Andrea 1 Tag

6.7 FRB ↔ BC Spenden-Sync automatisieren

Ziel: Täglicher automatischer Import von FRB-Spenden nach BC.

Umsetzungsschritte:

  1. Mapping definieren:
  2. FRB-Projekt → BC-Dimension (Kostenstelle)
  3. FRB-Person (external_person_id) → BC-Debitor
  4. FRB-Betrag → BC-Buchungsbetrag
  5. FRB-Custom-Field "Buchungsvermerk" (14245) → BC-Buchungstext

  6. FRB-receipt_status → BC-Belegart

  7. Import-Script:

  8. Täglicher Abruf: FRB API donations.json?status=confirmed&sort=-date&received_at_from={gestern}
  9. Prüfung: Bereits in BC gebucht? (Duplikat-Check über transaction_id)

  10. BC API: Fibu-Buchung oder Debitor-Posten erstellen

  11. Monitoring:

  12. Fehlerhafte Imports (fehlende Debitorennummer, unbekanntes Projekt) → Benachrichtigung
  13. Dashboard: Import-Status, offene Zuordnungen

6.8 Brevo-Datenqualität sichern

Ziel: Saubere Listen, eindeutige Attribute, keine toten Sender.

Umsetzungsschritte:

  1. Doppelte Listen identifizieren und zusammenführen:
  2. PNL WDS Dortmund: ID 240 (2.688 Kontakte) + ID 300 (2.693 Kontakte) → zusammenführen
  3. Weitere Duplikate systematisch suchen (ähnliche Namen, ähnliche Kontaktzahlen)

  4. Brevo API: GET /contacts/lists/{id}/contacts → Mitglieder vergleichen

  5. Singstimme-Attribute konsolidieren:

  6. Ist: SING_STIMME (Kategorie: SOPRAN/ALT/TENOR/BASS), CHORSTIMME (Kategorie: Sopran/Alt/Tenor/Bass), SINGSTIMME (Freitext)
  7. Soll: Nur CHORSTIMME behalten
  8. Migration: Kontakte mit SING_STIMME oder SINGSTIMME aber ohne CHORSTIMME → Wert übertragen

  9. Dann: SING_STIMME und SINGSTIMME löschen

  10. Sender bereinigen:

  11. ID 2 ("ev-pop-insitut.de", deaktiviert) → löschen

7. Zielarchitektur

Systemlandschaft (Soll)

┌─────────────────────────────────────────────────────────┐
│                    Business Central                      │
│              MASTER: Stammdaten (Kontakte,               │
│              Debitoren, Kreditoren, Artikel)              │
└───────┬──────────────────┬──────────────────┬────────────┘
        │ Sync             │ Sync             │ Sync
        ▼                  ▼                  ▼
┌───────────────┐  ┌──────────────┐  ┌────────────────┐
│   D365 CS     │  │    Brevo     │  │ FundraisingBox │
│               │  │              │  │                │
│ • Cases       │  │ • Newsletter │  │ • Spenden      │
│ • Queues      │  │ • Kampagnen  │  │ • SEPA         │
│ • Vivenu-     │  │ • Opt-In/Out │  │ • Zuw.besch.   │
│   Tickets     │  │ • DOI-Flows  │  │ • Projekte     │
│ • Chor-       │  │ • Listen     │  │                │
│   verwaltung  │  │ • Bounce-    │  │                │
│ • 1:1 E-Mail  │  │   Mgmt      │  │                │
└───────┬───────┘  └──────────────┘  └────────────────┘
        │ Import
        ▼
┌───────────────┐
│    Vivenu     │
│ • Ticketing   │
│ • Events      │
│ • Checkout    │
└───────────────┘

Systemverantwortung

Aufgabe Führendes System Empfänger
Stammdaten (Name, Adresse, Tel, E-Mail) BC → D365, Brevo, FRB
Buchhaltung, Rechnungen BC —
Service-Center, Cases D365 CS —
Ticketing, Events Vivenu → D365 CS
Chorverwaltung D365 CS —
Newsletter, Massen-E-Mail Brevo —
Marketing-Listen, Segmentierung Brevo —
Opt-In/Opt-Out Brevo → D365, FRB
Spendenverwaltung FRB → BC
SEPA-Lastschriften FRB —
Zuwendungsbescheinigungen FRB → BC (Buchung)

Datenflüsse (Soll)

# Fluss Trigger Methode
1 BC → D365 CS: Stammdaten-Update Kontaktänderung in BC Power Automate oder Webhook
2 BC → Brevo: Stammdaten-Update Kontaktänderung in BC Brevo API (Batch oder Echtzeit)
3 BC → FRB: Stammdaten-Update Kontaktänderung in BC FRB API (Batch)
4 Brevo → D365 + FRB: Opt-Out Abmeldung/Spam-Report Brevo Webhook → Script
5 D365 → Brevo + FRB: DSGVO-Löschung Case-Abschluss (DSGVO) Power Automate → APIs
6 FRB → BC: Spenden-Import Täglich (Batch) Script: FRB API → BC API
7 Vivenu → D365 CS: Tickets Automatisch (bestehend) Vivenu-Integration

8. Umsetzbarkeit mit Claude Code

Direkt umsetzbar (API-Zugriff vorhanden, Scripts auf raspip5)

# Maßnahme Methode Aufwand
A Telefonnummern normalisieren (alle 4 Systeme) Python-Script: APIs lesen → normalisieren → zurückschreiben 1–2 Stunden
B Brevo: Doppelte Listen identifizieren Script: Alle Listen laden, Mitglieder vergleichen, Duplikate melden 1 Stunde
C Brevo: Singstimme-Attribute migrieren Script: SING_STIMME/SINGSTIMME → CHORSTIMME übertragen, alte löschen 1 Stunde
D Brevo: Deaktivierten Sender löschen 1 API-Call (DELETE /senders/2) 5 Minuten
E BC: Kontaktbereinigung Phase 1 Script: BC API → 143.412 Kontakte ohne Business Relation exportieren, Abgleich mit D365/Brevo/FRB, Reports für Andrea erstellen (Leere, "gelöscht", nicht referenzierte) 2–3 Stunden
F FRB ↔ BC: Verknüpfungslücken finden Script: FRB-Personen ohne external_person_id auflisten 30 Minuten
G D365 ↔ Brevo: Kontaktnummern-Abgleich Script: D365-Kontakte mit cnsc_kontaktnummer vs. Brevo KONTAKTNUMMER_CRM 1 Stunde
H Opt-Out-Abgleich (Ist-Analyse) Script: Sperren in D365 vs. Brevo vs. FRB vergleichen, Lücken auflisten 1–2 Stunden
I FRB → BC: Spenden-Import-Script Python: Täglicher Abruf FRB-Spenden, Mapping, BC-Buchung (als systemd-Timer) 3–5 Stunden
J D365: Marketing-Listen exportieren Script: Alle Listen mit Mitgliedern exportieren (CSV für Brevo-Import) 1–2 Stunden
K Brevo Webhook für Opt-Out Python-Script als Webhook-Empfänger (Docker/systemd), aktualisiert D365 + FRB 2–3 Stunden

Nicht mit Claude Code umsetzbar (erfordern UI/Admin-Zugriff)

# Maßnahme Warum nicht Wer
L D365: Duplikatserkennungsregel ändern Power Platform Admin Center, kein API-Zugriff D365-Admin (Bernd Sieper)
M Vivenu: Import-Logik ändern Vivenu-Konfiguration, kein API-Zugriff Vivenu-Support / Ansprechpartner
N BC: Kontakte löschen/archivieren (Phase 2) Buchhaltungsrelevant, braucht fachliche Freigabe. 379 leere sofort löschbar, 2.913 "gelöscht" nach Postenprüfung, Rest archivieren Buchhaltung (Andrea Paschen)
O BC: Negative Bestände korrigieren Buchhalterische Korrekturbuchung Buchhaltung (Andrea Paschen)
P D365: Marketing-Listen deaktivieren Organisatorische Entscheidung + Kommunikation Marketing (Dominik Ballhausen)
Q Brevo: Listen zusammenführen (final) Brevo UI nötig für Merge, API kann nur löschen Marketing (Dominik Ballhausen)
R BC → D365 Sync via Power Automate Power Automate Lizenz + Flow-Designer D365-Admin

Empfohlene Reihenfolge (Claude Code)

Schritt Maßnahme Voraussetzung
1 D — Brevo Sender löschen Keine
2 B — Brevo doppelte Listen identifizieren Keine (nur Analyse)
3 C — Brevo Singstimme konsolidieren Keine
4 E — BC leere Kontakte identifizieren Keine (nur Analyse)
5 F — FRB Verknüpfungslücken finden Keine (nur Analyse)
6 G — D365 ↔ Brevo Kontaktnummern-Abgleich Keine (nur Analyse)
7 H — Opt-Out-Abgleich Keine (nur Analyse)
8 A — Telefonnummern normalisieren Freigabe durch AK
9 J — D365 Marketing-Listen exportieren Entscheidung für Brevo-Konsolidierung
10 I — FRB → BC Spenden-Import Mapping-Freigabe durch Buchhaltung
11 K — Brevo Opt-Out Webhook Infrastruktur-Entscheidung