Was sind die Supportpflichten eines Anbieters nach Abschluss der Systementwicklung?

Es ist allgemein bekannt, dass Systementwicklungsspezialisten, auch bekannt als Anbieter, eine “Projektmanagementpflicht” in der Systementwicklung übernehmen. Es gibt jedoch auch ein ähnliches, aber unterschiedliches Konzept im Gesetz, das als “Supportpflicht” bezeichnet wird. In diesem Artikel werden wir die “Supportpflicht” unter Berücksichtigung früherer Gerichtsentscheidungen und ähnlicher Fälle erläutern.

Was ist die Supportpflicht?

Überblick über die Supportpflicht

Wenn es um die Pflichten geht, die ein Anbieter gegenüber einem Nutzer hat, ist die Projektmanagementpflicht ein typisches Beispiel. Dies ist ein Konzept, das sich durch wiederholte Erwähnungen in früheren Gerichtsurteilen etabliert hat und die Pflichten zusammenfasst, die der Anbieter als Experte für Systementwicklung für ein gesamtes Projekt hat.

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

Die Projektmanagementpflicht ist ein sehr bekannter juristischer Begriff im Zusammenhang mit der Systementwicklung und es besteht kein Zweifel daran, dass sie eine der Hauptpflichten ist, die der Anbieter übernimmt. In einigen Gerichtsurteilen wird jedoch die Existenz einer anderen Pflicht, der “Supportpflicht”, anerkannt, die sich von der Projektmanagementpflicht unterscheidet.

Die Supportpflicht wird im Zusammenhang mit der Betriebsunterstützung für den Nutzer problematisch

Aber was ist die Supportpflicht? Und warum wird sie ausdrücklich anders bezeichnet als die Projektmanagementpflicht? Die Supportpflicht wird normalerweise nach Abschluss der Systementwicklung problematisch. Ein Systementwicklungsprojekt endet grundsätzlich, wenn das zu erstellende System fertiggestellt ist, da es sich um ein “Entwicklungs”-Projekt handelt. Das heißt, ein Systementwicklungsprojekt beginnt mit der Klärung dessen, was das zu erstellende System sein soll (= Anforderungsdefinition) und endet mit der Überprüfung, ob es tatsächlich erstellt wurde (= Test oder Abnahme). Übrigens, bezüglich des Abnahmeprozesses, der eine wichtige Bedeutung für das “Ende des Systementwicklungsprojekts” hat, werden die rechtlichen Probleme, die in diesem Stadium häufig auftreten, im folgenden Artikel ausführlich behandelt.

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

Aber selbst wenn ein Systementwicklungsprojekt als der eigentliche Entwicklungsprozess für ein neues System verstanden wird, ist es selbstverständlich, dass das entwickelte System danach im Geschäftsbetrieb genutzt wird. Mit anderen Worten, es wäre unvernünftig zu sagen, dass “solange wir nur in der Position sind, die Entwicklung zu übernehmen, es ausreicht, wenn wir es einfach erstellen”, ohne zu berücksichtigen, wie das System nach der Entwicklung genutzt wird. Vor diesem Hintergrund wurde in früheren Gerichtsurteilen die Frage aufgeworfen, ob es nicht möglich wäre, dem Anbieter, der die Systementwicklung übernimmt, auch eine gewisse Betriebsunterstützungspflicht aufzuerlegen. Das heißt, es stellt sich die Frage, ob die Pflichten, die der Anbieter im Rahmen des Systementwicklungsvertrags hat, nicht auch Pflichten in Bezug auf die Betriebsunterstützung nach der Entwicklung beinhalten sollten. Da die Betriebsunterstützung nicht Teil des eigentlichen Entwicklungsprozesses ist, wird angenommen, dass der Begriff “Supportpflicht” verwendet wurde, um ihn von der Projektmanagementpflicht zu unterscheiden.

Was sind Gerichtsfälle, in denen die Supportpflicht ein Problem darstellte?

Ein Fall, in dem die Durchführung der Geschäfte des Benutzers während der Systemtestphase beeinträchtigt wurde

