IT-Projektverträge: Gestaltung, Verhandlungen, Durchführung

Transkript

1 Cebit - Mittelstandspodium 2006 "Rechtssicherheit für den Mittelstand" IT-Projektverträge: Gestaltung, Verhandlungen, Durchführung Rechtsanwalt Prof. Dr. Jochen Schneider, München

2 1. "Projektsünden" 2. Vergleich Soll/Ist der Projektschritte 3. "Streichkonzert" 4. Umfang der Änderungen beim Kunden 5. Migration, Pflege 6. Typische Vertragsthemen 2

3 1. Projektsünden (1) Bei der Gestaltung und dem Aushandeln von Verträgen ist das Ziel, die typischen Projektsünden zu vermeiden. Solche sind - u.a. -: 1.1 Es fehlt eine eindeutige und klare Strukturierung und Zuordnung hinsichtlich - Vorgehen und - Vertragstyp. Gründe sind u.a., dass viele Auftraggeber zu viel wollen und strukturell Verschiedenes mischen (z.b. Werkvertrag und Steuerung durch AG). Oft ist aber auch einfach schlicht nur mangelnde Sorgfalt. 3

4 1. Projektsünden" (2) 1.2 Es fehlt eine klare fachliche Leistungsvorgabe aus Auftraggebersicht und 1.3 der Auftragnehmer macht sich ans Werk, ohne vorher eine klare technische Leistungsbeschreibung aus den fachlichen Vorgaben zu entwickeln (als ersten Schritt der Umsetzung). (s. Schema zu 1.3) 1.4 Es fehlt eine klare Strukturierung der Phasen mit Zuordnung der Verantwortlichkeiten bei den einzelnen Schritten/Stufen. 4

5 1. Projektsünden" (3) 1.5 Es besteht eine Diskrepanz zwischen - dem Angebot des Auftragnehmers und - den Wünschen des Auftraggebers, was später zu umfangreichen "Änderungen" führt. Dabei halten sich die beiden Vertragspartner oft nicht an das Änderungsverfahren, selbst wenn ein solches vereinbart ist. Es ist unklar, - wer für Verzögerungen verantwortlich ist, - wer für den Aufwand aufzukommen hat. 5

6 1. Projektsünden" (4) 1.6 Es ist nicht klar, wie getestet werden soll, welche Kriterien dabei angelegt werden welche Vorleistungen von wem dafür zu erbringen sind, insbesondere hinsichtlich Echtdaten, Testumgebung u.ä. und wie je nach Testergebnis weiter zu verfahren ist 6

7 1. Projektsünden" (5) 1.7 Die Mitwirkung des Kunden ist nicht (genau) festgelegt, insbesondere nicht in dem Aktivitäten- und Fristenplan. 1.8 Viele Verträge haben keine klare Regelung hinsichtlich des sogenannten Änderungsmanagements einschließlich der Frage, wer Änderungen vereinbaren darf und wie sie zu vergüten sind (unter Berücksichtigung von Minderungen). 7

8 1. Projektsünden" (6) 1.9 Es fehlen klare Regelungen und eine klare Handhabung hinsichtlich - Dokumentation, - Quellcode und - Rechtseinräumung. Bei Dokumentation geht es v.a. um die Ausgestaltung, um die Arten der Dokumentation und die Fälligkeit (s. Schema zu 1.9). 8

9 1.10 Schema zu 1.3 Projektphasen klassisch (1) (angelehnt an BVB) PLANUNG SOLL IST 1. Idee v 2. Vorstudie v 3. Ist-Analyse f 4. Schwachstellen-Analyse f 5. Soll-Analyse f 6. Grob-Konzept 6.1 fachlich v 6.2 technisch f 7. Fein-Konzept 7.1 fachliche Feinspezifikation ( Pflichtenheft ) f <!Angebot und Streichkonzert > 9

