Rechtliche Probleme im Zusammenhang mit der Übertragung von alten Systemen in der Systementwicklung

Das Erstellen eines neuen IT-Systems für Unternehmen ist ein typisches Aufgabenfeld für IT-Ingenieure. Wenn wir jedoch von der “Erstellung eines neuen Systems” sprechen, beinhaltet dies oft auch den Prozess der “Abschaffung des bisher genutzten Systems”. In diesem Artikel werden wir das Projekt der Entwicklung eines neuen Systems aus der Perspektive der “Abschaffung des alten Systems” neu betrachten und die damit verbundenen rechtlichen Fragen erläutern.

Was bedeutet der Übergang zu einem neuen System?

Die Lebensdauer eines IT-Systems ist nicht ewig

Es ist ein Irrglaube, dass IT-Systeme, die in Unternehmen eingesetzt werden, einmal erstellt und dann dauerhaft genutzt werden können. Es ist auch nicht unbedingt gut, alte Dinge immer weiter zu verwenden. Obwohl es natürlich Unterschiede zwischen den Unternehmen und den Verwendungszwecken der Systeme gibt, ist es als grobe Richtlinie üblich, dass nach etwa zehn Jahren der Betrieb eines Systems die Entscheidung getroffen wird, es durch etwas Neues zu ersetzen.

In zehn Jahren kann sich die Leistung der auf dem Markt erhältlichen Computer drastisch verändern. Zum Beispiel könnten Programme, die vor zehn Jahren aufgrund von Einschränkungen wie der Verarbeitungsgeschwindigkeit des Computers (aus menschlicher Sicht einfach und gut gestaltet) nicht realistisch implementiert werden konnten, nun umsetzbar sein. Darüber hinaus könnten sich nach zehn Jahren kontinuierlicher Nutzung die Arbeitsabläufe und internen Regeln des Unternehmens erheblich verändert haben. Der Code, der nachträglich implementiert wurde, um auf diese internen und externen Veränderungen in der Geschäftsumgebung zu reagieren, könnte eine so komplexe und verworrene Struktur angenommen haben, dass er vom Bildschirm aus nicht mehr erkennbar ist. In solchen Fällen könnte es für die Benutzer unmöglich werden, zusätzliche Funktionen hinzuzufügen, die sie wünschen, da die Entwickler die Implementierung von Ergänzungen nicht mehr für möglich halten.

Alte Systeme können dazu führen, dass IT-Ingenieure zunehmend “manuelle” Arbeiten (wie das Ausführen von Abfragen zur individuellen Datenauswahl) durchführen müssen. Ironischerweise führt das System selbst, wenn es alt wird, dazu, dass die Arbeit “personalisiert” wird. Wenn versucht wird, weitere “Systematisierungs”-Maßnahmen für Aufgaben im Zusammenhang mit Systemen einzuführen, die zu alt und zu personalisiert geworden sind, entsteht das Projekt “Entwicklung eines neuen Systems zur Migration vom alten System”.

Die Entwicklung des neuen Systems geht Hand in Hand mit der Abschaffung des alten Systems

Wie bereits erwähnt, beinhaltet ein Systementwicklungsprojekt (auch wenn nicht alle Projekte so sind) oft gleichzeitig den Aspekt der Migration vom alten System. Das System selbst wechselt oft diskontinuierlich an einem bestimmten Tag.

Der tägliche Geschäftsbetrieb selbst sollte jedoch kontinuierlich von der Vergangenheit über die Gegenwart in die Zukunft verlaufen. Während die notwendigen Daten aus der Vergangenheit gespeichert werden, sollte der aktuelle Geschäftsbetrieb nicht unterbrochen werden und es sollten weiterhin hervorragende Konzepte für die “Systematisierung” für die Zukunft entwickelt werden. Der Übergang zu einem neuen System bringt oft verschiedene Herausforderungen mit sich. Durch die Kombination dieser Umstände werden die Entwicklung des neuen Systems und die Betriebs- und Wartungsarbeiten des bestehenden Systems komplex miteinander verknüpft und es entsteht eine untrennbare Beziehung.

