Eine Person, ein Datensatz: Wie ein Abteilungs-Silo durch ein einheitliches CRM ersetzt wurde

Eine Jugendliche nimmt an einem Jugendprogramm teil. Einige Jahre später schreibt sie sich in ein Campus-Programm ein und später wird sie Spenderin. Für die Organisation ist dies eine lange Beziehung. Für ihre Datenbanken waren es drei Fremde.

So sah die Realität bei der Orthodox Union aus, einer gemeinnützigen Organisation, die viele Programme unter einem Dach betreibt.

Die Organisation 

Die Programme der Orthodox Union umfassen:

• NCSY für Jugendliche

• JLIC auf College-Campus

• Yachad für Menschen mit Behinderungen

• der Impact Accelerator für andere gemeinnützige Organisationen

• Lobbykampagnen

• unter anderem Programme in Israel

Im Laufe der Jahre baute jede Abteilung ihr eigenes System auf, sodass dieselbe Person in mehreren Datenbanken gespeichert werden konnte und niemand das vollständige Bild hatte.

Warum separate Systeme nicht mehr funktionierten

• Kein vollständiges Bild. Datensätze wurden in verschiedenen Abteilungen dupliziert, sodass niemand die komplette Historie einer Person mit der Organisation sehen konnte.

• Überall Legacy-Systeme. MARS, die Yachad-API, die Impact Accelerator-Plattform und eine separate Hintergrundüberprüfungs-App enthielten jeweils jahrelange Daten und tägliche Arbeitsabläufe.

• Sensible Daten auf dem Spiel. Die Zusammenführung der Datensätze bedeutete, dass eine Datenbank medizinische Details für Jugend- und Inklusionsprogramme enthalten würde. Jede Abteilung musste jedoch weiterhin nur ihre eigenen Datensätze sehen.

• Zu viel manuelle Arbeit. Genehmigungen, Bestätigungen, Erinnerungen und Dankesnachrichten wurden größtenteils manuell abgewickelt.

Die Architektur: drei Schichten

In den Jahren 2025–2026 beauftragte die Entwicklungsfirma SoftPro, diese Systeme zu einer Plattform zu konsolidieren. Sie ist in drei Schichten organisiert:

1. Webanwendung für Mitarbeiter. Abteilungen arbeiten in ihren eigenen Bereichen mit ihren eigenen Bildschirmen und Zugriffsregeln.

2. API. Sie betreibt die Anwendung und enthält die Geschäftslogik.

3. Einbettbare Widgets. Veranstaltungsregistrierung, Zahlungen und Bewerbungen laufen auf den öffentlichen Websites der Organisation.

Im Zentrum steht ein Datensatz für jede Person und jeden Haushalt. Er enthält die gesamte Historie mit der Organisation: Programme, Veranstaltungen, Familie, Spenden und Kommunikation.

Sechs Designentscheidungen, die es möglich machten

• Geteilte Datensätze, Abteilungsschichten. Jede Abteilung fügt ihre eigenen Daten über einen gemeinsamen Personen- und Haushaltsdatensatz hinzu. Duplikate werden erkannt und zusammengeführt.

• Eine Migration Feature für Feature. Jedes Legacy-Feature wurde einem neuen Ort zugeordnet, Arbeitsabläufe wurden im CRM neu aufgebaut, und dedizierte Importwerkzeuge überführten bestehende Daten.

• Datenschutz in der Datenschicht. Abteilungsisolation filtert jede Anfrage automatisch. Zugriffsregeln, Einwilligungsverfolgung und Prüfnachweise wurden unter Berücksichtigung der HIPAA-Anforderungen entwickelt.

• Module mit klaren Grenzen. Jede Abteilung wurde gleichzeitig in derselben Codebasis entwickelt. Jeder Abteilungsbereich ist ein separates Modul, das bei jeder Änderung automatisch überprüft wird, sodass Arbeit an einem Bereich viel weniger wahrscheinlich einen anderen beeinträchtigt.

• Widgets für die Öffentlichkeit. Ein kurzer Code-Snippet bettet ein Widget auf jeder Website ein. Die Anmeldung erfolgt passwortlos über einen Link per E-Mail, und Registrierungen sowie Zahlungen fließen direkt ins CRM.

• Ereignisgesteuerte Automatisierung. Eine neue Registrierung, Zahlung oder andere Änderung löst fertige Workflows für Genehmigungen, Bestätigungen, Erinnerungen und Dankesnachrichten aus.

Technologie-Stack

• Backend: Node.js, Express, oRPC, Zod

• Frontend: Vue 3, TypeScript, Tailwind CSS, shadcn-vue, TanStack Query, TanStack Table, Storybook

• Daten: PostgreSQL (Amazon Aurora), Prisma ORM, ClickHouse

• Widgets: Web Components (Vue)

• Authentifizierung: Okta, Amazon Cognito

• KI: Amazon Bedrock (Claude), Google Gemini

• Cloud und Bereitstellung: AWS, Docker, Kubernetes, Helm, GitHub Actions

• Integrationen: SendGrid, Amazon SES, Zoom, JotForm, Checkr, Congress.gov, das Zahlungsgateway der Organisation

Stand des Projekts

• Ersetzte Systeme. Das CRM ersetzt MARS, die Yachad API, die Impact Accelerator Plattform und eine eigenständige Background-Check-App.

• Skalierung. Die Plattform umfasst mehr als 40 Funktionsmodule, die Jugend, Campus, Inklusion, Israel, Interessenvertretung, Veranstaltungen, Fundraising, Zahlungen, Mitarbeiter und Freiwillige abdecken. Diese laufen auf über 480 Datenbanktabellen, mehr als 40 API-Bereichen und über 70 automatisierten Workflows.

• Öffentliche Widgets. Widgets für Veranstaltungsregistrierungen, Zahlungen, Kampagnen zur Interessenvertretung und Berateranwendungen sind bereit zur Einbettung.

• Datenschutz integriert. Die Abteilungsisolation gilt für jede Anfrage, zusammen mit Nachverfolgung von Einwilligungen und Prüfpfaden.

• Rollout-Plan. Die Abteilungen werden nacheinander live geschaltet, jede zuerst von einer kleinen Gruppe realer Nutzer getestet. Der vollständige Rollout ist für Ende 2026 geplant.

Lektion für Organisationen mit mehreren Programmen

Der Fall OU zeigt, dass das Zusammenführen von Daten und die Unabhängigkeit der Abteilungen in einem System funktionieren kann. Der Schlüssel ist, von Anfang an für beides zu entwerfen: einen gemeinsamen Kern-Datensatz, Isolation auf Datenebene und modularen Code. Organisationen, die einen ähnlichen Schritt planen, können mit dem SoftPro-Team darüber sprechen, wie sie es angehen.

Fazit

Die Orthodoxe Union wechselte von vielen voneinander getrennten Systemen zu einer Plattform, auf der jede Person einen Datensatz hat und jede Abteilung nur sieht, was sie soll. Alte Workflows wurden neu aufgebaut, öffentliche Websites speisen Daten direkt ins CRM, und Routine-Nachrichten laufen eigenständig. Die Abteilungen werden nacheinander vor einem vollständigen Launch Ende 2026 umgestellt.