10 1.10 Schema zu 1.3 Projektphasen klassisch (2) REALISIERUNG 7.2 technische Feinspezifikation f 8. Realisierung, Umsetzung Datenflussplan, Programmablaufplan 9. Codierung Start AN 10. Compilierung 11. Test von Modulen 12. Integrationstest, Performancetests Implementierung 14. Installation, >>>> 10

11 1.10 Schema zu 1.3 Projektphasen klassisch (3) 15. Nachweis der Abnahmefähigkeit 16. Einweisung/Schulung Evtl. mitgeschuldet: Datenübernahme 17. Abnahme 17.1 Auf Testsystem? 17.2 Auf Produktivsystem? 18. Betrieb 19. Pflege 11

12 1.11 Schema Dokumentationen Arten der Dokumentation - Anwenderdokumentation nur diese ist v. BGH behandelt worden! - Installationsbeschreibung - Quellcode mit Programmbeschreibung + Kommentierung - Beschreibung der Entwicklungsumgebung, evtl. - Entwicklungsumgebung selbst - Die bei Generierung/Kompilierung entstandenen Ergebnisse sowohl in Text als auch in elektronischer Form - Die bei Tests entstandenen Ergebnisse - Die bei Anpassung/Einstellung entstandenen Zustände (Befund) - Geschäftsmodell bzw. Datenreferenzen, Datenmodell - Wartungs- oder Pflege-Dokumentation, - Administrator-Anweisungen - Betriebs-Konzept. 12

13 2. Vorschläge für Vertragsgestaltung und Verhandlung (1) 2.1 Die Vertragsgestaltung wird versuchen, Projekt-sünden wie in Ziff. 1. zu vermeiden. Dennoch streiten sich Verhandlungspartner häufig mehr um die Haftungsklausel als um die "Essentials". Sie berücksichtigen nicht, dass eine mangelnde Festlegung des Leistungsgegenstandes und des gesamten Pflichtenprogramms zu Lasten beider Parteien, zumindest wirtschaftlich, geht: - Der Kunde erhält nicht das, was er eigentlich will. - Der Auftragnehmer erhält evtl. nicht die Vergütung für das, was er geleistet hat. 13

14 2. Vorschläge für Vertragsgestaltung und Verhandlung (2) Die BGH-Rechtsprechung zum mittleren Ausführungsstandard bei fehlendem "Pflichtenheft" ist insoweit nicht hilfreich, als dann zwar der Prozess entschieden werden kann, aber der Auftraggeber immer noch nicht das hat, was er will. Dieser will oft etwas, was sehr auf seine Belange zugeschnitten ist. Dann soll er es auch artikulieren, zumindest, - was er erwartet, - was seine Ziele sind (Geschäftsgrundlage, subj. Mangelbegriff). Der Auftragnehmer hat keine genuine Erkundungspflicht (str., s. v.a. OLG Köln, , CR 1998, 459). 14

15 2. Vorschläge für Vertragsgestaltung und Verhandlung (3) 2.2 Häufig gehen die Vorstellungen der beiden Parteien hinsichtlich des Pflichtenhefts auseinander. Vieles wird von den Auftragnehmern auf die Phasen nach Vertragsschluss verlegt. Dabei wird übersehen, dass nach Vertragsschluss häufig - Zeit, - Kapazitäten und - Einigungswille/Motivation fehlen, um noch - die Leistungsvorgaben zu präzisieren und - die Unterlagen zu erstellen. 15

16 2. Vorschläge für die Vertragsgestaltung und Verhandlung (4) Infolge dessen wäre eine der wichtigsten Aufgaben beim Projekt, genaue Differenzierung vorzunehmen und Aufgaben zuzuweisen hinsichtlich - fachliche Grob-Spezifikation (seitens des Kunden) - fachliche Fein-Spezifikation (mit Unterstützung des Auftragnehmers, evtl. zugleich als Beratungsprojekt im Projektion auf die evtl. zu beschaffende Standardsoftware, wenn diese anzupassen ist) - technische Grob-Spezifikation einschließlich Infrastruktur - technische Fein-Spezifikation (Pflichtenheft im technischen Sinne) 16

