Innovations-Chance oder Bremse? Rechtsunsicherheit aufgrund von 651 BGB Ein Plädoyer für die Neutralisierung

Größe: px

Ab Seite anzeigen:

Download "Innovations-Chance oder Bremse? Rechtsunsicherheit aufgrund von 651 BGB Ein Plädoyer für die Neutralisierung"

Karsten Kappel
vor 5 Jahren
Abrufe

1 Innovations-Chance oder Bremse? Rechtsunsicherheit aufgrund von 651 BGB Ein Plädoyer für die Neutralisierung RAin Michaela Witzel, LL.M. 5. Bayerischer IT-Rechtstag auf der Systems München

2 Überblick zu 651 BGB (1) Nach 651 BGB gilt für Werkverträge über die Herstellung beweglicher Sachen in weiten Bereichen Kaufrecht. Nur hinsichtlich der Mitwirkungsobliegenheiten verbleibt es bei den Regeln des Werkvertrages ( 651 S. 3 BGB). Dogmatisch ist 651 BGB eine Rechtsfolgenverweisung: Ein Vertrag über die Herstellung beweglicher Sachen ist kein Kaufvertrag, sondern ein Werkvertrag, der aber im Wesentlichen kaufrechtlichen Vorschriften unterliegt. Wendet man auf Verträge über die Erstellung und Einführung (Implementierung) von Individualsoftware oder Verträge über die Anpassung und Einführung (Implementierung) von Standardsoftware Kaufrecht an, gibt es keine gesetzliche Regelung die eine Abnahme vorschreibt. Seite 2

3 Überblick zu den durch 651 BGB bedingten Problemen(2) Durch die Diskussion um 651 BGB ist unklar, welche Verjährungsvorschriften ( 634 a Abs. 1 Nr. 1 oder 3 BGB) richtigerweise Anwendung finden. Konsequenterweise müsste die Ablehnung der Sachqualität zur Anwendung von 634 a Abs. Nr. 3 BGB fallen, was neben der längeren Verjährungsfrist vor allem zur Folge hat, dass der Verjährungsbeginn nicht mit Abnahme eintritt. 651 BGB steht (vermutlich) nicht zur Partei-Disposition. Die Verweisung ins Kaufrecht wird sich nicht aufheben lassen, innerhalb des Vertragstyps lassen sich Änderungen und Erweiterungen aber vorstellen. Seite 3

4 Ansätze zur Umgehung des 651 BGB Ablehnung der Sachqualität: Software ist keine Sache, daher findet 651 BGB keine Anwendung; Reduzierende, teleologische, final orientierte Interpretation des 651: Die Folgen der Anwendung des Kaufrechts führen zu unpraktikablen Ergebnissen. Deshalb sei auf den Erfolgscharakter des Vertrages bzw. den immateriellen Charakter des erfolgsorientierten Teils des Vertrages abzustellen und damit Werkvertragsrecht anzuwenden; Die vermittelnde Ansicht nimmt Differenzierungen vor und stellt auf unterschiedliche Fallgestaltungen ab. Seite 4

5 Typisches (?) Leistungsportfolio eines Software-Anbieters bei IT-Projekten: Kann 651 BGB dieses abdecken? Ermittlung und Analyse von Anforderungen des Anwenders; Dokumentation der ermittelten und analysierten Anforderungen (Erstellung des Pflichtenhefts ); Projektplanung und Projektmanagement; Realisierung der ermittelten und analysierten Anforderungen (Programmierung/Customizing/Parametrisierung); Durchführung und Prüfung von (vereinbarten) Qualitätssicherungssicherungsmaßnahmen; Organisation und Durchführung eines Change Management Verfahrens; Vorbereitung und Durchführung von Tests (einschließlich Abnahmeprüfungen); Vorbereitung und Durchführung von Schulungen; Integration des neuen Systems in die vorhandene IT-Landschaft; Fachliche und organisatorische Implementierung des Systems in die Organisation des Anwenders; Altdatenübernahme, Migration Seite 5

6 Verhältnis der Realisierungsphase zur Analysephase und Testphase 35 % des Aufwandes: Entwurf (Konzeptionierung Pflichtenheft) 20 % des Aufwandes: Programmierung und Implementierung 45 % des Aufwandes: Test Die Phasen von der IST-Analyse bis zum Design brauchen ungefähr doppelt so lange wie die Programmierung. Testen und Validieren dauern noch einmal doppelt solange. Seite 6

7 Vertragstypologie aus Projektmanagement-Sicht: (Wieczorrek/Mertens, Management von IT-Projekten, Springer 2004) Eine ausschließliche Empfehlung für Dienst- oder für Werkverträge im Rahmen von IT-Projekten kann nicht gegeben werden. Der große Vorteil von Werkverträgen liegt in der Zusicherung eines Festpreises und eines Gewährleistungszeitraums, die einem Projektleiter eine gewisse Planungssicherheit bieten. Dies wird allerdings durch einen nicht unerheblichen Sicherheitsaufschlag erkauft.voraussetzung für den Abschluss eines Werkvertrages ist in jedem Fall ein aussagekräftiges Pflichtenheft. Liegt kein oder nur ein wenig präzises Pflichtenheft vor, so ist der unterzeichnete Werkvertrag nur wenig wert und beide Vertragspartner werden an vereinbarten Konstellation nur wenig Freude haben. Stellt sich im Zuge der Umsetzung des Auftrags heraus, dass die umzusetzenden Anforderungen wesentlich umfangreicher als zunächst angenommen sind, so nimmt der Konflikt seinen Anfang. Seite 7

