Vereinheitlichung verstreuter Geschäftsdaten in der Praxis

Der Finanzleiter stellt am Freitagnachmittag erneut dieselbe Frage: Wie viele Bestellungen haben wir tatsächlich in Bearbeitung? Um die Antwort zu finden, müssen Daten aus dem CRM des Vertriebs, dem Webshop, dem Lagersystem und einigen Excel-Dateien gesammelt werden. Bis der Bericht fertig ist, ist es nicht sicher, ob die Zahlen noch dieselbe Situation widerspiegeln. Die Vereinheitlichung verstreuter Geschäftsdaten betrifft genau solche Situationen – es geht nicht nur um Datenbanken, sondern darum, dass Führungskräfte und Mitarbeiter aus derselben Realität arbeiten.

Bei den meisten wachsenden Unternehmen ist es nicht ein einziges großes Systemproblem, das die Schwierigkeiten verursacht. Vielmehr häufen sich viele Lösungen an, die auf den ersten Blick sinnvoll erscheinen. Eine Tabelle anstelle eines alten Exports, eine manuelle E-Mail, weil zwei Systeme nicht kommunizieren, eine separate Aufzeichnung, weil es schneller war, einen neuen Prozess zu starten. Diese funktionieren einzeln. Zusammen jedoch machen sie den Betriebsablauf unsicher.

Das Problem ist nicht, dass es mehrere Systeme gibt.

In einer Organisation mit 50 oder 200 Personen ist es natürlich, dass es mehrere Systeme gibt. Der Webshop erfüllt eine andere Aufgabe als das ERP, das CRM, die Buchhaltungssoftware, die Produktionssteuerung oder die Lageranwendung. Es ist nicht das Ziel, alle Geschäftsprozesse in eine einzige Software zu zwängen. Solche Bestrebungen sind oft teuer, langsam und schaffen gleichzeitig neue Kompromisse.

Die eigentliche Frage ist, ob die mit einem Geschäftsvorfall verbundenen Daten nachvollziehbar sind. Wenn ein Kunde eine Bestellung aufgibt, ist es klar ersichtlich, wann sie eingegangen ist, was sie enthält, ob sie auf Lager ist, zu wem sie gehört, ob sie ausgeliefert und fakturiert wurde? Wenn jedes System darauf eine andere Antwort gibt, dann gibt es nicht einfach nur einen Datenmangel. Das Unternehmen hat mehrere, miteinander konkurrierende Realitätsbilder.

Dies hat auch menschliche Konsequenzen. Die Kollegen beginnen, ihre eigenen, als verlässlich erachteten Dateien zu verwenden. Die Führungskräfte fordern immer mehr Abstimmungen. Ein erfahrener Mitarbeiter wird zum Übersetzer zwischen den Systemen, der weiß, welcher Zahl man vertrauen kann. Wenn er in den Urlaub geht oder das Unternehmen verlässt, verlangsamt sich der Prozess plötzlich.

Wie zeigt sich das Problem verstreuter Geschäftsdaten?

Die Verstreutheit der Daten zeigt sich selten dadurch, dass jemand sagt: Unsere Datenarchitektur ist schlecht. Vielmehr ist sie an wiederkehrenden, alltäglichen Symptomen erkennbar. Der Monatsabschluss beginnt mit einer mehrtägigen Datensammlung. Das Lager fragt telefonisch oder per E-Mail nach einer Bestellbestätigung. Der Vertrieb verspricht einen Bestand, der tatsächlich schon reserviert ist. Die Rechnungsstellung kann erst nach manueller Überprüfung beginnen.

Ein besonders aussagekräftiges Zeichen ist, wenn dieselbe Stammdaten an mehreren Stellen gepflegt werden müssen. Eine Kundenadresse erscheint im CRM, in der Buchhaltungssoftware, im Webshop und auf der Speditionsplattform. Eine Artikelnummer oder ein Preis eines Produkts existiert in mehreren Tabellen. Dann ist nicht die Frage, ob es Abweichungen gibt, sondern wann sie entdeckt werden.