17 2. Vorschläge für Vertragsgestaltung und Verhandlung (5) 2.3 Durch eine Änderung des BGB, 651, im Rahmen der Schuldrechtsmodernisierung ist unklar, wie die vertrags-typologische Einordnung vorzunehmen ist. Es multiplizieren sich die Probleme: >>> 17

18 2. Vorschläge für Vertragsgestaltung und Verhandlung (6) - Probleme a) Der Auftraggeber stellt sich Werkvertrag vor und besteht seinerseits auf der Abnahme bzw. dieser Institution. b) Der Auftragnehmer stellt sich vor, er unterstützt nur den Auftraggeber und denkt an Dienstvertrag. c) Selbst wenn der Vertrag als Werkvertrag zu qualifizieren wäre - was die Gerichte bei Softwareerstellung bzw. Projekten überwiegend annehmen - kann es sein, dass er nach Kaufrecht zu beurteilen ist. d) Dienstvertrag ohne individuelle Ausgestaltung der Folgen von Leistungsstörungen ist für den AN sehr gefährlich! >>> 18

19 2. Vorschläge für Vertragsgestaltung und Verhandlung (7) - Probleme Infolge dessen kommt der Leistungsbeschreibung überragende Bedeutung zu, wenn evtl. die Abnahme als Institution entfällt. Man kann sie allerdings individualvertraglich vereinbaren. 19

20 2. Vorschläge für Vertragsgestaltung und Verhandlung (8) 2.4 Parallel zur Spezifikation braucht es in abgestuften Detaillierungsgraden eine Art Übersetzung in Form einer prozessorientierten Darstellung, also einen ggf. noch zu verfeinernden Aktivitäten- und Fristenplan. Die Hoheit über diesen Plan, insbesondere über die Ausgestaltung, und das Fortschreibungs-Verfahren im Laufe des Projekts sollten genau festgelegt werden. 20

21 2. Vorschläge für Vertragsgestaltung und Verhandlung (9) 2.5 Projektverantwortung und Projektleitung sollten synchron laufen. Soll der Auftragnehmer die Projekt-Verantwortung übernehmen, muss er die Projektleitung stellen, selbst wenn dies nicht explizit vereinbart ist. Aus der Zuweisung der Projektleitung kann man auf die Projektverantwortung zurückschließen (sehr gefährlich). Eine gemeinsame Projektleitung (Lenkungsausschuss) deutet auf Kooperation,nicht Werkvertrag und Übernahme der Projektverantwortung durch AN. Bei Koop ist die Frage besonders schwierig zu lösen, wem welche Rechte an der Software zustehen, wenn dies nicht ausdrücklich geregelt ist. 21

22 2. Vorschläge für Vertragsgestaltung und Verhandlung (10) 2.6 Einerseits muss das Projekt selbst genau dokumentiert werden, um z.b. eine Soll-/Ist-Kalkulation, nicht zuletzt im Falle des Scheiterns bzw. des Abbruchs, vornehmen zu können (auch für 649 BGB). Andererseits sind eine Reihe von Dokumentationen die Endprodukte der Leistungen aus dem Projekt. Diese Dokumentationen sollten genau beschrieben sein (vielleicht als Muster dem Vertrag in der Anlage beigefügt sein). (s. Schema zu 1.9). 22

23 2. Vorschläge für Vertragsgestaltung und Verhandlung (11) 2.7 Aus Sicht des Auftraggebers wird zu empfehlen sein, dass eine Art Dreiklang hergestellt wird zwischen - Leistungsgegenstand - Umfang der Rechtseinräumung i.v.m. Dokumentation und Quellcode und - Vergütungsregelung. 23

