15
Kooperationsmodelle bei Entwicklung von Software DGRI Jahrestagung 10. Oktober 2008

Kooperationsmodelle bei Entwicklung von Software

  • Upload
    kathie

  • View
    26

  • Download
    0

Embed Size (px)

DESCRIPTION

Kooperationsmodelle bei Entwicklung von Software. DGRI Jahrestagung 10. Oktober 2008. Überblick. Es gibt keine Großprojekte, in denen voller Konsens über alle Leistungsmerkmale besteht Jedes Großprojekt setzt Zusammenwirken sowohl bei Spezifizierung als auch Ausführung voraus - PowerPoint PPT Presentation

Citation preview

Page 1: Kooperationsmodelle bei Entwicklung von Software

Kooperationsmodelle bei Entwicklung von Software

DGRI Jahrestagung

10. Oktober 2008

Page 2: Kooperationsmodelle bei Entwicklung von Software

Überblick

• Es gibt keine Großprojekte, in denen voller Konsens über alle Leistungsmerkmale besteht

• Jedes Großprojekt setzt Zusammenwirken sowohl bei Spezifizierung als auch Ausführung voraus

• Das gesetzliche Instrumentarium wird dem nicht gerecht, weil es nur „Mitwirkung“ regelt, nicht aber das Zusammenwirken

• Konsequenterweise ist geistiges Grundkonzept § 320 BGB, der kein Zusammenwirken, sondern wechselseitige Lähmung als Kern hat

• Gilt auch für § 643 BGB, der kein synallagmatisches Verhältnis zwischen Besteller und Unternehmer mit Hinblick auf die Ausführung („Risikogemeinschaft“)

• Praxis sollte sich stärker auf Vermeidung von Eskalation konzentrieren

• Einige Empfehlungen

Page 3: Kooperationsmodelle bei Entwicklung von Software

Entwicklungsverträge

• Irgendwo zwischen klassischem Forschungsauftrag und klassischem Werkvertrag

• Forschungsauftrag: kein Erfolg geschuldet

• Werkvertrag: schärfste Erfolgshaftung überhaupt

Page 4: Kooperationsmodelle bei Entwicklung von Software

Kaufvertrag und Werkvertrag

• Kaufvertrag für Standardsoftware• Werkvertrag für Individualsoftware• Konnotation:

- Standardsoftware – „as is“- Werkvertrag – wie spezifiziert

• Das gesetzliche Leitbild für Kaufvertrag und Werkvertrag sind im Grunde sehr ähnlich: Angebot, Annahme, Ablieferung, Gewährleistung

– Ausgerichtet auf Beschaffung, Verschaffung, nicht auf Herstellung– Beide stellen kein Dauerschuldverhältnis dar – Der Besteller hat Verantwortung bis zum Vertragsschluss– Dann hat der Unternehmer die alleinige Verantwortung– Nach Abnahme ist Verantwortung geteilt bis zum Ablauf der Verjährungsfrist– Besteller trägt Spezifikationsrisiko– Unternehmer trägt Ausführungsrisiko– Werkvertragsmodell– Ist auf einfache Handwerksleistung zugeschnitten – Bestellung eines

Maßanzugs

Page 5: Kooperationsmodelle bei Entwicklung von Software

Dienstvertrag, Gesellschaft, Urheberrecht

Dienstvertrag• Intensive Kooperation, aber wie zwischen Herr und Knecht• Teilung der Verantwortung (Dienst muss fehlerfrei erbracht werden) aber

wegen Verschuldenserfordernis schwierige Beweislast im Verletzungsfall• Rechtsfolge Schadenersatz, Kündigung, nicht Erfüllungsanspruch• Erhebliche Flexibilität (Kündigung und Weisungsrecht)Gesellschaftsrecht• Kooperation rechtlich nur bei echten Joint Ventures geregelt• i.d.R. nicht zwischen Kunde und Anbieter wegen „Interessenkonflikt“• Aber: „Mitunternehmer“ (Nicklisch) insbesondere bei BTO-Deal• „Build budget“• Inhaltliche Vorgaben durch Besteller, Sign offs, etc.• Materialisierung durch AnbieterUrheberrecht• Kein Kooperationsmodell• Lediglich Regelung der Rechtsfolge mit Hinblick auf IP Rechte

