Zentrale Stammdatenverwaltung

Dieses Buch beschreibt die fachlichen und technischen Anforderungen an die geplante zentrale Stammdatenplattform. Es dient als Pflichtenheft, Architekturgrundlage und fortlaufende Projektdokumentation.

Dokumentstatus: Entwurf
Version: 0.1
Stand: August 2026

1. Projektübersicht


1. Projektübersicht

1.1 Ausgangssituation

Im Unternehmen werden Kunden-, Lieferanten- und zugehörige Stammdaten derzeit in mehreren voneinander unabhängigen Softwaresystemen geführt.

Betroffen sind insbesondere:

System Funktion
Unitrade bisheriges ERP-System
Gevis neues ERP-System
AddOne Anwendung für den Bereich Bautechnik
Addison Finanzbuchhaltung

Durch die getrennte Datenhaltung bestehen teilweise:

Eine zentrale und systemübergreifend verbindliche Datenbasis existiert derzeit nicht. Lediglich Gevis ist als führendes Stammdatensystem eingesetzt und verteilt per API die Datensätze an die Bereichsprogramme. Diese Datenbasis kann aber nicht zu 100% valide betrachtet werden und muss daher in Phase 1 überarbeitet werden.

1. Projektübersicht

1.2 Projektziel

Ziel des Projektes ist der Aufbau einer zentralen Stammdatenplattform, welche langfristig als führendes System für Kunden-, Lieferanten- sowie Zahlungs- und Mahnbedingungen dient.

Die zentrale Datenbank soll schrittweise zur Single Source of Truth für die betreffenden Stammdaten werden.

Die wesentlichen Projektziele sind:

  1. Zusammenführung bestehender Stammdaten aus allen relevanten Quellsystemen.
  2. Erkennung und Bereinigung von Dubletten.
  3. Prüfung bestehender Stammdaten auf Plausibilität und Richtigkeit.
  4. Abgleich mit externen Datenquellen.
  5. Normalisierung von Adress- und Kommunikationsdaten.
  6. Vereinheitlichung von Zahlungs- und Mahnbedingungen.
  7. Dokumentation historischer und nicht mehr gültiger Datensätze.
  8. Zentrale Neuanlage von Kunden und Lieferanten.
  9. Vermeidung zukünftiger Doppelanlagen.
  10. Automatische Bonitätsprüfung neuer Kunden.
  11. Zentrale Verwaltung von Zahlungs- und Mahnbedingungen.
  12. Automatische Verteilung neuer oder geänderter Stammdaten an angebundene Systeme.
  13. Vollständige Nachvollziehbarkeit automatischer und manueller Änderungen.
  14. Erweiterbarkeit auf weitere zentrale Stammdaten.
1. Projektübersicht

1.3 Projektphasen

Die Umsetzung erfolgt schrittweise.

Phase 1 – Konsolidierung und Datenbereinigung

Zusammenführung und Bereinigung der bestehenden Stammdaten aus:

Ergebnis ist ein geprüfter und konsolidierter initialer Stammdatenbestand.

Phase 2 – Zentrale Stammdatenanlage

Neue Kunden und Lieferanten werden über ein zentrales Web-Portal angelegt und geprüft.

Gevis übernimmt zunächst weiterhin die Verteilung an die angeschlossenen Fachanwendungen.

Phase 3 – Direkte Systemintegration

Die zentrale Stammdatenplattform überträgt Änderungen direkt per API an die angeschlossenen Systeme.

Phase 4 – Erweiterung

Weitere gemeinsam verwendete Stammdaten können zukünftig in die Plattform aufgenommen werden.

2. Architektur und Grundprinzipien


2. Architektur und Grundprinzipien

2.1 Zielarchitektur

Die zentrale Stammdatenplattform besteht aus mehreren logisch getrennten Komponenten.

Zentrale Stammdatenbank

Sie enthält die konsolidierten, geprüften und normalisierten Stammdaten.

Langfristig stellt sie das führende System für diese Informationen dar.

Web-Portal

Das Web-Portal dient zur:

SSO und Berechtigungen

Benutzer melden sich mit ihrer bestehenden Unternehmensidentität an.