24 2. Vorschläge für Vertragsgestaltung und Verhandlung (12) Zur projektsynchronen Absicherung kann es sich empfehlen, einerseits Vorauszahlungen abzusichern (z.b. durch Bürgschaften), andererseits den Quellcode bereits zu übergeben bzw. "auszusondern". Hierzu bietet sich die Hinterlegung bei einem Escrow-Agenten mit entsprechender Verfügung und evtl. gesonderter Honorierung im Falle der Übergabe (wie BGH ) an. 24

25 2. Vorschläge für Vertragsgestaltung und Verhandlung (13) 2.8 Das "Abnahmeverfahren" wäre im Detail zu regeln (zu den Themenfeldern s. Bartsch, CR 2006, 7). Hier bietet es sich an, eine Staffelung, aber auch eine handhabbare Einteilung vorzunehmen, etwa jeweils AN >>> AG mit Unterstützung AN und Nachbesserung >>> AG: - Module/Funktionen einzeln zu testen - Komplexe, die bereits selbst ausgetestet sind, zusammen zu testen - zunächst beim Auftragnehmer, dann beim Auftraggeber zu testen und - schließlich ein Gesamt-Integrationstest und dann - ein Gesamtperformancetest vorzunehmen, - Produktivsetzung. 25

26 2. Vorschläge für Vertragsgestaltung und Verhandlung (14) Während genau zu bestimmender Frist (frozen zone) dürften bestimmte Arten von Fehlern (sogenannte A- und B-Fehler bzw. nicht beseitigte C-Fehler in größerer Zahl) nicht auftreten. Wenn sie doch auftreten, wäre das Verfahren bis zu einer begrenzten Zahl von Versuchen zu wiederholen. Im Falle der Abnahme durch Tests im Rahmen des Produktivbetriebs sollte klargestellt sein, wer für evtl. Folgen von Datenverlusten u.ä. bei Auftreten von Mängeln während dieser Phase verantwortlich ist. Vor Abnahme wird der AN darauf hinweisen, dass es sich noch um den Abnahmetest handelt (auch wenn schon produktiv gesetzt wurde). 26

27 2. Vorschläge für die Vertragsgestaltung und Verhandlung (15) 2.9 Bei AGB, die eine der beiden Vertragspartner der anderen stellt, fragt man sich häufig als Betroffener, dem die AGB gestellt werden, was besser ist: - Die häufig unwirksamen bzw. unbrauchbaren AGB stehen lassen und darauf vertrauen, dass sie nicht benötigt werden bzw. unwirksam sind oder - zu verhandeln. Verhandlungen machen allerdings nur Sinn, wenn dadurch etwas besseres erreicht wird, also dann gilt, wenn die AGB unwirksam sind. Das Verhandlungsergebnis müsste also wesentlich besser sein als das Gesetz, sonst lohnt sich der Aufwand nicht. 27

28 2. Vorschläge für Vertragsgestaltung und Verhandlung (16) 2.10 In diesem Zusammenhang sind einige Grundmissverständnisse auch auf Auftragnehmerseite oft "tödlich", weil sich der Auftragnehmer in der Folge falsch verhält: - Der Auftragnehmer denkt, ihm müsse eine Frist mit Ablehnungsandrohung gesetzt werden, bevor der Kunde zu Schadensersatzansprüche schreiten kann (ist entfallen, kann individuell vereinbart werden), - der Auftragnehmer glaubt, der Kunde müsse die Dokumentation erstellen, - der Auftragnehmer denkt, dass die Qualität der übernommenen Daten nur so gut sein kann, wie das Ausgangsmaterial und er für schlechte Ausgangsdaten nicht haftet. 28