Page 6: Kooperationsmodelle bei Entwicklung von Software

Realität nicht Punkt (Bestellung) zu Punkt (Ablieferung)

a) Leistungsbeschreibung muss komplettiert werden – wer hat hier die Hoheit

i. Gesetzlich nicht geregelt

ii. Juristisches Paradigma: Lückenfüllung vs Ergänzung/Vertragsänderung

b) Leistungsbeschreibung muss korrigiert werden – wer trägt die Konsequenzen (Ausführungsfristen und Vergütung) – im Modell der Kunde, in Realität aber umfangreiche Prüf- und Warnpflichten - § 313 (2) BGB: Annahmen stellen sich als falsch heraus

c) Laufendes Informationsbedürfnis des Werkunternehmens

d) Laufendes Informationsbedürfnis des Bestellers (Risk management und Koordination mit eigenen Pflichten)

Page 7: Kooperationsmodelle bei Entwicklung von Software

Gesetzliche Ansätze für Kooperation

a) § 642 BGB konzipiert als Durchbrechung Elemente Dauerschuldverhältnis; aber

a) Nur Obliegenheit, keine echte Verpflichtung

b) BGH. Anders, wenn Vertragszweck gefährdet, oder vertragliche Regelung

c) Nur Entschädigungsanspruch (Stillstandskosten), b) GoA meist ausgeschlossen, c) Kündigung

b) Bei komplexen Werkverträgen wird Besteller zum „Mitunternehmer“ (Niecklisch)

Page 8: Kooperationsmodelle bei Entwicklung von Software

Gesetzliche Ansätze für Kooperation

a) § 645 BGB – Teilvergütung entsprechend gelisteter Arbeit wenn Werk aufgrund fehlender Bestellerweisungen oder Beistellungen unausführbar geworden ist

b) Von keinem zu vertretende Unmöglichkeit: § 323 BGB – Risiko voll bei Unternehmer wegen fehlender Bereicherung des Bestellers (818 Abs. 4)

c) Rechtsprechung und Literatur betonen Mitwirkungsverantwortung des Auftraggebers, verzögert sich der Erfolg mangels Mitwirkung, so kommt der Entwickler nicht in Verzug

Page 9: Kooperationsmodelle bei Entwicklung von Software

Gesetzliche Regelungsdefizite

a) Rechtsfolgen fehlerhafter Spezifikation

i. des Bestellers – Spezifikationshoheit bis zur Bestellung

ii. des Unternehmers – Ausführungshoheit nach Bestellung

1. Spezifikation wird mit Ausführung fortgeschrieben

2. Spezifikation ist teilweise Bestandteil der Ausführung

3. Lücken – Auslegung, Dissens, Füllen durch Werkunternehmer; Füllen durch Besteller De facto ein Dialog, weil nur im Dialog feststellbar ist, welcher dieser Topoi zutrifft

4. Dissens: Nichtigkeit - § 818 (4) BGB, i.e. Risiko einseitig bei Unternehmer

5. Bedeutung salvatorischer Klausel

b) Änderungen der subjektiven Anforderung an das Werk

c) Änderungen aufgrund des bei Vertragsschluss vorausgesetzten Gebrauchs

Page 10: Kooperationsmodelle bei Entwicklung von Software

Konsequenzen des gesetzlichen Modells

a) Niemand ist verantwortlich für die laufende Koordination zwischen Unternehmer und Besteller

b) Besteller erhält das bestellte Werk, das möglicherweise bei Ablieferung nutzlos ist

c) Besteller hat keinerlei Anspruch auf laufende Information über Projektfortgang

d) Unternehmer trägt Investitionsrisiko alleine