Die Berechtigungen werden rollenbasiert vergeben.

Prüf- und Normalisierungsdienst

Dieser übernimmt:

Externe Datenquellen

Vorgesehen sind insbesondere Schnittstellen zu:

Integrationsschicht

Eine zentrale API- bzw. Integrationsschicht übernimmt den Datenaustausch mit:

2. Architektur und Grundprinzipien

2.2 Datenhoheit – Single Source of Truth

Langfristig muss die zentrale Stammdatenbank die fachlich führende Datenquelle für die darin verwalteten Daten darstellen.

Andere Anwendungen sollen diese Stammdaten konsumieren und grundsätzlich nicht unabhängig verändern.

Damit soll verhindert werden, dass beispielsweise derselbe Kunde gleichzeitig in Gevis, AddOne und Addison unterschiedlich gepflegt wird.

Während der Übergangsphasen kann Gevis weiterhin eine besondere Rolle als Verteiler übernehmen.

Mit Phase 3 soll diese technische Abhängigkeit aufgehoben werden.

2. Architektur und Grundprinzipien

2.3 Nachvollziehbarkeit und Audit

Jede Änderung an einem Stammdatensatz muss nachvollziehbar sein.

Mindestens zu protokollieren sind:

Die Änderungshistorie darf durch normale Benutzer nicht verändert oder gelöscht werden können.

3. Datenmodell

3. Datenmodell

3.1 Geschäftspartner

Die zentrale Entität des Systems ist der Geschäftspartner.

Ein Geschäftspartner kann:

sein.

Kunde und Lieferant sollen daher nicht zwingend als vollständig voneinander unabhängige Adressdatensätze geführt werden.

Ein Geschäftspartner kann mehrere zugehörige Informationen besitzen, beispielsweise:

3. Datenmodell

3.2 Golden Record

Für jeden eindeutig identifizierten Geschäftspartner soll ein zentraler Golden Record entstehen.

Dieser stellt die aktuell als korrekt bewertete Version des Stammdatensatzes dar.

Der Golden Record kann Informationen aus unterschiedlichen Quellen kombinieren.

Beispiel:

Information Quelle
Firmenname Handelsregister
Rechtsform Handelsregister
Geschäftsanschrift Handelsregister / Creditreform
Telefonnummer interner Datenbestand
E-Mail-Adresse Gevis
Zahlungsbedingung zentrale Stammdatenverwaltung

Die Herkunft der einzelnen Informationen muss nachvollziehbar bleiben.

3. Datenmodell

3.3 Quellsysteme und externe IDs

Für jeden importierten Datensatz muss gespeichert werden:

Beispiel:

Zentrale ID System Quell-ID
100025 Unitrade 4711
100025 Gevis 82347
100025 Addison 112358
100025 AddOne K-0815

Dadurch bleibt dauerhaft nachvollziehbar, welche Datensätze in den verschiedenen Systemen denselben Geschäftspartner repräsentieren.

3. Datenmodell

3.4 Qualitäts- und Prüfstatus

Jeder Stammdatensatz soll einen Qualitätsstatus besitzen.

Mögliche Status:

Optional kann zusätzlich ein numerischer Qualitätswert verwendet werden.

Beispiel:

Datenqualität: 94/100

4. Phase 1: Konsolidierung und Datenbereinigung

4. Phase 1: Konsolidierung und Datenbereinigung

4.1 Datenimport

In Phase 1 werden bestehende Stammdaten aus folgenden Anwendungen übernommen:

Abhängig vom jeweiligen System kommen unterschiedliche Importverfahren infrage:

Die ursprünglichen Quelldaten müssen während der Konsolidierung unverändert erhalten bleiben.

Datenbankverbindungen.png

4. Phase 1: Konsolidierung und Datenbereinigung

4.2 Dublettenerkennung

Die importierten Daten werden automatisiert auf mögliche Dubletten untersucht.

Dabei dürfen nicht ausschließlich identische Zeichenketten verglichen werden.

In die Bewertung sollen unter anderem einfließen:

Das System berechnet einen Ähnlichkeits- bzw. Konfidenzwert.