Die Kosten der Fehler sind nicht immer offensichtlich. Es kann ein Paket mit falschem Etikett sein, eine verspätet ausgestellte Rechnung oder ein ungenauer Bestandsbericht. Aber wenn sich diese täglich wiederholen, wächst die Verwaltung oft schneller als der Umsatz. Das Unternehmen stellt mehr Personal für die Koordination ein, während die grundlegende Unsicherheit des Prozesses unverändert bleibt.

Die Vereinheitlichung beginnt mit der Aufdeckung des Datenflusses

Vor der Vereinheitlichung verstreuter Geschäftsdaten ist es sinnvoll, nicht Systeme, sondern Prozesse zu untersuchen. Wählen Sie einen Prozess aus, der direkt den Umsatz, die Leistung oder das Kundenerlebnis beeinflusst. Dies kann der Weg von der Bestellung bis zur Rechnungsstellung, der Einkauf, die Reklamationsbearbeitung oder die Bearbeitung von Produktionsaufträgen sein.

Anschließend muss verfolgt werden, was tatsächlich passiert, und nicht das, was die Prozessbeschreibung annimmt. Wer erfasst die Daten zuerst? Welches System gilt als offizielle Quelle? Wer kopiert, ergänzt oder überprüft sie? Wo entsteht eine E-Mail, ein Telefonanruf oder ein Excel-Export, weil die Informationen dort nicht verfügbar sind, wo sie benötigt werden?

Bei einem Webshop-Händler kann die Bestellung beispielsweise automatisch eingehen, aber der Mitarbeiter exportiert sie jeden Morgen in eine Tabelle, überprüft dort den Bestand und erfasst die Daten dann manuell in der Buchhaltungssoftware. Auf den ersten Blick scheint es ein Problem von drei Systemen zu sein. Bei näherer Betrachtung könnte die Hauptfrage sein: Welches System verwaltet den verfügbaren Bestand und wann wird die Bestellung zur finanziellen Erfüllung? Solange es darauf keine klare geschäftliche Antwort gibt, wird eine technische Verbindung die Unsicherheit nur schneller weitertragen.

Wer ist der Datenverantwortliche?

Jede kritische Daten sollte einen primären Verantwortlichen haben. Dies muss nicht unbedingt eine Person sein, sondern ein eindeutig zugewiesenes System und Verantwortlichkeitsregel. Der Kundenstamm kann beispielsweise im CRM authentisch sein, die Rechnungsdaten im Finanzsystem, der physische Bestand im Lager- oder ERP-System.

Die Zuweisung eines Verantwortlichen bedeutet nicht, dass kein anderes System die Daten nutzen darf. Im Gegenteil: Die Informationen müssen dorthin gelangen, wo sie eine geschäftliche Aufgabe unterstützen. Der Unterschied besteht darin, dass klar ist, wo Änderungen vorgenommen werden können und wo der aktuelle Wert übernommen werden muss. Dies reduziert die Notwendigkeit doppelter Dateneingaben und späterer Abstimmungen.

Ebenso wichtig sind die Identifikatoren. Wenn derselbe Kunde, dasselbe Produkt oder dieselbe Bestellung in jedem System unter einem anderen Namen oder Code geführt wird, wird die Integration allein keine zuverlässigen Daten erzeugen. Einheitliche Identifikatoren sind weniger auffällig als ein neues Dashboard, aber sie bilden die Grundlage für spätere Berichte und automatisierte Prozesse.

Nicht jede Abweichung ist ein technischer Fehler

Viele Unternehmen machen den Fehler, bei der ersten Unregelmäßigkeit nach einem neuen System zu suchen. Doch abweichende Daten weisen oft auf das Fehlen echter Geschäftsregeln hin. Beispielsweise interpretiert der Vertrieb, das Lager und die Finanzabteilung den Status einer Bestellung unterschiedlich. Für das eine Team ist die Bestellung abgeschlossen, wenn der Kunde sie aufgegeben hat. Für das andere, wenn sie zusammengestellt wurde. Für die Finanzabteilung erst, wenn sie fakturierbar ist.

