Wechsel der Vertriebssoftware ohne Betriebsunterbrechung

Die häufigste Ursache für ein Scheitern ist die Big-Bang-Umstellung: An einem Freitagabend wird das alte System abgeschaltet, das neue eingeschaltet, und am Montagmorgen entdeckt das gesamte Unternehmen gleichzeitig das Unbekannte. Das kleinste Problem — ein ungetesteter Ablauf, ein fehlendes Zugriffsrecht, ein missverstandener Bildschirm — verbreitet sich sofort über alle Lager, ohne Sicherheitsnetz. Was ein kleiner Vorfall gewesen wäre, wird zu einer für alle Kunden sichtbaren Krise.

Die zweite Ursache, still, aber verheerend, sind schmutzige Daten. Doppelte Kunden, Phantomprodukte, inkonsistente Maßeinheiten, veraltete Adressen: Das alte System duldete sie aus Gewohnheit, das neue lehnt sie ab oder, schlimmer, verbreitet sie. Man migriert einen Katalog und eine Kundendatei niemals „wie sie sind", ohne sie zuerst bereinigt zu haben.

Vernachlässigte Schulung vervollständigt das Bild. Exzellente Software, die von einem unvorbereiteten Team genutzt wird, liefert schneller schlechte Ergebnisse als mittelmäßige Software, die gut beherrscht wird. Schließlich starten viele Unternehmen ohne Rückfallplan: Wenn etwas schiefgeht, gibt es keinen dokumentierten Weg zurück, und Panik ersetzt die Entscheidung.

Der rote Faden all dieser Misserfolge ist derselbe: die Migration als einmaliges technisches Ereignis zu behandeln statt als schrittweises Betriebsprojekt. Die folgenden Abschnitte schlagen das Gegenteil vor.

Parallelbetrieb bedeutet, das alte und das neue System gleichzeitig über einen definierten Zeitraum laufen zu lassen. Konkret wird zwei bis vier Wochen lang jeder kritische Vorgang — Auftragserfassung, Wareneingang, Versand, Fakturierung — in beide Werkzeuge eingegeben. Das ist ein vorübergehender Mehraufwand, aber der Preis für ein echtes Sicherheitsnetz: Zu keinem Zeitpunkt verlieren Sie die Fähigkeit, einen Kunden zu bedienen.

Das Herzstück der Methode ist der tägliche Abgleich. Am Ende jedes Tages werden die beiden Systeme anhand einiger einfacher Kennzahlen verglichen: Anzahl der Aufträge, gesamter fakturierter Wert, Bestandsbewegungen, Inventurabweichungen. Eine Abweichung ist kein Scheitern, sondern eine Information: Sie deckt ein falsches Mapping, eine schlecht übersetzte Geschäftsregel oder eine zu korrigierende Benutzeraktion auf. Jede Abweichung und ihre Behebung wird dokumentiert.

Die Umstellung darf niemals vom Kalender abhängen, sondern von messbaren Vertrauenskriterien, die im Voraus definiert werden. Zum Beispiel: drei aufeinanderfolgende Tage ohne Fakturierungsabweichung über einem Schwellenwert; null verlorene Aufträge; Erfassungszeit wieder normal; stabile Versandfehlerquote. Solange diese Kriterien nicht erfüllt sind, verlängert man den Parallelbetrieb, statt zu erzwingen.

Dieser Zeitraum hat auch einen menschlichen Vorzug: Er verwandelt Angst in Gewohnheit. Die Teams lernen das neue Werkzeug an echten Daten, aber ohne unumkehrbaren Einsatz, da das alte System die Quelle der Wahrheit bleibt, bis Vertrauen aufgebaut ist. Mit SupplyCore erleichtern der CSV- und JSON-Export/-Import und die öffentliche REST-API diese doppelte Einspeisung und den automatisierten Vergleich beider Datensätze.

Die Migration beginnt mit einem vollständigen Export aus dem alten System, idealerweise in CSV oder JSON: Kunden, Lieferanten, Produktkatalog, Preise, Bestände, offene Aufträge, jüngste Historie. Dieser Export ist Ihr Rohstoff. Die goldene Regel: niemals direkt vom Alten ins Neue importieren. Man geht immer über einen Zwischenschritt der Bereinigung und Kontrolle.

Die Bereinigung nimmt sich zuerst die Deduplizierung vor. Derselbe Kunde dreimal in drei Schreibweisen erfasst, zwei Produktreferenzen für einen identischen Artikel, gemischte Maßeinheiten: Das sind die Fehler, die später Bestände und Fakturierung verschmutzen. Man führt zusammen, normalisiert Formate (Codes, Einheiten, Währungen), füllt die Pflichtfelder des neuen Systems aus und archiviert Totes, statt es zu migrieren.