Beispiel:

Konfidenz Bewertung
100 % sicher identisch
95 % sehr wahrscheinlich identisch
78 % mögliche Dublette
35 % wahrscheinlich unterschiedliche Datensätze

Die Schwellenwerte müssen konfigurierbar sein.

4. Phase 1: Konsolidierung und Datenbereinigung

4.3 Manuelle Konfliktbearbeitung

Kann das System keine ausreichend sichere Entscheidung treffen, darf keine automatische Zusammenführung erfolgen.

Der Datensatz wird einem Benutzer im Web-Portal zur Prüfung vorgelegt.

Beispiel:

Feld Unitrade Gevis Addison Vorschlag
Firma Müller GmbH Mueller GmbH Müller GmbH Müller GmbH
Straße Hauptstr. 5 Hauptstraße 5 Hauptstrasse 5 Hauptstraße 5
PLZ 49762 49762 49762 49762

Der Benutzer muss mindestens folgende Möglichkeiten besitzen:

4. Phase 1: Konsolidierung und Datenbereinigung

4.4 Normalisierung

Die Stammdaten werden nach zentral definierten Regeln normalisiert.

Beispiele:

Eingangswert Normalisierter Wert
Hauptstr. Hauptstraße
Hauptstrasse Hauptstraße
05933 / 1234 +49 5933 1234
0049 5933 1234 +49 5933 1234
Deutschland DE
Germany DE

Die Regeln müssen konfigurierbar sein.

Eine wesentliche Anforderung ist die länderabhängige Normalisierung.

Internationale Anschriften dürfen nicht nach deutschen Schreibregeln verändert werden.

4. Phase 1: Konsolidierung und Datenbereinigung

4.5 Prüfung über externe Datenquellen

Unternehmensdaten sollen soweit technisch und vertraglich möglich mit externen Datenquellen abgeglichen werden.

Vorgesehen sind insbesondere:

Geprüft werden können abhängig von der verfügbaren Schnittstelle beispielsweise:

Dabei muss zwischen verschiedenen Datenquellen unterschieden werden:

  1. amtliche bzw. verifizierte Daten
  2. Creditreform-Daten
  3. interne Unternehmensdaten
  4. Benutzereingaben
  5. normalisierte Daten
  6. KI-generierte Vorschläge

Die Herkunft eines Wertes muss nachvollziehbar bleiben.

4. Phase 1: Konsolidierung und Datenbereinigung

4.6 Nicht mehr aktive Geschäftspartner

Kunden und Lieferanten, die nicht mehr existieren oder nicht mehr aktiv sind, dürfen nicht einfach aus dem Datenbestand gelöscht werden.

Mögliche Status sind:

Bei Fusionen, Übernahmen oder Rechtsnachfolgen soll eine Beziehung zum Nachfolgeunternehmen hinterlegt werden können.

4. Phase 1: Konsolidierung und Datenbereinigung

4.7 Zahlungs- und Mahnbedingungen

Bestehende Zahlungs- und Mahnbedingungen müssen während der Migration vereinheitlicht werden.

Hierzu existieren mindestens:

Die Bedingungen werden anhand ihrer Texte und ihrer fachlichen Bedeutung miteinander verglichen.

Beispiel:

Alt:

14 Tage 2 %, 30 Tage netto

Neu:

Zahlbar innerhalb 14 Tagen mit 2 % Skonto, ansonsten 30 Tage netto

Das System soll erkennen können, dass beide Bedingungen fachlich identisch sind.

Für jede bisherige ID wird eine Zuordnung zur neuen ID erzeugt.

Alte ID Neue ID Konfidenz
12 105 100 %
17 112 98 %
23 ? 64 %

Unsichere Zuordnungen müssen manuell geprüft werden.

Nach erfolgreicher Zuordnung werden im konsolidierten Stammdatenbestand die bisherigen IDs durch die neuen IDs ersetzt.

Dasselbe Verfahren gilt für Mahnbedingungen.

4. Phase 1: Konsolidierung und Datenbereinigung

4.8 Abschluss und Initialimport

Nach Abschluss von Phase 1 muss ein:

