Doppelt hält besser – nur bei Stammdaten nicht!

Stammdaten steuern alle betriebswirtschaftlichen Prozesse. Stimmen Stammdaten nicht, dann „vererben“ sich Fehler in die Geschäftsvorfälle und dann geht immer etwas systematisch schief. Ähnliche Probleme entstehen, wenn in SAP Stammdaten nicht eindeutig sind, weil Stammdatendubletten existieren. Dieser Blog Post erklärt, was die spezifischen Probleme von Stammdatendubletten sind und wie diese im betrieblichen Umfeld entstehen. Wie es sich für einen ordentlichen SAP Audit Blog Beitrag gehört, wird natürlich auch verraten, wie man Stammdatendubletten bei Kreditoren und Debitoren in SAP ausfindig macht, um daraufhin einmal richtig aufzuräumen.

Wie entstehen Stammdatendubletten?

Zunächst mal könnte man denken, Stammdatendubletten sind eigentlich kein Problem. Warum sollte man denn für z.B. ein und denselben Kreditor zweimal Stammdaten anlegen? Natürlich passiert das in aller Regel nicht bewusst oder mit Absicht, sondern weil man den Überblick verloren hat.

Gründe für Stammdatendubletten sind in der Praxis häufig:

• Schlechte Master Data Governance: Zuständigkeiten für die Anlage von Stammdaten sind unklar und deshalb sind verschiedene Personen mit der Anlage von Stammdaten beschäftigt und es passieren dadurch Doppelarbeiten.

• Mangelnde Funktionstrennung (Segregation of Duties): Es gibt kein ordentliches Berechtigungskonzept im SAP-System und es wird bei der Vergabe von Zugriffsberechtigungen nicht auf die Funktionstrennung geachtet. Z.B. sollte eine Person nicht in der Lage sein, Kreditorenstammdaten anzulegen / zu ändern und Eingangsrechnungen zu buchen. Da die Berechtigungen zu weitreichend vergeben werden, wird davon auch gebraucht gemacht und Kreditorenstammdaten von verschiedenen Personen angelegt.
• Konsolidierung mehrerer Datenquellen: Verschiedene Datenquellen liefern (auch im Rahmen automatischer Prozesse) Stammdaten in ein SAP-System. Es entstehen Stammdatendubletten, da z.B. ein Kreditor in einem Quellsystem zwar nur einmal vorkommt, aber womöglich in mehreren Quellsystemen gleichzeitig existiert.
• Datenmigrationen: Bei einer Daten- oder Systemmigration werden Daten in ein neues SAP-System transferiert. Weil es bei solchen Projekten häufig hektisch und zeitkritisch wird, sieht man über eine Stammdatenbereinigung („Data Cleansing“) vor der Migration großzügig hinweg. Im neuen SAP-Zielsystem ist die Datenqualität dann gleich von Anfang an schlecht.

Was ist das Problem bei Stammdatendubletten?

Stammdatendubletten müssen nicht schlimm sein, wenn die Beteiligten um die Existenz von Stammdatendubletten wissen – aber in der Praxis ist das natürlich ein Problem. Folgende Phänomene und die damit verbundenen Probleme treten bei Stammdatendubletten häufig auf:

• Saldo für Kreditoren nicht mehr feststellbar: Gibt es für denselben Kreditor mehrere Kreditorenkonten und verteilen sich die Verbindlichkeiten auf diese Konten, so ist nicht mehr eindeutig feststellbar, wie hoch die Verbindlichkeiten ggü. solchen Kreditoren sind.
• Verbindlichkeiten werden schlecht gefunden: Verbindlichkeiten werden schlecht wiedergefunden, da sich diese willkürlich auf verschiedenen Kreditorenkonten befinden.
• Chaotische Offene-Posten Verwaltung: Weil Verbindlichkeiten schlecht aufgefunden werden, wird die Auszifferung von offenen Posten komplizierter und dauert länger.
• Hektische Bezahlprozesse: Da aufgrund mehrerer Kreditorenkonten der Überblick verloren geht und der Lieferant die Zahlung anmahnt, wird hektisch gezahlt. Weil es hektisch passiert, wird dies als Anzahlung gebucht (Downpayment) und nicht sofort die Verbindlichkeit mit ausgeziffert. Dadurch wird die Offene-Posten Verwaltung noch chaotischer.
• Überzahlungen: Weil sich Verbindlichkeiten unübersichtlich auf verschiedenen Kreditorenkonten befinden und dann mittels Anzahlungen hektisch beglichen wird, werden Lieferanten überzahlt, ohne dass dies sofort bemerkt wird.
• Vermögensschäden: Die Rückforderung von Zahlungen an überzahlte Lieferanten gestaltet sich zäh. Einige Lieferanten sind mittlerweile schon insolvent oder haben den Betrieb aufgegeben. Man bleibt auf der Rückforderung sitzen. Die Kohle ist weg.

