MONOLITH LAW OFFICE+81-3-6262-3248Wochentags 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Was ist die richtige Vorgehensweise bei der Änderungsverwaltung in der Systementwicklung aus rechtlicher Sicht?

IT

Was ist die richtige Vorgehensweise bei der Änderungsverwaltung in der Systementwicklung aus rechtlicher Sicht?

In Systementwicklungsprojekten kommt es oft vor, dass Benutzer im Laufe der Arbeit Änderungen an Inhalten vornehmen, die sie zuvor erklärt haben. Daher kann es auch für den Dienstleister, der den Auftrag annimmt, notwendig werden, Änderungen am Inhalt eines einmal abgeschlossenen Vertrags vorzunehmen.

In diesem Artikel erläutern wir, wie man aus rechtlicher Sicht mit dem Phänomen der “Änderungen”, die nachträglich in Systementwicklungsprojekten vorgenommen werden, die nicht wie erwartet verlaufen, umgehen sollte.

Warum werden Systementwicklungsprojekte “geändert” nach ihrer Fertigstellung?

Systementwicklung ist eine gemeinsame Arbeit von Anbietern und Benutzern

Im Allgemeinen durchläuft die Systementwicklung die Planungs- und Vorschlagsphase, in der die Anforderungen für die Entwicklung definiert und Verträge abgeschlossen werden. Nach Abschluss des Vertrags werden verschiedene Designs erstellt und gemäß diesen Designs implementiert. Schließlich wird ein Test durchgeführt, um den Prozess abzuschließen. Während des gesamten Prozesses hat der Anbieter, der die Arbeit annimmt, natürlich eine breite Verantwortung als Experte für Systementwicklung, aber auch der Benutzer hat eine gewisse Pflicht zur Zusammenarbeit. Insbesondere bei Prozessen wie der Identifizierung der Funktionen, die das zu erstellende System haben sollte (= Anforderungsdefinition), dem Aussehen und der Bedienbarkeit der Benutzeroberfläche (= Grunddesign) und der Überprüfung, ob die Anforderungen erfüllt wurden (= Test oder Abnahme), ist die Zusammenarbeit des Benutzers wichtig. Für eine allgemeine Erklärung der Pflichten, die der Benutzer in der Systementwicklung hat, siehe den folgenden Artikel.

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

Obwohl es eine Pflicht zur Zusammenarbeit gibt, fordern Benutzer oft Änderungen

Aber selbst wenn der Benutzer kein Experte für Systementwicklung ist, kann er nicht immer alle notwendigen Informationen für die Systementwicklung vollständig und umfassend an den Anbieter weitergeben. In der Realität ist es oft unmöglich für den Benutzer vorherzusagen, welche Fakten in späteren Phasen entscheidend sein könnten, gerade weil es sich um eine detaillierte und präzise Arbeit handelt. Ironischerweise kann dies dazu führen, dass wichtige Fakten erst später in kleinen Mengen auftauchen. Aus diesen Gründen ist es in realen Projekten, obwohl das Ideal wäre, “von der Upstream-Phase zur Downstream-Phase in einem Rutsch” zu gehen, wichtig, wie man das “Änderungsmanagement” unter der Annahme durchführt, dass verschiedene Änderungen nachträglich vorgenommen werden können.

Was ist ein Änderungsmanagement-Dokument?

Wie geht man mit “Änderungsmanagement” um, das während der Systementwicklung auftritt?

Wann wird ein Änderungsmanagement-Dokument verwendet?

Ein Änderungsmanagement-Dokument ist ein Dokument, das ein Benutzer verwendet, um einen Anbieter um Änderungen der Spezifikationen oder zusätzliche Funktionen zu bitten, die von den ursprünglichen Erklärungen abweichen. Wie bereits erwähnt, haben sowohl der Benutzer als auch der Anbieter die Pflicht, in Phasen wie der Anforderungsdefinition und dem grundlegenden Design zusammenzuarbeiten. Es ist jedoch durchaus möglich, dass im weiteren Verlauf unterschiedliche Anforderungen gestellt werden.

Beispiele für Situationen, in denen ein Änderungsmanagement-Dokument benötigt wird, sind beispielsweise:

  • Wenn bei der Anforderungsdefinition oder dem grundlegenden Design etwas übersehen wurde und später eine zusätzliche Funktion angefordert wird
  • Wenn während der Entwicklung eine Überprüfung der Geschäftspolitik oder ähnliches erforderlich ist und eine Änderung der Spezifikationen erforderlich wird

