Drei Systeme, derselbe Kunde, drei verschiedene Länderabkürzungen für Deutschland. ERP sagt „DE“, das Produktionssystem sagt „DEU“, die Insel-Datenbank sagt „D“. Alle drei haben recht. Keines weiß davon.
So sah es aus bei einem Hersteller im Bereich Gebäudetechnik in Schleswig-Holstein, als ich ankam: ERP, Produktionsmanagement-Software und Content-Management-System liefen parallel, jedes mit einem eigenen Datenstamm. Dieselben Kunden, Artikel, Länder — dreifach gepflegt, dreifach abweichend.
Warum Insel-Datenbanken neben dem ERP entstehen
Insel-Datenbanken sind kein Versagen. Sie entstehen, weil das ERP etwas nicht kann oder zu langsam kann.
Die Produktionsabteilung braucht eine schnelle Erfassungsmaske ohne ERP-Freigabeprozess. Das Marketing braucht Stammdaten in einem Format, das die Branchenlösung nicht liefert. Das Lager will eine Auswertung, die drei Klicks im ERP bedeutet. Also baut jemand mit Microsoft Access schnell etwas Passendes — und das Ding läuft, weil es die Arbeit erleichtert.
Das Problem entsteht nicht beim Bau der Insel. Es entsteht, wenn die Insel wächst und niemand mehr weiß, welche Version eines Wertes die gültige ist.
Typischer Befund in der Praxis: Ein Datensatz existiert im ERP, in der Insel-DB und in einer Excel-Exportdatei, die irgendjemand irgendwann angelegt hat. Drei Wahrheiten für denselben Wert.
Was ein Export-Excel nicht löst
Die naheliegende Antwort ist meistens: „Wir exportieren morgens aus dem ERP und spielen das in Access ein.“ Das ist kein Sync. Das ist ein Snapshot mit Verfallsdatum.
Ein Export-Excel hat drei strukturelle Schwächen:
Erstens ist er tagaktuell, nicht echtzeit. Wer mittags im ERP einen Artikel anlegt, sieht ihn in Access erst am nächsten Morgen, wenn jemand den Export manuell angestoßen hat — oder auch nicht, wenn die Person krank ist.
Zweitens ist er unidirektional. Daten fließen vom ERP nach Access. Was in Access gepflegt wird, kommt nie zurück.
Drittens ist er nicht bereinigt. Wenn ERP und Access unterschiedliche Schlüssel verwenden — etwa verschiedene Länderabkürzungen — bricht der Export entweder ab oder erzeugt Dubletten.
Ein schreibender Sync ist etwas anderes. Er läuft automatisch, läuft in beide Richtungen und behandelt Konflikte nicht als Fehler, sondern als Information.
Wie ein nächtlicher Sync mit Bereinigungsstufe aussieht
Beim Hersteller in Schleswig-Holstein lief der Datenaustausch zwischen ERP, Produktionssystem und Content-System über einen nächtlichen SQL-Server-Job. Die Architektur hatte drei Ebenen:
Staging-Tabellen nehmen die Rohdaten aus allen drei Systemen auf, ohne sie sofort in den produktiven Bestand zu schreiben. Jede Quelltabelle hat ein eigenes Staging-Pendant mit Herkunftskennzeichen und Zeitstempel.
Bereinigungsregeln laufen auf dem Staging. Länderabkürzungen werden auf einen Zielschlüssel gemappt — eine Mapping-Tabelle in Access, gepflegt von einer Person, die die Besonderheiten der Systeme kennt. „D“, „DE“, „DEU“ werden auf „DE“ normalisiert. Gleiches Prinzip für Artikelnummern, Lieferantenkürzel, Warengruppen.
Konfliktfälle landen nicht automatisch im Zielbestand. Sie landen in einer Prüftabelle, die am nächsten Morgen von einer definierten Person in Access bearbeitet wird. Das ist bewusst: Manche Konflikte sind keine technischen Fehler, sondern fachliche Entscheidungen. Die Technik soll sie sichtbar machen, nicht lösen.
Das Ergebnis: Ein zentraler SQL-Server-Bestand, der Quelldaten aus allen drei Systemen kennt und einmal täglich konsolidiert. Die Access-Insel bleibt — aber als Bereinigungswerkzeug, nicht als dritte Wahrheit.
Wo dieser Ansatz an Grenzen stößt
Ein Sync ist kein ERP-Ersatz und kein Integrationsprojekt. Er eignet sich, wenn die Systeme stabil laufen, die Datenmengen überschaubar sind und die Konflikte sich auf bekannte Schlüsselprobleme reduzieren lassen.
Wer drei Systeme mit täglich tausenden Bewegungsdaten und komplexer Prozesskopplung hat, braucht eine andere Architektur. Dann ist eine Middleware oder eine Integrationsplattform das richtigere Werkzeug.
Wer dagegen eine überschaubare Insel-DB mit einigen tausend Stammdatensätzen hat und das manuelle Dreifach-Pflegen loswerden will, für den ist ein SQL-Server-basierter Nacht-Sync mit manueller Konflikttabelle oft die pragmatischste Antwort.
Was das für dich bedeutet, wenn du nicht der Entwickler bist
Du zahlst gerade dafür, dass dieselbe Information dreimal eingepflegt wird. Einmal im ERP, einmal in der Insel-DB, einmal in irgendeiner Excel-Datei. Jedes Mal mit dem Risiko, dass einer der drei Werte falsch ist.
Ein schreibender Sync ist kein großes IT-Projekt. Er ist eine Automatisierung eines Vorgangs, den ihr heute manuell macht — mit einem zusätzlichen Filter für die Fälle, bei denen ein Mensch entscheiden muss.
Wer das einmal anschauen lassen möchte, erreicht mich über sesoft.de/kontakt.
Autor
Sönke Schäfer berät seit über 25 Jahren norddeutsche Unternehmen bei der Anbindung von Branchensoftware an eigenentwickelte Datenbanklösungen. Sein Schwerpunkt liegt auf SQL-Server-basierten Integrationsarchitekturen und auf der pragmatischen Weiterentwicklung von Microsoft-Access-Beständen, die neben ERP-Systemen entstanden sind.