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 erhalten, 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, dass die Zahlen noch dieselbe Situation widerspiegeln. Die Vereinheitlichung verstreuter Geschäftsdaten bezieht sich genau auf 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 einziger großer Systemfehler, der das Problem verursacht. Vielmehr überlagern sich viele Lösungen, die auf den ersten Blick vernünftig erscheinen. Eine Tabelle statt 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 können einzeln funktionieren. Zusammen jedoch machen sie den Betriebsablauf unsicher.

Das Problem ist nicht, dass es mehrere Systeme gibt

Für eine Organisation mit 50 oder 200 Personen ist es natürlich, mehrere Systeme zu haben. Der Webshop erfüllt eine andere Aufgabe als das ERP, das CRM, die Rechnungsstellung, die Produktionssteuerung oder die Lageranwendung. Es ist nicht das Ziel, alle Geschäftsprozesse in eine einzige Software zu zwingen. Solche Bestrebungen sind oft teuer, langsam und schaffen neue Kompromisse.

Die eigentliche Frage ist, ob die mit einem Geschäftsvorfall verbundenen Daten nachvollziehbar sind. Wenn ein Kunde eine Bestellung aufgibt, ist es dann klar ersichtlich, wann sie eingegangen ist, was sie enthält, ob sie auf Lager ist, zu wem sie gehört, ob sie ausgeliefert und in Rechnung gestellt wurde? Wenn jedes System darauf eine andere Antwort gibt, 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 überprüft geltenden Dateien zu verwenden. Die Führungskräfte verlangen 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 darin, dass jemand sagt: Unsere Datenarchitektur ist schlecht. Vielmehr erkennt man sie an wiederkehrenden, alltäglichen Symptomen. Der Monatsabschluss beginnt mit einer mehrtägigen Datensammlung. Das Lager fragt telefonisch oder per E-Mail eine Bestätigung für eine Bestellung an. Der Vertrieb verspricht einen Bestand, der tatsächlich bereits reserviert ist. Die Rechnungsstellung kann erst nach manueller Überprüfung gestartet werden.

Ein besonders aussagekräftiges Zeichen ist, wenn dieselbe Grunddaten an mehreren Stellen gepflegt werden müssen. Eine Kundenadresse erscheint im CRM, in der Rechnungsstellung, im Webshop und auf der Speditionsplattform. Eine Artikelnummer oder ein Preis eines Produkts lebt 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 einem falschen Etikett sein, eine verspätet ausgestellte Rechnung oder ein ungenauer Bestandsbericht. Aber wenn diese täglich wiederkehren, wächst die Verwaltung oft schneller als der Umsatz. Das Unternehmen stellt mehr Menschen für die Koordination ein, während die grundlegende Unsicherheit des Prozesses unverändert bleibt.

Die Vereinheitlichung beginnt mit der Untersuchung des Datenwegs

Vor der Vereinheitlichung verstreuter Geschäftsdaten lohnt es sich, 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, das Reklamationsmanagement oder die Bearbeitung von Produktionsaufträgen sein.

Danach muss verfolgt werden, was tatsächlich passiert, nicht das, was die Prozessbeschreibung annimmt. Wer erfasst die Daten zuerst? Welches System gilt als offizielle Quelle? Wer kopiert, ergänzt oder überprüft? 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 im Rechnungswesen. 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 Leistung? 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 klar zugewiesenes System und Verantwortlichkeitsregel. Der Kundenstamm kann beispielsweise im CRM authentisch sein, die Rechnungsdaten im Finanzsystem und der physische Bestand im Lager- oder ERP-System.

Die Zuweisung eines Verantwortlichen bedeutet nicht, dass ein anderes System die Daten nicht verwenden kann. Im Gegenteil: Die Informationen müssen dorthin gelangen, wo sie eine geschäftliche Aufgabe unterstützen. Der Unterschied besteht darin, dass klar ist, wo sie geändert 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 unterschiedliche Daten weisen oft auf das Fehlen realer Geschäftsregeln hin. Zum Beispiel 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 gut 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 Management-Kostenbericht eine tägliche Aktualisierung ausreichend sein 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 Frachtinformationen können ohne erneute Eingabe in das entsprechende System übertragen werden. 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 sein, dass ein Prozess mit zu vielen Genehmigungen vereinfacht werden muss. Manchmal ist die Datenstruktur eines alten Systems so inkonsistent, dass es zuerst gereinigt, standardisiert oder schrittweise modernisiert werden muss. 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 genauso wichtig wie die Geschwindigkeit der Datenübertragung. Es muss bekannt sein, was passiert, wenn ein System vorübergehend nicht verfügbar ist, ein Datensatz fehlerhaft ist oder dieselbe Nachricht zweimal ankommt. Es muss Nachvollziehbarkeit, Fehlerprotokollierung, Rückverfolgbarkeit und klare Verantwortung 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 zusammengeführt werden. Sie entsteht dadurch, dass jeder weiß, welche Informationen zuverlässig sind, wie sie zum nächsten Schritt gelangen und was passiert, wenn es Abweichungen gibt. Wenn dies klar ist, sind technologische Entwicklungen keine isolierten Projekte mehr, sondern Teil eines berechenbareren Betriebs.