Stammdatenbestand vorliegen.

Dieser wird initial nach Gevis übertragen.

Gevis übernimmt in dieser Phase die Weiterverteilung an die übrigen Systeme.

5. Phase 2: Zentrale Stammdatenanlage


5. Phase 2: Zentrale Stammdatenanlage

5.1 Web-Portal

Nach Abschluss der initialen Migration werden Kunden und Lieferanten nicht mehr unabhängig in den einzelnen Anwendungen angelegt.

Die Stammdatenanlage erfolgt über das zentrale Web-Portal.

Dieses muss mindestens folgende Funktionen bereitstellen:

Beispiele, wie es aussehen könnte:

grafik.png

grafik.png

grafik.png

grafik.png

grafik.png

grafik.png

5. Phase 2: Zentrale Stammdatenanlage

5.2 Benutzer und Berechtigungen

Mindestens folgende Rollen sind vorzusehen:

Benutzer

Darf Stammdaten erfassen und abhängig vom Berechtigungskonzept bearbeiten.

Stammdatenverantwortlicher

Darf zusätzlich:

Administrator

Darf zusätzlich:

Das endgültige Berechtigungsmodell wird während der Detailplanung festgelegt.

5. Phase 2: Zentrale Stammdatenanlage

5.3 Live-Dublettenprüfung

Bereits während der Eingabe eines Kunden oder Lieferanten muss nach bestehenden Datensätzen gesucht werden.

Beispiel:

Eingabe:

Müller GmbH
Hauptstraße 5
49762 Lathen

Das System könnte daraufhin anzeigen:

Möglicherweise bereits vorhanden
Müller GmbH, Hauptstr. 5, 49762 Lathen
Übereinstimmung: 96 %

Der Benutzer muss den vorhandenen Datensatz unmittelbar öffnen und vergleichen können.

Bei hoher Übereinstimmung soll eine Doppelanlage verhindert oder nur mit entsprechender Berechtigung und Begründung ermöglicht werden.

5. Phase 2: Zentrale Stammdatenanlage

5.4 Automatische Prüfung und Korrektur

Spätestens beim Speichern müssen die eingegebenen Daten automatisiert geprüft werden.

Hierzu gehören:

Beispielsweise kann aus:

Müller GMBH, Hauptstr. 5

nach der Prüfung:

Müller GmbH, Hauptstraße 5

werden.

Wesentliche Änderungen müssen nachvollziehbar protokolliert werden.

5. Phase 2: Zentrale Stammdatenanlage

5.5 Bonitätsprüfung

Bei der Neuanlage eines Kunden erfolgt automatisiert eine Bonitätsabfrage über Creditreform.

Der konkrete Umfang hängt von folgenden Faktoren ab:

Mögliche Workflows:

Bonität unauffällig

Normale Weiterverarbeitung und Freigabe.

Bonität auffällig

Weiterleitung an einen berechtigten Mitarbeiter zur Prüfung.

Keine eindeutige Identifikation

Manuelle Prüfung des Geschäftspartners.

Eine negative oder unklare Bonitätsauskunft darf nicht automatisch zu einer endgültigen Ablehnung führen, sofern hierfür keine explizite Geschäftsregel definiert wurde.

5. Phase 2: Zentrale Stammdatenanlage

5.6 Übertragung nach Gevis

Nach erfolgreicher Anlage und Freigabe wird der Datensatz automatisch an Gevis übertragen.

Mögliche Übertragungsstatus:

Fehlgeschlagene Übertragungen müssen automatisch erneut versucht werden.

Nach einer konfigurierbaren Anzahl fehlgeschlagener Versuche wird ein Administrator informiert.

6. Phase 3: Direkte Systemintegration

6. Phase 3: Direkte Systemintegration

6.1 Zielarchitektur

n Phase 3 wird die Abhängigkeit von Gevis als technischem Verteiler aufgehoben.

Die zentrale Stammdatenplattform verteilt Änderungen selbstständig an die angeschlossenen Systeme.

Zentrale Stammdatenplattform

↓

Integrationsschicht / API

↓

Die zentrale Stammdatenplattform bleibt dabei das führende System.

