Was sind die Lösungen, wenn die Systementwicklung aufgrund der Benutzerumstände unterbrochen wird?

Die Aufgabe der Systementwicklung nimmt oft die Form eines langfristigen Projekts an. Was kann jedoch getan werden, wenn der Benutzer einseitig sagt: “Wir brauchen dieses System nicht mehr, also müssen Sie es nicht erstellen”, nachdem er mit der Systementwicklung begonnen hat? Was kann der Auftragnehmer, also der Anbieter, in diesem Fall tun?

In diesem Artikel werden wir die Besonderheiten eines Vertrags zur Systementwicklung klären und erläutern, welche Maßnahmen in solchen Fällen ergriffen werden können.

Die Bedeutung der Überlegung zu Unterbrechungen aufgrund von Benutzeranforderungen

Verträge über Systementwicklung haben einige charakteristische Merkmale, wenn man sie als Verträge betrachtet. Eines davon ist, dass die Bauzeit normalerweise lang ist und der Anbieter (Vendor) eine große Verantwortung zusammen mit einem großen Ermessensspielraum hat, um das Projekt zu managen. Eine detaillierte Erklärung des gesamten Inhalts der Projektmanagementpflichten, die der Anbieter trägt, finden Sie im folgenden Artikel.

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

Ein weiteres Merkmal ist, dass der Benutzer, obwohl er ein Kunde ist, eine weitreichende Pflicht hat, mit den Arbeiten des Anbieters zusammenzuarbeiten. Da es sich um ein System handelt, das intern im Unternehmen verwendet wird, kann es nicht einfach an den Anbieter “ausgelagert” werden. Es besteht eine Pflicht zur angemessenen Zusammenarbeit, damit der Anbieter seine Fachkenntnisse einsetzen und seine Arbeit erledigen kann, auch aus dem internen Bereich des Unternehmens. Eine detaillierte Erklärung dazu finden Sie im folgenden Artikel.

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

Wenn wir die obigen Punkte kurz zusammenfassen, gibt es zwischen dem Anbieter und dem Benutzer sowohl eine Beziehung der Gegenleistung, in der der “externe Dienstleister” das System entwickelt und der “Kunde” die Vergütung zahlt, als auch gleichzeitig eine Beziehung, in der sie als “Kollegen” zusammenarbeiten sollten, um das gemeinsame Ziel der Projektverwirklichung zu erreichen. Diese Komplexität der Beziehungen ist normalerweise nicht bei einfachen Maßschneidern wie Anzugherstellern vorhanden und ist ein großes Merkmal von Verträgen im Zusammenhang mit der Systementwicklung. Streitigkeiten im Zusammenhang mit der Systementwicklung sind aufgrund dieser komplexen Beziehungen oft kompliziert und schwierig zu lösen, wenn es darum geht, wie die Beziehungen zwischen den Parteien rechtlich zu ordnen sind, sobald sie verwickelt sind.

Es ist sinnvoll, über das Problem nachzudenken, wie die Rechte und Pflichten beider Parteien zu verstehen sind, wenn der Benutzer seine Meinung ändert und plötzlich sagt: “Wir brauchen dieses System letztendlich nicht mehr, also müssen wir das Projekt nicht weiter vorantreiben”. Dies hat auch die Bedeutung, ein praktisches Beispiel dafür zu geben, wie man rechtlich denken sollte, angesichts dieser komplexen Vertragsbeziehungen. Im Folgenden werden wir die Punkte, die nach einer solchen Annahme zu prüfen sind, organisieren.

Zuerst den Grund für die Kündigung klären

Aus Sicht des Anbieters kann es Fälle geben, in denen der Nutzer das Projekt einseitig unterbrechen möchte. Es ist jedoch nicht immer gewährleistet, dass diese Wahrnehmung auch zwischen dem Nutzer und dem Anbieter geteilt wird. Als Beispiel könnte man ein Projekt zur Entwicklung eines Systems zur Verwaltung von Personal, das in ausländischen Niederlassungen arbeitet, anführen. Später wurde der Plan zur Expansion ins Ausland selbst zurückgezogen, wodurch die Entwicklung des Systems selbst unnötig wurde. Sicherlich könnte man aus dieser Erklärung allein schließen, dass es sich um eine einseitige Änderung der Meinung auf Seiten des Nutzers handelt.

Aber was wäre, wenn es im Hintergrund dieser Entscheidung auch tatsächliche Verstöße gegen die Projektmanagementpflichten auf Seiten des Anbieters, wie Verzögerungen in verschiedenen Phasen, gab und die Entwicklung selbst schwierig war, was auch zu einer Änderung der Unternehmenspolitik beigetragen hat?

