Die rechtliche Bedeutung von Geschäftszielen und quantitativen Zielen in Systementwicklungsprojekten

Systementwicklungsprojekte sind oft eng mit umfangreichen Geschäftsverbesserungen in Unternehmen und Arbeitsplätzen verbunden. Es kann vorkommen, dass eine Haltung gefordert wird, die zur Lösung von Managementproblemen auf der Benutzerseite des Unternehmens und zur Erreichung von quantitativen Zielen beiträgt. Aber ist es wirklich eine rechtliche Verpflichtung, sich auf solche Managementziele zu verpflichten? Die rechtliche Bedeutung von quantitativen Zielen und Managementzielen wird zum Problem. In diesem Artikel werden wir die rechtlichen Fragen erläutern, die mit den verschiedenen “Zwecken” und “Zielen” der Systementwicklung verbunden sind.

Warum werden die Ziele und Absichten der Systementwicklung zum Konfliktherd?

Es ist eine Herausforderung, die zwischen der Kooperationspflicht des Nutzers und dem Ermessensspielraum des Anbieters liegt

Wenn man sich die Art und Weise von Geschäftstransaktionen ansieht, gibt es einige charakteristische Punkte in Systementwicklungsprojekten. Einer davon ist, dass ein Systementwicklungsprojekt durch einen Anbieter nicht allein durchgeführt werden kann, sondern die Zusammenarbeit des Nutzers erfordert. Diese Pflicht ist in der Rechtsprechung als “Kooperationspflicht” bekannt. Insbesondere wird vom Nutzer erwartet, dass er in Phasen wie ① Anforderungsdefinition, ② Grundlegende Design und ③ Abnahme der Ergebnisse zur Systementwicklung beiträgt.

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

Ein weiterer Punkt ist, dass vom Anbieter normalerweise erwartet wird, dass er ein großes Maß an Ermessen ausübt und seine Aufgaben wahrnimmt. Es gibt einen rechtlichen Begriff, der die Aufgaben zusammenfasst, die der Anbieter in einem Systementwicklungsprojekt erfüllen muss, nämlich die “Projektmanagementpflicht”. Dies wird im folgenden Artikel ausführlich erläutert.

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

Zusammenfassend lässt sich sagen, dass es zwei wichtige Punkte zu beachten gibt.

• Der Nutzer wird in der Praxis aufgefordert, dem Anbieter die notwendigen Informationen zur Verfügung zu stellen und bei der Entwicklungstätigkeit des Anbieters mitzuwirken.
• Der Anbieter wird in der Praxis aufgefordert, das Ziel und den Zweck des Projekts für den Nutzer zu verstehen und entsprechende Maßnahmen zu ergreifen.

Aufgrund dieser beiden Punkte wird die Frage, inwieweit die Erreichung von Geschäfts- und quantitativen Zielen, die im Voraus vom Nutzer erklärt wurden, rechtlich zur Pflicht des Anbieters werden kann, zum Problem. Mit anderen Worten, es gibt einerseits die Ansicht, dass es die Pflicht des Nutzers ist, die Aufgaben, die der Anbieter erfüllen sollte, in Spezifikationen zusammenzufassen und vorzulegen (anstatt vage Dinge wie Ziele), andererseits gibt es die Ansicht, dass der Anbieter als Fachmann die Pflicht hat, das zu liefern, was der Nutzer im Wesentlichen verlangt (anstatt einfach nur das zu tun, was ihm gesagt wurde). Diese gegensätzlichen Standpunkte kollidieren miteinander und sind ein Merkmal von Konflikten um die “Ziele” und “Absichten” der Systementwicklung. Aus rechtlicher Sicht besteht die praktische Herausforderung darin, Leitlinien für eine faire Konfliktlösung für beide Seiten zu geben.

Konkrete Situationen, in denen die Ziele des Nutzers das Projekt beeinflussen

Systementwicklungsprojekte sind oft mit Maßnahmen zur Verbesserung und Effizienzsteigerung von großen Unternehmens- oder Arbeitsplatzoperationen verbunden, und oft werden bereits in der Planungs- und Vorschlagsphase Anhörungen zu Geschäftsproblemen und Geschäftszielen durchgeführt. Dabei kann es zu Diskussionen über die Kosten-Nutzen-Verhältnisse der Systementwicklung und den Austausch über verschiedene quantitative Ziele kommen.

• Personalkostenreduktion durch Rationalisierung
• Umsatz- oder Gewinnsteigerung
• Verkürzung der Arbeitszeit

Zum Beispiel könnte der Anbieter in Fällen, in denen die oben genannten Punkte das endgültige Ziel des Projekts sind, im Voraus in der Rolle eines Beraters die Investitionseffekte der Systementwicklung erklären und Geschäfte tätigen.