29 2. Vorschläge für die Vertragsgestaltung und Verhandlung (17) Häufig sind aber die Qualitätsprobleme nicht deutlich danach unterscheidbar, ob sie von schlechten Datenmaterial oder schlechter Umsetzung herrühren. Infolge dessen wäre genau zu klären, wer für was bei der Migration und wann zuständig ist. - Pflege, sei (voll) vergütungspflichtig ab Ablieferung der Standardsoftware - Versicherbarkeit (sei nicht gegeben) - Gemeinsame Projektgremien (seien hilfreich) 29

30 3. "Streichkonzert (1) 3.1 Die typische Grob-Phaseneinteilung wäre die in - Planung und - Realisierung. Wie schon beim Vergleich Soll-/Ist-Phasen (s. Schema zu 1.3) gezeigt, vernachlässigen oft beide Vertragspartner die Planungsphase und sogar einleitende Phasen der Realisierung. Dies geht im wesentlichen bei Werkverträgen zu Las-ten des Auftragnehmers, weil er trotzdem einen Erfolg schuldet. 30

31 3."Streichkonzert (2) 3.2 Bei ausgefeilten Projektverträgen wird es sich empfehlen, nicht nur die Zweiteilung genau zu beachten, sondern zwischen die beiden Phasen noch eine Phase zu schalten, die salopp mit "Streichkonzert" bezeichnet wird. 1. Planung >> 2. Streichkonzert >> 3. Realisierung Sinn und Zweck ist folgender: -Ein Festpreis ist vor Ende der Planung schwer kalkulierbar. - Viele Auftraggeber misstrauen einem erst auf die Planungsphase folgenden Angebot des Auftraggebers hinsichtlich der Höhe. Sie sehen sich dann abhängig, nehmen an, dass der Auftragnehmer sich bereits in der Situation sieht, dass nur noch er die zweiten Teil des Projekts ausführen könnte und infolge dessen zu hohe Preise verlangen kann. >>> 31

32 3."Streichkonzert (3) 3.3 Dem kann durch eine klare Vorgehensweise und vorherige Vereinbarung weitgehend begegnet werden: - Schon in der Planungsphase legt der Auftragnehmer seine Kalkulation jeweils (je Schritt) offen. - Die Planungsphase endet mit einem Ergebnis, das alle Wünsche des Auftraggebers abdeckt. - Diese Soll-Vorgabe Entwurf - kalkuliert der AN. >>> 32

33 3."Streichkonzert (4) - Aufgrund der Transparenz der Kalkulation ist es dem Auftraggeber möglich, festzustellen, welche Wünsche seinerseits wie viel kosten. - Eine Faustregel besagt: das Streichen von ca. 10 % von Forderungen spart ca. 30 % der Projektkosten ein. - Infolge dessen empfiehlt es sich, im Anschluss an die Planungsphase nicht nur das Angebot des AN mit der transparenten Kalkulation einzufordern, sondern auch gemeinsam das "Streichkonzert" durchzuführen. Eng damit verbunden ist ein Kardinalproblem vieler Projektverträge, nämlich ein absolutes Defizit. 33

34 4. Einzelpunkt Defizite: Umfang der Änderungen beim Kunden (1) Nur mühsam oder evtl. gar nicht lässt sich dem sogenannten Pflichtenheft entnehmen, bis zu welchem Grad der Auftraggeber ggf. bereit ist, seine Organisation der vorhandenen Software (die an seine Belange angepasst werden soll) seinerseits anzupassen. Diese wechselseitige Annäherungsbewegung wird im Pflichtenheft unzureichend oder gar nicht beschrieben. 34

35 4. Einzelpunkt Defizite: Umfang der Änderungen beim Kunden (2) Der Auftragnehmer sollte darauf bestehen, dass auch und gerade ein mittelständischer Kunde deutlich macht, welche Teile der Geschäftsprozesse bzw. welche Geschäftsprozesse unabweisbar so gestaltet sein müssen und bei welchen Teilen sich der Auftraggeber anpassen kann und wird. Zu den angedeuteten Einsparungspotentialen bei Projekten (und dem Ausräumen von Hindernissen) gehört auch, Art und Umfang der Anpassung der Organisation des Kunden an die Software etwa im Aktivitäten- und Fristenplan festzulegen. Die Abdeckung dieses Komplexes ist im Gesetz äußerst unzureichend. Die org. Änderungen beim AG als dessen Mitwirkungspflicht einzufordern und durchzusetzen, fällt häufig schwer. 35

