Zentrale Stammdatenverwaltung Dieses Buch beschreibt die fachlichen und technischen Anforderungen an die geplante zentrale Stammdatenplattform. Es dient als Pflichtenheft, Architekturgrundlage und fortlaufende Projektdokumentation. Dokumentstatus: EntwurfVersion: 0.1Stand: 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 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: Zusammenführung bestehender Stammdaten aus allen relevanten Quellsystemen. Erkennung und Bereinigung von Dubletten. Prüfung bestehender Stammdaten auf Plausibilität und Richtigkeit. Abgleich mit externen Datenquellen. Normalisierung von Adress- und Kommunikationsdaten. Vereinheitlichung von Zahlungs- und Mahnbedingungen. Dokumentation historischer und nicht mehr gültiger Datensätze. Zentrale Neuanlage von Kunden und Lieferanten. Vermeidung zukünftiger Doppelanlagen. Automatische Bonitätsprüfung neuer Kunden. Zentrale Verwaltung von Zahlungs- und Mahnbedingungen. Automatische Verteilung neuer oder geänderter Stammdaten an angebundene Systeme. Vollständige Nachvollziehbarkeit automatischer und manueller Änderungen. 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: 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.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. 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: amtliche bzw. verifizierte Daten Creditreform-Daten interne Unternehmensdaten Benutzereingaben normalisierte Daten 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: 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 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 ↓ 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 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: Welche Datenbankstrukturen besitzen Unitrade, Gevis, AddOne und Addison? Welche Systeme verfügen über dokumentierte APIs? Welche Systeme erlauben direkten lesenden Datenbankzugriff? Welche Systeme erlauben Schreibzugriffe per API? Welche konkreten Registerdaten können automatisiert abgefragt werden? Welche Creditreform-Produkte und APIs stehen zur Verfügung? Welches SSO-Verfahren wird verwendet? Welche Verfügbarkeitsanforderungen bestehen? Welche RPO- und RTO-Anforderungen gelten? Welche technischen Anforderungen bestehen an die Zielsysteme? 13.2 Fachliche offene Punkte Folgende fachliche Entscheidungen müssen getroffen werden: Welche Datenquelle gilt bei widersprüchlichen Angaben für welches Feld als führend? Welche Daten dürfen automatisch korrigiert werden? Welche Änderungen benötigen eine manuelle Freigabe? Welche Schwellenwerte gelten für automatische Dublettenentscheidungen? Welche Zahlungsbedingungen existieren alt und neu? Welche Mahnbedingungen existieren alt und neu? Welche Systeme benötigen welche IDs? Welche internen Felder dürfen nicht durch externe Informationen überschrieben werden? Welche Bonitätsinformationen werden benötigt? Welche Benutzer dürfen Bonitätsinformationen einsehen? 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.