Beste Praktiken vor der Systemumstellung

Eine Systemumstellung verzögert sich selten, weil die neue Anwendung an sich schlecht ist. Häufiger treten Probleme auf, weil während der Umstellung festgestellt wird, dass die Bestelldaten an mehreren Stellen abweichen, eine Lagerausnahme nur im Kopf eines erfahrenen Kollegen existiert oder eine Excel-Tabelle eine Entscheidung unterstützt, die niemand dokumentiert hat. Die besten Praktiken vor einer Systemumstellung sind daher nicht ausschließlich IT-Kontrollpunkte. Sie sind die Voraussetzungen für die Kontrolle des Betriebs.

Bei einem wachsenden Unternehmen kann der Austausch oder die Integration eines Systems den Vertrieb, den Einkauf, die Produktion, das Lager, die Rechnungsstellung und die Managementberichte betreffen. Wenn die Umstellung nur als Technologieprojekt gestartet wird, bleiben die alten Fehler leicht bestehen – nur auf einer neuen Oberfläche. Der bessere Ansatz ist, dass das Unternehmen zuerst untersucht, wie es tatsächlich arbeitet, und erst dann entscheidet, was übertragen, umgewandelt oder weggelassen werden muss.

Vor der Systemumstellung sollten die tatsächlichen Prozesse bewertet werden

Der beschriebene Prozess und die tatsächliche Arbeitsweise sind oft nicht dasselbe. Laut Prozessdiagramm wird die Bestellung im Webshop automatisch ins ERP übertragen, in der Praxis überprüft, korrigiert und ergänzt jedoch ein Mitarbeiter jeden Morgen manuell die fehlenden Daten. Dies ist nicht unbedingt ein Fehler des betroffenen Kollegen. Es ist eher ein Zeichen dafür, dass das System oder der Prozess Ausnahmen nicht angemessen behandelt.

Vor der Umstellung ist es sinnvoll, einige echte Fälle von Anfang bis Ende zu verfolgen. Eine eingehende Bestellung, eine Rücksendung, ein dringender Einkauf, eine Produktionsabweichung oder eine Reklamation. Wer initiiert den Prozess? Auf welcher Informationsgrundlage wird entschieden? In welchem System werden Daten erfasst? Wo wartet der Fall, und wer greift ein, wenn etwas nicht wie gewohnt abläuft?

Diese Arbeit ist keine administrative Formalität. Hier wird deutlich, welche Funktionen in einem neuen System ab dem ersten Tag tatsächlich funktionieren müssen und welche alten Schritte keinen geschäftlichen Zweck mehr erfüllen. In vielen Fällen wird das größte Ergebnis nicht durch eine Entwicklung erzielt, sondern durch die Beseitigung einer unnötigen Genehmigung, paralleler Dateneingabe oder manueller Abstimmung.

Ausnahmen können wichtiger sein als durchschnittliche Fälle

Der normale Prozess lässt sich in der Regel leicht darstellen. Die Schwierigkeit beginnt, wenn Teillieferungen eintreffen, der Kunde eine andere Lieferadresse wünscht, der Bestand eines Produkts negativ wird oder eine Bestellung nach Rechnungsstellung geändert werden muss. Diese Fälle sind oft nicht alltäglich, verursachen jedoch erheblichen Zeitaufwand, Abstimmung und Risiko.

Es ist nicht das Ziel, jede Ausnahme vollständig zu automatisieren. Bei einer seltenen und spezialisierten Entscheidung kann es besser sein, wenn das System das Problem klar signalisiert und an eine bestimmte Person weiterleitet. Wichtig ist, dass die Behandlung der Ausnahme kein versteckter, personenabhängiger Umweg ist.

Vor der Datenmigration muss der Datenverantwortliche geklärt werden

Ein häufiges Missverständnis bei Umstellungen ist, dass alle vorhandenen Daten übertragen werden müssen. Das ist nicht sicher. Die Migration eines zehn Jahre alten, unvollständigen oder doppelten Stammdatensatzes ist keine Bewahrung, sondern die Fortsetzung der alten Unsicherheit.

Zuerst muss bestimmt werden, welche Daten für den täglichen Betrieb, gesetzliche oder vertragliche Verpflichtungen sowie für die Geschäftsanalyse erforderlich sind. Danach muss der Datenverantwortliche identifiziert werden. Wer ist verantwortlich für die Bezeichnung, Maßeinheit und den Status eines Artikelstamms? Wer kann über die Änderung von Partnerdaten entscheiden? Welches System ist die primäre Quelle, wenn dieselben Kundendaten im CRM, ERP und im Abrechnungssystem vorhanden sind?

Wenn es darauf keine klare Antwort gibt, wird die Integration die Abweichungen nur schneller verbreiten. Die technische Verbindung kann Daten weiterleiten, aber nicht entscheiden, welche Daten korrekt sind.

Nicht nur Datensätze, sondern auch Geschäftsregeln testen

Ein Datenimport gilt nicht als erfolgreich, wenn jede Zeile geladen wurde. Es muss auch geprüft werden, ob mit den Daten wichtige Geschäftsoperationen durchgeführt werden können. Wird die Bestellung korrekt erstellt? Kann der Bestand reserviert werden? Werden die richtige Mehrwertsteuer, Zahlungsbedingungen, Preise oder Rabatte auf das Dokument angewendet? Zeigt der Bericht dasselbe an, was das Management bisher verwendet hat, und wenn nicht, wissen sie genau, warum?

Es ist nützlich, wenn die Überprüfung nicht nur Aufgabe der IT und des Anbieters ist. Die Finanzabteilung, das Lager, der Vertrieb und die Produktion erkennen Fehler, die technisch nicht unbedingt sichtbar sind, aber im Betrieb sofort zu Störungen führen.

