# 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.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:
- Mehrfachanlagen desselben Kunden oder Lieferanten
- unterschiedliche Schreibweisen
- veraltete Anschriften
- unterschiedliche Kontaktdaten
- fehlerhafte oder unvollständige Datensätze
- unterschiedliche Zahlungsbedingungen
- unterschiedliche Mahnbedingungen
- unterschiedliche IDs für fachlich identische Stammdaten (Nummernkreise in Gevis und AddOne müssen erhalten bleiben)
- Datensätze zu nicht mehr existierenden Unternehmen oder Personen
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.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.3 Projektphasen
Die Umsetzung erfolgt schrittweise.
#### Phase 1 – Konsolidierung und Datenbereinigung
Zusammenführung und Bereinigung der bestehenden Stammdaten aus:
- Unitrade
- Gevis
- AddOne
- Addison
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.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:
- Stammdatenanlage
- Stammdatenpflege
- Dublettenprüfung
- Bearbeitung von Konfliktfällen
- Freigabe von Änderungsvorschlägen
- Verwaltung von Zahlungsbedingungen
- Verwaltung von Mahnbedingungen
- Einsicht in Prüfungen
- Einsicht in Änderungshistorien
#### SSO und Berechtigungen
Benutzer melden sich mit ihrer bestehenden Unternehmensidentität an.
Die Berechtigungen werden rollenbasiert vergeben.
#### Prüf- und Normalisierungsdienst
Dieser übernimmt:
- Plausibilitätsprüfung
- Dublettenerkennung
- Normalisierung
- Klassifizierung
- Vergleich unterschiedlicher Datensätze
- Erkennung widersprüchlicher Informationen
- KI-gestützte Bewertung
#### Externe Datenquellen
Vorgesehen sind insbesondere Schnittstellen zu:
- Handelsregister bzw. verfügbaren Registerdaten
- Creditreform
#### Integrationsschicht
Eine zentrale API- bzw. Integrationsschicht übernimmt den Datenaustausch mit:
- Gevis
- AddOne
- Addison
- zukünftigen Anwendungen
# 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.3 Nachvollziehbarkeit und Audit
Jede Änderung an einem Stammdatensatz muss nachvollziehbar sein.
Mindestens zu protokollieren sind:
- betroffener Datensatz
- geändertes Feld
- vorheriger Wert
- neuer Wert
- Änderungszeitpunkt
- Benutzer bzw. ausführender Dienst
- Herkunft der Änderung
- Grund der Änderung
- ggf. externe Referenz
- ggf. verwendetes KI-Prüfverfahren
- Freigabestatus
Die Änderungshistorie darf durch normale Benutzer nicht verändert oder gelöscht werden können.
# 3. Datenmodell
# 3.1 Geschäftspartner
Die zentrale Entität des Systems ist der **Geschäftspartner**.
Ein Geschäftspartner kann:
- Kunde
- Lieferant
- Kunde und Lieferant
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:
- Anschriften
- Kommunikationsdaten
- Ansprechpartner
- Zahlungsbedingungen
- Mahnbedingungen
- externe Identifikatoren
- Quellsystem-IDs
# 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:
Die Herkunft der einzelnen Informationen muss nachvollziehbar bleiben.
# 3.3 Quellsysteme und externe IDs
Für jeden importierten Datensatz muss gespeichert werden:
- aus welchem System er stammt
- welche ID er dort besitzt
- wann er importiert wurde
- wann er im Quellsystem zuletzt geändert wurde
- welchem zentralen Datensatz er zugeordnet wurde
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.4 Qualitäts- und Prüfstatus
Jeder Stammdatensatz soll einen Qualitätsstatus besitzen.
Mögliche Status:
- ungeprüft
- automatische Prüfung läuft
- automatisch geprüft
- manuelle Prüfung erforderlich
- manuell geprüft
- extern verifiziert
- Konflikt vorhanden
- gesperrt
Optional kann zusätzlich ein numerischer Qualitätswert verwendet werden.
Beispiel:
**Datenqualität: 94/100**
# 4. Phase 1: Konsolidierung und Datenbereinigung
# 4.1 Datenimport
In Phase 1 werden bestehende Stammdaten aus folgenden Anwendungen übernommen:
- Unitrade
- Gevis
- AddOne
- Addison
Abhängig vom jeweiligen System kommen unterschiedliche Importverfahren infrage:
- direkter Datenbankzugriff
- API
- CSV
- XML
- JSON
- andere strukturierte Exportformate
Die ursprünglichen Quelldaten müssen während der Konsolidierung unverändert erhalten bleiben.
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/datenbankverbindungen.png)
# 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:
- Firmenname
- Firmenname ohne Rechtsform
- Vorname und Nachname
- Straße
- Hausnummer
- PLZ
- Ort
- Land
- Telefonnummer
- Mobilnummer
- E-Mail-Adresse
- Domain
- Umsatzsteuer-ID
- Handelsregisternummer
- Registergericht
- Creditreform-Nummer
- weitere eindeutige Identifikatoren
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.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:
- Datensatz A übernehmen
- Datensatz B übernehmen
- Datensätze zusammenführen
- beide Datensätze behalten
- einzelne Feldwerte auswählen
- Werte manuell korrigieren
- Entscheidung zurückstellen
# 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.5 Prüfung über externe Datenquellen
Unternehmensdaten sollen soweit technisch und vertraglich möglich mit externen Datenquellen abgeglichen werden.
Vorgesehen sind insbesondere:
- Handelsregister bzw. Registerdaten
- Creditreform
Geprüft werden können abhängig von der verfügbaren Schnittstelle beispielsweise:
- Unternehmensname
- Rechtsform
- Sitz
- Geschäftsanschrift
- Handelsregisternummer
- Registergericht
- Unternehmensstatus
- weitere Identifikationsmerkmale
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.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:
- aktiv
- inaktiv
- insolvent
- in Liquidation
- gelöscht
- verschmolzen
- übernommen
- verstorben
- Geschäftsbetrieb eingestellt
- unbekannter Status
Bei Fusionen, Übernahmen oder Rechtsnachfolgen soll eine Beziehung zum Nachfolgeunternehmen hinterlegt werden können.
# 4.7 Zahlungs- und Mahnbedingungen
Bestehende Zahlungs- und Mahnbedingungen müssen während der Migration vereinheitlicht werden.
Hierzu existieren mindestens:
- bisherige Zahlungsbedingungen
- neue Zahlungsbedingungen
- bisherige Mahnbedingungen
- neue Mahnbedingungen
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.8 Abschluss und Initialimport
Nach Abschluss von Phase 1 muss ein:
- konsolidierter
- deduplizierter
- geprüfter
- normalisierter
- dokumentierter
- fachlich freigegebener
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.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:
- SSO-Anmeldung
- rollenbasierte Berechtigungen
- Kundenanlage
- Lieferantenanlage
- Bearbeitung bestehender Stammdaten
- Dublettensuche
- Live-Dublettenprüfung
- Verwaltung von Zahlungsbedingungen
- Verwaltung von Mahnbedingungen
- Konfliktbearbeitung
- Freigabeverfahren
- Änderungshistorie
- Status externer Prüfungen
- Synchronisationsstatus
Beispiele, wie es aussehen könnte:
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/6nIgrafik.png)
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/7Iegrafik.png)
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/zxegrafik.png)
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/yRygrafik.png)
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/2Gfgrafik.png)
[](https://helpme.schlichter.biz/uploads/images/gallery/2026-08/uTFgrafik.png)
# 5.2 Benutzer und Berechtigungen
Mindestens folgende Rollen sind vorzusehen:
#### Benutzer
Darf Stammdaten erfassen und abhängig vom Berechtigungskonzept bearbeiten.
#### Stammdatenverantwortlicher
Darf zusätzlich:
- Konflikte bearbeiten
- Dubletten zusammenführen
- Änderungen prüfen
- Stammdaten freigeben
#### Administrator
Darf zusätzlich:
- Benutzerrechte verwalten
- Systemeinstellungen ändern
- Normalisierungsregeln verwalten
- Schnittstellen konfigurieren
- technische Fehler einsehen
Das endgültige Berechtigungsmodell wird während der Detailplanung festgelegt.
# 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.4 Automatische Prüfung und Korrektur
Spätestens beim Speichern müssen die eingegebenen Daten automatisiert geprüft werden.
Hierzu gehören:
- Prüfung der Pflichtfelder
- syntaktische Prüfung
- Normalisierung
- Dublettenprüfung
- Plausibilitätsprüfung
- externe Unternehmensprüfung
- KI-gestützte Prüfung
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.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:
- verfügbarer API
- bestehendem Vertrag
- Lizenzmodell
- Kosten je Abfrage
- datenschutzrechtlichen Anforderungen
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.6 Übertragung nach Gevis
Nach erfolgreicher Anlage und Freigabe wird der Datensatz automatisch an Gevis übertragen.
Mögliche Übertragungsstatus:
- ausstehend
- in Verarbeitung
- erfolgreich
- Warnung
- fehlgeschlagen
- erneute Übertragung erforderlich
Fehlgeschlagene Übertragungen müssen automatisch erneut versucht werden.
Nach einer konfigurierbaren Anzahl fehlgeschlagener Versuche wird ein Administrator informiert.
# 6. Phase 3: Direkte Systemintegration
# 6.1 Zielarchitektur
In 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**
↓
- Gevis
- AddOne
- Addison
- ggf. Unitrade
- weitere Systeme
Die zentrale Stammdatenplattform bleibt dabei das führende System.
# 6.2 Ereignisgesteuerte Synchronisation
Bei Anlage oder Änderung eines Stammdatensatzes wird ein Ereignis erzeugt.
Beispiele:
- `CustomerCreated`
- `CustomerUpdated`
- `SupplierCreated`
- `SupplierUpdated`
- `PaymentTermCreated`
- `PaymentTermUpdated`
- `DunningTermCreated`
- `DunningTermUpdated`
Die Integrationsschicht verarbeitet das Ereignis und überträgt die Änderung an die betroffenen Systeme.
# 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.4 Vermeidung von Synchronisationsschleifen
Das System muss verhindern, dass Änderungen zwischen Anwendungen endlos gegenseitig übertragen werden.
Jede Änderung benötigt daher mindestens:
- eindeutige Event-ID
- Quellsystem
- Zeitstempel
- Versionsnummer des Datensatzes
Das zentrale System muss erkennen können, ob eine empfangene Änderung bereits verarbeitet wurde.
# 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:
- Ansprechpartner
- Bankverbindungen
- Lieferadressen
- Rechnungsadressen
- Steuernummern
- Umsatzsteuer-IDs
- Kreditlimits
- Vertreterzuordnungen
- Kundengruppen
- Lieferantengruppen
- Preisgruppen
- Rabattgruppen
- Versandbedingungen
- Lieferbedingungen
- Kommunikationsdaten
- Dokumente
- weitere ERP-relevante Stammdaten
Die konkrete Umsetzung ist nicht Bestandteil der ersten drei Projektphasen.
# 8. KI und automatisierte Datenprüfung
# 8.1 Aufgaben der KI
KI kann insbesondere für folgende Aufgaben eingesetzt werden:
- Erkennung unterschiedlicher Schreibweisen
- semantischer Vergleich von Zahlungsbedingungen
- semantischer Vergleich von Mahnbedingungen
- Unterstützung der Dublettenerkennung
- Plausibilitätsbewertung
- Erkennung ungewöhnlicher Feldinhalte
- Vorschläge zur Datenbereinigung
- Klassifizierung unklarer Datensätze
Die KI stellt hierbei eine zusätzliche Prüfinstanz dar und ist nicht selbst die maßgebliche Quelle für Unternehmensdaten.
---
# 8.2 Automatische Entscheidungen
**KI-Ergebnisse sind grundsätzlich als Bewertung oder Änderungsvorschlag zu behandeln.**
Automatische Änderungen dürfen nur erfolgen, wenn:
- eine definierte Geschäftsregel vorliegt,
- die Änderung eindeutig ist,
- eine ausreichend hohe Konfidenz besteht,
- die Änderung nachvollziehbar protokolliert wird.
Bei fachlich relevanten oder unklaren Änderungen erfolgt eine manuelle Freigabe.
Die entsprechenden Schwellenwerte müssen konfigurierbar sein.
# 8.3 Datenschutz beim KI-Einsatz
Bei Verwendung externer KI-Dienste muss geklärt werden:
- welche Daten das Unternehmen verlassen
- wo die Daten verarbeitet werden
- ob Daten gespeichert werden
- ob Daten für Trainingszwecke verwendet werden
- welche Auftragsverarbeitungsverträge erforderlich sind
- ob personenbezogene Daten übertragen werden
- ob eine lokale bzw. unternehmensinterne KI-Lösung erforderlich ist
Eine KI darf keine nicht nachvollziehbaren Änderungen an produktiven Stammdaten durchführen.
# 9. Technische Anforderungen
# Neue Seite
# 9.1 Grundanforderungen
Die Plattform soll modular aufgebaut werden.
Vorzusehen sind mindestens:
- relationale Datenbank
- REST-API
- Web-Frontend
- SSO-Anbindung
- rollenbasierte Berechtigungen
- Hintergrunddienste bzw. Worker
- Integrationsschicht
- Audit-Logging
- zentralisiertes Fehlerlogging
- Monitoring
- konfigurierbare Normalisierungsregeln
- konfigurierbare Prüfregeln
Die einzelnen Komponenten sollen möglichst unabhängig voneinander erweitert oder ausgetauscht werden können.
# 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:
- Authentifizierung
- Autorisierung
- GET
- POST
- PUT/PATCH
- Suche
- Filterung
- Pagination
- Versionierung
- strukturierte Fehlercodes
- Logging
- Idempotenz für relevante Schreiboperationen
# 9.3 Sicherheit und Datenschutz
Die Anwendung verarbeitet personenbezogene und unternehmensbezogene Daten.
Zu berücksichtigen sind insbesondere:
- DSGVO
- Zugriffskontrolle
- Rollen- und Berechtigungskonzept
- Transportverschlüsselung
- sichere Speicherung sensibler Zugangsdaten
- Audit-Logging
- Aufbewahrungsfristen
- Lösch- und Sperrkonzepte
- Backup
- Restore
- Schutz von API-Zugangsdaten
- Protokollierung externer Abfragen
Passwörter, API-Keys und andere Secrets dürfen nicht unverschlüsselt in Konfigurationsdateien oder Datenbanktabellen gespeichert werden.
# 9.4 Backup und Wiederherstellung
Aufgrund der Wichtigkeit der zentralen Datenbank ist ein umfangreiches Backup- und Wiederherstellungskonzept vorzusehen.
Dieses muss mindestens berücksichtigen:
- regelmäßige Vollsicherungen
- inkrementelle bzw. transaktionsbasierte Sicherungen
- definierte Aufbewahrungsfristen
- regelmäßige Restore-Tests
- dokumentiertes Disaster-Recovery-Verfahren
Da die Plattform langfristig das führende System darstellt, ist ihre Wiederherstellbarkeit als kritische Systemanforderung zu betrachten.
# 10. Administration und Monitoring
# 10.1 Administrationsbereich
Das Web-Portal soll einen zentralen Administrationsbereich bereitstellen.
Dort sollen mindestens verwaltet werden können:
- Benutzer und Rollen
- Normalisierungsregeln
- Dubletten-Schwellenwerte
- Prüfregeln
- Schnittstellen
- Quellsysteme
- Mappingtabellen
- Zahlungsbedingungen
- Mahnbedingungen
- Synchronisationsstatus
- fehlgeschlagene Übertragungen
- offene Konfliktfälle
# 10.2 Dashboard und Datenqualität
Das Dashboard soll einen Überblick über den Zustand des Stammdatenbestandes und der Schnittstellen geben.
Mögliche Kennzahlen:
- Gesamtzahl Geschäftspartner
- Anzahl Kunden
- Anzahl Lieferanten
- Kunden und Lieferanten
- erkannte Dubletten
- offene Dublettenfälle
- ungeprüfte Datensätze
- extern verifizierte Datensätze
- inaktive Unternehmen
- Insolvenzfälle
- offene Bonitätsprüfungen
- fehlgeschlagene Synchronisationen
- offene Zahlungsbedingungszuordnungen
- offene Mahnbedingungszuordnungen
# 11. Abnahmekriterien
# 11.1 Abnahme Phase 1
Phase 1 gilt als fachlich abgeschlossen, wenn:
- alle definierten Quellsysteme importiert wurden
- Quell-IDs nachvollziehbar gespeichert wurden
- Dubletten analysiert wurden
- unklare Dubletten manuell entschieden wurden
- Adressen normalisiert wurden
- externe Prüfungen gemäß vereinbartem Umfang erfolgt sind
- Zahlungsbedingungen zugeordnet wurden
- Mahnbedingungen zugeordnet wurden
- nicht mehr aktive Unternehmen gekennzeichnet wurden
- kritische Konflikte bearbeitet wurden
- ein freigegebener Golden Record je Geschäftspartner vorliegt
- der bereinigte Datenbestand erfolgreich nach Gevis übertragen wurde
# 11.2 Abnahme Phase 2
Phase 2 gilt als abgeschlossen, wenn:
- Benutzer sich per SSO anmelden können
- Rollen und Berechtigungen funktionieren
- Kunden zentral angelegt werden können
- Lieferanten zentral angelegt werden können
- Zahlungsbedingungen verwaltet werden können
- Mahnbedingungen verwaltet werden können
- Live-Dublettenprüfung funktioniert
- Normalisierung funktioniert
- externe Unternehmensprüfung funktioniert
- die vereinbarte Creditreform-Bonitätsprüfung funktioniert
- Änderungen protokolliert werden
- freigegebene Datensätze automatisch nach Gevis übertragen werden
- Übertragungsfehler sichtbar und erneut ausführbar sind
# 11.3 Abnahme Phase 3
Phase 3 gilt als abgeschlossen, wenn:
- die zentrale Stammdatenplattform Änderungen selbstständig verteilt
- alle vorgesehenen Zielsysteme angebunden sind
- Übertragungen unabhängig voneinander erfolgen
- Fehler eines Zielsystems andere Systeme nicht blockieren
- fehlgeschlagene Übertragungen wiederholt werden können
- keine Synchronisationsschleifen entstehen
- der Synchronisationsstatus vollständig nachvollziehbar ist
# 12. Projektplanung
# 12.1 Umsetzung
#### Projektabschnitt 1 – Analyse
- Datenbanken analysieren
- Datenmodelle erfassen
- Schnittstellen prüfen
- Datenqualität analysieren
- Creditreform-Schnittstelle prüfen
- verfügbare Registerschnittstellen prüfen
- Mappingtabellen erstellen
#### Projektabschnitt 2 – Umsetzung Phase 1
- zentrale Datenbank erstellen
- Importer entwickeln
- Daten zusammenführen
- Dubletten erkennen
- Normalisierung durchführen
- Zahlungs- und Mahnbedingungen migrieren
- Web-Oberfläche für Konfliktfälle erstellen
- Golden Records erzeugen
- initialen Gevis-Import durchführen
#### Projektabschnitt 3 – Umsetzung Phase 2
- Web-Portal vervollständigen
- SSO implementieren
- Rechteverwaltung implementieren
- zentrale Stammdatenanlage aktivieren
- KI-Prüfung integrieren
- Registerabgleich integrieren
- Creditreform integrieren
- automatische Gevis-Übertragung aktivieren
#### Projektabschnitt 4 – Umsetzung Phase 3
- direkte Schnittstellen zu den Zielsystemen entwickeln
- Event-Verarbeitung implementieren
- Retry-Mechanismen implementieren
- Monitoring implementieren
- Gevis als notwendigen Verteiler ablösen
#### Projektabschnitt 5 – Umsetzung Phase 4
- weitere Stammdatenarten evaluieren
- Datenmodell erweitern
- weitere Systeme integrieren
# 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.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.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.