Wie bereits erwähnt, ist die Systementwicklung etwas, bei dem sowohl der Anbieter als auch der Nutzer große Verpflichtungen eingehen und eng zusammenarbeiten müssen. Daher sollte man sich bewusst sein, dass selbst wenn der Nutzer den Wunsch nach Unterbrechung geäußert hat und der Anbieter dies als Kündigung aus persönlichen Gründen ansieht, es möglich ist, dass der Nutzer auf Gründe hinweist, die dem Anbieter zuzuschreiben sind, und behauptet, dass es sich um eine Kündigung aufgrund von Vertragsverletzungen oder eine einvernehmliche Kündigung handelt.

Ob es sich um eine Kündigung aus persönlichen Gründen, eine Kündigung aufgrund von Vertragsverletzungen oder eine einvernehmliche Kündigung handelt, hängt stark von den Umständen des Projekts und dem bisherigen Verhandlungsverlauf ab. Daher ist es wichtig, wenn der Anbieter die Nachbearbeitung auf der Grundlage der Annahme, dass es sich um eine Kündigung aus persönlichen Gründen des Nutzers handelt, vorantreibt, dass er dies deutlich in den Protokollen von Meetings und dergleichen festhält, um spätere Streitigkeiten zu vermeiden.

Bestätigung der Rechtsgrundlage für Honorarforderungen und Schadensersatz

Nach Berücksichtigung der oben genannten Punkte, wenn die Diskussion als Kündigung aufgrund der eigenen Umstände des Nutzers fortgesetzt werden kann, wird als nächstes geprüft, ob der Anbieter dem Nutzer eine Honorarforderung entsprechend dem Fertigstellungsgrad oder eine Schadensersatzforderung stellen kann.

Die in solchen Fällen zu berücksichtigenden Bestimmungen variieren je nach Vertragstyp. Verträge über Systementwicklung können grob in Werkverträge und quasi-Auftragsverträge unterteilt werden.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Und im Falle von quasi-Auftragsverträgen und Werkverträgen hat das japanische Zivilgesetz (Japanisches Zivilgesetzbuch) die folgenden Bestimmungen:

a.) Im Falle eines quasi-Auftragsvertrags
Honorarforderung: Japanisches Zivilgesetzbuch Artikel 648 Absatz 3
Wenn der Auftrag aufgrund von Umständen, die nicht dem Beauftragten zuzuschreiben sind, in der Mitte der Ausführung endet, kann der Beauftragte ein Honorar entsprechend dem bereits geleisteten Anteil der Ausführung verlangen.
Schadensersatzforderung: Japanisches Zivilgesetzbuch Artikel 651
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.

b.) Im Falle eines Werkvertrags
Schadensersatzforderung: Japanisches Zivilgesetzbuch Artikel 641
So lange der Auftragnehmer die Arbeit nicht abgeschlossen hat, kann der Auftraggeber jederzeit den Vertrag kündigen, indem er den Schaden ersetzt.

Es ist zu beachten, dass der Umfang des Schadensersatzes nach Artikel 641 des japanischen Zivilgesetzbuchs (Japanisches Zivilgesetzbuch) nicht nur die bereits ausgegebenen Kosten, sondern auch den “Gewinn, der erzielt worden wäre, wenn der Vertrag nicht gekündigt worden wäre”, umfasst. Dies spiegelt die Ansicht wider, dass es sinnlos wäre, das Gesetz dazu zu zwingen, die Arbeit abzuschließen, obwohl sie aus Sicht des Auftraggebers nicht mehr benötigt wird, und dass es daher rationaler wäre, den Gewinn der Auftragnehmerseite durch die Zahlung eines gleichwertigen Entgelts zu sichern.

Es ist jedoch zu beachten, dass es nicht selten vorkommt, dass Schadensersatzforderungen nach Artikel 641 des japanischen Zivilgesetzbuchs (Japanisches Zivilgesetzbuch) in individuellen Verträgen zwischen Anbieter und Nutzer ausgeschlossen sind. In solchen Fällen hat die individuelle Vereinbarung zwischen den Parteien (= Vertrag) Vorrang, und es ist zu bedenken, dass diese Bestimmungen des Zivilgesetzbuchs nicht zur Anwendung kommen.

Weitere Beweisführung von Leistung und Schaden

Im Falle einer Kündigung aus eigenem Antrieb des Nutzers ist es üblich, dass im Vertrag festgelegt ist, dass eine Forderung für die Leistung (d.h. den abgeschlossenen Teil) und eine Schadensersatzforderung gestellt werden kann. Daher ist es normalerweise notwendig für den Anbieter, Beweise für die Leistung und den Schaden zu erbringen, um eine Schadensersatzforderung zu stellen.