In dem unten zitierten Urteil konnte der Benutzer das System während des Systemtests vor dem Systemstart nicht wie ursprünglich angenommen nutzen, was dazu führte, dass der Benutzer den Betrieb des Systems selbst aufgeben musste. In diesem Fall handelte es sich um ein Problem beim Start der Benutzeroperation, und die Frage war, wie die Verantwortung des Anbieters auf der Grundlage des zuvor abgeschlossenen Vertrags für die Systementwicklung begründet werden konnte. Das Ergebnis war, dass der Schadenersatzanspruch des Benutzers anerkannt wurde und als Grundlage dafür ein “Verstoß gegen die Supportpflicht” angeführt wurde.

I Verstoß gegen die Supportpflicht
(A) Der Vertreter des Klägers forderte den Beklagten am 14. Juli 1997 (Heisei 9) auf, “Nicht nur das System zu erstellen, sondern es bis zum Ende ordnungsgemäß laufen zu lassen.“, “Wir sind Laien, also wollen wir, dass es bis zum Ende funktioniert, da wir viel Geld bezahlen.“. Der Beklagte erklärte, dass er in der Lage sei, ein System zu erstellen, das die Einführungsziele des Klägers erreichen kann, und versprach, Unterstützung zu leisten, bis es ordnungsgemäß funktioniert. Dadurch wurde zwischen dem Kläger und dem Beklagten eine Vereinbarung getroffen, dass der Beklagte den Kläger unterstützt, bis das System ordnungsgemäß funktioniert.
Es ist offensichtlich, dass der Beklagte eine Supportpflicht gegenüber dem Kläger hat, da er unter dem Posten “Paket-Einführungshilfe” im Vertrag über die Systementwicklung Kosten in Höhe von 1.726.000 Yen verbucht hat und in dem Kostenvoranschlag unter der monatlichen Wartungsgebühr “kostenlose Wartung für sechs Monate nach der Einführung” angegeben ist und in einem Dokument mit dem Titel “Über zukünftige SE-Unterstützung (interne Besprechungsunterlagen)” bestätigt wurde, dass SE-Unterstützung für die Erstellung eines “Einführungsverfahrens (Plan)” und “Daten-/Betriebstestarbeiten” für Frischwarenbestellungen erhalten werden kann.

(B) Die spezifische Supportpflicht, die der Beklagte gegenüber dem Kläger hat, beinhaltet mindestens, dass der Beklagte dem Kläger bis zum Start des Systems ① angemessene Ratschläge zur Bedienung des Systems gibt, ② an Betriebstests teilnimmt und auf Probleme im System reagiert, die während der Betriebstests auftreten, ③ Verbesserungen am System vornimmt, die auf den Ergebnissen der Betriebstests basieren, und ④ Schulungen für die Bediener durchführt.
Jedoch hat der Beklagte, obwohl es während der Betriebstests zu zahlreichen Problemen kam, diese nicht ernst genommen und behauptet, dass es sich um ein Problem mit der Lernkurve der Bediener handelt, und hat nur die Kosten für die Schulung der Bediener gefordert, ohne dem Kläger in irgendeiner Weise angemessene Unterstützung für den Start zu bieten.

Urteil des Bezirksgerichts Hachioji, Tokio, vom 5. November 2003 (Heisei 15)

In diesem Urteil erscheint das Wort “Support” etwa 30 Mal im gesamten Urteil, einschließlich des Inhaltsverzeichnisses. Die Stimme des Benutzers, der um angemessene Unterstützung bittet, wird direkt im Urteil erwähnt, was darauf hindeutet, dass das Urteil das Ergebnis einer sorgfältigen Abwägung des Verlaufs des Falls und des Strebens nach einer fairen Lösung war. Besonders bemerkenswert in Bezug auf das Verständnis dieses Falles sind:

• Der Verstoß gegen die Supportpflicht wird als “Vertragsverletzung” behandelt, was dazu führt, dass Schadenersatz für den daraus resultierenden Schaden verlangt wird.
• Der Begriff “Projektmanagementpflicht” wird im gesamten Urteil nicht einmal verwendet.

Obwohl es sich um ein anderes Konzept als das Projektmanagement handelt, ist die Haltung erkennbar, es als vertragliche Pflicht zu behandeln, die der Vertrag über die Systementwicklung beinhaltet.

Wie sollte die Natur der Supportpflicht interpretiert werden?

Die Supportpflicht ist noch kein klares Konzept

