Fallstudie zur Systemintegration bei einem Webshop

Jemand öffnet jeden Morgen das Admin-Interface des Webshops, lädt die neuen Bestellungen herunter und überträgt sie dann in das Verwaltungssystem. Danach überprüft er den Lagerbestand in einer separaten Tabelle, sendet die Mängelliste an das Lager und korrigiert die Zeilen, in denen die Daten abweichen. Bis der Prozess abgeschlossen ist, sind bereits neue Bestellungen eingegangen. Diese Fallstudie zur Systemintegration ist keine Geschichte eines schlecht arbeitenden Teams. Im Gegenteil: Es handelt sich um Mitarbeiter, die versuchen, den bestehenden Prozess funktionsfähig zu halten, während das Unternehmen aus ihm herauswächst.

Das folgende Beispiel zeigt einen typischen, anonymisierten wachsenden Handelsbetrieb. Die Lehre daraus ist nicht, dass für jedes Problem ein neues System oder ein vollständiger ERP-Austausch die Antwort ist. Der Kernpunkt ist, dass man zuerst verstehen muss, wo der Informationsfluss unterbrochen wird und warum Menschen die Verbindung zwischen den Systemen ersetzen.

Fallstudie zur Systemintegration: Wenn Bestellungen manuell reisen

Das Unternehmen verkaufte Tausende von Produkten über den eigenen Webshop und einige Partnerkanäle. Der Webshop, das Rechnungsprogramm und die Lagerverwaltung funktionierten jeweils für sich. Das Problem lag in dem, was dazwischen geschah.

Die Bestelldaten wurden zweimal täglich in das Verwaltungssystem übertragen. Die Lagerinformationen gelangten nur verzögert zurück in den Webshop, sodass es vorkam, dass ein Produkt noch kaufbar war, obwohl es bereits ausverkauft war. Vor der Rechnungsstellung überprüften die Kollegen manuell die Kundendaten, die Versandart und die Nachnahmebestellungen. Wenn ein Kunde seine Adresse änderte, erschien die Änderung oft nur in einem der Systeme.

Die erste Frage der Geschäftsführung war verständlicherweise: Sollen wir die Bestellabwicklung automatisieren? Die richtige erste Frage war jedoch eine andere: Warum muss dieselbe Bestellung dreimal überprüft werden und welches System ist die verlässliche Quelle für die jeweiligen Daten?

Dieser Unterschied ist wesentlich. Wenn man einen ungeordneten Prozess technisch verbindet, überträgt die Integration die Fehler nur schneller. Eine fehlerhafte Lagerlogik, ein unvollständiger Artikelstamm oder unklare Verantwortlichkeiten werden nicht dadurch gelöst, dass die Datenübertragung automatisch erfolgt.

Die Untersuchung begann nicht mit den Schnittstellen

Bei der Kartierung des Prozesses wurde nicht zuerst darauf geachtet, welche APIs die Systeme haben. Man verfolgte, was passiert, vom Eingang einer Bestellung bis zum Versand des Pakets und der Erstellung der Rechnung und des Berichts.

Es stellte sich heraus, dass ein erheblicher Teil der manuellen Arbeit keine echte Dateneingabe war, sondern Risikomanagement. Die Mitarbeiter überprüften jede Bestellung, weil sie den Lagerdaten nicht vertrauten. Sie führten separate Tabellen über problematische Artikel, weil im Lagersystem nicht einfach nach Teillieferungen gefiltert werden konnte. Sie stimmten sich per E-Mail mit der Finanzabteilung ab, weil der Status von Rückerstattungen nicht einheitlich ins Kundenmanagement zurückfloss.

Die Untersuchung klärte vier Entscheidungen. Der Webshop wurde zur Quelle des Bestelleingangs, das Verwaltungssystem für die Rechnungs- und Finanzstatus, und das Lagersystem für den tatsächlichen Bestand und die Erfüllung. Außerdem musste festgelegt werden, wann eine Bestellung als bearbeitbar gilt, wie mit Lagerengpässen umgegangen wird und wer berechtigt ist, Ausnahmen zu erstellen.

Dies ist weniger spektakuläre Arbeit als der Start einer neuen Integration, aber hier entscheidet sich, wie viele Ausnahmen später manuell korrigiert werden müssen. Eine gute Systemverbindung ist nicht dadurch gut, dass sie viele Daten bewegt, sondern dadurch, dass alle Beteiligten denselben Geschäftsstatus sehen.

Wohin gehört welche Daten?

Hinter den meisten Integrationsproblemen steht eine einfache, aber unbeantwortete Frage: Wenn dieselben Daten in mehreren Systemen vorkommen, welche sind gültig?

In diesem Fall konnten der Produktname und die Marketingbeschreibung im Webshop bleiben, aber der Bestand, der Beschaffungsstatus und die Lieferfähigkeit waren an den Lagerbetrieb gebunden. Die Rechnungsdaten und der Zahlungsstatus kamen aus dem Verwaltungssystem zurück. Nicht jedes Feld musste überallhin kopiert werden. Nur das, welches dort eine geschäftliche Rolle hatte.

Dies verringerte die Anzahl der Datenkonflikte und machte auch das Fehlermanagement klarer. Wenn der Bestand fehlerhaft ist, muss nicht der Webshop-Kollege in drei Systemen nachforschen. Es wird sichtbar, wo die Abweichung entstanden ist und wer für die Korrektur verantwortlich ist.

