Was ist die richtige Art, Protokolle in der Systementwicklung aus rechtlicher Sicht zu führen?

Wenn ein Unternehmen die Systementwicklung an ein anderes Unternehmen auslagert, ist es oft der Fall, dass Verträge, die mit dem Firmenstempel der Geschäftsführer abgeschlossen werden, und Anforderungsdokumente, die vom Verantwortlichen erstellt wurden, nicht immer klar definieren, was bis wann erstellt werden soll. In vielen Systementwicklungsprojekten werden täglich E-Mails und Telefonate auf Mitarbeiterebene, Meetings, die von verantwortlichen Personen organisiert werden, und Anfragen zur Spezifikationsbestätigung von zunächst unklaren Punkten, Änderungen der Spezifikationen entsprechend der sich ändernden Situation, Anfragen zur Hinzufügung von Funktionen und Anfragen zur Zusammenarbeit bei aufgetretenen Problemen durchgeführt.

Aus der Sicht der reibungslosen Durchführung der Systementwicklung und der Vorbereitung auf mögliche Streitigkeiten ist die Erstellung und Verwaltung von Dokumenten wichtig für die reibungslose Durchführung eines Systementwicklungsprojekts.

In diesem Artikel werden wir erklären, wie man Protokolle und Meeting-Materialien für Fortschrittsmeetings in der Systementwicklung aus rechtlicher Sicht aufbewahrt.

Warum Dokumentenmanagement in der Systementwicklung wichtig ist

In Systementwicklungsprojekten ist es äußerst wichtig, aus rechtlicher Sicht, Aufzeichnungen über den Inhalt von Bestätigungssitzungen, den Fortschritt und den Verlauf des Projekts zu führen. Die Gründe dafür können wie folgt zusammengefasst werden:

Um spätere Streitigkeiten zu vermeiden

Systementwicklung ist in der Regel ein Projekt, das viele Beteiligte sowohl auf der Benutzer- als auch auf der Anbieterseite einbezieht. Daher kann es zu Problemen im weiteren Verlauf des Projekts kommen, wenn es Unstimmigkeiten in der Wahrnehmung zwischen Benutzer- und Anbieterseite darüber gibt, welche Rolle jeder übernimmt und welche Verpflichtungen jeder übernimmt.

Außerdem bedeutet die Beteiligung vieler Menschen an einem Projekt, dass es oft zu Kommunikationsproblemen kommt, wie “Was jeder sagt, ist leicht unterschiedlich und es ist unklar, wer recht hat”.

Es ist sinnvoll, den Inhalt der getroffenen Vereinbarungen schriftlich festzuhalten, um sicherzustellen, dass es keine Unstimmigkeiten in der Wahrnehmung beider Parteien gibt. Darüber hinaus trägt das Zusammenfassen der Vereinbarungen in einem Dokument, das alle Beteiligten zu ihrem eigenen Zeitpunkt überprüfen können, dazu bei, die Schritte aller Beteiligten zu koordinieren.

Übrigens, die Nutzung von rechtlichem Wissen als Mittel zur Vorbeugung von Streitigkeiten im Voraus wird manchmal als präventive Rechtsarbeit bezeichnet.

Als Maßnahme für den Fall, dass später ein Streit entsteht

Wenn wir die Wichtigkeit des Dokumentenmanagements aus einer etwas anderen Perspektive als der präventiven Rechtsarbeit erklären, könnten wir auch den Aspekt der “Krisenmanagement” in Betracht ziehen, wenn wir tatsächlich einen Konfliktfall voraussetzen.

Stellen Sie sich vor, es kommt zu einem Problem und das Projekt wird unterbrochen, bevor das Endprodukt fertiggestellt ist, oder es wird klar, dass der ursprüngliche Liefertermin nicht eingehalten werden kann. In einem solchen Fall, der zu einem Gerichtsverfahren führen könnte, gilt für beide Seiten, Benutzer und Anbieter, dass sie, selbst wenn sie sagen, “es gibt eine Erklärung für das, was passiert ist”, ohne schriftliche Aufzeichnungen nicht in der Lage wären, ihre Position zu beweisen und könnten im Gerichtsverfahren benachteiligt werden.