Was sind die Schritte zur Umstellung auf ein neues System?

Beim Übergang von einem bestehenden zu einem neuen System ist es besonders wichtig, die Daten korrekt zu übertragen. Die Schritte zur Datenübertragung folgen in der Regel dem folgenden Verfahren:

1. Klärung, welche der vom alten System gespeicherten Daten auf das neue System übertragen werden sollten → Es muss auch unterschieden werden, welche Daten leicht von der Benutzeroberfläche des neuen Systems aus durchsucht werden können und welche Daten nicht unbedingt durchsuchbar sein müssen, aber bei Bedarf (z.B. für Audits) abgerufen werden können.
2. Ausgabe der in Schritt 1 identifizierten Daten, die in das neue System importiert werden sollen, in einem Format wie CSV.
3. Importieren der in Schritt 2 extrahierten Daten in das neue System.
4. Überprüfung, ob die in Schritt 3 importierten Daten im neuen System reflektiert werden, und Bestätigung, ob die Migration korrekt durchgeführt wurde. → Die Ergebnisse der Überprüfung, ob die Migration korrekt durchgeführt wurde, werden normalerweise durch das Hinterlassen von Beweismaterial, wie Bildschirmanzeigen oder gedruckten Berichten, dokumentiert (der sogenannte Testprozess).

Die Umstellung auf ein neues System ist schwierig, wenn es um die Rollenklärung von Benutzern und Anbietern geht

In den oben genannten Schritten der Datenmigration stellt sich oft die Frage, inwieweit die Benutzerseite dies als internes Problem betrachten und unter Kontrolle halten sollte. Darüber hinaus ist eine allgemeine Erläuterung der “Pflicht zur Zusammenarbeit der Benutzer” in Systementwicklungsprojekten im Allgemeinen, nicht nur in Bezug auf die Datenmigration, in dem folgenden Artikel zu finden.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Im Allgemeinen ist es in einem Systementwicklungsprojekt oft der Fall, dass der Anbieter in Bezug auf das spezialisierte Know-how für die Systementwicklung den Benutzern überlegen ist (oder vielmehr, dass es oft Gründe gibt, warum er mit dieser Aufgabe betraut ist). Auf der anderen Seite ist es oft der Fall, dass nur die Benutzerseite über das “sollte sein” des eigenen Systems diskutieren kann.

Vor diesem Hintergrund könnte man sich vorstellen, dass die Benutzer die oben genannten Schritte 1 und 4 durchführen. Um es anders auszudrücken, könnte man sagen, dass es eine Methode ist, die “Anforderungsdefinition” der zu migrierenden Daten und die “Abnahme”, ob die Daten gemäß den Anforderungen migriert wurden, als Pflicht zur Zusammenarbeit der Benutzer zu organisieren. Oder anders gesagt, wenn es auf der Benutzerseite jemanden gibt, der über umfangreiches Wissen über das alte System verfügt, könnte man auch darüber nachdenken, Schritt 2 als Aufgabe der Benutzerseite zu übernehmen.

Wenn man in der Lage ist, das alte System intern zu handhaben, ohne es auszulagern, könnte man darüber nachdenken, nur das neue System an den Anbieter auszulagern. In dieser Form kann die Rollenklärung zwischen Benutzern und Anbietern bei der Datenmigrationsarbeit manchmal unklar werden. Darüber hinaus, wenn Benutzer Systementwicklungsaufgaben an Anbieter auslagern, finden Sie eine allgemeine Erläuterung darüber, welche Rollen normalerweise vom Anbieter erwartet werden und welche rechtlichen Verpflichtungen zugeschrieben werden, in dem folgenden Artikel.

https://monolith.law/corporate/project-management-duties[ja]

Vergangene Gerichtsurteile im Zusammenhang mit der Umstellung auf neue Systeme