6. Phase 3: Direkte Systemintegration

6.2 Ereignisgesteuerte Synchronisation

Bei Anlage oder Änderung eines Stammdatensatzes wird ein Ereignis erzeugt.

Beispiele:

Die Integrationsschicht verarbeitet das Ereignis und überträgt die Änderung an die betroffenen Systeme.

6. Phase 3: Direkte Systemintegration

6.3 Fehlerbehandlung

Ein Fehler in einem Zielsystem darf die Synchronisation anderer Systeme nicht verhindern.

Beispiel:

System Status
Gevis erfolgreich
AddOne erfolgreich
Addison Fehler

Der zentrale Datensatz wird entsprechend als teilweise synchronisiert gekennzeichnet.

Fehlgeschlagene Übertragungen müssen erneut ausgeführt werden können.

6. Phase 3: Direkte Systemintegration

6.4 Vermeidung von Synchronisationsschleifen

Das System muss verhindern, dass Änderungen zwischen Anwendungen endlos gegenseitig übertragen werden.

Jede Änderung benötigt daher mindestens:

Das zentrale System muss erkennen können, ob eine empfangene Änderung bereits verarbeitet wurde.

7. Phase 4: Erweiterung der Plattform

7. Phase 4: Erweiterung der Plattform

7.1 Weitere Stammdaten

Die Architektur muss so ausgelegt sein, dass zukünftig weitere gemeinsam genutzte Stammdaten zentral verwaltet werden können.

Mögliche Erweiterungen sind:

Die konkrete Umsetzung ist nicht Bestandteil der ersten drei Projektphasen.

8. KI und automatisierte Datenprüfung

8. KI und automatisierte Datenprüfung

8.1 Aufgaben der KI

KI kann insbesondere für folgende Aufgaben eingesetzt werden:

Die KI stellt hierbei eine zusätzliche Prüfinstanz dar und ist nicht selbst die maßgebliche Quelle für Unternehmensdaten.

8. KI und automatisierte Datenprüfung

8.2 Automatische Entscheidungen

KI-Ergebnisse sind grundsätzlich als Bewertung oder Änderungsvorschlag zu behandeln.

Automatische Änderungen dürfen nur erfolgen, wenn:

Bei fachlich relevanten oder unklaren Änderungen erfolgt eine manuelle Freigabe.

Die entsprechenden Schwellenwerte müssen konfigurierbar sein.

8. KI und automatisierte Datenprüfung

8.3 Datenschutz beim KI-Einsatz

Bei Verwendung externer KI-Dienste muss geklärt werden:

Eine KI darf keine nicht nachvollziehbaren Änderungen an produktiven Stammdaten durchführen.

9. Technische Anforderungen

9. Technische Anforderungen

9.1 Grundanforderungen

Die Plattform soll modular aufgebaut werden.

Vorzusehen sind mindestens:

Die einzelnen Komponenten sollen möglichst unabhängig voneinander erweitert oder ausgetauscht werden können.

9. Technische Anforderungen

9.2 API

Die zentrale API muss versioniert werden.

Beispielsweise:

/api/v1/customers

/api/v1/suppliers

/api/v1/payment-terms

/api/v1/dunning-terms

Die API muss mindestens unterstützen:

9. Technische Anforderungen

9.3 Sicherheit und Datenschutz

Die Anwendung verarbeitet personenbezogene und unternehmensbezogene Daten.

Zu berücksichtigen sind insbesondere:

Passwörter, API-Keys und andere Secrets dürfen nicht unverschlüsselt in Konfigurationsdateien oder Datenbanktabellen gespeichert werden.

9. Technische Anforderungen

9.4 Backup und Wiederherstellung

Aufgrund der Wichtigkeit der zentralen Datenbank ist ein umfangreiches Backup- und Wiederherstellungskonzept vorzusehen. 

Dieses muss mindestens berücksichtigen:

Da die Plattform langfristig das führende System darstellt, ist ihre Wiederherstellbarkeit als kritische Systemanforderung zu betrachten.

10. Administration und Monitoring

10. Administration und Monitoring