Wie identifiziert man Stammdatendubletten?

Um den mit Stammdatendubletten verbundenen Problemen zu entgehen, muss man die Stammdaten aufräumen. Dies geht aber erst, wenn man diese zuverlässig identifiziert hat. Je nachdem, ob es sich um Kreditorenstammdaten oder um Debitorenstammdaten handelt, gibt es hierfür verschiedene Ansätze:

• Mehrfach verwendete USt-IDs: Bei Debitorenstammdaten ist die Verwendung derselben USt-Identifikationsnummern mehrfach bei verschiedenen Debitoren eine Indikation dafür, dass Stammdatendubletten vorliegen. In den SAP Daten kann man deshalb auswerten, ob es USt-IDs gibt, die bei mindestens zwei Debitoren hinterlegt sind.
• Mehrfach verwendete Steuernummern: Bei z.B. Kreditorenstammdaten ist die Verwendung derselben Steuernummer (gemeint ist hier nicht die USt-ID) mehrfach bei verschiedenen Kreditoren eine Indikation dafür, dass Stammdatendubletten vorliegen. In den SAP Daten kann man deshalb auswerten, ob es Steuernummern gibt, die bei mindestens zwei Kreditoren hinterlegt sind.
• Mehrfach verwendete Bankverbindungen: Bei z.B. Kreditorenstammdaten ist die Verwendung derselben Bankverbindung mehrfach bei verschiedenen Kreditoren eine Indikation dafür, dass Stammdatendubletten vorliegen. In den SAP Daten kann man deshalb auswerten, ob es Bankverbindungen gibt, die bei mindestens zwei Kreditoren hinterlegt sind.
• Abgleich des Lieferantennamen und der Adresse im Lieferantenstamm: In den SAP Kreditorenstammdaten könnte man abfragen, ob Lieferanten den gleichen Namen und gleiche Adresse haben. Ein exakter Vergleich z.B. des Lieferantennamens, der Straße und des Ortes ist aber häufig nicht zu empfehlen, da leicht unterschiedliche Schreibweisen eine Entdeckung mangels exakter Übereinstimmung vereiteln. Man sollte diese Merkmale deshalb dahingehend abgleichen, ob diese „weich“ übereinstimmen. Hierfür kann man phonetische Algorithmen verwenden. Phonetische Algorithmen prüfen, ob sich zwei Worte von der Aussprache her gleichen. Die Aussprache kann dann gleich sein, obwohl die Ausgangsworte sich (leicht) unterscheiden. Ein häufig verwendeter Algorithmus ist . Bei SOUNDEX ergeben die Worte „HAMBURG“, „HAMABURG“ und „HAMBURCH“ alle den SOUNDEX-Code „H516“. Dagegen ergibt „HARBURG“ den SOUNDEX-Code „H616“. „HAMBURG“ und „HARBURG“ wären also nicht gleich gemäß SOUNDEX, „HAMBURG“ und „HAMABURG“ dagegen schon.

Wenn Sie wissen möchten, wie man alle diese Ansätze schnell und einfach mit einigen Datenbank-Queries in SQL umsetzen kann, dann laden Sie sich die zugehörige SQL-Anleitung herunter. In der Anleitung befindet sich ein SQL-Glossar mit Datenbank-Queries, die Ihnen Ihre Arbeit erleichtert:

Was macht man gegen Stammdatendubletten?

Wenn man die Stammdatendubletten identifiziert hat, kann man auch etwas dagegen tun. Sinnvolle Maßnahmen sind:

1. Umbuchung: Buchen Sie alle Forderungen und Verbindlichkeiten von Stammdatendubletten auf das richtige Personenkonto um und gleichen Sie damit alle offenen Posten auf den redundanten Personenkonten aus.
2. Sperrung: Sperren Sie in SAP die redundanten Personenkonten für weitere Buchungen.
3. Archivierung: Archivieren Sie die redundanten Personenkonten, damit Sie diese nach den Aufräumarbeiten irgendwann löschen können.