Insbesondere bei Problemen, die durch das Nicht-Einhalten von Fristen verursacht werden, sind Fragen wie “Wann und unter welchen Umständen wurde das Problem entdeckt?”, “Wann wurde eine Anforderung zur Änderung der Spezifikationen gestellt?” und “Wie hat der Anbieter auf eine Anforderung zur Hinzufügung von Funktionen von der Benutzerseite reagiert?” oft entscheidende Punkte, die den Ausgang eines Gerichtsverfahrens beeinflussen können. Wenn es in solchen Fällen zu vielen “Ich habe es gesagt, ich habe es nicht gesagt”-Problemen kommt, wird es schwierig, eine faire Streitbeilegung zu erwarten.

Was ist besonders wichtig im Protokoll einer Systementwicklungssitzung?

Arten von Meetings in der Systementwicklung

In Systementwicklungsprojekten werden oft verschiedene Meetings geplant und durchgeführt. Dies ist nicht überraschend, wenn man bedenkt, dass viele Menschen an solchen Projekten beteiligt sind. Programmierer und Ingenieure, die die Implementierung des Programms vor Ort durchführen, halten oft regelmäßige Meetings, um den Fortschritt ihrer Arbeit zu überprüfen. Es kann auch vorkommen, dass der tatsächliche Code überprüft wird, um sicherzustellen, dass es keine Probleme mit der Wartbarkeit oder Sicherheitslücken gibt.

Neben diesen Meetings auf Arbeitsebene gibt es auch Meetings, an denen die Geschäftsführung des Unternehmens oder verantwortliche Personen mit Befugnissen teilnehmen. In solchen Fällen handelt es sich oft um Meetings, in denen die allgemeine Ausrichtung und Politik des Entwicklungsprojekts festgelegt wird. Solche Meetings auf Führungsebene, die wichtige Angelegenheiten “in der Hand” haben, werden auch als Steuerungsausschüsse bezeichnet.

Das Steuerungskomitee erfordert besondere Aufmerksamkeit

Wie bereits erwähnt, werden in der Systementwicklung je nach Position und Ziel der beteiligten Personen verschiedene Meetings geplant. Aus rechtlicher Sicht ist das wichtigste dieser Meetings das Steuerungskomitee. Im Vergleich zu Fortschritts- und Überprüfungssitzungen auf Arbeitsebene sollte die Bedeutung der Dokumentation im Steuerungskomitee, insbesondere aus Sicht der Prävention und Bewältigung von Konflikten, klar erkannt werden. Die Gründe dafür sind:

1. Aufgrund der Tatsache, dass das Steuerungskomitee ein Meeting ist, das von Personen auf Führungsebene organisiert wird, ist es oft an wichtigen Entscheidungen beteiligt und wird daher aus rechtlicher Sicht oft als wichtig angesehen, da es zeigt, wie das Verständnis von Benutzern und Anbietern ist.
2. Bei Arbeitsebene-Meetings werden die Inhalte der Meetings normalerweise in verschiedenen Design- und Spezifikationsdokumenten reflektiert, so dass es in der Praxis unwahrscheinlich ist, dass Probleme aufgrund des Fehlens von Dokumenten auftreten. (Allerdings, wenn die Dokumentation auch für diese dünn ist, wäre es notwendig, Verbesserungen zu erwägen.)

Diese Punkte können als Gründe angeführt werden.

Gerichtsentscheidungen in Bezug auf Protokolle von Lenkungsausschüssen