36 4. Einzelpunkt Defizite: Umfang der Änderungen beim Kunden (3) Die Anbieter verschleiern häufig auch die Notwendigkeit solcher Festlegungen. Typisch dürfte die Entscheidung des OLG Köln sein: "Verspricht ein Unternehmer, dass in seinen einzelnen Produktscheinen angebotene Soft- und Hardware die gesamte für den Betrieb des Bestellers erforderliche Anwendersoftware enthalte, so schuldet er aufgrund des mit der Unterzeichnung dieser Produktscheine geschlossenen Vertrages eine Gesamtlösung und kann sich nicht darauf berufen, der Besteller habe zunächst als Basislösung lediglich die in den einzelnen Produktscheinen aufgeführte Hard- und Software bestellt und für etwaige Ergänzungen hätte dieser zusätzliche Sondersoftware erwerben müssen." (OLG Köln vom , CR 2003, 246) 36

37 4. Einzelpunkt Defizite: Umfang der Änderungen beim Kunden (4) Hinsichtlich der Durchführung von Verhandlungen und von Projekten wird es sich dringend empfehlen, die Ausgangsposition der beiden Parteien (beim Auftragnehmer der Stand der Standardsoftware, beim Auftraggeber dessen Organisation) genau zu beschreiben. Häufig findet sich aber in den Präsentationen der Auftragnehmer nur der Hinweis, dass die Software bestens für die Belange des Auftraggebers geeignet sei und damit schon die Gefahr eröffnet, dass es als ei-ne Aussage im Sinne der obigen Entscheidung des OLG zu verstehen ist. Im schlimmsten Fall für den Auftragnehmer könnte dies bedeuten, dass der Auf-wand für die Anpassung der Software selbst gar nicht mehr verlangt werden kann. 37

38 5. Einzelpunkte: Migration, Pflege (Sicherung der Investition) (1) Die Besonderheit bei Projektverträgen besteht darin, dass häufig darunter nur die Softwareerstellung verstanden wird. Schon die Migration oder auch die Inbetriebnahme ist nach Auffassung mancher Auftragnehmer nicht Bestandteil eines solchen Vertrages. Damit würden praktisch die Pflichten des Auftragnehmers mit der Abnahme der Software enden (von den Mängelansprüchen des Kunden abgesehen). >>> 38

39 5. Einzelpunkte: Migration, Pflege (Sicherung der Investition) (2) Dementsprechend wird auch in vielen Fällen eine teilweise Abnahme je Stufen vorgesehen und dann soll darüber hinaus auch schon der Regelvertrag Ablieferung der Software selbst, also der Standardsoftware, laufen (weil auch schon Aktualisierungen vorgenommen werden u.ä.). Im Hinblick darauf, dass der Pflegevertrag eine Reihe von weiteren Leistungen enthält, die erst nach Abnahme virulent werden bzw. erst mit Produktivsetzung, erscheint es nicht fair, vorsichtig ausgedrückt, wenn die Vergütung des Pflegevertrages bereits ab Ablieferung der Software, wenn der Kunde noch gar nichts mit ihr anfangen kann, voll zu zahlen ist. Andererseits wird der Kunde evtl. Interesse an einem langjährigen Pflegevertrag haben. Dies sollte ausdrücklich geregelt werden, evtl. mit Sonderkündigungs- und Abfindungsregelung. 39