Alle drei Perspektiven können berechtigt sein, aber dasselbe Feld darf nicht mit unterschiedlicher Bedeutung verwendet werden. In solchen Fällen ist nicht unbedingt ein einziger Status erforderlich, sondern klar definierte Zustände, Verantwortliche und Übergabepunkte. Die Technologie kann dies später handhaben, aber die Definition ersetzt sie nicht.

Deshalb ist es sinnvoll, die Vereinheitlichungsarbeit mit Fragen zur Datenqualität zu beginnen. Welche Felder sind obligatorisch? Wer darf fehlerhafte Daten korrigieren? In welchem Fall kann ein System ein anderes überschreiben? Welche Verzögerung ist bei einer Aktualisierung akzeptabel? Bei einer logistischen Bestandsdaten können schon wenige Minuten entscheidend sein, während bei einem Managementkostenbericht eine tägliche Aktualisierung ausreichen kann. Die richtige Lösung hängt vom geschäftlichen Zeitbedarf der Entscheidung ab.

Wann ist eine Integration gerechtfertigt und wann ist eine andere Antwort erforderlich?

Wenn der Prozess klar ist, kann die Automatisierung der Datenübertragung zwischen den Systemen viel manuelle Arbeit beseitigen. Die Bestellung, die Bestandsbewegung, die Rechnung oder die Transportdaten können in das entsprechende System übertragen werden, ohne dass jemand sie erneut eingeben muss. Dies kann die Leistung beschleunigen, Tippfehler reduzieren und aktuellere Berichte liefern.

Aber nicht in jedem Fall ist die Integration der richtige erste Schritt. Es kann vorkommen, dass ein Prozess mit zu vielen Genehmigungen vereinfacht werden muss. Manchmal ist die Datenstruktur eines alten Systems so inkonsistent, dass zuerst eine Bereinigung, Standardisierung oder schrittweise Modernisierung erforderlich ist. Es gibt Fälle, in denen eine gezielte interne Anwendung den Ausnahmeprozess besser handhabt als eine weitere Anpassung eines allgemeinen Systems.

Bei der technischen Umsetzung ist die Zuverlässigkeit mindestens ebenso wichtig wie die Geschwindigkeit der Datenübertragung. Es muss klar sein, was passiert, wenn ein System vorübergehend nicht verfügbar ist, ein Datensatz fehlerhaft ist oder dieselbe Nachricht zweimal eingeht. Es muss Überprüfbarkeit, Fehlerprotokollierung, Rückverfolgbarkeit und klare Verantwortlichkeiten geben. Eine unsichtbar fehlerhafte Verbindung kann gefährlicher sein als ein gut sichtbarer manueller Schritt.

Ein guter Bericht entsteht nicht als separates Projekt

Das Management-Dashboard ist oft das sichtbarste Ergebnis einheitlicher Daten, aber es ist nicht ratsam, damit zu beginnen. Wenn die Daten hinter den Kennzahlen aus unterschiedlichen Definitionen, späten Exporten und manuellen Korrekturen bestehen, zeigt das schöne Diagramm nur schneller ungenaue Zahlen.

Zuerst muss festgelegt werden, welche Entscheidung der Bericht unterstützen soll. Muss der Lagerbestand, die Deckung, die Auftragsabwicklungszeit, Verzögerungen oder die Produktionskapazität sichtbar sein? Wer nutzt ihn, wie oft, und was passiert, wenn der Wert vom Plan abweicht? Ein gut gestalteter Bericht informiert nicht nur, sondern macht deutlich, wo eingegriffen werden muss.

Dauerhafte Ordnung entsteht nicht dadurch, dass alle Daten an einem Ort gesammelt werden. Sie entsteht dadurch, dass jeder weiß, welche Informationen verlässlich sind, wie sie zum nächsten Schritt gelangen und was passiert, wenn es Abweichungen gibt. Wenn dies klar ist, sind technologische Entwicklungen keine separaten Projekte mehr, sondern Teil eines berechenbareren Betriebs.