In Projekten zur Systementwicklung, die auf die Umstellung auf ein neues System abzielen, gibt es tatsächlich Fälle, in denen Probleme aufgetreten sind und es zu Gerichtsverfahren gekommen ist. Der Fall, auf den das unten zitierte Urteil Bezug nimmt, beinhaltet Probleme wie das Scheitern der Migrationsarbeit während der Datenmigration, das Auftreten mehrerer Dateninkonsistenzen und Bugs im neuen System und Verzögerungen bei der Lieferung. Es wurde diskutiert, welche Verpflichtungen die Anbieter- und Benutzerseite jeweils gegenüber dem Projekt hatten. Als Ergebnis wurde festgestellt, dass die Anbieterseite die folgenden Pflichten als ihre Sorgfaltspflicht hätte erfüllen müssen und ein Verstoß gegen die Sorgfaltspflicht der Anbieterseite anerkannt wurde.

Der Beklagte hatte nicht nur die Pflicht, die Daten vom alten System auf das neue System zu übertragen, sondern auch die Pflicht, das neue System mit den übertragenen Daten in Betrieb zu nehmen. Konkret bedeutet dies, dass er vor Beginn der Datenmigrationsarbeit die zu migrierenden Daten auf dem alten System untersuchen und analysieren, die Eigenschaften und den Zustand der Daten verstehen, prüfen sollte, ob diese Daten nach ihrer Übertragung auf das neue System den Betrieb behindern würden, und wenn ja, wann und wie diese Daten korrigiert werden sollten. Schließlich hatte er die Pflicht, das neue System mit den vom alten System übertragenen Daten in Betrieb zu nehmen.

Es ist angemessen anzunehmen, dass er in diesem Fall die Pflicht hatte, Dateninkonsistenzen zu korrigieren und zu beseitigen, wenn er die Daten migriert hat.

Tokyo District Court, November 30, Heisei 28 (2016)

In diesem Fall war ursprünglich geplant, dass die Benutzerseite die Schritte 1 und 4 und die Anbieterseite die Schritte 2 und 3 übernimmt. Das bedeutet, dass die Anbieterseite einmal die Datenextraktion (Schritt 2) vom alten System übernommen hat. Daher hat das Gericht entschieden, dass der Anbieter, als Fachmann für Systementwicklung, hätte prüfen können, ob die Datenextraktion reibungslos durchgeführt werden kann.

Was wäre jedoch passiert, wenn die Benutzerseite die Datenextraktion (Schritt 2) als ihre Aufgabe definiert hätte und dann bei der Extraktion gescheitert wäre? In diesem Fall könnte es sein, dass die Benutzerseite, weil sie die vorherige Untersuchung, ob die Datenextraktion reibungslos durchgeführt werden kann, vernachlässigt hat und dadurch Verzögerungen bei der Lieferung entstanden sind, nun ihrerseits wegen Verletzung der Kooperationspflicht belangt wird.

Darüber hinaus basieren solche Entscheidungen nicht nur auf dem Vertrag, sondern auch auf Protokollen, die dem Fortschritt der Systementwicklung entsprechen. Die Bedeutung von Protokollen wird im folgenden Artikel ausführlich erläutert.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Zusammenfassung

Projekte wie die Systementwicklung erfordern eine sorgfältige Kommunikation zwischen den Nutzern und den Anbietern, da beide Seiten viele Verpflichtungen eingehen müssen. Daher kann in den zuvor erwähnten Gerichtsentscheidungen die Verantwortung leicht auf beide Seiten, Nutzer und Anbieter, umgekehrt werden, selbst wenn sich die Voraussetzungen nur geringfügig ändern.

Angesichts der Tatsache, dass ein System, das eine enorme Menge an Daten und komplexe Mechanismen beinhaltet, die man sich kaum vorstellen kann, nur aufgrund des Aussehens der Benutzeroberfläche, und dass sich das endgültige Gerichtsurteil erheblich ändern kann, selbst bei geringfügigen Unterschieden in den Voraussetzungen, kann man sagen, dass es wichtig ist, das Risikomanagement von neuen Systementwicklungsprojekten umfassend zu betrachten, einschließlich der Abschaffung alter Systeme.