Im Folgenden stellen wir einen Fall vor, in dem das Protokoll eines Lenkungsausschusses als wichtiges Beweismittel in einem tatsächlichen Gerichtsverfahren behandelt wurde. Der Fall, auf den sich das unten zitierte Urteil bezieht, betrifft ein Systementwicklungsprojekt, das mitten im Prozess ins Stocken geriet, und es wurde festgestellt, dass der Anbieter seine Projektmanagementpflichten verletzt hat. Der Inhalt des Protokolls in diesem Fall, das die ursprüngliche Wahrnehmung sowohl des Anbieters als auch des Nutzers darstellt, hatte eine sehr große Bedeutung im Gerichtsverfahren.

Der Anbieter hat darauf hingewiesen, dass der Inhalt des Protokolls des Lenkungsausschusses, auf das er sich zur Bestätigung des Fortschritts der Systementwicklung stützt, von den Nutzern korrigiert wurde und daher nicht unbedingt die tatsächliche Arbeit widerspiegelt. Allerdings wurde der Lenkungsausschuss mit dem Ziel eingerichtet, Entscheidungen auf oberster Managementebene für die Systementwicklung zu treffen. Sowohl vom Anbieter als auch vom Nutzer nahmen die Verantwortlichen für die Durchführung der Systementwicklung teil, um eine Gesamtbewertung vorzunehmen, den Fortschritt und die Probleme des Arbeitsplans zu teilen und wichtige Entscheidungen zu treffen. Die wichtigsten Punkte, die dort diskutiert wurden, wurden vom Anbieter in einem Protokoll festgehalten, das bis zum Vormittag des übernächsten Arbeitstages erstellt und in der Protokolldatenbank registriert wurde, um die endgültigen Entscheidungen der Sitzung zu dokumentieren. Bei der Festlegung des Protokolls haben sowohl der Anbieter als auch der Nutzer den Inhalt und die Formulierung unter Berücksichtigung der Bedeutung der Dokumentation der Arbeit durch das Protokoll überprüft und den Inhalt festgelegt, der die tatsächliche Sitzung widerspiegelt. Insbesondere kann man sagen, dass der Anbieter, der die Systementwicklung als Geschäft betreibt, die Bedeutung und Methode der Erstellung solcher Protokolle natürlich gut kennt. Daher kann man sagen, dass es angemessen ist, das festgelegte Protokoll als etwas zu behandeln, das die tatsächliche Arbeit des Lenkungsausschusses widerspiegelt, und es ist angemessen, den Inhalt der Arbeit usw. als das zu bestätigen, was im Lenkungsausschuss an dem betreffenden Tag zusammengefasst wurde, es sei denn, es gibt besondere Umstände.

Tokyo High Court, 26. September 2013 (Heisei 25)

Es kann angenommen werden, dass die Haltung des Gerichts darin besteht, dass ein schriftliches Protokoll einer Sitzung, das von beiden Seiten, dem Anbieter und dem Nutzer, in Übereinstimmung erstellt wurde, als “Beweis” eine gewisse Vermutungskraft haben kann. Aus einer anderen Perspektive sollte man vorsichtig sein, da eine zu leichtfertige Aufzeichnung in einem Protokoll das Risiko birgt, dass sie direkt als Beweis verwendet wird.

Was genau sollte in einem Sitzungsprotokoll festgehalten werden?

Das Protokoll einer Sitzung hat eine wichtige Bedeutung, auch als Beweismittel in einem möglichen Gerichtsverfahren (und auch wenn es nicht zu einem Gerichtsverfahren kommt, für die reibungslose Fortsetzung der Verhandlungen zwischen den Parteien). Aber was genau sollte in einem Sitzungsprotokoll dokumentiert und aufgezeichnet werden? Im Folgenden werden wir dies klären.

Was sollte aus der Sicht des Anbieters im Protokoll festgehalten werden?

Der Anbieter hat als Experte für Systementwicklung eine Projektmanagementpflicht gegenüber dem Projekt. Was genau diese Pflicht beinhaltet, wird im folgenden Artikel ausführlich erläutert.

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

