Was ist das Gesetz in Bezug auf das 'Ausgebranntsein' von Systementwicklungsprojekten?

Ein Projekt wie die Systementwicklung ist nicht etwas, das über Nacht erreicht werden kann. Es erfordert eine Vielzahl von Ressourcen, einschließlich zahlreicher Personen und Organisationen, erheblicher finanzieller Mittel und einer langen Entwicklungszeit. In diesem Artikel werden wir erläutern, wie das Phänomen des “Ausbrechens” eines Projekts in der Systementwicklung im Rahmen des rechtlichen Systems organisiert werden kann, und wir werden Richtlinien für Lösungen zusammenstellen.

Warum “brennen” Projekte?

Ein IT-System, selbst wenn es kein besonders groß angelegtes Projekt ist, funktioniert erst richtig, wenn eine große Menge an erstellten Programmdateien und Quellcodes aufgebaut wurde. Oft ist die Konstruktion so detailliert und präzise, dass man sich das kaum vorstellen kann, wenn man nur die Bedienung von der Bildschirmseite aus betrachtet (oder eher, je einfacher und übersichtlicher die Bedienung von der Bildschirmseite aus erscheint, desto wahrscheinlicher ist dies).

• Die Frist ist das Einzige, was festgelegt wurde, während die Spezifikationen und Anforderungen immer noch unklar sind und die Zeit vergeht
• Viele Mitglieder sind so sehr mit internen politischen Problemen beschäftigt, dass sie aufgrund von Beziehungsstress auf halbem Weg aussteigen
• Es gibt einen Mangel an Verhandlungsfähigkeiten auf Managementebene, einschließlich des Projektmanagers, und es wird nicht genug Berichterstattung, Kommunikation und Beratung von den Mitgliedern verlangt

Die konkreten Gründe für das “Brennen” eines Projekts können von Projekt zu Projekt variieren. Aus rechtlicher Sicht können die Gründe für das “Brennen” eines Projekts jedoch relativ einfach in mehrere Typen eingeteilt werden.

Flammentyp 1: Wenn ein Projekt mitten im Prozess scheitert

Ein typischer Grund, warum ein Systementwicklungsprojekt mitten im Prozess scheitert, ist eine mangelnde Kommunikation zwischen dem Nutzer und dem Anbieter. Ein Systementwicklungsprojekt erfordert nicht nur die technischen und organisatorischen Fähigkeiten des Anbieters, sondern auch die Zusammenarbeit des Nutzers, der das System letztendlich nutzen wird.

Wenn ein Projekt mit unklaren Rollenverteilungen fortgesetzt wird und eine Art “Geschäftsschieberei” entsteht, wird der reibungslose Ablauf des Projekts behindert. Für eine rechtliche Betrachtung der Pflichten des Nutzers und des Anbieters, siehe die folgenden Artikel:

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

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

Die genauen Details zu den jeweiligen Verantwortlichkeiten können in den oben genannten Artikeln nachgelesen werden. Der Punkt hier ist, dass sowohl der Nutzer als auch der Anbieter in einem Systementwicklungsprojekt bestimmte Verantwortlichkeiten haben. Grob gesagt, erkennt die Rechtsprechung eine Pflicht zur Zusammenarbeit des Nutzers in Bereichen an, die ohne die Zusammenarbeit des Nutzers nicht abgeschlossen werden können, wie z.B. die Definition von Anforderungen, das Design von Oberflächen und die Abnahme.

Auf der anderen Seite hat der Anbieter, nachdem er die oben genannten Unterstützungen vom Nutzer erhalten hat (und gleichzeitig die Bemühungen um Kommunikation unternommen hat), eine umfassende Verpflichtung zur reibungslosen Durchführung des Projekts und zur Identifizierung und Beseitigung von Hindernissen.

Unter dieser Prämisse zeigt das Gericht eine Haltung, die die Pflicht des Nutzers, die Governance intern zu stärken, und die Pflicht des Anbieters, als externer Experte Fachwissen und technische Fähigkeiten einzubringen, aufzeigt und alle Konflikte fair behandelt.

Ein typischer “Scheitern”-Punkt ist die Abnahme. Eine detaillierte Erklärung zur Abnahme finden Sie im folgenden Artikel:

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

In solchen Fällen wird, sobald ein Konflikt entsteht, oft auf objektiv überprüfbare Beweise wie den Verlauf früherer Projekte und den Inhalt von Besprechungen zurückgegriffen. Daher spielen im Voraus erstellte Dokumente oft eine große Rolle. Um Ihre Position nicht zu benachteiligen, ist eine gründliche Dokumentenverwaltung wichtig. Für eine detaillierte Erklärung aus der Perspektive der Wichtigkeit der Dokumentenverwaltung in der Systementwicklung, siehe den folgenden Artikel:

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

Flammentyp 2: Kündigung aus persönlichen Gründen des Nutzers

Es kann auch vorkommen, dass ein Projekt auf Wunsch des Nutzers in der Mitte abgebrochen wird. Nehmen wir zum Beispiel an, ein Unternehmen hat begonnen, ein IT-System zu entwickeln, das die Personalverwaltung einschließlich der ausländischen Niederlassungen zentralisiert, und dann wird die gesamte Strategie der Unternehmensexpansion ins Ausland zurückgezogen. In solchen Fällen könnte die Entwicklung des begonnenen Systems für den Nutzer nicht mehr notwendig sein.