Die Lösung: gezielte Verbindung, kein vollständiger Systemwechsel

Nach der Erhebung wurde kein neues Unternehmensführungssystem eingeführt. Die bestehenden Systeme unterstützten noch die grundlegenden Geschäftsanforderungen, ein vollständiger Austausch hätte jedoch ein unangemessenes Risiko, Kosten und betriebliche Belastung bedeutet.

Stattdessen verwaltete eine Zwischenintegrationsschicht die Übertragung von Bestell-, Bestands- und Statusdaten. Diese Schicht überprüfte die Pflichtfelder, protokollierte die Datenbewegungen und separierte die Fälle, die eine menschliche Entscheidung erforderten. Beispielsweise verschwand eine unbekannte Artikelnummer oder eine nicht interpretierbare Versandart nicht stillschweigend im Prozess. Das System gab eine Fehlermeldung aus und der zuständige Mitarbeiter sah die Aufgabe in einer handhabbaren Ausnahmeliste.

Die Integration wurde nicht auf einmal scharf geschaltet. Zuerst wurden die Bestellstatus, die Mehrwertsteuersätze, die Rabatte, die Teillieferungen und die stornierten Belege mit Testdaten überprüft. Danach startete der Betrieb mit einem engeren Produktkreis und schließlich schrittweise mit dem gesamten Umsatz.

Die schrittweise Einführung war keine Verzögerung, sondern ein Schutz des Geschäftsbetriebs. In einem Bestellprozess betrifft Datenverlust, doppelt berechnete Artikel oder fehlerhafte Bestandsanzeige direkt den Kunden. Daher gehörten zur Aktivierung auch Wiederherstellungsmöglichkeiten, Protokollierung, Berechtigungsregelung und ein klares Fehlermanagementverfahren.

Was hat die Systemintegration im Arbeitsalltag verändert?

Das auffälligste Ergebnis war nicht nur, dass weniger Daten manuell erfasst werden mussten. Das morgendliche Bestellkopieren entfiel, aber noch wichtiger war, dass die Kollegen den Tag nicht damit begannen, die Abweichungen vom Vorabend zu suchen.

Das Lager erhielt schneller eine bearbeitbare Bestellliste. Der Kundenservice sah denselben Bestell- und Erfüllungsstatus wie die Logistik. Die Finanzabteilung musste keine separaten Listen für Rückerstattungen anfordern. Die Geschäftsführung erhielt einen Bericht, der nicht aus dem wöchentlichen Zusammenfügen mehrerer Dateien bestand.

Die messbare Wirkung variiert je nach Unternehmen, daher lohnt es sich nicht, im Voraus allgemeine Prozentsätze zu versprechen. In dieser Art von Situation reduziert sich jedoch in der Regel die Zeit für manuelle Überprüfungen, es gibt weniger Korrekturen aufgrund von Tippfehlern und die Bestellabwicklung wird schneller. Der weniger quantifizierbare Gewinn ist ebenfalls erheblich: Der Betrieb stützt sich nicht auf das Gedächtnis und die tägliche Aufmerksamkeit einer einzigen erfahrenen Person.

Was sich nicht zu automatisieren lohnt

Nicht jede Ausnahme muss beseitigt werden. Eine Bestellung mit hohem Wert und individuellen Lieferbedingungen oder eine verdächtige Zahlungssituation kann eine menschliche Genehmigung rechtfertigen. Das Ziel ist nicht, dass jede Entscheidung maschinell getroffen wird, sondern dass das System erkennt, was ein normaler Geschäftsprozess ist und was tatsächlich Aufmerksamkeit erfordert.

Deshalb blieben in der Integration bewusste Kontrollpunkte. Bestellungen, die das Nachnahmelimit überschreiten, unvollständige Adressdaten und bestimmte Fälle von Lagerengpässen wurden zur Überprüfung vorgelegt. Der Unterschied war, dass die Mitarbeiter nicht jede Bestellung überprüften, sondern nur die, bei denen es einen geschäftlichen Grund dafür gab.

Was sollte man im eigenen Betrieb erkennen?

Ein Systemintegrationsprojekt ist dann gerechtfertigt, wenn das Problem nicht auf einen einzelnen Fehler einer Person oder eine vorübergehende organisatorische Störung zurückzuführen ist, sondern auf ein wiederkehrendes Betriebsmuster. Ein solches Zeichen ist, wenn dieselben Daten an mehreren Stellen geführt werden, wenn Abteilungen per E-Mail Informationen weitergeben, die im System erscheinen sollten, oder wenn die Erstellung eines wöchentlichen Managementberichts Stunden dauert.

Die Tiefe der Lösung hängt davon ab, wie stabil die bestehenden Systeme sind, wie die Datenqualität ist und wie viele Ausnahmen der Prozess behandelt. In einigen Fällen genügen einige gut definierte Datenverbindungen. Anderswo müssen zuerst der Artikelstamm, die Verantwortungsbereiche oder der Lagerprozess in Ordnung gebracht werden. Die technologische Entscheidung kann erst danach dauerhaft gut sein.

Wenn in einem wachsenden Unternehmen die Mitarbeiter regelmäßig als Menschen zwischen zwei Systemen agieren, bedeutet das nicht unbedingt, dass mehr Personal benötigt wird. Oft deutet es darauf hin, dass es sich lohnt, den Informationsfluss selbst zu untersuchen - bevor der nächste Wachstumsschritt noch mehr manuelle Arbeit in den Betrieb einbaut.