Stammdaten vor einer Systemintegration richtig klären

Eine Systemintegration löst kein ungeklärtes Datenproblem, sondern verteilt es häufig nur schneller in weitere Systeme. Bevor CRM, ERP, Shop oder Fachanwendung verbunden werden, sollte klar sein, welche Daten wo entstehen, welches System jeweils führend ist und wie Abweichungen behandelt werden. Fehlen diese Entscheidungen, ist eine technische Schnittstelle zwar möglich, aber im Betrieb fehleranfällig und schwer nachvollziehbar.

Warum Schnittstellen an Stammdaten scheitern können

Stammdaten beschreiben dauerhaft benötigte Objekte eines Unternehmens: etwa Kunden, Ansprechpartner, Lieferanten, Artikel, Leistungen, Standorte oder Kostenstellen. Im Unterschied zu einzelnen Vorgängen wie Angeboten, Aufträgen oder Tickets werden sie in vielen Prozessen wiederverwendet. Deshalb wirken sich Dubletten, uneinheitliche Bezeichnungen oder fehlende Pflichtfelder weit über ein einzelnes Team hinaus aus.

In der Praxis speichern mehrere Systeme oft ähnliche Informationen mit unterschiedlichem Zweck. Das CRM führt Vertriebschancen und Ansprechpartner, das ERP rechnet mit Debitoren und Rechnungsadressen ab, während ein Ticketsystem operative Kontakte enthält. Das ist nicht automatisch falsch. Problematisch wird es, wenn niemand festgelegt hat, ob beispielsweise eine geänderte Anschrift aus dem CRM ins ERP übernommen werden darf oder umgekehrt.

Eine Integration braucht für jedes übertragene Feld eine fachliche Bedeutung. Ein Feld namens „Kunde“ genügt nicht als Spezifikation: Es kann eine juristische Einheit, eine Rechnungsadresse, eine Unternehmensgruppe oder einen einzelnen Ansprechpartner meinen. Werden solche Unterschiede nur technisch übersetzt, entstehen scheinbar korrekte Datensätze, die fachlich nicht zusammenpassen.

Die zentrale Entscheidung: Welches System ist führend?

Für jeden Stammdatentyp sollte es eine eindeutige Antwort geben: Wo wird ein Datensatz angelegt, wo verbindlich geändert und welche Anwendungen erhalten ihn nur zur Nutzung? Dieses führende System wird oft als „Single Source of Truth“ bezeichnet. Gemeint ist nicht, dass alle Daten zwingend in einer Anwendung liegen müssen. Gemeint ist eine eindeutige fachliche Verantwortung pro Information.

• Kundenstammdaten: Klären, ob Vertrieb, Buchhaltung oder ein zentrales Stammdaten-Team die Anlage verantwortet.
• Ansprechpartner: Festlegen, ob sie kundenzentral gepflegt oder nur für einzelne Vertriebs- und Servicevorgänge geführt werden.
• Artikel und Leistungen: Definieren, ob Preise, steuerliche Merkmale und Bezeichnungen aus einem kaufmännischen System kommen.
• Statuswerte: Prüfen, ob Begriffe wie „aktiv“, „gesperrt“ oder „qualifiziert“ in allen Systemen dasselbe bedeuten.
• Löschungen und Sperrungen: Regeln, ob Daten entfernt, anonymisiert, archiviert oder nur für neue Vorgänge gesperrt werden.

Ein führendes System ist kein Freibrief für eine Einweg-Schnittstelle. Andere Anwendungen können Informationen ergänzen, wenn dies fachlich sinnvoll ist. Dann muss jedoch klar sein, welche Felder zurückgeschrieben werden dürfen und welche nicht. Besonders kritisch sind beidseitige Änderungen desselben Felds. Ohne Konfliktregel kann eine nächtliche Synchronisierung eine korrekte manuelle Anpassung unbemerkt überschreiben.

Wann zuerst aufräumen sinnvoll ist – und wann nicht

Eine vollständige Bereinigung aller historischen Daten vor Projektbeginn ist selten nötig. Sie kann ein Vorhaben unverhältnismäßig verzögern, besonders wenn Altbestände nur noch für Auskunfts- oder Archivzwecke benötigt werden. Sinnvoller ist eine risikobasierte Trennung: Welche Daten werden künftig aktiv genutzt, welche werden nur lesend übernommen und welche bleiben im Quellsystem?

Vor der Integration bereinigt werden sollten vor allem Daten, die Prozesse oder Abrechnung unmittelbar beeinflussen. Dazu zählen doppelte Kundennummern, widersprüchliche Rechnungsadressen, nicht eindeutige Zuordnungen zwischen Ansprechpartnern und Firmen sowie unterschiedliche Artikelkennungen. Historische Freitexte, veraltete Notizen oder unvollständige Datensätze können dagegen häufig zunächst außerhalb der laufenden Synchronisierung bleiben.

Warnsignale für einen zu frühen Integrationsstart

• Mehrere Teams können denselben Kunden in unterschiedlichen Systemen neu anlegen, ohne gemeinsame Kennung oder Prüfung.
• Mitarbeitende gleichen Daten regelmäßig per E-Mail oder Tabellen ab, weil keinem System vollständig vertraut wird.
• Für denselben Geschäftsbegriff existieren unterschiedliche Statuslisten, Kategorien oder Pflichtfelder.
• Unklar ist, wer eine Datenkorrektur entscheiden darf und wie sie in andere Systeme gelangt.
• Die gewünschte Schnittstelle soll zugleich alte Datenfehler finden, korrigieren und künftige Regeln erzwingen.