10.1 Administrationsbereich

Das Web-Portal soll einen zentralen Administrationsbereich bereitstellen.

Dort sollen mindestens verwaltet werden können:

10. Administration und Monitoring

10.2 Dashboard und Datenqualität

Das Dashboard soll einen Überblick über den Zustand des Stammdatenbestandes und der Schnittstellen geben.

Mögliche Kennzahlen:

11. Abnahmekriterien

11. Abnahmekriterien

11.1 Abnahme Phase 1

Phase 1 gilt als fachlich abgeschlossen, wenn:

11. Abnahmekriterien

11.2 Abnahme Phase 2

Phase 2 gilt als abgeschlossen, wenn:

11. Abnahmekriterien

11.3 Abnahme Phase 3

Phase 3 gilt als abgeschlossen, wenn:

12. Projektplanung

12. Projektplanung

12.1 Umsetzung

Projektabschnitt 1 – Analyse

Projektabschnitt 2 – Umsetzung Phase 1

Projektabschnitt 3 – Umsetzung Phase 2

Projektabschnitt 4 – Umsetzung Phase 3

Projektabschnitt 5 – Umsetzung Phase 4

13. Offene Punkte und Entscheidungen

13. Offene Punkte und Entscheidungen

13.1 Technische offene Punkte

Vor Beginn bzw. während der Detailplanung sind insbesondere folgende Fragen zu klären:

  1. Welche Datenbankstrukturen besitzen Unitrade, Gevis, AddOne und Addison?
  2. Welche Systeme verfügen über dokumentierte APIs?
  3. Welche Systeme erlauben direkten lesenden Datenbankzugriff?
  4. Welche Systeme erlauben Schreibzugriffe per API?
  5. Welche konkreten Registerdaten können automatisiert abgefragt werden?
  6. Welche Creditreform-Produkte und APIs stehen zur Verfügung?
  7. Welches SSO-Verfahren wird verwendet?
  8. Welche Verfügbarkeitsanforderungen bestehen?
  9. Welche RPO- und RTO-Anforderungen gelten?
  10. Welche technischen Anforderungen bestehen an die Zielsysteme?
13. Offene Punkte und Entscheidungen

13.2 Fachliche offene Punkte

Folgende fachliche Entscheidungen müssen getroffen werden:

  1. Welche Datenquelle gilt bei widersprüchlichen Angaben für welches Feld als führend?
  2. Welche Daten dürfen automatisch korrigiert werden?
  3. Welche Änderungen benötigen eine manuelle Freigabe?
  4. Welche Schwellenwerte gelten für automatische Dublettenentscheidungen?
  5. Welche Zahlungsbedingungen existieren alt und neu?
  6. Welche Mahnbedingungen existieren alt und neu?
  7. Welche Systeme benötigen welche IDs?
  8. Welche internen Felder dürfen nicht durch externe Informationen überschrieben werden?
  9. Welche Bonitätsinformationen werden benötigt?
  10. Welche Benutzer dürfen Bonitätsinformationen einsehen?
  11. Wie lange werden Historien und Prüfergebnisse aufbewahrt?

14. Zielzustand


14. Zielzustand

14.1 Soll-Zustand nach Projektabschluss

Nach vollständiger Umsetzung existiert im Unternehmen eine zentrale Plattform zur Verwaltung gemeinsam genutzter Stammdaten.

Ein Geschäftspartner wird grundsätzlich einmal zentral angelegt und gepflegt.

Die zentrale Stammdatenplattform übernimmt den vollständigen Prozess:

Erfassen → Suchen → Prüfen → Verifizieren → Normalisieren → Freigeben → Speichern → Versionieren → Verteilen

Dadurch wird verhindert, dass mehrere Anwendungen dauerhaft voneinander abweichende Versionen desselben Kunden oder Lieferanten führen.

Die einzelnen Fachanwendungen verwenden die zentral bereitgestellten Stammdaten, während die Datenhoheit bei der Stammdatenplattform liegt.

Die Plattform bildet gleichzeitig die technische Grundlage für die zukünftige zentrale Verwaltung weiterer unternehmensweit verwendeter Stammdaten.