Beste Praktiken vor einer Systemumstellung

Ein Systemwechsel verzögert sich selten, weil die neue Anwendung an sich schlecht ist. Häufiger liegt das Problem darin, dass während des Wechsels festgestellt wird: Die Bestelldaten weichen an mehreren Stellen ab, eine Lagerausnahme existiert nur im Kopf eines erfahrenen Kollegen, oder eine Excel-Tabelle unterstützt eine Entscheidung, die niemand dokumentiert hat. Die Best Practices vor einem Systemwechsel 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 des Systems den Vertrieb, den Einkauf, die Produktion, das Lager, die Rechnungsstellung und die Managementberichte betreffen. Wenn der Wechsel nur als technologisches Projekt beginnt, 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 soll.

Vor dem Systemwechsel die tatsächlichen Prozesse bewerten

Der beschriebene Prozess und die tatsächliche Arbeitsweise sind oft nicht dasselbe. Laut Flussdiagramm wird die Bestellung des Webshops 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 dem Wechsel ist es ratsam, 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 Grundlage wird entschieden? In welchem System werden Daten erfasst? Wo wartet der Fall, und wer greift ein, wenn etwas nicht wie gewohnt verläuft?

Diese Arbeit ist keine administrative Formalität. Hier zeigt sich, welche Funktionen in einem neuen System vom ersten Tag an wirklich 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 unnötiger Genehmigungen, paralleler Dateneingaben oder manueller Abstimmungen.

Ausnahmen können wichtiger sein als die Durchschnittsfälle

Der normale Prozess lässt sich in der Regel leicht darstellen. Die Schwierigkeit beginnt, wenn Teillieferungen eintreffen, der Kunde eine andere Lieferadresse anfordert, ein Produktbestand negativ wird oder eine Bestellung nach der Rechnungsstellung geändert werden muss. Diese Fälle sind oft nicht alltäglich, verursachen jedoch erheblichen Zeitaufwand, Abstimmungen und Risiken.

Es ist nicht das Ziel, jede Ausnahme vollständig zu automatisieren. Bei einer seltenen und hochspezialisierten Entscheidung kann es besser sein, wenn das System das Problem klar anzeigt und an eine bestimmte Person weiterleitet. Der Punkt ist, dass die Behandlung der Ausnahme kein versteckter, personenbezogener Umweg sein sollte.

Vor der Datenmigration muss der Datenverantwortliche geklärt werden

Eines der häufigsten Missverständnisse bei Wechseln 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 Fortführung der alten Unsicherheit.

Zuerst muss festgelegt werden, welche Daten für den täglichen Betrieb, gesetzliche oder vertragliche Verpflichtungen und die Geschäftsanalyse erforderlich sind. Dann 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 darauf keine klare Antwort gegeben werden kann, 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 auch dann nicht als erfolgreich, wenn alle Zeilen geladen wurden. Es muss auch geprüft werden, ob mit den Daten wichtige Geschäftsvorgänge 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 wie bisher von der Geschäftsführung verwendet, und wenn nicht, wissen sie genau, warum?

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

Best Practices vor einem Systemwechsel: klare Verantwortlichkeiten

Während des Wechsels fallen viele Aufgaben „jemandem“ zu. Jemand muss die Stammdaten 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 Freigabe für den Live-Start erteilen kann. Besonders wichtig ist die Festlegung der Entscheidungsgrenzen. Ein Entwickler kann nicht eigenständig entscheiden, ob eine Rechnungsabweichung geschäftlich akzeptabel ist, und ein Geschäftsleiter muss keine technische Antwort auf Datenbankebene geben.

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

Der Live-Start 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 ausprobiert, die aus Sicht des täglichen Betriebs kritisch sind. Bei einem Lager können dies der Wareneingang, die Einlagerung, die Kommissionierung, die Inventur und der Versand sein. In der Produktion die Materialausgabe, die Auftragsbearbeitung, die Erfassung von Ausschuss und die Aufnahme von Fertigprodukten. 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 an demselben Bestand arbeiten. Es ist auch wichtig, dass die Tester nicht nur das überprüfen, was das neue System können muss, sondern auch das, was zuvor zu Fehlern geführt hat.

Für die Entscheidung vor dem Live-Start sollten die Akzeptanzkriterien im Voraus festgelegt werden. Welche Prozesse müssen fehlerfrei funktionieren? Welche Abweichung ist nach dem Start noch handhabbar, und was stoppt den Wechsel? Dadurch wird eine unsichere, auf Eindrücken basierende „Gehen wir live“-Entscheidung vermieden.

Ein Rückfallplan ist notwendig, aber nicht in jedem Fall derselbe

Der 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 zu welchem Zeitpunkt zum alten System zurückgekehrt werden kann und wie die während des Übergangs 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 eine Zeit lang parallel gehalten werden. Bei einem zentralen ERP-Wechsel kann dies weitaus komplexer sein, da die parallele Buchführung und Bestandsverwaltung zwischen den beiden Systemen neue Abweichungen schaffen kann. Hier muss im Voraus abgewogen werden, wie kurz die alte Arbeitsweise 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 Probleme auftreten.

Die ersten Tage nach dem Start sind ebenfalls Teil des Projekts

Der Wechsel endet nicht mit dem Drücken des Live-Start-Knopfs. Aus den Fehlern, die in den ersten Tagen auftreten, wird schnell klar, wo es Abweichungen zwischen der angenommenen und der tatsächlichen Arbeitsweise gab. Dazu braucht es einen festgelegten Unterstützungsplan, kurze Entscheidungswege und eine gemeinsame Fehlerbehandlungsliste.

Es ist ratsam, zwischen Fehlern, die den Betrieb stoppen, Problemen, die mit Umwegen 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 einem Systemwechsel gestellten guten Fragen sind oft wertvoller als eine lange Funktionsliste. Welche Arbeit erledigen wir nur aus Gewohnheit? Wo entstehen dieselben Daten zweimal? Wer kann den Prozess alleine wiederherstellen? Wenn auf diese Fragen ehrliche Antworten gefunden werden, ersetzt das neue System nicht nur das alte, sondern bietet eine berechenbarere Arbeitsweise für das Wachstum.