Was sind Gerichtsfälle, in denen die von den Nutzern gesetzten Geschäftsziele problematisch wurden?

Dennoch sind Anbieter in der Regel Experten für Systementwicklung. Es wäre zu hart, wenn alle Verantwortung auf sie fallen würde, wenn es um die Geschäftsziele der Nutzer geht.

Fall, in dem die Verbesserung der Geschwindigkeit der Geschäftsabläufe als Ziel gesetzt wurde

In Bezug auf diesen Fall wurde in dem Projektplan, der bei der Gründung des Projekts erstellt wurde, der Zweck und die Ziele des Systementwicklungsprojekts festgelegt. Als das System jedoch fertiggestellt und in Betrieb genommen wurde, konnte es seine Ziele nicht erreichen und es kam zu Streitigkeiten. In dem ursprünglichen Projektplan wurde festgelegt, dass nach Fertigstellung des Systems und seiner tatsächlichen Nutzung folgende Zustände erreicht werden sollten:

• Die Zeit für die manuelle Eingabe durch Menschen um 50% reduzieren
• Die Verwaltungsaufgaben mit dem betreffenden IT-System innerhalb einer festgelegten Frist abschließen

Da der Nutzer diese Ziele letztendlich nicht erreichen konnte, versuchte er, den Anbieter wegen Vertragsverletzung und Gewährleistungsverantwortung zur Rechenschaft zu ziehen. Das Gericht hat diese Behauptung jedoch nicht anerkannt (die unterstrichenen und fett gedruckten Teile wurden vom Autor hinzugefügt).

Und, (Auszug) nach dem gesamten Inhalt der Argumentation, ① das Ziel dieses Falles ist “Effizienzsteigerung der Geschäftsabläufe”, “Aufbau einer CRM-Basis”, “Durchführung eines sichtbaren Managements” usw., was abstrakt ist, und die Zielwerte sind auch “Erhöhung der Berührungspunkte mit Kunden”, “Umverteilung der Arbeitskraft von Büroangestellten auf interne Kontrolle und Verkaufsunterstützung”, “genauere Umsatzprognosen”, “Eindämmung übermäßiger Umsatzrabatte” usw., die meist abstrakt sind, und “Reduzierung der Eingabezeit um 50%”, “Reduzierung der Kostenvoranschlagszeit um 50%”, “Erfüllung der gesetzlichen Offenlegung innerhalb der gesetzlichen Frist” usw., sind Zielwerte, die nach der Einführung von SBO auf die Art und Weise des Managements und der Geschäftsabläufe des Beklagten ankommen, und es ist nicht in der Natur der Sache, dass das Systementwicklungsunternehmen, das die Einführung von Paketsoftware unterstützt, diese Ziele erreichen kann, ② in den Protokollen der Besprechungen nach dem Kick-off des Projekts gibt es keine Aufzeichnungen darüber, dass über die Erreichung der Ziele und Zielwerte konkret gesprochen wurde, ③ im Projektplan gibt es Ausdrücke wie “ein börsennotiertes Unternehmen werden”, die nicht die Natur eines Vertrages haben, (Auszug) unter Berücksichtigung dieser Umstände, wird anerkannt, dass der Kläger auf der Grundlage der Erklärungen des Beklagten die Beschreibung des Ziels in dem Projektplan erstellt hat, um sicherzustellen, dass das Projekt nicht scheitert, und um ein gemeinsames Verständnis über das Ziel und die Ergebnisse des Projekts zu erlangen, und es kann nicht anerkannt werden, dass der Beklagte dem Kläger die Systementwicklung zur Erreichung des Ziels anvertraut hat. (Auszug) Daher kann nicht anerkannt werden, dass der Kläger die Systementwicklung zur Erreichung des Ziels vom Beklagten übernommen hat, und es gibt keinen Grund für die Behauptungen der Vertragsverletzung und der Gewährleistungsverantwortung.

Tokyo District Court, December 28, 2010 (Heisei 22)

Was ist die rechtliche Bedeutung von Geschäftszielen und quantitativen Zielen, die aus Gerichtsurteilen abgeleitet werden können?

Wie auch in diesem Urteil erwähnt, ob die Ziele der Systementwicklung oder die quantitativen Ziele, die in Zahlen ausgedrückt sind, erreicht werden können oder nicht, hängt normalerweise von verschiedenen Faktoren ab, wie z.B. den Geschäftsbemühungen der Nutzerseite, die das System nutzen. Daher sollte man davon ausgehen, dass die Hürde, diese als Verantwortung des Anbieters zu betrachten, sehr hoch ist. Im Grunde genommen, wenn die Verantwortung des Anbieters für Vertragsverletzung und Gewährleistungsverantwortung anerkannt wird, bedeutet das, dass die “Ziele” und “Ziele” als Teil des Vertragsinhalts integriert wurden. In diesem Fall jedoch waren die “Ziele” und “Ziele”:

• Für abstrakte und vage Dinge ist es schwierig, sie als Teil des Vertragsinhalts zu betrachten, da sie nicht mit der Natur der rechtlichen Verpflichtungen übereinstimmen
• Für Dinge, die die Selbsthilfebemühungen der Nutzerseite, insbesondere der Geschäftsseite, erfordern, ist es unangemessen, sie dem Anbieter zuzuschreiben, da sie außerhalb der Kontrolle des Anbieters liegen, und es ist schwierig, sie als Teil der vertraglichen Verpflichtungen zu betrachten

So wurde es rechtlich bewertet.

Weitere Erkenntnisse aus diesem Urteil

In diesem Urteil sind auch einige andere interessante Punkte enthalten.

• Das Gericht berücksichtigt die Möglichkeit, dass das Teilen der “Ziele” und “Ziele” eines Systementwicklungsprojekts nur ein Teil der Bemühungen um Kommunikation ist, um ein “gemeinsames Verständnis” zwischen Nutzern und Anbietern zu erlangen.
• Bei der Berücksichtigung, wie wesentlich diese “Ziele” und “Ziele” in einem Projekt waren, wurden auch Protokolle von Meetings als Referenz herangezogen.

Übrigens, aus der Sicht der Wichtigkeit von Dokumentenmanagement und Protokollen in Bezug auf rechtliche Fragen, die mit Systementwicklungsprojekten zusammenhängen, haben wir eine Erklärung in dem folgenden Artikel gegeben.

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

Rechtliche Hinweise zu Geschäftszielen und quantitativen Zielen

Es ist jedoch wichtig, die folgenden zusätzlichen Punkte im Zusammenhang mit diesen “Zielen” und “Zwecken” zu beachten.

Ob das Consulting bezahlt wird oder nicht, kann die Situation ändern

Wenn Sie nicht nur ein Systementwicklungsprojekt durchführen, sondern auch einen bezahlten Beratungsvertrag abschließen, kann sich die Situation erheblich ändern. Wenn zum Beispiel ein unrealistischer Aktionsplan erstellt wurde, ohne die Managementressourcen des Benutzers zu berücksichtigen, könnte es möglich sein, dass die Verantwortung für die Nichterfüllung der Verpflichtungen im Rahmen des bezahlten Beratungsvertrags geltend gemacht wird.

Defekte in den Ergebnissen und Inkonsistenzen in den Funktions- und Spezifikationsanforderungen sind separate Probleme

Wenn es Mängel im gesamten “Entwicklungs”-Projekt gibt, d.h. wenn Fehler oder Bugs in den Ergebnissen festgestellt werden, müssen diese Probleme separat verstanden werden. In diesem Fall geht es nicht um die “Ziele” und “Zwecke” des Managements, sondern hauptsächlich um die Übereinstimmung zwischen den Ergebnissen und den geforderten Funktions- und Spezifikationsanforderungen. Zum Beispiel haben wir in dem folgenden Artikel Maßnahmen für den Benutzer beschrieben, wenn nachträglich Mängel im System festgestellt werden.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Ein weiteres verwandtes Thema ist, dass es Dinge gibt, die als Pflicht zur Implementierung auf Ermessen des Anbieters anerkannt werden, obwohl sie nicht in den Anforderungen enthalten sind. Wir haben dies im folgenden Artikel ausführlich erklärt.

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

In jedem Fall sollten diese als etwas anderes als Streitigkeiten über “Zwecke” und “Ziele” verstanden werden.

Ein grundlegendes Verständnis von Themen wie Verantwortung und Verträgen wird gefordert

Wir haben die rechtlichen Fragen rund um die “Ziele” und “Zwecke” der Systementwicklung erläutert. In Streitigkeiten über diese Punkte gehen die Gerichte oft davon aus, dass die Bemühungen um Kommunikation zwischen den Nutzern und Anbietern als Teil der Bemühungen um eine einheitliche Vorgehensweise verstanden werden. Obwohl die Gültigkeit der Schlussfolgerung selbst durch das praktische Gefühl der Praktiker vollständig verstanden werden kann, wird in dem Prozess, der dazu führt, ein grundlegendes Verständnis von Dingen wie “Verantwortung” und “Verträge” gefordert. Wir erklären diese Punkte in dem folgenden Artikel.

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

Es ist wichtig zu verstehen, dass die rechtliche Verantwortung sich von einer vagen moralischen Verantwortung unterscheidet und dass eine klare “Übereinstimmung der Absichten” beider Parteien die vertragliche Verantwortung hervorruft. Es ist wichtig, ein tieferes Verständnis zu erlangen.