Allerdings ist es zu erwarten, dass die Beweisführung für diese Leistung, also den Fertigstellungsgrad, eine sehr mühsame Aufgabe sein kann, wenn sie tatsächlich durchgeführt wird. Denn es kann eine erhebliche Menge an Arbeit anfallen, wenn es darum geht, Interviews zur Fortschrittskontrolle durchzuführen, insbesondere wenn es mehrere Subunternehmer gibt, um zu klären, welcher Arbeitspunkt in welchem Ausmaß abgeschlossen war. Darüber hinaus wird es eine enorme Menge an Arbeit sein, wenn man alle Aufgaben, wie die Erstellung von Unterlagen zur Untermauerung der Interviewergebnisse und die Dokumentation des Inhalts der Interviews selbst, durchführt. Es gibt auch viele Schwierigkeiten, wie das Risiko, dass trotz all dieser Anstrengungen die Beweisführung als unzureichend angesehen wird, und die Mühe, die in die Vorbereitung der Beweisführung investiert wurde, kann vergeblich sein.

Als Maßnahme unter Berücksichtigung dieser Punkte kann man beispielsweise bereits in der Vertragsphase festlegen, dass im Falle einer Kündigung während der Laufzeit eine anteilige Berechnung auf der Grundlage der Anzahl der Tage bis zum Zeitpunkt der Kündigung durchgeführt wird, um die Berechnung zu vereinfachen. Darüber hinaus könnte man, angesichts des Aufwands für die Beweisführung für die Leistung, die Forderung für die Leistung selbst aufgeben und stattdessen in Betracht ziehen, eine Forderung für die “Kosten, die für die Entwicklung des bereits fertiggestellten Teils aufgewendet wurden”, zu stellen. Wenn es sich um interne Entwicklungskosten handelt, kann man in vielen Fällen einfach durch die einfache Formel “Arbeitsstunden x Einheitspreis” ermitteln. Insbesondere bei Projekten mit geringer Gewinnmarge kann es oft realistischer sein, den Schadensersatz zu priorisieren, indem man die Forderung auf der Basis der Kosten statt der Leistung priorisiert, da dies die Rückforderung von Forderungen erleichtert.

Was sollten Nutzer in Betracht ziehen?

Übrigens, auch auf der Nutzerseite gibt es Punkte, die vor dem Aussprechen einer Kündigung aus eigenem Antrieb in Betracht gezogen werden sollten. Dies beinhaltet die Überprüfung einer ungefähren Schadensersatzsumme, die an den Anbieter zu zahlen wäre. Mit “ungefähr” meinen wir, dass es ausreichend ist, eine grobe Schätzung zu haben, um den Verlauf der folgenden Verhandlungen abzuschätzen (da eine Verzögerung der Kündigungsabsicht selbst kontraproduktiv wäre, ist eine genaue Summe nicht unbedingt erforderlich).

Wenn die überprüfte Schätzung als unangemessen hoch angesehen wird, sollten Sie eine Erklärung verlangen. Allerdings kann übermäßiges Feilschen, um den Zahlungsbetrag zu senken, zu sinnlosen Klagen führen und die Situation weiter verschärfen. Wenn Verhandlungen zwischen den beiden Parteien schwierig erscheinen, könnte es eine Option sein, einen Anwalt zu konsultieren.

In diesem Artikel haben wir davon ausgegangen, dass ein Vertrag über die Systementwicklung besteht. In der Realität der Systementwicklung gibt es jedoch oft Streitigkeiten darüber, ob ein Vertrag überhaupt wirksam zustande gekommen ist. Wir erklären dies im Detail im folgenden Artikel.

https://monolith.law/corporate/system-development-contract[ja]

Zusammenfassung

In diesem Artikel haben wir den Prozess zur Bewältigung von Fällen, in denen ein Projekt aufgrund von Benutzerumständen unterbrochen wird, erläutert. Der wichtigste Punkt dieses Artikels ist jedoch, dass es notwendig ist, zu prüfen, ob es wirklich aufgrund von Benutzerumständen ist und ob es wirklich kein Verschulden auf Seiten des Anbieters gab.

Ein Merkmal von Systementwicklungsprojekten ist, dass sowohl der Anbieter als auch der Benutzer große Verpflichtungen eingehen. In Anbetracht dessen ist es wichtig, im Voraus sorgfältig zu prüfen, ob es wirklich möglich ist, die Verantwortung einseitig auf die andere Partei zu schieben. Andernfalls könnte dies zu einer Situation führen, die Öl ins Feuer gießt, und dies sollte beachtet werden.