Ein praxistaugliches Vorgehen vor der Umsetzung

Die fachliche Klärung muss nicht in einem langen Konzeptdokument enden. Für einen klar abgegrenzten Integrationsfall reicht oft ein gemeinsamer Arbeitsstand aus Prozessverantwortlichen, Fachteam und technischer Umsetzung. Entscheidend ist, dass die Regeln überprüfbar formuliert und später in Schnittstelle, Oberfläche oder Arbeitsanweisung wiederzufinden sind.

1. Den konkreten Auslöser beschreiben: etwa „Neukunde wird nach Vertragsabschluss im CRM angelegt“.
2. Betroffene Systeme und Datentypen erfassen, ohne sofort sämtliche denkbaren Felder einzubeziehen.
3. Für jeden Datentyp das führende System, die verantwortliche Rolle und die zulässigen Änderungswege festlegen.
4. Eindeutige Schlüssel bestimmen: beispielsweise Kundennummer, externe ID oder bewusst definierte Zuordnungsregel. Namen und E-Mail-Adressen allein sind häufig keine belastbare Identifikation.
5. Feldregeln dokumentieren: Quelle, Ziel, Pflichtstatus, Umwandlung, Überschreibschutz und Behandlung fehlender Werte.
6. Fehlerfälle planen: Was passiert bei Dubletten, ungültigen Daten, nicht erreichbaren Systemen oder fachlichen Konflikten?
7. Die Integration zunächst mit repräsentativen Fällen prüfen und die Regeln mit den späteren Anwendern nachschärfen.

Praxisbeispiel: Kundendaten zwischen Vertrieb und Abrechnung

Ein Unternehmen möchte CRM, internes Auftragswerkzeug und Rechnungsprogramm per API verbinden, um manuelle Datenpflege zu verringern. Zunächst scheint die Regel einfach: Ein neuer CRM-Kontakt wird in alle Systeme übertragen. Bei der Prüfung zeigt sich jedoch, dass Vertrieb mit einer Unternehmensgruppe arbeitet, während die Buchhaltung für einzelne rechtliche Einheiten eigene Rechnungsempfänger benötigt. Zusätzlich können mehrere Ansprechpartner dieselbe allgemeine E-Mail-Adresse verwenden.

Eine direkte Eins-zu-eins-Übertragung wäre hier riskant. Die fachliche Lösung kann darin bestehen, Firmen im CRM als Interessenten zu führen, einen abrechenbaren Debitor aber erst nach einer Prüfung im Rechnungsprogramm anzulegen. Die Schnittstelle übergibt dann ausgewählte Angaben und die stabile externe Kennung, legt jedoch keinen Rechnungsempfänger ohne definierte Pflichtdaten an. Abweichungen werden als bearbeitbarer Fall sichtbar gemacht, statt automatisch erraten zu werden.

Das Beispiel zeigt den eigentlichen Nutzen der Vorarbeit: Nicht die maximale Menge synchronisierter Felder ist das Ziel, sondern ein Prozess, dessen Datenherkunft verständlich bleibt. Eine kleinere Integration mit klaren Grenzen ist oft besser wartbar als ein umfassender Datenabgleich, den niemand fachlich verantworten kann.

Technische Konsequenzen für eine wartbare Integration

Fachliche Regeln sollten sich in der Technik wiederfinden. Dazu gehören stabile externe Kennungen statt unsicherer Namensvergleiche, nachvollziehbare Protokolle für Übertragungen und klar erkennbare Fehlerzustände. Ebenso wichtig ist die Trennung zwischen Datenübertragung und fachlicher Entscheidung: Eine Schnittstelle kann einen Konflikt erkennen und melden; sie sollte nicht ohne Regel selbst entscheiden, welcher von zwei widersprüchlichen Werten der richtige ist.

Datenschutz gehört in dieselbe Klärung. Es sollte nur übertragen werden, was der Zielprozess benötigt. Zugriffe, Aufbewahrung und Zuständigkeiten müssen zum jeweiligen Einsatz passen. Bei personenbezogenen Daten ist außerdem relevant, ob Testdaten geschützt behandelt werden und wer Fehlerprotokolle einsehen kann. Hosting, Berechtigungen und technische Architektur ersetzen diese fachlichen Entscheidungen nicht, können sie aber sauber unterstützen.

Die Entscheidung vor dem Projekt

Starten Sie die Umsetzung, wenn der Zielprozess abgegrenzt ist, führende Systeme und Schlüssel feststehen und typische Konfliktfälle entschieden sind. Verschieben Sie den Integrationsstart, wenn die Schnittstelle zuerst unklare Zuständigkeiten kaschieren soll oder wenn zentrale Begriffe je nach Abteilung etwas anderes bedeuten. Dann ist ein kurzer fachlicher Klärungsschritt meist wertvoller als zusätzliche Automatisierung.

OnLouis unterstützt Teams dabei, Prozessregeln, Datenflüsse und technische Schnittstellen gemeinsam zu planen. Eine gute Integration entsteht nicht aus möglichst vielen Verbindungen, sondern aus nachvollziehbaren Verantwortlichkeiten und einer Umsetzung, die sich langfristig ändern lässt.