Die Frage, wie ein IT-System in einem Unternehmen aufgebaut werden sollte, ist untrennbar mit der Frage verbunden, welche Art von Geschäft es in dem Unternehmen gibt. Daher ist es durchaus möglich, dass die Anforderungen an ein System (ob es nun notwendig oder unnötig ist) sich nachträglich ändern, wenn es von erheblichen Änderungen in der Organisationsstruktur, der Geschäftsabteilungsorganisation oder einer grundlegenden Überprüfung der Strategie betroffen ist.

Auch wenn ein Projekt aufgrund solcher Umstände in der Mitte abgebrochen wird, können verschiedene rechtliche Probleme auftreten. In solchen Fällen werden in der Regel dem Anbieter bestimmte rechtliche Rechte eingeräumt, wie zum Beispiel die Forderung nach einer Vergütung entsprechend dem Grad der Fertigstellung, da es sich um eine persönliche Angelegenheit des Nutzers handelt. Je nachdem, welcher Vertragstyp gewählt wurde, können die zugrunde liegenden Klauseln variieren, aber der Inhalt kann wie folgt zusammengefasst werden:

・Im Falle eines Werkvertrags: Artikel 641 des japanischen Bürgerlichen Gesetzbuches (BGB)
Artikel 641 des BGB
→Der Besteller kann jederzeit den Vertrag kündigen und Schadenersatz verlangen, solange der Auftragnehmer die Arbeit nicht abgeschlossen hat.
・Im Falle eines quasi-Auftragsvertrags: Artikel 648 Absatz 3 des BGB (je nach Situation kann auch eine Schadenersatzforderung gemäß Artikel 651 des BGB gestellt werden)
Artikel 648 des BGB
→Wenn der Auftrag aufgrund von Umständen, die dem Auftragnehmer nicht zuzuschreiben sind, in der Mitte der Erfüllung endet, kann der Auftragnehmer eine Vergütung entsprechend dem Grad der bereits erbrachten Leistung verlangen.
Artikel 651 des BGB
→1. Der Auftrag kann jederzeit von jeder Partei gekündigt werden.
→2. Wenn eine Partei den Auftrag zu einem für die andere Partei nachteiligen Zeitpunkt kündigt, muss diese Partei den Schaden der anderen Partei ersetzen. Dies gilt jedoch nicht, wenn es einen unvermeidlichen Grund gibt.

Flammentyp 3: Wenn Mängel im gelieferten System später entdeckt werden

Obwohl Benutzer oft die Qualität eines Systems anhand der Bedienbarkeit des Bildschirms beurteilen, sind aus Sicht des Auftragnehmers die Herausforderungen oft in der Datenbankgestaltung oder in der Identifizierung von Testelementen unter Berücksichtigung aller Betriebsmethoden zu finden.

Das bedeutet, dass selbst ein System, das anfangs problemlos zu funktionieren schien, tatsächlich Probleme aufweisen kann, wie:

• Die Verarbeitungsgeschwindigkeit verlangsamt sich mit zunehmender Menge an registrierten Daten
• Ein System, das im täglichen Grundbetrieb problemlos zu funktionieren schien, zeigt bei speziellen Operationen, die nur alle paar Monate oder Jahre auftreten, Fehler
• Auch wenn es so aussieht, als ob die Ergebnisse korrekt ausgegeben werden, ist die tatsächliche Logik möglicherweise nicht korrekt. Ein einfaches Beispiel wäre, dass eine Eingabe von “1+1” vom Benutzer korrekt als “2” ausgegeben wird, aber das bedeutet nicht unbedingt, dass die Berechnung korrekt durchgeführt wird. Es könnte sein, dass jede Rechenformel die Ausgabe “2” zurückgibt. Solche “Logikfehler” sind oft schwer zu entdecken, wenn man nur die Bildschirmbedienung durchführt. In diesem Sinne kann man sagen, dass eine gewisse “technische Fähigkeit” im Testprozess gefordert ist.

Solche Dinge können tatsächlich passieren. Wenn man diese Fälle aus einer rechtlichen Perspektive analysiert, könnte man sie als Verletzung der Projektmanagementpflichten auf Seiten des Anbieters betrachten, was im Sinne des Zivilrechts ein Problem der unvollständigen Erfüllung darstellen könnte.

In diesem Fall, wenn es keine speziellen Vereinbarungen im Vertrag gibt, würden normalerweise die Bestimmungen für Werkverträge zur Anwendung kommen.

Die zu berücksichtigenden Punkte in diesem Fall können wie folgt zusammengefasst werden:

https://monolith.law/corporate/defect-warranty-liability[ja]

So kann die Situation zusammengefasst werden.

Zusammenfassung

Jedes einzelne Systementwicklungsprojekt wird wahrscheinlich auf vielfältige Weise und mit vielen Wendungen voranschreiten. Wenn es jedoch um das “Ausgebranntsein” eines rechtlichen Projekts geht, bietet der in diesem Artikel vorgestellte Rahmen einen Überblick. Rechtsfragen im Zusammenhang mit der Systementwicklung beinhalten zweifellos eine Vielzahl von Themen.

Genau wie die Aufgabe der Systementwicklung konstruktives Denken erfordert, könnte das damit verbundene Risikomanagement durch den Erhalt eines Gesamtüberblicks über das Feld konstruktiver durchgeführt werden, oder nicht?