Die zuvor erwähnten Gerichtsurteile zeigen im Wesentlichen, dass der Anbieter, der die Systementwicklung durchgeführt hat, auch den notwendigen Support für den Nutzer bereitstellen sollte, um den Betrieb zu starten. Die Supportpflicht ist jedoch nicht so reich an Präzedenzfällen wie die Projektmanagementpflicht, und es gibt nicht viele Hinweise, um ihre tatsächliche Situation zu verstehen. Insbesondere enthält der Begriff “Support” selbst das Problem, dass es nicht klar ist, was konkret getan werden sollte.

Die Supportpflicht ist nicht unbegrenzt anerkannt

Das oben genannte Urteil, das einen Verstoß gegen die Supportpflicht des Anbieters anerkannt hat, hat auch einen sehr wichtigen Punkt klargestellt.

Der Beklagte wird verstanden, dass er aufgrund des vorliegenden Vertrags eine gewisse Unterstützung für das System, das er für den Kläger aufgebaut und geliefert hat, leisten muss, damit der Kläger es betreiben kann. Es wird jedoch nicht angenommen, dass der Inhalt, wie der Kläger behauptet, unbegrenzt ist und dass der Kläger das System bis er es tatsächlich betreiben kann, kostenlos unterstützt.

Urteil des Bezirksgerichts Tokyo Hachioji vom 5. November 2003 (Heisei 15)

Es wird angenommen, dass darauf hingewiesen wurde, dass es auch Einschränkungen für das, was als Support für den nachfolgenden “Betrieb” im Rahmen der Hauptaufgabe der System”entwicklung” durchgeführt werden sollte, gibt. In diesem Urteil gibt es auch einige bemerkenswerte Punkte, wie die bewusste Zitierung der Stimmen der Nutzer, die Unterstützung in der Urteilsbegründung fordern, die Erwähnung des Inhalts des vorläufigen Kostenvoranschlags und die Erwähnung des Vorhandenseins oder Fehlens einer Sondervereinbarung zur Durchführung von Support. Mit anderen Worten, es wird angenommen, dass die Absicht bestand, die Anerkennung eines Pflichtverstoßes selbst in Anbetracht der Tatsache, dass die Ausweitung des Konzepts der Supportpflicht eine große Belastung für den Anbieter darstellen würde, in gewissem Maße vorsichtig durchzuführen.

Die Realität der Supportpflicht sollte in Verbindung mit der Kooperationspflicht des Nutzers diskutiert werden

Die bisherige Diskussion lässt sich im Wesentlichen auf die Frage reduzieren, “wie Nutzer und Anbieter die Arbeitsbelastung in der Anfangsphase des Betriebs in der Systementwicklung teilen sollten”. Darin ist sicherlich die etwas schwierige Frage enthalten, inwieweit der Anbieter rechtliche Verpflichtungen hat, wenn er vom “Entwicklungs”vertrag zum Betriebsstart übergeht. Gleichzeitig ist es unvermeidlich zu sagen, dass es einen starken Trend gibt, individuelle Umstände zu berücksichtigen.

Dennoch wird angenommen, dass das Verständnis der Realität der Supportpflicht, die der Anbieter trägt, durch das Verständnis der Kooperationspflicht, die der Nutzer trägt, sicherer wird.

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

Die Bemühungen, die Geschäftsabläufe durch ein neues System zu verbessern, haben den Aspekt einer gemeinsamen Arbeit zwischen dem technischen Experten, dem Anbieter, und dem Nutzer, der das betriebliche Wissen im Unternehmen hat. Daher wird angenommen, dass es oft der Fall ist, dass der Umfang durch die Klärung der Angelegenheiten, die der Nutzer als Teil der “Erfüllung der Kooperationspflicht” durch eigene Anstrengungen lösen sollte, in Bezug auf die sogenannte Supportpflicht von selbst festgelegt wird.

Zusammenfassung

In diesem Artikel haben wir uns mit den Grundlagen des Projektmanagements auseinandergesetzt und dabei insbesondere die sogenannte “Unterstützungspflicht” als eine Art Ableitung davon geordnet. Obwohl es noch viele Unklarheiten im Konzept der Unterstützungspflicht gibt, glauben wir, dass das Verständnis der grundlegenden Aspekte wie “Projektmanagementpflicht” und “Kooperationspflicht” immer noch entscheidend ist.