Diese sind nur einige Beispiele.

Im Zusammenhang mit Themen wie der Hinzufügung von Funktionen und der Änderung von Spezifikationen ist für den Auftragnehmer vor allem die Frage von Interesse, ob eine Änderung des Kostenvoranschlags rechtlich zulässig ist. Dieser Punkt wird in einem separaten Artikel ausführlich erläutert.

https://monolith.law/corporate/increase-of-estimate[ja]

Ein Änderungsmanagement-Dokument dient als Grundlage zur Beurteilung der Angemessenheit eines Kostenvoranschlags, wenn eine nachträgliche Erhöhung des Kostenvoranschlags vorgenommen wird. Die Erstellung eines Änderungsmanagement-Dokuments ist wichtig, um Streitigkeiten mit der anderen Partei zu vermeiden, wenn auf der Grundlage des erhöhten Kostenvoranschlags eine Rechnung gestellt wird (und um im Falle einer Streitigkeit überzeugende Argumente für die eigene Position zu haben).

Inhalte des Änderungsmanagement-Dokuments

Was sollte also rechtlich in einem Änderungsmanagement-Dokument festgehalten werden? Der Vertragsmechanismus, der die Nutzung eines Änderungsmanagement-Dokuments zur Anpassung an Spezifikationsänderungen und zusätzliche Funktionen ermöglicht, ist bereits allgemein anerkannt. Daher kann man durch die Überprüfung von Vertragsklauselvorlagen, die von Behörden wie dem Ministerium für Wirtschaft, Handel und Industrie vorgeschlagen werden, im Allgemeinen verstehen, welche Punkte als Aufzeichnung festgehalten werden sollten.

(Änderungsmanagement-Verfahren)
Artikel 37 Wenn A oder B einen Änderungsvorschlag gemäß Artikel 34 (Änderung der Systemspezifikationen usw.), Artikel 35 (Genehmigung von Zwischenmaterialien durch den Benutzer) oder Artikel 36 (Behandlung von unbestimmten Angelegenheiten) von der anderen Partei erhält, soll er innerhalb von X Tagen nach Erhalt ein schriftliches Dokument (im Folgenden “Änderungsmanagement-Dokument” genannt) mit den folgenden Angaben an die andere Partei übergeben, und A und B sollen in dem in Artikel 12 festgelegten Kommunikationsausschuss über die Zulässigkeit dieser Änderung beraten.
Name der Änderung
Verantwortlicher für den Vorschlag
Datum
Grund für die Änderung
Detaillierte Informationen zur Änderung, einschließlich der betroffenen Spezifikationen
Wenn Kosten für die Änderung anfallen, deren Betrag
Zeitplan für die Änderungsarbeiten, einschließlich der Überprüfungsperiode
Weitere Auswirkungen der Änderung auf die Bedingungen dieses Vertrags und des Einzelvertrags (Arbeitszeit oder Liefertermin, Vertragsgebühr, Vertragsklauseln usw.)

Wenn Sie den Text direkt lesen und die empfohlenen Einträge überprüfen, benötigen Sie keine weitere Erklärung. Um später keine “Ich habe es gesagt/Ich habe es nicht gesagt”-Probleme zu haben, sollten Sie den Verlauf der Änderungen detailliert und konkret aufzeichnen.

Indem Sie diese Einträge klar festhalten und sie mit den Unterschriften oder Siegeln der Verantwortlichen und Entscheidungsträger von Anbieter und Benutzer kombinieren, erhalten Sie im Falle eines Rechtsstreits ein Dokument, das die gleiche Bedeutung hat wie ein Vertrag.

Was Sie über das Änderungsmanagement wissen sollten

Nach der Erstellung des Änderungsmanagement-Dokuments wird es in die Aufgabenverwaltungsliste aufgenommen.

Änderungsmanagement sollte in der Regel zusammen mit der Aufgabenverwaltung durchgeführt werden

Der Grund für die Erstellung eines Änderungsmanagement-Dokuments besteht darin, durch die Verwaltung der Änderungshistorie das Projekt zum Erfolg zu führen (oder im Falle eines Scheiterns, ungerechtfertigte Verantwortlichkeiten zu vermeiden). In der Praxis wird die Erstellung eines Änderungsmanagement-Dokuments oft zusammen mit der Erstellung und Aktualisierung einer Aufgabenverwaltungsliste durchgeführt. Das heißt, wenn die Änderungshistorie in der Änderungsmanagement-Tabelle verwaltet wird, werden die vereinbarten Änderungspunkte als zukünftige Aufgaben in die Aufgabenverwaltungsliste aufgenommen.