8 Unzureichende Abbildung eines Projekts durch das gesetzliche Modell Werkvertrag, Bartsch in Beck sches Formularbuch, Handels- und Wirtschaftsrecht Ein Projekt, bestehend aus Lieferung von Standardsoftware, Anpassung und Ergänzung dieser Software, Test und Installation sowie Schulung, wird durch das gesetzliche Modell Werkvertrag nur unzureichend abgebildet. Denn beim Werkvertrag gibt es ein versprochenes Werk, also eine Soll-Zustandsbeschreibung. Der Ist-Zustand des fertig gestellten Werkes wird dann diesem Soll-Zustand gegenübergestellt. Beim Projekt ist die Soll-Zustandsbeschreibung notwendig unvollständig. Seite 8

9 Untauglichkeit von 651 für Softwareimplementierung und entwicklung? (Müller-Hengstenberg, CR 2004, 161 ff) Die gesetzlichen Vorschriften des 651 BGB bieten kein ausgewogenes Bedingungswerk für die Implementierung bzw. Entwicklungen von Computersoftwarelösungen, da diese zu sehr auf ein Warenaustauschgeschäft ausgerichtet sind. Die relativ lange Projektdauer, der hohe Voraufwand des Software-Anbieters, die Wichtigkeit der Integration in die Kundenumgebung finden in den werkvertraglichen Regelungen der 632 a, 634 a Abs. 2, 640, 641 a BGB eine sachgerechte Berücksichtigung. Die Anwendung des Kaufrechts bei solchen IT-Entwicklungsprojekten bzw. Verträgen führt dazu, dass die Vertragspartner in der Praxis bei der Gestaltung ihrer Verträge alle fehlenden Regelungen des Werkvertragsrechts vereinbaren müssen, damit das Vertragswerk wieder ausgewogen und sachgerecht ist. Seite 9

10 Thesen für einen hilfreichen IT-Projektvertrag (1) IT-Projekte sind zu unterschiedlich, um über AGB abschließend für beide Seiten interessengerecht geregelt zu werden. Bei jedem Projektvertrag braucht es individuellen Gestaltungsspielraum. Beispielsweise können sich je nach Anwendungsgebiet einer Software unterschiedliche Schwerpunkte ergeben, die auch unterschiedliche vertragliche Gestaltung erfordern können. Ein IT-Projektvertrag sollte nicht (ausschließlich) rechtlichen Erfordernissen genügen, sondern auch ein lebbares Instrumentarium für das Projektmanagement sein. Vor allem Regelungen zu Tests, Abnahme und Mitwirkung können für ein erfolgreiches Projektmanagement notwendig sein. Seite 10

11 Typische Projektsünden Fehlende Projektstruktur; Fehlendes, unvollständiges Pflichtenheft; Fehlende Abgrenzung der Verantwortung; Unrichtiges Pflichtenheft; Fehlende Abnahmekriterien; Fehlende Mitwirkung des Auftraggebers; Fehlendes Änderungsmanagement; Fehlende Dokumentation; Seite 11

12 Thesen für einen hilfreichen IT-Projektvertrag (2) Die Leistungen des Software-Anbieters und die Mitwirkung des Anwenders sollte detailliert und genau beschrieben werden, um als Bewertungsgrundlage für eine etwaige Schlechtleistung eines Vertragspartners dienen zu können. Der Projektvertrag sollte auch bei Zuordnung der Verantwortung auf die Vertragspartner differenzieren. Es stellt sich die Frage, ob der Software- Anbieter eine (werkvertragliche) Erfolgsverantwortung für alle Leistungsbereiche eines IT-Projekts übernehmen kann. Für die Umsetzung organisatorischer Änderungen auf Seiten des Anwenders, die durch die Einführung eines neuen Systems bedingt sind, kann der Software-Anbieter keine Erfolgsverantwortung übernehmen. Seite 12

13 Notwendige Inhalte eines Projektvertrages Regelungen zur Festlegung des Vertragsgegenstands, wie z.b. zu Funktionalität und technischen Eigenschaften des zu entwickelnden/zu implementierenden Systems, zu Qualitätskriterien, aber auch zu Lieferumfang, Leistungsdaten und Nebenleistungen; Regelungen zur Handhabung von Änderungen des Leistungsumfangs; Definition des Projektverlaufs und der Projektstruktur wie Projektphasen, Termine. Zudem Regelungen zur Projektorganisation wie Projektgremien und Kommunikationswegen; Regelungen zur kaufmännischen Projektabwicklung, z.b. zu Zahlung, Bürgschaften, Versicherungen und Zinsregelung; Verantwortungsabgrenzung, Abhängigkeiten der Leistungen der Vertragspartner; Regelungen zur Eskalation bei Leistungsstörungen; Seite 13

Ähnliche Dokumente

Professionelles Projektmanagement in der Praxis

Professionelles Projektmanagement in der Praxis Veranstaltung 11 Teil 2 (30.06.2014): Vertragsmanagement (Contract Management) SS 2014 1 Vertragsmanagement Ziel des Vertragsmanagements (Contract Management):