40 6. Typische Vertragsthemen Überblick Rahmen Projektvertrag, also evtl. gesonderte Kapitel: - Beratung, Planung - Hardware, - Wartung - Lizenz Standardsoftware - Pflege - Services. Die typische Ausgestaltung von Verträgen zur Softwareerstellung befasst sich mit Themen: Vertragsgegenstand, evtl. unter Einbeziehung von bzw. mit Hinweisen auf "Pflichtenheft", Mitwirkung Rechtseinräumung, Details zu Quellcode, Dokumentation, Verhältnis zu Onlinehilfen, Vorgehen Verfahren bei Übergabe bis zur Abnahme der Software, Phasen Sach- und Rechtsmängelhaftung Sonstige Haftung, Haftungsausschlüsse, Versicherung, Service Level und Poenalen Freistellung/Schadensersatz wegen der Rechte Dritter Geheimhaltung, Schutz des Know-how, Datenschutz Optionen, vor allem zur Pflege der Software Sonstige Regelungen, vor allem zu - - Gerichtsstand und Erfüllungsort - - Schriftform... >>> 40

41 6. Typische Vertragsthemen Klauselthemen Softwareerstellungsvertrag (2) Rahmen Projektvertrag, also evtl. gesonderte Kapitel: - Beratung, Planung - Hardware, - Wartung - Lizenz Standardsoftware -Pflege - Services. 41

42 Klauselthemen Softwareerstellungsvertrag (3) Die typische Ausgestaltung von Verträgen im Bereich der Softwareerstellung befasst sich mit den folgenden Themen: - Vertragsgegenstand, evtl. unter Einbeziehung von bzw. mit - Hinweisen auf "Pflichtenheft", "Leistungsbeschreibung" u.ä. - Terminplan, Fristen, evtl. Umstellungsregelung, - Einführungsunterstützung, - Mitwirkung Allgemein - Regelung der Rechtseinräumung, -evtl. Detailszu Quellcode, Dokumentation und deren Ausführung, Verhältnis zu Onlinehilfen, Vorgehen 42

43 Klauselthemen Softwareerstellungsvertrag (4) Verfahren bei Übergabe bis zur Abnahme der Software, Phasen - - Mitteilung der Abnahmebereitschaft, - - Durchführung von Tests, Testfälle Test Auftragnehmer, Freigabe, Tests Auftraggeber, Freigabe, - - Abnahmekriterien, - - Abnahmeverfahren, unterbrechungsfreie Mindestphase, - - Zwischenergebnisse und deren Übergabe, - - Verfahren bei Nichterreichung, 43

44 Klauselthemen Softwareerstellungsvertrag (5) Zeitplan, Fertigstellungs-/Abnahme-Termine und evtl. Folgen bei (Verzug) Evtl. Änderungen im Projektverlauf, Change Management-Verfahren (CR), Projektplanung und -Koordination und Projektleitung in Verbindung mit Mitwirkung seitens des Kunden, >>> Aktivitäten- und Fristenplan, Verfahren der Einforderung, Umfang, Folgen der Nichterbringung Vergütungsregelung, evtl. mit Vorauszahlungen nach Projektfortschritt, Sicherheiten Verfahren für die Abnahme bzw. Verfahren, wie ein Verfahren für Abnahme gefunden werden soll 44

45 Klauselthemen Softwareerstellungsvertrag (6) Sach- und Rechtsmängelhaftung Sonstige Haftung, Haftungsausschlüsse, Versicherung, Service Level und Poenalen Freistellung/Schadensersatz wegen der Rechte Dritter Geheimhaltung, Schutz des Know-how, Datenschutz Optionen, vor allem zur Pflege der Software Sonstige Regelungen, vor allem zu - - Gerichtsstand und Erfüllungsort - - Schriftform - - Versuch der Einigung bei Streit u.ä. - - Geltungserhaltung - - Bei AGB v.a. noch Abwehrklauseln Evtl. Schieds- oder Schlichtungsklauseln, Mediation 45

46 ENDE 46