Es ist besser, auch die Durchführung von Änderungsbesprechungen zu regeln

Nicht nur die Methode des Änderungsmanagements, sondern auch die Durchführung von Änderungsbesprechungen sollte geregelt werden, um einen reibungslosen Ablauf der Änderungen zu gewährleisten. Dies ist besonders wichtig, wenn agile Entwicklungsmethoden verwendet werden, bei denen nachträgliche Änderungen vorausgesetzt werden. In der Praxis gibt es viele Beispiele dafür, dass festgelegt wird, bis wann der andere Teilnehmer auf eine Anfrage zur Änderungsbesprechung reagieren sollte.

Änderungsbesprechungen und Treuepflicht

Wenn beide Parteien einen einmal vereinbarten Vertrag ändern wollen, ist dies im Grunde genommen das Eingehen eines neuen Vertrags. Da der Vertrag auf dem freien Willen der Parteien beruht, besteht grundsätzlich keine Verpflichtung für den Anbieter, dem Änderungsvertrag zuzustimmen. Es besteht jedoch die Befürchtung, dass die Betonung dieser Rechte dazu führen könnte, dass das Systementwicklungsprojekt nicht reibungslos verläuft.

Daher wird in der Praxis oft in den Vertrag aufgenommen, dass es eine “Pflicht zur aufrichtigen Teilnahme an Änderungsbesprechungen” gibt, und es gibt Fälle, in denen festgelegt wird, dass Schadenersatzansprüche möglich sind, wenn der Anbieter nicht aufrichtig auf Änderungen reagiert.

Ein Beispiel für eine solche Klausel könnte folgendermaßen aussehen (nachfolgend ein Beispiel für eine Klausel, zitiert aus dem von der unabhängigen Verwaltungsbehörde “Information Processing Promotion Agency” offiziell erstellten “ff Basic/Individual Contract Model Basic Contract Draft”).

Artikel 4 Absatz 3 Bei Änderungsbesprechungen werden die Änderungsziele, die Möglichkeit von Änderungen, die Auswirkungen von Änderungen auf die Kosten und den Liefertermin usw. geprüft und beide Parteien beraten aufrichtig, ob Änderungen vorgenommen werden sollen.

Bestimmungen über die Änderungsmethode

Wie bereits erwähnt, ist es aus rechtlicher Sicht “sicherer”, bei jeder Änderung eine Änderungsbesprechung abzuhalten. Bei kleineren Projekten kann es jedoch vorkommen, dass nicht extra festgelegt wird, wie Änderungsbesprechungen durchgeführt werden sollen. In diesem Fall könnte man statt einer Regelung für Besprechungen vorsehen, dass Änderungen erst durch die Unterschrift oder den Stempel der Verantwortlichen von Benutzer und Anbieter im Änderungsmanagement-Dokument wirksam werden. Wenn Änderungen zu leichtfertig nur mündlich vereinbart werden können, kann es leicht unklar werden, ob Änderungen vorgenommen wurden oder nicht, was später zu großen Problemen führen kann. Daher sollte die Dokumentenverwaltung gründlich durchgeführt werden.

Allerdings kann es auch sein, dass es zu belastend ist, jedes Mal ein separates Dokument für das Änderungsmanagement vorzubereiten, und dass man flexibler reagieren möchte. In solchen Fällen könnte man überlegen, Änderungsangelegenheiten in das Protokoll der Besprechung aufzunehmen. Wie man das Protokoll einer Besprechung in der Systementwicklung führt, wird im folgenden Artikel ausführlich erklärt.

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

Zusammenfassung

In Umgebungen, in denen häufig Spezifikationsänderungen vorgenommen werden, besteht in der Tat oft das Risiko von Problemen und Streitigkeiten. Dennoch ist es in solchen flexiblen Situationen oft schwierig, realistische Maßnahmen zu ergreifen, indem man einfach nur die “Wichtigkeit des Managements” betont.

Die Frage, wie man das für das Geschäft erforderliche Tempo und die Vorbereitung auf unvorhergesehene Ereignisse in Einklang bringen kann, scheint oft unterschiedliche optimale Lösungen zu haben, abhängig von der Situation des Unternehmens und dem Inhalt des Projekts. Unter Berücksichtigung des Inhalts dieses Artikels ist es wichtig, dass jede Firma und jedes Projekt eine angemessene Vorgehensweise sucht.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Zurück Nach Oben