Niemand streitet gerne, denn "Recht haben" heißt noch lange nicht "Recht bekommen". Dies gilt vor allem bei streitigen Verfahren mit IT-Bezug, unabhängig davon, ob dieses vor einem ordentlichen Gericht, einem Schiedsgericht oder einer Schlichtungsstelle erfolgt. Denn besonders bei streitigen Verfahren mit IT-Bezug stellen sich für die Parteien diverse Herausforderungen: So haben die Parteien, entsprechend ihrer Beweislast, oftmals langjährige und komplexe Sachverhalte intensiv aufzuarbeiten und verständlich vorzutragen, an denen nicht selten mehrere Fachabteilungen beteiligt sind. Zugleich fühlen sich vor allem die staatlichen Gerichte, die regelmäßig über keine derart speziellen technischen und rechtlichen Kenntnisse im IT-Bereich verfügen, überfordert und scheuen eine Entscheidung nach Aktenlage. Das oft für beide Parteien unbefriedigende Ergebnis: Ein umfangreiches Sachverständigengutachten wird eingeholt, welches den Rechtsstreit entscheidet.
Foto: Smokedsalmon - shutterstock.com
Ein solches Ergebnis spiegelt selten die Interessen beider Parteien wider. Deshalb gilt es, solche Auseinandersetzungen vor allem bei langjährigen Softwareprojekten zu verhindern. Einfache, klare Spielregeln helfen bereits im Projekt, Streitigkeiten schnell zu beenden und so langjährige und kostenspielige Gerichtsverfahren zu vermeiden oder Gerichtsverfahren zu vereinfachen. Dies spart nicht nur Kosten, sondern auch Zeit.
1. Klartext - Was ist die Leistung?
Regelmäßig stellt sich erst während der mündlichen Verhandlung heraus, dass Auftraggeber und Auftragnehmer unterschiedliche Vorstellungen über die geschuldete Leistung hatten. Es ist deshalb unerlässlich, dass sich beide Parteien einig über die zu erbringenden Leistungen sind. Dies gilt unabhängig davon, ob die Software klassisch nach dem Wasserfallmodell erstellt oder agil programmiert wird.
Beim Wasserfallmodell handelt es sich um ein lineares Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in einzelnen, festen Phasen organisiert wird. Das heißt, die Software wird auf Basis der Anforderungen des Auftraggebers zuerst vom Auftragnehmer konzipiert und im Anschluss programmiert. Dem Auftraggeber ist hierbei dringend anzuraten, seine Erwartungen an die Software zu Beginn des Softwareprojektes in einem sogenannten Lastenheft zu dokumentieren, so dass der Auftragnehmer, bestenfalls gemeinsam mit dem Auftraggeber, auf dieser Basis das sogenannte Pflichtenheft erstellen kann, welches die geschuldeten Funktionen der Software beschreibt.
Foto: imagedb.com - shutterstock.com
Anders ist die Vorgehensweise bei der agilen Programmierung. Hier wird die Leistung iterativ, also schrittweise, bestimmt und fortentwickelt. Dennoch, auch in diesem Fall sollte seitens der Parteien Einigkeit darüber herrschen, was die vom Auftragnehmer konkret zu erbringende Leistung für die vom Auftraggeber zu zahlende Vergütung sein soll. Hierfür ist es in beiden Fällen erforderlich, dass der Auftraggeber in einem ersten Schritt seine Anforderungen an die Software identifiziert. Dies bedingt die rechtzeitige Einbindung aller für das Softwareprojekt zuständigen Fachabteilungen. Hierzu gehören regelmäßig die IT-, die Rechts- und die Einkaufsabteilung.
2. Gründlichkeit bei der Vertragserstellung
Unklare Verträgen sind einer der häufigsten Ursachen für Rechtsstreitigkeiten. Es gilt daher bereits bei Vertragserstellung an einen potentiellen Streitfall zu denken und den Vertrag auf Eindeutigkeit und Plausibilität zu prüfen.
Das bedeutet vor allem, dass die Parteien sowohl im Vertragsdokument an sich als auch in den zugehörigen Anlagen einheitliche Begriffe für die Leistungen verwenden und die Leistungen konkret und detailliert beschreiben. Von der Verwendung generischer Begriffe und Umschreibungen ist strikt abzuraten. Diese bergen nämlich nicht nur großen Auslegungsspielraum, sondern auch großes Konfliktpotential. Die Kontrollfrage lautet also: Würde ein Dritter, der nicht bei der Vertragshandlung zugegen war, den Vertrag genauso verstehen?
3. Change Request - die sich wandelnde Leistung
Herrscht Einigkeit über die Leistung, ist ein entscheidender Schritt getan, um Rechtsstreitigkeiten zu verhindern. Doch dies allein genügt nicht. Denn vor allem bei langjährigen Softwareprojekten ist es nicht unüblich, dass sich der Leistungsumfang von Vertragsschluss bis zur Erklärung der Abnahme ändert, zum Beispiel indem zusätzliche Funktionen oder neue Nachfolge-Applikationen vom Auftraggeber nachgefragt oder proaktiv vom Auftragnehmer angeboten werden.
Das Problem: Nicht selten werden bis an die hundert "kleinere Zusatzleistungen" schlicht per E-Mail oder mündlich von verschiedenen Ansprechpartnern des Auftraggebers beauftragt. Ein einheitlicher Prozess zur Beauftragung dieser Leistungsänderungen, der sogenannte Change Request, fehlt. Dies hat zur Folge, dass für beide Parteien zum Zeitpunkt der Abnahme nicht mehr nachvollziehbar ist, welche Change Requests beauftragt und somit Gegenstand der Abnahme sind oder erst nach Abnahme der Software zu erbringen sind.
Foto: arka38 - shutterstock.com
Den Parteien ist deshalb dringend anzuraten, Regelungen zum Change-Request-Verfahren in den Vertrag aufzunehmen, die eine Übersichtlichkeit sicherstellen und nur wenige Ansprechpartner zur Beauftragung von Change Requests berechtigen. Zudem sollte der Auftragnehmer zu jedem Change Request ein Angebot erstellen, welches darlegt, wie sich die Umsetzung des Change Request auf die Gesamtleistung, das heißt insbesondere auf den Zeitplan, die Abnahme oder die Vergütung auswirkt. Doch Achtung: Die Aufnahme einer Change-Request-Regelung im Vertrag allein genügt nicht, sie muss auch gelebt werden!
Dieser Umgang mit Leistungsänderungen spiegelt erst einmal nur die Vorgehensweise bei klassischen Softwareprojekten (Wasserfallmodell) wider. Denn bei der agilen Programmierung entsteht die Software "im Lauf", so dass bis zur Abnahme die Leistung "konkretisiert" und nicht "geändert" wird. Dennoch empfiehlt es sich auch hier, vertraglich festzuhalten, ob nicht zumindest Change-Request-Regelungen für sogenannte "Mindestinhalte" gelten sollten, da diese grundlegende Auswirkungen auf die Gesamtstruktur der zu erstellenden Software haben. Ferner wäre daran zu denken, bereits zum Zeitpunkt des Vertragsschlusses zu entscheiden, ob dem Auftraggeber vielmehr die Einhaltung eines fixen Termins mit "weniger" Leistung oder die Umsetzung jeder gewünschten Leistung zu einem "flexiblen", also zu einem entsprechend verschiebbaren, Termin wichtiger ist. Denn nur so kann sichergestellt werden, dass auch im agilen Softwareprojekt beide Parteien ein gemeinsames Ziel verfolgen.
4. Eskalationsmechanismen zur außergerichtlichen Lösung
Insbesondere bei größeren und komplexeren Softwareprojekten ist es den Parteien anzuraten, einen Eskalationsmechanismus vorsehen, um einen Streitfall möglichst unter den Parteien zu lösen.
Zur Lösung eines Streites sind daher sogenannte Eskalationsstufen von Arbeitsebene bis zur Projektleitung vorzusehen, innerhalb deren festgelegte Mitarbeiter der Auftragnehmer- und Auftraggeberseite eine Lösung des Rechtsstreits finden sollen. So kann erreicht werden, dass vor allem auch die jeweils sachlich und fachlich Zuständigen sich des Problems annehmen und dies im Sinne der Parteien lösen.
Fazit
Schon die Einhaltung dieser - einfachen - Spielregeln führt dazu, dass aufkommende Streitigkeiten bereits während des Softwareprojekts und unter den Parteien ressourcenschonend und ohne großen zeitlichen und kostspieligen Aufwand gelöst werden können. Anderenfalls, sollte es dennoch zu einem streitigen Verfahren kommen, sind bereits wesentliche Voraussetzungen für eine erfolgreiche Prozessführung gesetzt. Denn kann die Leistung anhand der Vertragsdokumente eindeutig bestimmt werden, werden auch die Richter schnell zu einer eindeutigen Entscheidung kommen. (haf)