In dem Teil „Changes Teil I“ habe ich dargelegt, dass die Unterscheidung zwischen echten und unechten Changes nur durch Auslegung gelingt. Juristen sprechen von einem sogenannten versteckten Dissens. Ein versteckter Dissens liegt vor, wenn beide Vertragsparteien dieselben Begriffe verwenden, aber unter den Begriffen unterschiedliche Dinge verstehen. Betrifft der versteckte Dissens einen wesentlichen Bestandteil des Vertrags, so ist nach juristischer Sichtweise der Vertrag überhaupt nicht zustande gekommen. Betrifft der versteckte Dissens einen nicht wesentlichen Vertragsteil, so ist im Wege der Auslegung zu versuchen, eine Anpassung des Vertrags herzustellen.
Und in der Tat wird in den wenigsten Fällen ein unechter Change dazu führen, dass der Vertrag rückabgewickelt wird. Die Rückabwicklung ist in den meisten Fällen für beide Seiten kein adäquater Weg, mit der Situation umzugehen. Eine Anpassung des Vertrags wird in der juristischen Terminologie im Wege der Auslegung und Konkretisierung bzw. Neuherstellung des Konsenses erfolgen. In den Anglizismen der Unternehmensberater und IT-Fachleute gesprochen, erfolgt die Vertragsanpassung durch Changes-Request-Procedures. Ich möchte gleich an dieser Stelle darlegen, dass Changes-Request-Procedures im Falle eines echten Changes wertvolle Hinweise über das weitere Verfahren zur Neuherstellung des Konsenses geben können. Im Falle des unechten Changes gilt dies nicht. Wenn zwei Parteien versehentlich nicht das Gleiche meinen, müssen sie sich bei der Herstellung des Konsenses vertragen. Das ist im Grunde eine banale Selbstverständlichkeit.
Echter Changes: Verursacht durch äußere Einflüsse
Die Notwendigkeit zur Herstellung eines echten Changes kann sich daraus ergeben, dass durch äußere Umstände eine Anpassung des einmal hergestellten Konsenses erforderlich wird. So können sich technische Standards ändern, wie z.B. die Systemumgebung. Auch tatsächliche Bedingungen, wie z.B. Gesetze können sich so ändern, dass eine Anpassung der Leistung erforderlich wird. Auch hier gibt es keine Patentlösung, die das Gesetz vorsieht. Die ehemals dem § 242 BGB (Treu und Glauben) unterfallende Fallgruppe des „Wegfalls der Vertragsgrundlage“, die nun im § 313 BGB geregelt ist, sieht vor, dass der ITler einen Anspruche nach § 313 Abs. 1 und 2 BGB auf Anpassung des Vertrags hat. Wie die Anpassung des Vertrags inhaltlich auszusehen hat, sagt der § 313 BGB natürlich nicht. Und so werden auch hier alle Regelungen nur vertraglich zu finden sein.
Changes-Request-Procedures
Aus juristischer Sicht kann man nun viele Regelungen darüber aufstellen, wie ein Changes zu finden ist. Letztlich ist das Change-Request aber nicht so besonders, dass diejenigen Regelungen, die für andere Situationen gelten, nicht auch auf die Welt der IT Anwendungen finden könnten. Die Frage, wie Verträge aussehen, in denen Changes-Request-Procedures enthalten sind, kann aus juristischer Sichtweise nur so aussehen, dass a) das Verfahren geregelt wird, wer was wann wie einen Change herstellt und b) was geschieht, wenn die Parteien es nicht schaffen, innerhalb einer bestimmten Zeitspanne oder bis zum Eintritt eines bestimmten Ereignisses eines Changes herzustellen. Diese grundsätzliche Herangehensweise findet sich z.B. im Gesellschaftsrecht. Hier können Juristen nicht den Inhalt eines Beschlusses vorwegnehmen und dazu fehlt ihnen die prophetische Gabe. Sie können nur darstellen, mit welchen formalen Mitteln ein Beschluss herzustellen ist und Wege aufzeigen, wie man sich gütlich trennen kann, wenn das Verfahren zur Herstellung eines Beschlusses scheitert.
Verpflichtung zur Durchführung eines Changes
Die Verpflichtung des IT-Unternehmens zur Durchführung eines Changes muss vertraglich konstituiert werden. Der Kunde hat nicht per se einen Anspruch darauf, dass ein ursprünglich vereinbarter Vertragsinhalt geändert wird. Das Gesetz geht von dem Grundsatz des „pacta sunt servanda“ also des Grundsatzes aus, dass Verträge mit dem ursprünglich abgeschlossenen Inhalt auch durchgeführt werden müssen. Nach dem Gesetz steht dem IT-Unternehmen also ein Ablehnungsrecht zu. Eine Durchbrechung des grundsätzlich bestehenden Ablehnungsrechts besteht nur in den Fällen, in denen wegen Treu und Glauben das IT-Unternehmen verpflichtet ist, einen Changes zu akzeptieren, so z.B. wegen einer nichtvorhersehbaren Änderung der Systemumgebung, technische Anforderung oder gesetzliche Anforderung, etc..
Fix-Preis-Projekte sind auch deswegen gefährlich, weil solche unvorhersehbaren Änderungen zu Lasten des IT-Unternehmens gehen. Eine Anpassung des Vertragsinhaltes, die sich durch äußere Umstände ergibt, beinhaltet auch immer das Risiko, dass das IT-Unternehmen den Change selbst bezahlen muss.
Echter Change: Willkürliche Abänderung
Möchte der Kunde den ursprünglichen Vertragsinhalt ändern, ohne dass sich hierfür eine Notwendigkeit durch von außen stammende Faktoren ergibt, handelt es sich um einen echten Change. In den Vertragsregelungen großer Unternehmen finden sich hier Kostenfallen für die IT-Unternehmen: Es wird angegeben, dass das IT-Unternehmen jederzeit die Verpflichtung hätte, Change-Verlangen des Kunden zu prüfen und basierend auf diesen Change verlangen, ein Angebot abzugeben. Falls der Vertrag, der zwischen den Parteien abgeschlossen wurde, als Werkvertrag zu qualifizieren ist, ergibt sich für das IT-Unternehmen immer die Verpflichtung, die Planung insgesamt noch einmal auf Konsistenz und Systemkompatibilität hin zu überprüfen. Diese Überprüfung kostet Geld. Es kann also nicht sein, dass der Kunde eine wahllose Anzahl von Change-Request an den ITler heranträgt und der ITler verpflichtet ist, auf eigene Kosten jeden Change-Request zu überprüfen. Hier sind vertragliche Regelungen einzubauen.
Abweichung zwischen dem gehegten Vertrag und dem Vertragstext
Ein ewiges Ärgernis für den Juristen sind die Fallkonstellationen – und die gibt es praktisch in jedem Projekt – in dem Changes auf andere Art Weise vereinbar werden, als dies im Vertragstext vorgesehen. Trotz des Zeitdruckes und des Wunsches des IT-Unternehmens, möglichst viele Changes aufzunehmen, damit der Kunde zufriedengestellt wird, muss zumindest im Rahmen des Werkvertragsrechts immer darauf geachtet werden, dass eine Konsistenz der Planung hergestellt wird. Genau aus diesem Grunde besagen vernünftige Change-Request-Procedures, dass jeder Change-Request des Kunden zunächst einmal geprüft und inhaltlich bewertet werden muss. Es macht genau aus diesem Grunde auch überhaupt keinen Sinn, wenn jeder Change des Kunden direkt beim Programmierer, bzw. Projektmanager landet und dann ohne Bewertung realisiert wird oder werden soll. Scheitert das Projekt an solchen Fällen, geschieht dies auf Verantwortung des IT-Unternehmens.