Mapping heißt, Feld für Feld zu entscheiden, was aus jedem Datum im Ziel wird: welches Quellfeld welches SupplyCore-Feld speist, welche Werte umgewandelt werden, welche Regeln gelten. Dieses Zuordnungsdokument ist der Vertrag der Migration; es wird mit den Fachverantwortlichen geprüft und validiert, nicht nur mit der IT.

Die Validierung stützt sich auf Testsätze und Integritätsprüfungen. Zuerst importiert man eine repräsentative Stichprobe, prüft, ob die Summen stimmen (Anzahl Kunden, Bestandswert, offene Posten), spielt einige Aufträge von Anfang bis Ende durch und weitet dann aus. Die KI-Agenten von SupplyCore und die REST-API helfen, Anomalien und verbleibende Duplikate automatisch zu erkennen, doch die endgültige Validierung bleibt eine menschliche Entscheidung, getroffen auf Zahlen, die sich abstimmen lassen.

Statt das gesamte Netz auf einmal einzuschalten, teilt die schrittweise Einführung die Bereitstellung Standort für Standort auf. Zuerst wählt man ein Pilotlager: weder das größte noch das kritischste, aber repräsentativ für die Abläufe, mit einem motivierten Team und einem lokalen Verantwortlichen, der den Wandel tragen kann. Dieser Standort fängt die ersten Anpassungen auf, dort, wo ein Fehler eingegrenzt bleibt.

Der Pilot dient dazu, aufzudecken, was kein Labortest zeigt: die realen Gewohnheiten, die Sonderfälle eines langjährigen Kunden, den Etikettendruck, die Integrationen mit einem Spediteur. Jedes aufgetretene Problem wird behoben und in einem Einführungshandbuch dokumentiert, das den folgenden Standorten dient. Der Pilot ist nicht erfolgreich, wenn es „funktioniert" an einem Tag, sondern wenn er mehrere Tage ohne außergewöhnlichen Eingriff läuft.

Danach folgt eine Welle von zwei oder drei weiteren Lagern, gewählt, um andere Fallkonstellationen abzudecken. In dieser Phase kapitalisiert man: Die Korrekturen des Piloten sind bereits eingebaut, die Schulung ist eingespielt, die Go/No-Go-Kriterien sind bekannt. Die Lernkurve der Organisation beschleunigt sich mit jeder Welle.

Die Verallgemeinerung auf das gesamte Netz erfolgt erst, wenn das Modell erprobt und stabilisiert ist. Dieser Ansatz hat einen entscheidenden Vorteil: Zu jedem Zeitpunkt läuft der Großteil des Unternehmens auf einem bekannten System — alt oder neu — und niemals ist der gesamte Betrieb gleichzeitig demselben Risiko ausgesetzt.

Die gescheiterte Schulung ist die, die alle gleich behandelt. Ein Fahrer, ein Lagerarbeiter, ein Verkäufer und ein Buchhalter nutzen nicht dieselbe Software: Sie nutzen vier verschiedene Programme innerhalb desselben Werkzeugs. Jeder muss seinen Weg lernen — die Bildschirme, die er wirklich berührt — und nichts anderes. Einen Lagerarbeiter in Buchhaltungsfunktionen zu ertränken, garantiert, dass er die eigenen schlecht behält.

Man baut also einen Plan nach Rolle. Die Verkäufer: Produktsuche, Verfügbarkeit, Auftragserfassung, Preise und Rabatte. Die Lagerarbeiter: Wareneingang, Einlagerung, Kommissionierung, Versand, Inventur. Die Fahrer: Touren, Liefernachweise, Retouren. Die Buchhaltung: Fakturierung, Zahlungseingänge, Abstimmungen, Steuern. Die Geschäftsführung: Dashboards und Steuerungskennzahlen. Jeder Weg verdient sein eigenes Material.

Das Format, das funktioniert, besteht aus kurzen, praktischen Sitzungen an echten Fällen des Unternehmens statt aus langen theoretischen Vorführungen. Eine gezielte Stunde, gefolgt von sofortiger Praxis während des Parallelbetriebs, verankert besser als ein ganzer Tag des Zuschauens. Einseitige Merkblätter am Arbeitsplatz sind mehr wert als ein hundertseitiges Handbuch, das niemand öffnet.