e) Unternehmer trägt insbesondere Dissensrisiko (allenfalls abgemildert durch seinen Empfängerhorizont)

f) Unternehmer stellt sich besser, wenn er sich in Kündigung flüchtet, statt selbst Ersatzvornahme vorzunehmen

Page 11: Kooperationsmodelle bei Entwicklung von Software

Diagnose

a) Absolute Starrheit, fehlen jeder Flexibilität

b) Fehlen jeden Einflusses für Besteller

c) „Dulde und Liquidiere“ – keine Ersatzvornahme oder Änderungsrechte für Unternehmer

d) Fehlen jeder Transparenz über Fortschritt, kein Zugriff auf Zwischenergebnisse

e) Absolute Geringschätzung der Zwischenergebnisse

Page 12: Kooperationsmodelle bei Entwicklung von Software

Praxisempfehlungen (I)

a) Laufendes Reporting

b) Prämienlösungen (komplementär zu Vertragsstrafen)

c) Klares Sign off von Zwischenergebnissen (versteckt dienstvertragliches Element) um Dissensrisiko aufzulösund und „alles oder nichts“

d) Vermeiden von Iterationen – i.e. jede Partei darf sich auf Sign off der anderen Partei verlassen

e) Pflicht zum Scopemangement bei der eigenen Seite (keine Berufung auf fehlende Vertretungsmacht)

f) Kündigungsrecht ex nunc für beide nach Spezifikationsphase

g) „Änderungsverfahren“ – eminent wichtig, aber letztlich oft nur eine Regelung der Vertretungsmacht

Page 13: Kooperationsmodelle bei Entwicklung von Software

Praxisempfehlungen (II)

h) „directed changes“ – Einbau dienstvertraglicher Elemente; Konsequent – Risiko des Verlus des Gewährleistungsanspruchs, vereinbarte Zeitpläne gelten nicht mehr, keine Wirtschaftlichkeitskontrolle

i) Bei Vorbehalt bzgl. Vergütung, Ausführungsfristen – kein Risiko des Rechtsverlusts durch Ausführung

j) „Töpfe“, „Budgets“ für Änderungen, Anpassungen, zweifelhafte Lösungen

k) Teilabnahmen (ohne Vorbehalt Gesamtabnahme, Integrationstest)

l) Hinweispflicht Unternehmer auf Mitwirkung und Konsequenzen (Hauptleistung aus Projektmanagement Funktion)

m) Recht auf „Ersatzvornahme“ für Unternehmer statt Stillstandskosten

n) Managementeskalation in Projekten

Page 14: Kooperationsmodelle bei Entwicklung von Software

Praxisempfehlungen (III)

o) Lückenfüllung durch Schiedsgutachter (praxisfern)

p) Lückenfüllung durch Schlichtung

q) Kündigungsmöglichkeiten statt Rücktritt bei ausbleibender Mitwirkung

r) Governance – mit Eskalationsmöglichkeiten – Drohungen mit Vorgesetzten, oft effektiv

s) Joint Venture Lösungen – nur machbar, bei gleich starken Partnern; dann aber denkbare Lösung

t) Kündigungsrechte des Anbieters? Nein

u) Hinweispflichten des Anbieters auf Mitwirkungspflichten – Konsequenz der PM-Rolle

Page 15: Kooperationsmodelle bei Entwicklung von Software

Conclusion

a) Fehlen überzeugenden gesetzlichen Modells

b) Stattdessen Furcht vor Folgen Dissens und vor „Alles oder Nichts“ zwingt zu Kompromissen

c) Evt. leicht abgemildert durch Kodifizierung der Anpassung bei Änderung der Geschäftsgrundlage (§ 313 BGB)

d) Jedenfalls Einführung Kündigungsrecht Bestellers ex nunc mit zwingendem Zugriff auf verwertbare Teile empfehlenswert

e) Bei fehlender Mitwirkung – „Unternehmer Ersatzvornahme“

f) Bindung an Entscheidungen und Kommunikation