Key Takeaways:
-
Parallelbetrieb ist die Regel, nicht die Ausnahme. Ein sauberer Schnitt über Nacht ist bei gewachsenen Systemen selten realistisch.
-
Für jede Entität gibt es genau ein führendes System. Zwei führende Systeme für dieselbe Information erzeugen Konflikte, die nicht lösbar sind.
-
Der Abgleich braucht eine Richtung. Beidseitig synchronisieren ist um ein Vielfaches aufwendiger und sollte die begründete Ausnahme bleiben.
-
Konflikte müssen sichtbar sein, nicht automatisch gelöst. Eine stille Regel, die entscheidet, erzeugt Datenstände, die niemand erklären kann.
-
Der Parallelbetrieb braucht ein Enddatum. Ohne das wird aus dem Übergang ein Dauerzustand mit doppelten Kosten. Und die GoBD (BMF-Schreiben vom 28.11.2019, BStBl. I S. 1269) verlangen, dass steuerrelevante Daten über den Systemwechsel hinweg nachvollziehbar bleiben. Zwei halb gepflegte Systeme sind das Gegenteil davon.
Bei einer Systemumstellung mit Parallelbetrieb entscheidet nicht die Technik über den Erfolg, sondern vier Festlegungen: welches System für welche Entität führend ist, in welche Richtung abgeglichen wird, wie Konflikte sichtbar werden, und wann der Parallelbetrieb endet. Werden diese vier vorher getroffen, ist der Abgleich überschaubar. Werden sie unterwegs getroffen, entsteht ein Zustand, in dem täglich jemand von Hand nachzieht.
Wir halten seit einigen Monaten zwei Systeme für einen Kunden synchron. Fast jede Störung lässt sich auf eine dieser vier Fragen zurückführen.
Warum Parallelbetrieb der Normalfall ist
Der saubere Schnitt setzt voraus, dass das neue System am Tag der Umstellung alles kann, was das alte konnte. Bei einem gewachsenen System bedeutet das, auch die Sonderfälle nachzubauen, die zwei Prozent der Vorgänge betreffen. Und zwar bevor man weiß, ob sie überhaupt noch gebraucht werden.
Der Parallelbetrieb erlaubt eine andere Reihenfolge: Das neue System übernimmt die Hauptfälle, das alte behält die Reste, und man sieht über Wochen, welche Reste tatsächlich noch auftreten. In der Softwaretechnik heißt dieses Vorgehen Parallel Change: erst erweitern, dann migrieren, während beide Wege funktionieren, zuletzt den alten Weg abbauen. Danilo Sato und Martin Fowler haben das 2014 für Schnittstellen beschrieben. Für ganze Systeme gelten dieselben drei Phasen.
Die günstigere Reihenfolge hat einen Preis: Sie erzeugt die Synchronisationsaufgabe.
Entscheidung 1: Wer führt?
Für jede Entität, also Kunden, Aufträge, Artikel, Preise, wird festgelegt, welches System die Wahrheit hält. Nicht „beide, aber koordiniert". Genau eines.
Das ist unbequem, weil es bedeutet, dass Nutzer für bestimmte Änderungen in das andere System wechseln müssen. Es ist aber die einzige Festlegung, die ohne Konfliktlogik auskommt. Und Konfliktlogik ist der Teil, der Projekte teuer macht.
Praktisch bewährt hat sich ein Schnitt nach Entität statt nach Nutzergruppe: Kunden werden ab Tag eins im neuen System gepflegt, Aufträge bleiben zunächst im alten. Das ist erklärbar. Ein Schnitt nach Abteilung ist es nicht.
Entscheidung 2: In welche Richtung?
Einseitiger Abgleich ist ein überschaubares Stück Arbeit. Beidseitiger Abgleich ist ein anderes Projekt: Man braucht eine Reihenfolge der Änderungen, eine Erkennung, welche Seite zuletzt geändert hat, und eine Regel für den Fall, dass beide gleichzeitig geändert haben.
Unsere Empfehlung ist deshalb, so lange wie möglich bei einer Richtung zu bleiben und die Führung stattdessen entitätsweise zu verschieben. Wenn die Kunden im neuen System geführt werden, fließen sie von neu nach alt. Wenn die Aufträge noch alt geführt werden, fließen sie von alt nach neu. Beides einseitig, nur mit unterschiedlicher Richtung.
Entscheidung 3: Was passiert bei Konflikten?
Es wird trotzdem Konflikte geben. Ein Datensatz, der auf beiden Seiten existiert und sich unterscheidet. Ein Datensatz, der auf der Zielseite gelöscht wurde und wieder auftaucht.
Der Fehler ist, das automatisch aufzulösen. „Der neuere Zeitstempel gewinnt" klingt vernünftig und führt zu Datenständen, die im Nachhinein niemand erklären kann. Zumal Zeitstempel in Altsystemen oft nicht das bedeuten, was man annimmt.
Besser: Konflikte werden in eine Liste geschrieben, der betroffene Datensatz wird nicht angefasst, und jemand entscheidet. Wenn diese Liste zu lang wird, ist das keine Überlastung des Prozesses. Es ist ein Hinweis darauf, dass die Führungsfrage falsch beantwortet wurde.
Entscheidung 4: Wann ist Schluss?
Ein Parallelbetrieb ohne Enddatum wird zum Dauerzustand. Beide Systeme werden gepflegt, beide lizenziert, beide getestet. Das ist der teuerste denkbare Zielzustand, und er wird selten bewusst gewählt. Er entsteht.
Für steuerrelevante Daten kommt die Pflichtseite dazu: Die GoBD (BMF-Schreiben vom 28.11.2019, BStBl. I S. 1269) verlangen Nachvollziehbarkeit und Unveränderbarkeit über den Systemwechsel hinweg, und § 147 AO schreibt vor, wie lange die Daten lesbar bleiben müssen. Wer den Parallelbetrieb treiben lässt, hat am Ende zwei Systeme, von denen keines die Anforderungen vollständig erfüllt.
Deshalb gehört zum Start des Parallelbetriebs ein Datum und eine Liste, was bis dahin im neuen System vorhanden sein muss. Wird das Datum verschoben, ist das in Ordnung. Aber es muss verschoben werden, nicht stillschweigend verstreichen.
Was davon Technik ist
Wenig. Der Abgleich selbst ist ein Stück Arbeit, das man beherrschen kann: Änderungen erkennen, übertragen, quittieren, protokollieren. Was Projekte scheitern lässt, sind die vier Entscheidungen davor. Und die trifft niemand in der IT allein.
Wenn bei Ihnen eine Systemumstellung mit Parallelbetrieb ansteht: Treffen Sie die vier Entscheidungen, bevor Sie das erste Angebot einholen. Wir gehen sie mit Ihnen in einer Stunde durch. Das Angebot danach ist ein anderes Dokument.
Quellen
- Sato, Fowler: ParallelChange, martinfowler.com, 2014
- Bundesministerium der Finanzen: Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD), BMF-Schreiben vom 28.11.2019, BStBl. I S. 1269
- § 147 AO — Ordnungsvorschriften für die Aufbewahrung von Unterlagen