Vor diesem Hintergrund sind die Punkte, die der Anbieter besonders protokollieren sollte:

1. Die Tatsache, dass jeder Entwicklungsprozess abgeschlossen ist, und das Datum
2. Die Historie darüber, wie auf Anfragen von der Benutzerseite bezüglich Änderungen der Spezifikationen oder Hinzufügungen von Funktionen reagiert wurde
3. Die Maßnahmen und deren Verlauf, die ergriffen wurden, um Unterstützung zu suchen, wenn der Fortschritt der Entwicklungsarbeit aufgrund von Umständen auf der Benutzerseite ins Stocken gerät

Diese Punkte können als Beispiele genannt werden.

Zur Ergänzung des oben genannten Punktes 3. wird im folgenden Artikel erläutert, was der Anbieter in Betracht ziehen sollte, wenn der Benutzer keine Abnahme durchführt. In diesem Artikel wird erklärt, wie stark das Urteil des Gerichts davon abhängt, wie kooperativ der Anbieter bei der Durchführung der Abnahme des Benutzers war, unter Bezugnahme auf tatsächliche Urteilsbegründungen.

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

Was sollte aus der Sicht des Benutzers im Protokoll festgehalten werden?

Natürlich hat auch der Benutzer, da es sich um ein System handelt, das er intern in seinem Unternehmen verwendet, eine gewisse Pflicht zur Zusammenarbeit mit der Entwicklungsarbeit des Anbieters in der Systementwicklung. Der gesamte Inhalt dieser Pflicht wird im folgenden Artikel erläutert.

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

1. Die Historie darüber, was der Benutzer dem Anbieter mitteilen sollte, wie gewünschte Funktionen, das Aussehen der Benutzeroberfläche usw.
2. Die Historie über verschiedene Probleme, die während des Prozesses des Anbieters aufgetreten sind (zum Beispiel, wenn ein Mitglied plötzlich ausscheidet oder wenn eine Verzögerung im Entwicklungsprozess aufgrund von unzureichenden Untersuchungen auf Seiten des Anbieters und deren Ursachen auftritt)

Im Zusammenhang mit dem oben genannten Punkt 2. ist es besonders wahrscheinlich, dass unvorhergesehene Probleme auftreten, wenn die Entwicklung eines neuen Systems gleichzeitig mit der Abschaffung des alten Systems vorangetrieben wird. Bei der Übertragung von Daten aus dem alten System in das neue System treten oft Probleme auf, aber eine detaillierte Erklärung der rechtlichen Fragen, die mit solchen Problemen verbunden sind, wird im folgenden Artikel gegeben.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Zusammenfassung

Das oben Genannte dient als Leitfaden für das Führen von Protokollen in der Systementwicklung aus rechtlicher Sicht. Neben praktischen Anleitungen ist es auch wichtig, das Verständnis für die Verbindung zwischen Themen wie “Recht”, “Systementwicklung” und “Dokumentenmanagement” zu vertiefen. Gerade weil die Systementwicklung viele Menschen und Organisationen einbezieht und leicht zu umfangreichen Geschäftstransaktionen führen kann, ist die Prävention und Bewältigung von damit verbundenen Streitigkeiten wichtig. Aus der Notwendigkeit der Beweissicherung aus rechtlicher Sicht ergibt sich die große Bedeutung von “Dokumenten”, die für jedermann objektiv überprüfbar sind.

Zweifellos ist es eine große Belastung und möglicherweise nicht realistisch, alle Interaktionen und Projektverläufe vollständig zu verbalisieren. Dennoch ist es wichtig, die rechtlich relevanten Punkte zu identifizieren und diese entsprechend zu dokumentieren. Dies sollte nicht nur von Rechtsexperten, sondern von allen, die im Geschäftsleben tätig sind, weitgehend anerkannt werden.