Die besten Praktiken vor einer Systemumstellung: klare Verantwortlichkeiten

Während der Umstellung fallen viele Aufgaben „jemandem“ zu. Jemand muss den Stammdatensatz genehmigen, den Import überprüfen, die Benutzer informieren oder eine Entscheidung zu einer offenen Frage treffen. „Jemand“ ist jedoch kein Verantwortungsbereich.

Bereits zu Beginn des Projekts muss festgelegt werden, wer Geschäftsentscheidungen trifft, wer für den Prozess verantwortlich ist, wer die Daten vorbereitet, wer die technischen Änderungen vornimmt und wer die Genehmigung für den Start erteilen kann. Besonders wichtig ist die Festlegung der Entscheidungsgrenzen. Ein Entwickler kann nicht eigenständig entscheiden, ob eine Rechnungsabweichung geschäftlich akzeptabel ist, während ein Geschäftsleiter keine technische Antwort auf Datenbankebene geben muss.

Die Klärung der Verantwortlichkeiten macht auch die Belastung der Schlüsselpersonen sichtbar. Viele Projekte verlangsamen sich, weil dieselben zwei Experten die tägliche Operation durchführen, während von ihnen alle Tests und Genehmigungen erwartet werden. In solchen Fällen muss der Umstellungsplan mit Vertretung, gezielten Zeitfenstern oder vorübergehender Kapazität rechnen.

Der Go-Live sollte nicht der erste vollständige Test sein

Die Testumgebung allein ist keine Garantie. Sie bietet nur dann echte Sicherheit, wenn das Unternehmen Szenarien darin testet, die aus Sicht des täglichen Betriebs kritisch sind. In einem Lager können dies der Wareneingang, die Einlagerung, Kommissionierung, Inventur und der Versand sein. In der Produktion die Materialausgabe, Auftragsbearbeitung, Ausschussregistrierung und Fertigwarenannahme. Im Handel die Kette von Bestellung, Zahlung, Rechnungsstellung, Rückerstattung und Kundeninformation.

Der Test sollte möglichst mit realistischen Mengen und Rollen durchgeführt werden. Eine einzige Musterbestellung reicht nicht aus, wenn im normalen Betrieb Daten aus mehreren Kanälen eingehen, Bestandsbewegungen stattfinden und mehrere Personen am selben Bestand arbeiten. Es ist auch wichtig, dass die Tester nicht nur überprüfen, was das neue System können muss, sondern auch, was zuvor zu Fehlern geführt hat.

Für die Entscheidung vor dem Go-Live sollten die Akzeptanzkriterien im Voraus festgelegt werden. Welche Prozesse müssen fehlerfrei funktionieren? Welche Abweichung ist nach dem Start noch handhabbar und was stoppt die Umstellung? Dies vermeidet eine unsichere, auf Eindrücken basierende „Go-Live“-Entscheidung.

Ein Rückfallplan ist notwendig, aber nicht immer derselbe

Ein Rückfallplan ist kein Pessimismus, sondern Geschäftskontinuitätsdisziplin. Wenn im neuen System ein kritischer Fehler auftritt, muss jeder wissen, wer über den Rückfall entscheidet, welche Daten gesichert werden können, bis wann zum alten System zurückgekehrt werden kann und wie die während der Übergangszeit entstandenen Transaktionen behandelt werden.

Ein vollständiger Rückfall ist nicht immer realistisch oder notwendig. Bei einer schrittweise eingeführten neuen Reporting-Lösung kann der alte Bericht für eine Weile parallel gehalten werden. Bei einem zentralen ERP-Wechsel kann dies weitaus komplexer sein, da parallele Buchhaltung und Bestandsverwaltung zwischen den beiden Systemen neue Abweichungen schaffen können. Hier muss im Voraus abgewogen werden, wie kurz die alte Betriebsweise aufrechterhalten werden kann und welches Risiko die doppelte Datenverwaltung darstellt.

Der Plan muss sich auch mit den Auswirkungen auf Kunden, Lieferanten und Mitarbeiter befassen. Wenn eine Unterbrechung zu Verzögerungen bei der Bestätigung, Lieferung oder Rechnungsstellung führt, sollte es klare Kommunikations- und manuelle Verfahren geben. Ein gut vorbereiteter Übergang ist nicht dadurch gut, dass es nie Probleme gibt, sondern dadurch, dass die Organisation nicht improvisiert, wenn ein Problem auftritt.

Die ersten Tage nach dem Go-Live sind ebenfalls Teil des Projekts

Die Umstellung endet nicht mit dem Drücken des Go-Live-Buttons. Die in den ersten Tagen auftretenden Fehler zeigen schnell, wo es Abweichungen zwischen der angenommenen und der tatsächlichen Arbeitsweise gab. Dazu braucht es einen festgelegten Unterstützungsplan, kurze Entscheidungswege und eine gemeinsame Fehlerliste.

Es ist sinnvoll, zwischen Fehlern, die den Betrieb stoppen, Problemen, die mit einem Workaround behandelt werden können, und Entwicklungsanforderungen zu unterscheiden. Wenn jede Beobachtung die gleiche Dringlichkeit erhält, verliert das Team den Fokus. Wenn jedoch kritische Probleme schnell sichtbar werden, kann das Management fundierter über Prioritäten entscheiden.

Die vor einer Systemumstellung gestellten guten Fragen sind oft wertvoller als eine lange Funktionsliste. Welche Arbeit wird nur aus Gewohnheit erledigt? Wo entstehen dieselben Daten zweimal? Wer kann den Prozess alleine wiederherstellen? Wenn darauf ehrliche Antworten gefunden werden, ersetzt das neue System nicht nur das alte, sondern bietet eine vorhersehbarere Arbeitsweise für das Wachstum.