Es hilft, einige interne Ansprechpartner pro Standort und pro Funktion auszubilden: Kollegen, die sich schneller einarbeiten und zur ersten Anlaufstelle für andere werden. Für spezifische Bedürfnisse bietet SupplyCore muttersprachlichen Support auf Französisch und Anpassungs-Stundenpakete zu 125 $/h, die genutzt werden können, um einen Bildschirm anzupassen, einen Ablauf zu justieren oder maßgeschneidertes Schulungsmaterial zu erstellen, ohne ein schweres Projekt anzustoßen.

Ein ernsthaftes Migrationsprojekt plant sein eigenes Scheitern ein. Der Rückfallplan (Rollback) ist das schriftliche Szenario, das eine einzige Frage beantwortet: Wenn das neue System eines Morgens unbrauchbar wird, wie nehmen wir die Tätigkeit in weniger als einer Stunde wieder auf? Die ehrliche Antwort ist, während der gesamten Übergangsphase das alte System schreibgeschützt verfügbar zu halten: Offene Aufträge bleiben einsehbar, die Historie bleibt zugänglich, und bei Bedarf kann dort ein kritischer Vorgang erneut erfasst werden.

Der Rückfallplan ist kein Dokument in der Schublade. Er legt fest, wer entscheidet, wer ausführt, in welcher Reihenfolge und welche Daten bei der Rückkehr resynchronisiert werden müssen. Er wird vor der Umstellung mindestens einmal getestet, wie eine Evakuierungsübung: Ein Rollback, das nie geprobt wurde, ist nur eine Absicht.

Bei jeder Etappe — Ende der Datenmigration, Ende des Piloten, vor jeder Welle, vor der Verallgemeinerung — trifft man eine ausdrückliche Go/No-Go-Entscheidung. Das „Go" ist nie ein Gefühl; es beruht auf im Voraus festgelegten, bezifferten Kriterien: abgestimmte Summen, null verlorene Aufträge, Bearbeitungszeiten im Rahmen, Fehlerquote unter einem Schwellenwert, geschulte und zuversichtliche Teams. Ist auch nur ein blockierendes Kriterium nicht erfüllt, gilt „No-Go", und man korrigiert, bevor man weitergeht.

Dieser Rahmen verlagert die Entscheidung vom emotionalen auf den faktischen Boden. Niemand muss „fühlen", dass es der richtige Moment ist: Die Zahlen entscheiden. Genau das erlaubt es einer Betriebsleitung, den Wandel gelassen anzugehen, im Wissen, dass ein sauberer Rückweg zu jedem Zeitpunkt möglich bleibt.

Eine SupplyCore-Bereitstellung wird typischerweise über zwei bis sechs Wochen organisiert, je nach Größe des Netzes und Komplexität der Abläufe. Ein Einzelstandort-Distributor mit Standardprozessen liegt am unteren Ende; ein Mehrlager-Netz mit Integrationen und Sonderfällen liegt am oberen Ende. Wichtig ist nicht die absolute Dauer, sondern die logische Abfolge der Schritte.

Woche 1 — Rahmen und Daten. Man richtet die Ziele aus, identifiziert Rollen und Ansprechpartner, startet den Export aus dem alten System und die Bereinigung. Man verfasst das Mapping-Dokument und bereitet die Umgebung vor. Parallel legt man die Go/No-Go-Kriterien und den Rückfallplan schwarz auf weiß fest. Woche 2 — Import und Validierung. Man importiert einen ersten Satz, führt Integritätsprüfungen durch, spielt Testaufträge nach und korrigiert das Mapping, bis sich die Summen abstimmen. Die ersten rollenbasierten Schulungen beginnen.

Wochen 3 bis 4 — Pilot und Parallelbetrieb. Das Pilotlager geht in den Parallelbetrieb: Doppelerfassung, täglicher Abgleich, Anpassungen. Das alte System bleibt schreibgeschützt die Quelle der Wahrheit. Man stellt den Piloten erst um, wenn die Vertrauenskriterien mehrere Tage in Folge halten. Das Einführungshandbuch füllt sich mit den real angetroffenen Fällen.

Wochen 5 bis 6 — Wellen und Verallgemeinerung. Gestützt auf den Piloten stellt man die folgenden Lager in Wellen bereit, mit dank der gewonnenen Erfahrung komprimierter Schulung und Parallelbetrieb, bis zur Verallgemeinerung. Man hält das alte System nach der vollständigen Umstellung noch eine Weile schreibgeschützt zugänglich und zieht es dann zurück, sobald das Vertrauen endgültig gefestigt ist. Durchgehend erlauben der muttersprachliche Support auf Französisch, die KI-Agenten und die Anpassungs-Stundenpakete, das Unvorhergesehene aufzufangen, ohne den Zeitplan zu entgleisen — und ohne den Betrieb je zu unterbrechen.